Arch Linux: Systemhärtung und Sicherheit – Best Practices

Arch Linux: Systemhärtung und Sicherheit - Best Practices
Navigation

Nachdem du in unserem letzten Artikel zu den Best Practices und Tipps für Arch Linux die Grundlagen der täglichen Pflege gemeistert hast – von der Systemüberwachung über Backups bis hin zu ersten Sicherheitschecks wie Benutzerrechten und regelmäßigen Updates – bist du bereit für den nächsten Level. Du kennst jetzt, wie du dein Arch am Laufen hältst: Logs prüfen mit journalctl, Ressourcen mit top im Blick, Pakete mit Pacman sauber managen und sogar erste Passwortrichtlinien einrichten.

Aber ein System, das nur gepflegt wird, ohne dass du es richtig abschottest, ist wie ein Auto mit offenen Fenstern auf der Autobahn: Es fährt, aber es lädt Risiken ein. Genau hier kommt die Systemhärtung ins Spiel. In diesem Beitrag der Arch-Linux-Serie zeigen wir dir, wie du dein System – ob als flexibler Desktop oder zuverlässiger Server – gegen gängige Bedrohungen wappnest, ohne den puren Arch-Charme zu verlieren. Wir fokussieren uns auf bewährte Maßnahmen, die Stabilität boosten, Angriffsflächen minimieren und deine Daten schützen, alles praxisnah und ohne unnötigen Ballast.

Was ist Systemhärtung eigentlich?

Stell es dir vor wie das Verstärken der Mauern deines digitalen Hauses: Du optimierst Konfigurationen, deaktivierst Schwachstellen und baust Schichten auf, die Angriffe abprallen lassen. In Archs Rolling-Release-Welt, wo Updates ständig kommen, ist das essenziell – eine Lücke in einem Dienst kann schnell das Ganze kompromittieren. Was passiert hier? Du änderst nichts Grundlegendes an der Installation, sondern tweakst Dinge wie Mount-Optionen, SSH-Einstellungen oder Kernel-Parameter, um Root-Zugriffe zu erschweren und Prozesse zu isolieren. Warum machen wir das? Weil Arch minimal ist: Wenig vorinstallierter Kram bedeutet weniger Risiken, aber auch mehr Eigenverantwortung. Ein gehärtetes System läuft effizienter, verbraucht weniger Ressourcen und hält Brute-Force-Attacken oder Exploits stand – denk an reale Szenarien, wo ein offenes Port Hacker anlockt.

Achte darauf, immer mit Backups zu starten (wie du’s aus dem letzten Artikel kennst), und teste in einer VM, falls du unsicher bist. In der Praxis brauchst du das später, um dein Home-Setup vor neugierigen Nachbarn zu schützen, DevOps-Tests sicher zu halten oder sogar Compliance in semi-produktiven Umgebungen zu erfüllen.

Als Linux-Admin sparst du dir so nächtliche Panikattacken, wenn ein Update schiefgeht.

⚠️ Wichtig: Dieser Artikel richtet sich sowohl an Einsteiger mit grundlegenden Linux-Kenntnissen als auch an erfahrene Anwender, die Arch Linux sicher und zuverlässig betreiben möchten. Er versteht sich nicht als klassisches Einsteiger-Tutorial, sondern als praxisorientierter Leitfaden, der fundiertes Wissen, sinnvolle Methoden und erprobte Vorgehensweisen für den täglichen Einsatz vermittelt. Wenn du frisch bei Arch bist, frisch die Basics aus dem vorherigen Beitrag auf: sudo-Nutzung und pacman-Updates. Für Oldies: Hier teile ich Tricks aus jahrelanger Server-Pflege – von Laptops bis zu produktiven Hosts.

Praktische Relevanz:

In deinem Alltag als Power-User oder Admin macht Härtung den Unterschied zwischen „funktioniert gerade so“ und „läuft wie geschmiert„. Auf dem Desktop verhinderst du, dass Malware aus dubiosen Downloads greift; als Server-Op blockst du SSH-Brute-Forcer und DoS-Attacken. Die Maßnahmen sind skalierbar: Für den Einstieg reicht’s, unnötige Dienste zu killen und Firewalls zu setzen – das spart CPU und hält dein System clean. Später profitierst du von Tools wie AppArmor, die Prozesse isolieren und Exploits eindämmen, ohne den Workflow zu stören. Und in der DevOps-Welt? Hier wird’s zum Standard: Sichere Umgebungen für CI/CD-Pipelines oder Container, die nicht den Host killen. Das Ganze passt perfekt zu Archs Philosophie – minimal, aber mächtig. Du investierst ein Wochenende, und langfristig hast du ein System, das nicht nur up-to-date ist, sondern auch tough gegen reale Threats.

Was dich in diesem Artikel erwartet

Wir bauen schrittweise auf deinen Kenntnissen auf und gliedern uns in drei Hauptbereiche. Zuerst gehen wir grundlegende Härtungsmaßnahmen durch – Benutzerverwaltung, sichere Updates und Dateisystem-Optionen, die direkt an deine Pacman-Routinen anknüpfen. Danach folgen Netzwerk- und Firewall-Konfigurationen, um dein System nach außen abzuschotten, inklusive SSH-Härtung und sicherer Listener-Konfiguration. Abschließend schauen wir uns an, wie du Netzwerkereignisse zuverlässig überwachst und Logs filterst, damit du Angriffe früh erkennst und sauber dokumentierst.

Jeder Abschnitt erklärt nicht nur den Befehl, sondern auch den Kontext: Was passiert beim Setzen von noexec? Warum deaktivierst du Root-Login? Worauf achtest du bei IPv6-Firewalls? Und wie hilft dir Monitoring in der Praxis, z. B. um Anomalien im Netzwerk zu erkennen oder Ports zu überwachen, die plötzlich auftauchen.

💡 Info: Die fortgeschrittenen Sicherheitsmechanismen wie AppArmor, Kernel-Härtung, sysctl-Tuning, Secure-Boot-Optionen und regelmäßige Audits behandeln wir im nächsten Artikel dieser Serie. Hier konzentrieren wir uns auf die grundlegende Systemhärtung, die du in jedem Arch-Setup beherrschen solltest, bevor du in die tieferen Schichten einsteigst.

Wie gewohnt findest du im gesamten Artikel spezielle Markierungen:

💡 Tipps und Hinweise für effizientere Arbeitsweisen, z. B. smarte Workarounds für Rolling-Release-Herausforderungen.
⚠️ Warnungen und Stolperfallen, die dir Probleme ersparen, wie Risiken bei Fehlkonfigs.
🔧 Praktische Beispiele zum direkten Nachvollziehen, mit Code-Snippets und realen Szenarien.
❗ Typische Fehlerquellen und deren Lösungen, z. B. was tun, wenn ein Update die Firewall killt.
💡 Tipp: Bevor du loslegst, check mit lynis audit system (nach Installation), ob dein Basis-Setup schon Lücken hat – das gibt dir einen schnellen Overview und motiviert für die nächsten Schritte.

Arch ist eine Linux Distribution, die du formst, und Härtung macht sie unzerbrechlich. Lass uns starten – dein sichereres System ist nur ein paar Tweaks entfernt!

Grundlegende Härtungsmaßnahmen

Der Einstieg in die Sicherheit

Benutzerverwaltung und Zugriffsrechte optimieren

Du hast in der Einleitung gesehen, wie Härtung dein Arch zu einem robusten Bollwerk macht – jetzt legen wir mit den Basics los. Der erste Schritt in jeder Absicherung ist die Benutzerverwaltung: Wer hat Zugriff, auf was und wie? In Arch startest du als Root, aber das ist wie ein offenes Bankschalter – praktisch, aber riskant. Optimierte Rechte bedeuten, Root-Rechte zu minimieren, Gruppen schlau zu managen und Tools wie sudo sicher zu konfigurieren. Das reduziert die Chance, dass ein kompromittierter Account das ganze System lahmlegt.

Was passiert hier? Du verschiebst administrative Tasks von Root zu Normal-Usern, setzt Policies für Passwörter und sperrst unnötige Accounts. Warum machen wir das? Weil der Großteil der Exploits über privilegierte Zugriffe läuft – ein schwaches sudo oder offener Root-Account lädt Brute-Force ein. Achte darauf, Änderungen in /etc immer zu backupen, und teste mit id oder groups, ob alles greift. In der Praxis brauchst du das, um als Power-User deine Dev-Umgebung zu schützen oder als Admin Multi-User-Server ohne Panik zu betreiben – stell dir vor, ein Kollege loggt sich versehentlich als Root ein und löscht Logs.

Lass uns direkt in die Action springen

Zuerst checkst du deine aktuellen User und Gruppen. Arch verwendet PAM (Pluggable Authentication Modules) für Authentifizierung, was flexibel, aber konfigurierbar ist. Starte als Normal-User (nie als Root, wenn’s nicht sein muss) und sieh dir an, wer da ist.

# Deine User-ID und Gruppen anzeigen
id $USER

# Alle User auflisten
cut -d: -f1 /etc/passwd

# Gruppenmitglieder prüfen, z.B. für sudo
getent group sudo
Bash

Die Ausgabe von id zeigt etwas wie uid=1000(deinname) gid=1000(deinname) groups=1000(deinname),27(sudo),100(users) – das heißt, du bist in der sudo-Gruppe, was dir Admin-Rechte gibt, ohne Root zu sein. Was passiert? id holt Infos aus /etc/passwd und /etc/group, ohne sensible Daten preiszugeben. Warum? Es hilft, zu sehen, ob unnötige Accounts (wie alte Test-User) rumhängen, die Angreifer nutzen könnten. Achte auf UID unter 1000 – das sind System-User wie daemon oder nobody; die darfst du nie löschen.

In der Praxis scannst du das wöchentlich, um in produktiven Setups die Compliance gemäß der DSGVO (insbesondere Artikel 5 zur Datenminimierung und Artikel 32 zur Sicherheit der Verarbeitung) zu gewährleisten. Unnötige Accounts werden entfernt, da unbefugte oder nicht mehr benötigte Benutzerkonten ein Sicherheitsrisiko darstellen und gegen die Prinzipien der Datenminimierung und der Datensicherheit verstoßen.

# Einen neuen, eingeschränkten User anlegen – Beispiel für einen Gast
useradd -m -G users -s /bin/bash gastuser
passwd gastuser  # Setze ein starkes Passwort

# User löschen, falls unnötig (z.B. alter Test-Account)
userdel -r alteruser
Bash

Beim Anlegen mit useradd -m erstellst du ein Home-Verzeichnis (-m), weist Gruppen zu (-G users für Basisrechte) und setzt eine Shell. Was passiert? Der User bekommt /home/gastuser mit Standard-Rechten (755 für Verzeichnisse, 644 für Dateien), und Passwort-Setzung aktiviert den Account. Warum? Standard-User ohne sudo sind sicherer – sie können nicht Befehle ausführen wie rm -rf /. Achte darauf, nie Root als Daily-Driver zu nutzen; deaktiviere Root-Login per SSH (dazu später).

⚠️ Warnung: Beim Löschen mit userdel -r gehen Home und Mails weg – immer checken, ob Daten wichtig sind, sonst landen sie im Nirvana. Und: System-User (UID <1000) nie anfassen, sonst killst du Dienste wie Apache.

Als Nächstes kommt sudo – das Tool, das Root-Rechte deleigiert, ohne den Switch zu flippen. Standard in Arch via pacman -S sudo, aber du tweakst /etc/sudoers mit visudo (Editor, der Syntax checkt und Saves vor Fehlern schützt). Öffne es und sieh die Defaults:

# visudo aufrufen (als Root oder sudo)
sudo visudo

# In der Datei: Defaults umsetzen, z.B. Passwort-Timeout
Defaults timestamp_timeout=15  # 15 Minuten Cache für sudo

# Spezifische Regeln hinzufügen, z.B. User darf nur apt updaten
deinname ALL=(ALL) NOPASSWD: /usr/bin/pacman -Syu
Bash

Was passiert? timestamp_timeout cached sudo für 15 Minuten, damit du nicht ständig tippst; NOPASSWD erlaubt passwortlosen Aufruf für spezifische Commands. Warum? Es minimiert Tippfehler (Passwörter im History landen) und schränkt Rechte ein – deinname darf updaten, aber nicht alles rebooten. Achte auf den korrekten Syntax: Ein Komma zu viel, und sudo crasht. In der Praxis brauchst du das für Skripte – z.B. ein Backup-Skript läuft als Normal-User, ruft sudo für rsync auf, ohne Interaktion. Für Server: Gruppiere sudo-User in /etc/group und beschränke auf Gruppen.

# Gruppen editieren (manuell oder mit vigr)
sudo vigr

# Beispiel: Sudo-Gruppe hinzufügen
usermod -aG sudo deinname
Bash

Hier fügst du mit usermod -aG (append group) User zur sudo-Gruppe hinzu – -a verhindert Überschreiben anderer Gruppen. Was passiert? Der User loggt sich aus/ein, und sudo funktioniert. Warum? Gruppenmanagement skaliert besser als per-User-Regeln in sudoers. Achte darauf, nie „wheel“ oder „admin“ zu vergessen – in Arch ist „sudo“ der Standard. Praxis: In semi-produktiven Teams gibst du Devs „developers“-Gruppe mit limitiertem sudo, Admins die vollen Rechte.

💡 Tipp: Für effiziente Workflows: Integriere sudo in Aliase in ~/.bashrc, z.B. alias update='sudo pacman -Syu'. Das spart Keystrokes und passt zu Archs Speed-Fokus. Und check regelmäßig mit sudo -l deine Rechte. Der Befehl listet dir auf, was du darfst und klar, was du nicht darfst.

Nun zu den SUID-Bit-Fallen – das ist ein Stolperstein, den viele übersehen. SUID (Set User ID) lässt Dateien als Owner laufen, z.B. /usr/bin/passwd als Root, damit Normal-User Passwörter ändern können. Aber missbraucht, ist’s ein Exploit-Vektor.

# SUID-Dateien finden
find /usr/bin -perm -4000 2>/dev/null

# Typische Ausgabe: /usr/bin/passwd, /usr/bin/sudo, /usr/bin/mount
# Einen unnötigen SUID entfernen (Vorsicht!)
sudo chmod u-s /path/to/unnecessary_suid_binary
Bash

Was passiert? find -perm -4000 sucht ausführbare SUID-Bits; chmod u-s entfernt es. Warum? Viele Binaries brauchen’s nicht, und Exploits wie Dirty-COW nutzen SUID. Achte darauf, nur bekannte zu touchen – passwd und sudo bleiben! In der Praxis auditierst du das monatlich, besonders nach AUR-Installs, die SUID setzen könnten. Für Server: Deaktiviere SUID auf Mounts mit nosuid (dazu im nächsten Unterabschnitt).

Diagramm zur Veranschaulichung von Rechten-Hierarchie:

+---------------+
| Root (UID 0)  |  <- Volle Kontrolle, aber minimieren!
+-----------+---+
            |
            | sudo delegiert (temporär)
            v
+--------------------------+
| Normal-User (UID 1000+)  |  <- Täglicher Betrieb
| Gruppen: sudo, users     |     - Lesen/Schreiben in /home
+-----------+--------------+     - Admin via sudo
            |                    - Kein direktes Root
            | PAM & Policies
            v
+--------------------------+
| System-User (UID <1000)  |  <- Dienste: nobody, daemon
| z.B. apache (UID 48)     |     - Isoliert, keine Shell
+--------------------------+
Markdown

Das Diagramm zeigt die Schichten: Root oben, Normal-User mittig mit sudo-Brücke, System-User unten. Warum visualisieren? Es macht dir klar, warum du Traffic von unten nach unten hältst – ein kompromittierter apache-User greift nicht an Root, wenn Rechte tight sind.

❗ Typische Fehlerquelle: sudoers falsch editieren ohne visudo – führt zu Lockout. Lösung: Mache vorab ein Backup (sudo cp /etc/sudoers /etc/sudoers.bak), und bei Fehlern: Ins Recovery-Mode booten, Datei fixen. Ein weiterer Klassiker: User in falsche Gruppe, sudo klappt nicht. Fix: id checken, usermod -aG sudo user und danach aus/einloggen.

Zum Abschluss: Policies für Passwörter via PAM in /etc/pam.d/passwd oder /etc/security/pwquality.conf. Installier libpwquality für Checks.

# Pacman für PW-Qualität
sudo pacman -S libpwquality

# In /etc/security/pwquality.conf:
minlen = 12
dcredit = -1  # Mind. eine Ziffer
ucredit = -1  # Mind. ein Uppercase
Bash

Was passiert? Neue Passwörter müssen 12 Zeichen haben, mit Zahlen und Großbuchstaben. Warum? Schwache PW sind 80% der Breaches. Achte auf Kompatibilität – alte User updaten beim nächsten Change. In der Praxis: In Firmen erfüllt das Standards; für dich verhindert’s, dass dein PW in 5 Minuten geknackt wird.

Mit optimierten Rechten hast du die Basis gelegt – dein Arch fühlt sich schon sicherer an. Nächster Schritt: Updates sichern, um Lücken zu patchen.

Systemaktualisierungen und Paketmanagement

Mit den Rechten im Griff hast du nun ein stabiles Gerüst, auf dem dein Arch steht – jetzt sorgen wir dafür, dass es frisch und gepatcht bleibt. In Archs Rolling-Release-Welt sind Updates das Lebenselexir: Sie fixen Sicherheitslücken, aber ohne smarte Handhabung können sie auch Risiken bergen, wie manipulierte Pakete oder Sync-Probleme. Sichern des Paketmanagements bedeutet, Pacman und Mirrors zu konfigurieren, Signaturen zu prüfen und Automatisierung einzubauen, die dich vor Downtime schützt. Was passiert hier? Du tweakst /etc/pacman.conf für strenge Verifikation, wähle zuverlässige Mirrors und setzt Hooks für post-Update-Checks. Warum machen wir das? Rolling-Release bedeutet tägliche Updates, und eine gefälschte DB oder schwacher Mirror kann Malware einschleusen – Signaturen und Mirrors minimieren das. Achte darauf, nie partial Updates zu machen (z.B. nur -Sy), das bricht Dependencies. In der Praxis brauchst du das, um als DevOps-Typ deine Builds aktuell zu halten oder als Server-Admin Outages zu vermeiden – ein unpatched System ist ein offenes Tor für Exploits wie Log4Shell.

Zuerst die Basis: Pacman signiert Pakete mit GPG, um Integrität zu gewährleisten. Standardmäßig in Arch aktiviert, aber du verstärkst es. Öffne /etc/pacman.conf und check die SigLevel:

# Pacman.conf editieren (als Root)
sudo nano /etc/pacman.conf

# Stelle sicher, dass global SigLevel streng ist
SigLevel = Required DatabaseOptional
LocalFileSigLevel = Optional

# Für Repo-spezifisch, z.B. [core]
[core]
SigLevel = Required DatabaseSignature
Bash

Was passiert hier? SigLevel = Required DatabaseOptional prüft Paket-Signaturen, aber DBs optional – das ist Default, aber du änderst zu DatabaseSignature, um DBs zu signieren. Warum? Ohne DB-Signatur kann ein MITM (Man-in-the-Middle-Angriff) die Mirror-DB austauschen und dich zu fake Paketen leiten. Achte darauf, dass Keys up-to-date sind; bei Fehlern initialisiere neu. In der Praxis läuft das bei jedem pacman -Syu im Hintergrund – du merkst’s nur, wenn ein Paket ungültig ist, und es blockt den Install.

Für Server: Setze das repo-weit, um alle Syncs abzusichern.

# Keys initialisieren und populieren
sudo pacman-key --init
sudo pacman-key --populate archlinux

# Keys updaten, falls expired
sudo pacman -Sy archlinux-keyring
sudo pacman-key --refresh-keys
Bash

Diese Commands bauen den Keyring auf und laden frische Keys. Was passiert hier? --init erstellt leeren Keypool, --populate fügt Archs Master-Keys hinzu. Warum? Keys rotieren, und alte können Exploits erlauben. Achte auf Warnungen bei Refresh – wenn Keys fehlen, stoppe sofort Pacman. In der Praxis: In semi-produktiven Setups cronst du das wöchentlich, um vor Key-Expiry zu schützen.

Nun zu den Mirrors

Archs Mirrorlist in /etc/pacman.d/mirrorlist bestimmt, woher DBs und Pakete kommen. Schlechte Mirrors syncen verzögert, was zu Partial-Upgrades führt.

Generiere eine frische Liste und priorisiere schnelle, sichere:

# Mirrorlist updaten via reflector (installiere es zuerst)
sudo pacman -S reflector
sudo reflector --latest 10 --protocol https --sort rate --save /etc/pacman.d/mirrorlist

# Oder manuell: Top-Mirrors aus https://archlinux.org/mirrors/status/ kopieren
sudo pacman -Syy  # DBs mit neuer List syncen
Bash

Was passiert? reflector scannt Mirrors, wählt die 10 neuesten HTTPS (sicherer als HTTP), sortiert nach Speed und überschreibt die List. Warum? HTTPS verhindert MITM auf DB-Downloads; schnelle Mirrors reduzieren die Update-Zeit. Achte darauf, nur offizielle Mirrors zu nutzen – Drittanbieter sind risky. In der Praxis randomisierst du das monatlich mit --country Germany --shuffle, um Last zu verteilen und Single-Mirror-Angriffe zu vermeiden. Für Desktops: HTTPS-Mirrors sind essenziell, wenn du öffentliches WLAN nutzt.

💡 Tipp: Für effiziente Routinen: Füge in ~/.bashrc einen Alias hinzu, z.B. alias mirrorupdate='sudo reflector --latest 5 --sort rate --save /etc/pacman.d/mirrorlist && sudo pacman -Syy'. Das spart dir bei jedem Update den manuellen Schritt und hält deine Mirrors frisch.

AUR ist Archs Community-Repo, super für Custom-Software, aber unsicherer – PKGBUILDs können bösartig sein. Sichere es mit Helpers wie yay oder paru, die Builds in Clean-Chroots machen.

# Yay installieren (aus AUR, via git)
git clone https://aur.archlinux.org/yay.git
cd yay
makepkg -si

# Sicheres AUR-Paket bauen
yay -S --builddir /tmp/aurbuild some-aur-package
Bash

Was passiert? makepkg -si kompiliert und installiert yay; später --builddir isoliert Builds in /tmp, löscht danach. Warum? AUR-Pakete laufen Code – Chroot verhindert, dass sie dein System touchen. Achte auf PKGBUILD-Review: Öffne vor Build und check makepkg Commands. In der Praxis: Für DevOps nutzt du AUR sparsam, immer mit --review in yay, um Malware zu spotten. Typisch: Ein AUR-Skript lädt externe Sources – diff sie gegen Upstream.

Update-Flow in einem gesicherten Setup:

+-------------------+     +--------------------+
| Mirror Check      |     | Key Verification   |
| reflector -> HTTPS| --> | pacman-key refresh |  
+-------------------+     +--------------------+
         |                         |
         v                         v
+-------------------+     +--------------------+
| DB Sync           | <-- | Pacman -Syy        |
| /etc/pacman.d/... |     | SigLevel=Required  |
+-------------------+     +--------------------+
         |                          |
         +-------------+------------+
                       |
                       v
+-------------------+     +--------------------+
| Package Update    |     | Post-Hook Check    |
| pacman -Syu       | --> | paccache -r        |
| Signatures OK?    |     | Clean Cache        |
+-------------------+     +--------------------+
Markdown

Das Diagramm zeigt den sequentiellen Flow: Von Mirror-Auswahl über Verifikation zu Update und Cleanup. Warum? Es visualisiert, wie Schichten (HTTPS, Keys, Hooks) den Prozess absichern – ein Break in einer Stage stoppt alles.

Automatisierung macht’s Routine: Hooks in /etc/pacman.d/hooks/ laufen bei Events wie Updates. Erstelle einen für Post-Upgrade-Checks.

# Hook-Verzeichnis checken
ls /etc/pacman.d/hooks/

# Neuen Hook erstellen: /etc/pacman.d/hooks/update-security.hook
sudo tee /etc/pacman.d/hooks/update-security.hook > /dev/null <<EOF
[Trigger]
Operation = Upgrade
Type = Package
Target = *

[Action]
Description = Sicherheits-Check nach Update
When = PostTransaction
Exec = /usr/bin/lynis audit system --quick  # Oder dein Skript
EOF

# Lynis für Audits installieren
sudo pacman -S lynis
Bash

Was passiert? Der Hook triggert nach jedem Upgrade (PostTransaction), läuft lynis für einen Quick-Audit. Warum? Updates können Lücken öffnen – Lynis scannt auf bekannte Issues. Achte darauf, Exec-Skripts ausführbar zu machen (chmod +x). In der Praxis cronst du pacman -Syu täglich auf Servern: crontab -e mit 0 2 * * * /usr/bin/lockrun -l /tmp/pacman.lock -- pacman -Syu --noconfirm. Aber: Nie auf Desktops blind, da Rolling-Release Konflikte braucht manuelle Fixes.

Cache-Management verhindert Bloat: Pacman cached Downloads in /var/cache/pacman/pkg/, was Speicher frisst.

# Unnötige Pakete entfernen
sudo pacman -Sc  # Nur ungenutzte

# Oder aggressiv: Alles clearen
sudo pacman -Scc

# Besser: paccache für Versions-Kontrolle
sudo pacman -S pacman-contrib
paccache -r  # Behalte 3 Versionen pro Paket
paccache -ruk0  # Unnötige komplett löschen
Bash

Was passiert? -Sc removed deinstalliert Packages; paccache -r behält 3 alte Versionen für Rollbacks. Warum? Cache >10GB ist üblich, aber alte Versionen helfen bei Breaks. Achte auf -u für uninstalled – es löscht Orphans. Praxis: Hook es post-Update, um Disk lean zu halten; für Server spart’s I/O bei schnellen SSDs.

⚠️ Warnung: Partial Syncs wie pacman -Sy ohne -u führen zu Dependency-Hell – immer full -Syu. Und: Bei Key-Fehlern nie --lsign ohne Verifikation, das öffnet Türen für Fake-Keys.
❗ Typische Fehlerquelle: Mirror out-of-sync verursacht "database not compatible" – Lösung: pacman -Syyu für Force-Sync und Upgrade. Ein weiterer: AUR ohne Clean-Build installiert Malware. Fix: Immer makepkg --nobuild + inspect, dann build.

Mit gesichertem Paketflow patchst du Lücken blitzschnell – dein Arch bleibt nicht nur aktuell, sondern vertrauenswürdig. Als Nächstes widmen wir uns mit dem Thema: Dateisysteme härten, um Exploits auf Mount-Level zu blocken.

Dateisystem- und Partitionssicherheit

Mit gepatchten Paketen im System hast du nun die Software-Seite abgedeckt – jetzt drehen wir uns zu den Speichern um, wo Daten ruhen und Exploits lauern. Dateisystem- und Partitionssicherheit geht um smarte Mounts und Verschlüsselung, um sensible Bereiche wie /tmp oder /home vor Missbrauch zu schützen. In Arch, wo du alles selbst konfigurierst, setzt du Optionen wie noexec oder LUKS, um Ausführung zu blocken und Daten zu verschleiern. Was passiert hier? Du editierst /etc/fstab für restriktive Mounts und setupst verschlüsselte Volumes, die beim Boot entschlüsselt werden. Warum machen wir das? Offene Partitionen erlauben Skripte, die Binaries aus /tmp laden, oder Angreifer, die Daten snatchen – Verschlüsselung und Flags machen das zunichte. Achte darauf, Boot-Änderungen zu testen (z.B. mit mount -o remount), und hab ein Live-USB parat für Recovery. In der Praxis brauchst du das, um als Power-User deine privaten Daten zu sichern oder als Server-Admin Compliance zu wahren – ein kompromittierter Mount kann Logs oder Keys ausspucken, aber gehärtet hält’s stand.

Fang mit den Mount-Optionen an

In /etc/fstab definierst du, wie Partitionen hängen, und fügst Flags wie noexec, nosuid und nodev hinzu. noexec verhindert Code-Ausführung, nosuid blockt SUID-Bits (die Root-Rechte geben), nodev stoppt Device-Files (die Hardware simulieren). Ideal für /tmp, /var oder /home – aber nicht für /usr, wo Binaries laufen müssen.

# Aktuelle Mounts checken
mount | grep ' / '

# fstab editieren
sudo nano /etc/fstab

# Beispiel-Einträge hinzufügen/ändern, z.B. für /tmp als tmpfs (RAM-basiert)
tmpfs   /tmp    tmpfs   defaults,noexec,nosuid,nodev,mode=1777,size=2G   0 0

# Für /home (auf ext4-Partition /dev/sda3)
UUID=abcd1234    /home   ext4    defaults,noexec,nosuid,nodev     0 2

# Remount testen, ohne Reboot
sudo mount -o remount /home
Bash

Was passiert? tmpfs mountet /tmp in RAM (flüchtig, sicher), mit Flags, die Ausführung und Privilegien killen; size=2G limitiert auf 2GB. Für /home blockst du Exec auf User-Files. Warum? /tmp ist world-writable – ohne noexec laden Malware Binaries; nosuid verhindert Escalation. Achte darauf, UUIDs statt Labels zu nutzen (via blkid checken), und mode=1777 für sticky Bits (nur Owner löscht). In der Praxis mountest du /var/tmp ähnlich, um Logs vor Exploits zu schützen; für Desktops hält’s Downloads clean, ohne dass Viren ausführt werden können.

# UUIDs für Partitionen holen
sudo blkid /dev/sda3  # Zeigt UUID für /home

# Partition neu mounten und Flags prüfen
sudo mount -o remount,noexec /home
mount | grep home  # Sollte noexec zeigen
Bash

Diese Commands validieren Änderungen live. Was passiert? blkid spuckt UUIDs für fstab; remount wendet Flags ohne Umhang. Warum? Falsche UUIDs booten nicht – teste immer. Achte auf nodev für USB-Mounts, um rogue Devices zu blocken. Praxis: Auf Servern setzt du das für /var/log, um DoS (Denial of Service) durch volle Disks zu mildern; als User verhindert es, dass ein Sketchy-Skript aus Downloads greift.

⚠️ Warnung: noexec auf /boot oder /usr killt den Boot – lass Exec da, wo Binaries brauchen. Und: tmpfs frisst RAM; bei Low-Mem setz size=512M oder bleib bei Disk-Mount mit Flags.
Als nächstes LUKS-Verschlüsselung

Für sensible Partitionen wie /home oder Swap, damit Daten bei Diebstahl oder Zugriff safe sind. Arch unterstützt LUKS2 mit dm-crypt – setup beim Install oder post-factum.

# cryptsetup installieren (falls nicht da)
sudo pacman -S cryptsetup

# Neue Partition verschlüsseln, z.B. /dev/sda4 für Daten
sudo cryptsetup luksFormat /dev/sda4  # Passwort setzen, stark!

# Öffnen und Mapping
sudo cryptsetup open /dev/sda4 encrypted_data
sudo mkfs.ext4 /dev/mapper/encrypted_data
sudo mount /dev/mapper/encrypted_data /mnt/data

# In fstab eintragen
echo ' /dev/mapper/encrypted_data /mnt/data ext4 defaults 0 2' | sudo tee -a /etc/fstab

# Initramfs updaten für Boot-Unterstützung
sudo nano /etc/mkinitcpio.conf  # HOOKS: ... block encrypt filesystems ...
sudo mkinitcpio -P
Bash

Was passiert? luksFormat initialisiert LUKS-Container mit Passwort; open mapped zu /dev/mapper, formatiert und mountet. fstab macht’s persistent; mkinitcpio integriert für Boot-Decrypt. Warum? Klartext-Daten sind easy zu lesen – LUKS verschleiert mit AES, schützt vor Offline-Attacken. Achte auf ein starkes Passwort (mind. 20 Zeichen, Diceware), und backup Header mit cryptsetup luksHeaderBackup. In der Praxis cryptest du /home für Laptops (anti-Theft); Servern Swap, um Keys im RAM zu schützen.

Für automatisches Decrypt mit Keyfile (weniger Typing, aber sicherer Ort):

# Keyfile generieren
sudo dd if=/dev/urandom of=/etc/luks_keyfile bs=4096 count=1
sudo chmod 600 /etc/luks_keyfile
sudo cryptsetup luksAddKey /dev/sda4 /etc/luks_keyfile  # Alt-PW eingeben

# In crypttab für Auto-Open
echo 'encrypted_data UUID=abcd1234 /etc/luks_keyfile luks' | sudo tee -a /etc/crypttab

# Initramfs refresh
sudo mkinitcpio -P
Bash

Was passiert? dd macht random Keyfile; luksAddKey addet als Slot; crypttab mapped beim Boot. Warum? Passwort-Typing nervt – Keyfile auf separater Partition (z.B. USB) ist safer. Achte darauf, Keyfile zu sichern (backup offsite). Praxis: In Dev-Setups cryptest du Volumes für Secrets; vermeid USB für Production, da physisch stehlbar.

Partitionstabelle vor/nach Härtung:

Vor Härtung: Offen und riskant
+-------------------+
| /dev/sda1 (EFI)   |  <- boot,ef
+-----------+-------+
            |
            | /dev/sda2 (/)    ext4 defaults
            v
+-------------------+  
| /dev/sda3 (/home) |  <- Klartext, exec ok
+-------------------+    ext4 defaults,rw
         |
         v
+-------------------+
| Daten-Partition   |  <- /dev/sda4 (data) ext4 rw
+-------------------+

Nach Härtung: Geschützt und restricted

+-------------------+
| /dev/sda1 (EFI)   |  <- noexec,nosuid,nodev
+-----------+-------+
            |
            | /dev/sda2 (/)    ext4 defaults
            v
+-------------------+
| /dev/sda3 (/home) |  <- /tmp als tmpfs noexec
+-------------------+  ext4 noexec,nosuid,nodev
         |
         v
+---------------+ 
| LUKS Header   |  <- LUKS-Wrapper
+---------------+  Passwort/Keyfile
         |
         v
+-------------------+
| encrypted_data    |  <- Inner: ext4 defaults
+-------------------+
Markdown

Das Diagramm kontrastiert: Vorher offen, danach mit Flags und LUKS-Layer. Warum? Es zeigt, wie Schichten (Mount-Flags außen, Crypto innen) Exploits abfangen – ein Angreifer sieht nur verschleierte Daten.

💡 Tipp: Für dynamische Mounts nutz systemd-tmpfiles für volatile /tmp – edit /etc/tmpfiles.d/tmp.conf mit d /tmp 1777 root root - und systemd-tmpfiles --create. Spart Disk und boostet Speed in RAM.

💡 Tipp: Für dynamische Mounts nutz systemd-tmpfiles für volatile /tmp – edit /etc/tmpfiles.d/tmp.conf mit d /tmp 1777 root root - und systemd-tmpfiles --create. Spart Disk und boostet Speed in RAM.
❗ Typische Fehlerquelle: fstab-Typo bootet nicht (Kernel Panic). Lösung: Boot mit Arch-ISO, chroot und fix (mount -a testen vor Save). Ein weiterer: LUKS-PW vergessen – Header-Backup restore mit cryptsetup luksHeaderRestore, dann retry.

Zusätzlich: Sysctl für FS-Schutz in /etc/sysctl.d/50-security.conf.

# Sysctl-Conf erstellen
sudo tee /etc/sysctl.d/50-security.conf > /dev/null <<EOF
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
fs.protected_fifos = 2
fs.protected_regular = 2
EOF

# Apply
sudo sysctl --system
Bash

Was passiert? Diese Flags blocken Hardlinks/Symlinks in world-writable Dirs wie /tmp, verhindern Privilege-Escalation. Warum? Symlinks können Root-Files faken. Achte auf Wert 2 für strict Mode. Praxis: Essentiell für Multi-User, stoppt TOCTOU-Exploits.

Mit diesen Tweaks sind deine Speicher ein Fort – Daten safe, Ausführung kontrolliert. Als nächstes widmen wir uns dem abschotten vom Netzwerk, um den Traffic zu managen.

Netzwerk- und Firewall-Konfiguration

Abschottung nach außen

Grundlagen der Netzwerksicherheit

Deine Speicher sind jetzt ein Bunker, der Daten und Ausführungen kontrolliert – aber dein Netzwerk ist die Tür, durch die Traffic rein- und rausfließt, und in Arch musst du die selbst verbarrikadieren. Grundlagen der Netzwerksicherheit drehen sich um das Verständnis, wie dein System mit dem Netz kommuniziert, unnötige Dienste abschaltest und Tools wie SSH oder NetworkManager richtig einrichtest. In Arch, das minimal startet, ohne fertige Firewall oder Manager, baust du das von Grund auf: Entscheide zwischen systemd-networkd für Server oder NetworkManager für Desktops, und härte SSH, um Brute-Force abzuwehren.

Was passiert hier? Du konfigurierst Interfaces, deaktivierst unnötige Listener und setzt klare Policies, die ausschließlich erforderlichen Traffic zulassen. Warum machen wir das? Das Netzwerk ist einer der häufigsten Einstiegspunkte für Angreifer: Offene Ports werden automatisiert gescannt, und in einem Rolling-Release-System kann ein Update unbeabsichtigt neue Dienste aktivieren oder Ports freigeben.

Achte darauf, regelmäßig mit ss -tuln zu prüfen, welche Dienste lauschen, und halte ein Backup deiner Netzwerk-Konfigurationen bereit. In der Praxis brauchst du das, um als DevOps-Interessierter sichere Remote-Sessions zu gewährleisten oder als Power-User in öffentlichen WLANs nicht unnötig Angriffsfläche zu bieten. Ein gehärtetes Netzwerk reduziert automatisierte Scans, verhindert ungewollte Zugriffe und hält Dienste wie Web

Lass uns mit den Basics starten

Archs Netzwerk-Setup ist flexibel, aber du wählst basierend auf Use-Case. Für Server eignet sich systemd-networkd – leicht, daemon-less und integriert mit systemd. Für Desktops eignet sich der NetworkManager, er ist GUI-freundlich und handhabt LAN, WLAN wie auch VPN. Beide minimieren Overhead, aber du musst unnötige Dienste killen, um Ports zu schließen.

# Offene Ports und Listener checken
ss -tuln | grep LISTEN

# Typische Ausgabe: tcp LISTEN 0 128 0.0.0.0:22 0.0.0.0:*  (SSH auf Port 22)
# Wenn unnötig, z.B. Avahi (mDNS) deaktivieren
sudo systemctl disable --now avahi-daemon
sudo systemctl mask avahi-daemon
Bash

Was passiert? ss -tuln listet TCP/UDP-Listener mit IPs und PIDs – greifbarer als netstat. systemctl disable stoppt und maskiert Dienste wie Avahi, das Bonjour/Multicast macht, aber Ports wie 5353 öffnet und Discovery-Angriffe einlädt. Warum? Jeder Listener ist eine Angriffsfläche – in Home-Netzen unnötig, auf Servern ein No-Go. Achte darauf, PIDs zu notieren und mit ps aux | grep PID zu verifizieren, bevor du sie killst. In der Praxis führst du den Check wöchentlich aus, um nach Updates neue Listener zu entdecken; auf Desktops deaktivierst du zudem Bluetooth-Discovery (über bluetooth.service), um unnötiges Tracking zu verhindern.

Nun die Wahl: systemd-networkd vs. NetworkManager. systemd-networkd ist für statische Setups ideal, konfiguriert via /etc/systemd/network/.

Installier es, falls nicht da.

# systemd-networkd aktivieren (für Server)
sudo pacman -S systemd  # Meist schon da
sudo systemctl enable --now systemd-networkd
sudo systemctl enable --now systemd-resolved  # Für DNS

# Beispiel-Konfig: /etc/systemd/network/20-wired.network für Ethernet
sudo tee /etc/systemd/network/20-wired.network > /dev/null <<EOF
[Match]
Name=enp0s3

[Network]
Address=192.168.1.100/24
Gateway=192.168.1.1
DNS=8.8.8.8
EOF

# Reload und Status
sudo systemctl restart systemd-networkd
networkctl status
Bash

Was passiert? Die .network-Datei matched Interface (z.B. enp0s3 via ip link), setzt IP, Gateway und DNS. networkctl status zeigt den aktuellen Status. Warum? Es ist deklarativ – keine daemons wie dhcpcd, die Ports öffnen. Achte auf Match-Namen (via ip link show), und für DHCP: Füge [DHCP] Yes hinzu. In der Praxis nutzt du das für headless Server: Statische IPs verhindern IP-Konflikte, und resolved handhabt /etc/resolv.conf sicher. Für Failover: Füge DNS=1.1.1.1 8.8.8.8 für Redundanz.

Für Desktop-Systeme ist der NetworkManager die sinnvollste Wahl. Er bietet eine stabile Verwaltung für LAN, WLAN, VPNs und mobile Verbindungen und lässt sich mit dem nm-applet komfortabel per GUI steuern.

# NetworkManager installieren und aktivieren
sudo pacman -S networkmanager
sudo systemctl enable --now NetworkManager

# GUI-Tool für Connections
nm-connection-editor  # Oder via nm-applet in DE

# CLI: Connection hinzufügen, z.B. Wired
nmcli con add type ethernet con-name "Wired" ifname enp0s3 autoconnect yes
nmcli con mod "Wired" ipv4.method manual ipv4.addresses 192.168.1.100/24 ipv4.gateway 192.168.1.1 ipv4.dns 8.8.8.8

# Status checken
nmcli device status
nmcli con show
Bash

Was passiert? nmcli con add erstellt Connections; mod setzt Params. device status zeigt up/down. Warum? Es managed dynamisch – WiFi scannt SSIDs, VPN integriert OpenVPN oder Wireguard ohne Extra-Setup. Achte auf autoconnect yes, um Drops zu vermeiden, und deaktiviere IPv6, falls unnötig (ipv6.method ignore). In der Praxis: Als User connectest du via nmcli dev wifi list und nmcli dev wifi connect SSID pw PASS – super für Laptops in Cafés. Für Security: Setze nmcli con mod "Wired" connection.autoconnect-retries 0, um endless Loops zu stoppen.

💡 Tipp: In gemischten Setups (z.B. Server mit GUI): Kombiniere – systemd-networkd für wired, NetworkManager für wireless. Und integriere firewall Hooks: Nach Connect nmcli con mod ID dispatcher.d /path/to/script für auto-Firewall-Updates.

Die Härtung von SSH ist essenziell, da es dein zentraler Remote-Zugang ist. Die Standardkonfiguration ist jedoch unsicher: Root-Login ist erlaubt, Passwort-Authentifizierung aktiv und der Dienst lauscht auf Port 22. Passe daher die Datei /etc/ssh/sshd_config an, um den Zugriff gezielt zu schützen.

# SSH installieren (falls nicht)
sudo pacman -S openssh

# Config editieren
sudo nano /etc/ssh/sshd_config

# Wichtige Änderungen:
Port 2222  # Nicht 22, um Scanner zu umgehen
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AllowUsers deinname  # Nur spezifische User
MaxAuthTries 3
LoginGraceTime 30
ClientAliveInterval 300
ClientAliveCountMax 2

# Reload SSH
sudo systemctl restart sshd
Bash

Was passiert? Port 2222 ändert Listener; PermitRootLogin no blockt Root; PasswordAuthentication no forced Keys. AllowUsers limitiert Logins. Warum? Port 22 wird permanent gescannt – egal ob Desktop oder Server – Port 2222 reduziert Noise; Keys sind bruteforce-resistent (ECDSA/Ed25519). Achte auf Backup der Config, und teste mit ssh -p 2222 deinname@ip von einem anderem Host. In der Praxis generierst du Keys: ssh-keygen -t ed25519 -C "deinmail", kopierst mit ssh-copy-id -p 2222 deinname@ip – kein Passwort mehr nötig.

Für Server: Füge Match Group admins für Gruppen-Limits.

# SSH-Key generieren und deployen
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519 -C "admin@host"
ssh-copy-id -i ~/.ssh/id_ed25519.pub -p 2222 deinname@192.168.1.100

# Authorized_keys sichern
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
Bash

Was passiert? ssh-keygen macht Pair; ssh-copy-id appendet Pubkey zu ~/.ssh/authorized_keys. Das setzen von korrekten chmod verhindern Lesen. Warum? Schwache Permissions leak Keys. Achte auf -t ed25519 – schneller und sicherer als RSA. Praxis: In Teams verteilst du Keys via Ansible, und revokierst mit ssh-keygen -R host oder Edit authorized_keys.

Fail2Ban-Integration: Es banned IPs nach failed Logins, perfekt für SSH.

# Fail2Ban installieren
sudo pacman -S fail2ban

# Config für SSH: /etc/fail2ban/jail.local
sudo tee /etc/fail2ban/jail.local > /dev/null <<EOF
[sshd]
enabled = true
port = 2222
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 3600
findtime = 600
EOF

# Fail2Ban starten
sudo systemctl enable --now fail2ban
fail2ban-client status sshd
Bash

Was passiert? jail.local enabled SSH-Jail, mit 3 Retries in 10 Min, Ban für 1h. status zeigt Bans. Warum? Brute-Force scannt Ports – Fail2Ban droppt IPs dynamisch via iptables. Achte auf logpath – in Arch oft /var/log/secure oder journalctl. In der Praxis: Für Webserver addierst du Jails für Apache; check Bans mit fail2ban-client get sshd banip. Unban: fail2ban-client set sshd unbanip IP.

🔧 Praktisches Beispiel:

Stell dir vor, du setupst einen Home-Server für Git: SSH auf 2222, Keys only, Fail2Ban on. Connect von Laptop: ssh -p 2222 -i ~/.ssh/id_ed25519 git@server – sicher, passwordless. Wenn ein Bot probiert, bannt Fail2Ban nach 3 Fails, und Logs zeigen’s via journalctl -u sshd -f.

Netzwerk-Flow in Arch:

Internet (untrusted)
         |
         v
+--------------------+
|   Router/Firewall  |  <- NAT, exposes only needed ports
+----------+---------+
           |
           v
+-------------------+     +-------------------+
| Interface (enp0s3)| <-- | systemd-networkd  |  (Server: static IP)
| IP: 192.168.1.100 |     | or NetworkManager |  (Desktop: DHCP/WiFi)
+-------------------+     +-------------------+
           |                         |
           | Traffic in/out           | Manage Connections
           v                         v
+--------------------+     +--------------------+
|   SSH Listener     |     |   Ports check      |
| Port 2222, Keys    | <-- | ss -tuln           |
| Fail2Ban Bans      |     | Deaktiviere extras |
+--------------------+     +--------------------+
           |
           v
+-------------------+
|   App/Dienste     |  <- Nur allowed Traffic
| z.B. Git, Web     |
+-------------------+
Markdown

Das Diagramm zeigt den Stack: Von außen über Interface zu Manager, dann Listener mit Schutz. Warum? Es verdeutlicht, wie Layer (Manager, SSH-Härtung) Traffic filtern – untrusted Internet trifft auf controlled Ports.

UFW vs. iptables vs. nftables

Für grundlegende Setups eignet sich UFW (Uncomplicated Firewall) als einfache Oberfläche für iptables bzw. nftables. Auf Arch-Systemen empfiehlt es sich jedoch, direkt mit nftables zu arbeiten, da es moderner ist, klarere Strukturen bietet und langfristig die Standardlösung darstellt.

# UFW installieren und easy Setup
sudo pacman -S ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 2222/tcp  # SSH
sudo ufw enable
sudo ufw status verbose
Bash

Was passiert? default deny incoming droppt alles rein, allows out; allow 2222/tcp öffnet SSH. status zeigt Rules. Warum? UFW ist beginner-freundlich – „allow from 192.168.1.0/24 to any port 2222“ für LAN-only. Achte auf ufw enable Warnung – reboot-safe. In der Praxis: Für Desktops UFW für Quick-Setup; reload mit ufw reload nach Changes.

Für fortgeschritten: nftables ist seit 2020 der Standard unter Arch. Es ersetzt iptables mit einer moderneren, tabellarischen Syntax und arbeitet deutlich effizienter, da Regeln zentral verarbeitet und nicht über mehrere Tabellen verstreut werden.

# nftables installieren (oft da)
sudo pacman -S nftables
sudo systemctl enable --now nftables

# Basic Rules: /etc/nftables.conf
sudo tee /etc/nftables.conf > /dev/null <<EOF
#!/usr/sbin/nft -f
table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;
        ct state established,related accept
        iif lo accept
        tcp dport 2222 ct state new accept
        ip protocol icmp accept
        reject
    }
    chain forward { type filter hook forward priority 0; policy drop; }
    chain output { type filter hook output priority 0; policy accept; }
}
EOF

# Load und check
sudo nft -f /etc/nftables.conf
sudo nft list ruleset
Bash

Was passiert? Die Conf droppt Input default, allows established, loopback, new SSH und ICMP. nft -f lädt Rules. Warum? nft handhabt IPv4/IPv6 unified; ct state tracked Connections. Achte auf reject für polite Drops (ICMP unreachable). In der Praxis: Add tcp dport { 80, 443 } für Web; für DoS: limit rate 10/second burst 20 accept auf new States.

⚠️ Warnung: Bei SSH-Änderungen (Port, Keys) teste von anderem Host – Lockout via Console fixen. Und: Deaktiviere keine Dienste, die du brauchst, z.B. DHCP-Client (Port 68 UDP) – check mit ss post-Change.
Monitoring

Integriere Logs für Netzwerk-Events.

# rsyslog für Netzwerk-Logs konfigurieren
sudo pacman -S rsyslog
sudo systemctl enable --now rsyslog

# In /etc/rsyslog.conf: auth, cron to separate file
sudo tee -a /etc/rsyslog.conf > /dev/null <<EOF
auth,authpriv.*                 /var/log/auth.log
EOF

# Journalctl filtern für SSH
journalctl -u sshd -f
journalctl -p err -t sshd  # Errors only
Bash

Was passiert? rsyslog splittet Logs; journalctl -u tails SSH. Warum? Standard journal ist flüchtig – separate Files für Archivierung. Achte auf Rotation in /etc/logrotate.d/rsyslog. In der Praxis: Für Intrusion: grep "Failed password" /var/log/auth.log | wc -l zählt Attempts; pipe zu Fail2Ban.

❗ Typische Fehlerquelle: NetworkManager und systemd-networkd kollidieren – deaktiviere einen: systemctl disable systemd-networkd wenn NM on. Lösung: Check ps aux | grep network und Conflicts. Ein weiterer: SSH Keys nicht appended – ssh-add oder authorized_keys edit; fix mit ssh -v für Debug.

Für IPv6: Unter Arch standardmäßig aktiv, daher solltest du deine Firewall-Regeln immer für IPv4 und IPv6 gleichermaßen härten. Offene Ports gelten in beiden Protokollfamilien – eine vollständige Absicherung funktioniert nur dual.

# IPv6 disable, falls unnötig (in /etc/sysctl.d/99-ipv6.conf)
sudo tee /etc/sysctl.d/99-ipv6.conf > /dev/null <<EOF
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
EOF
sudo sysctl --system

# Oder in nftables: Add ip6 family rules
Bash

Was passiert? Sysctl deaktiviert IPv6 stack-wide. Warum? Viele Netze haben keine IPv6 – exposed Ports doppelt. Achte auf: Wenn du IPv6 brauchst, add nft table ip6 filter mit ähnlichen Rules. Praxis: In Server-Setups disable für Simplicity; Desktops check ip -6 addr und forward Rules.

Zusätzlich: TCP/IP Tuning für Security in /etc/sysctl.d/50-network.conf.

sudo tee /etc/sysctl.d/50-network.conf > /dev/null <<EOF
net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
EOF
sudo sysctl --system
Bash

Was passiert? tcp_syncookies anti-SYN-Flood; rp_filter anti-Spoofing; ICMP-Ignore blockt Smurfs. Warum? Defaults sind lax – das härte gegen DoS. Achte auf rp_filter=1 strict. Praxis: Für exposed Hosts essenziell; test mit sysctl net.ipv4.tcp_syncookies.

Mit diesen Grundlagen ist dein Netzwerk kein offenes Feld mehr, sondern ein kontrollierter Kanal – hinein kommt nur, was du ausdrücklich zulässt. Der nächste Schritt ist die detaillierte Firewall-Konfiguration, um Regeln präzise anzupassen und den Schutz weiter zu verfeinern.

Firewall mit nftables oder firewalld

Dein Netzwerk fließt jetzt kontrolliert, SSH ist gehärtet und die Listener hast du im Griff – aber ohne eine Firewall bleibt alles eine offene Brücke, über die Traffic ungehindert passieren kann. In diesem Abschnitt setzen wir deshalb eine echte Barriere davor: nftables für flexible, moderne Regelwerke oder firewalld für benutzerfreundliche Zonen. Beide Tools filtern Pakete auf Kernel-Ebene, blocken unerwünschte Verbindungen und loggen verdächtige Versuche, sodass Angriffe früh sichtbar werden.

In Arch, wo nftables der Standard ist, wählst du abhängig vom Einsatzgebiet: nftables für Server mit individuellen Regeln, firewalld für Desktop-Systeme mit dynamischen Zonen wie „home“ oder „public“.

Was passiert hier? Du definierst Chains, setzt Policies und testest eingehenden Traffic so, dass nur legitime Pakete passieren. Warum machen wir das? Offene Ports werden permanent gescannt, und ohne Filter können DoS-Versuche oder massives Port-Scanning dein System belasten. Eine klare drop-Policy eliminiert den Großteil dieses Rauschens.

Worauf solltest du achten? Sorge immer dafür, dass eine gültige Accept-Regel für SSH existiert – sonst sperrst du dich selbst aus. Halte eine lokale Konsole oder einen Fallback bereit. In der Praxis brauchst du das, um als DevOps-User API-Endpunkte zu schützen oder als Desktop-Nutzer in öffentlichen WLANs nur Web-Traffic zuzulassen. Eine gehärtete Firewall macht Nmap-Scans weitgehend wirkungslos und hält Dienste wie HTTP sauber isoliert.

Starte mit nftables, da es unter Arch die bevorzugte Lösung ist: Es ersetzt iptables mit einer tabellarischen Syntax, verarbeitet IPv4 und IPv6 einheitlich und arbeitet performanter. Die Konfiguration liegt in /etc/nftables.conf, wird beim Boot geladen und macht Regeln persistent. Für den Einstieg definierst du eine Input-Chain, setzt drop als Standard-Policy und fügst nur gezielte Ausnahmen hinzu.

# nftables aktivieren, falls nicht
sudo systemctl enable --now nftables

# Basic Konfig erstellen: /etc/nftables.conf
sudo tee /etc/nftables.conf > /dev/null <<EOF
#!/usr/sbin/nft -f
flush ruleset

table inet filter {
    chain input {
        type filter hook input priority filter; policy drop;
        comment "Accept established/related connections"
        ct state established,related accept
        comment "Accept loopback"
        iif lo accept
        comment "Accept ICMP for diagnostics"
        ip protocol icmp limit rate 5/second accept
        comment "Allow SSH on custom port"
        tcp dport 2222 accept
        comment "Allow HTTPS for updates/web"
        tcp dport { 443, 80 } accept
        comment "Reject with ICMP unreachable"
        reject with icmp type port-unreachable
    }
    chain forward {
        type filter hook forward priority filter; policy drop;
    }
    chain output {
        type filter hook output priority 0; policy accept;
    }
}
EOF

# Laden und validieren
sudo nft -f /etc/nftables.conf
sudo nft list ruleset | grep -E 'table|chain|accept|drop'
Bash

Was passiert? flush ruleset cleared alte Rules; die Input-Chain droppt default, akzeptiert bestehende Sessions (ct state), Loopback, begrenztes ICMP (anti-Spoof) und spezifische Ports. reject sendet Feedback, statt silent Drop. Warum? Policy drop blockt alles Unerwünschte; limit rate verhindert ICMP-Floods. Achte auf hook input priority filter – das ist vor anderen Modulen. In der Praxis lädst du das, dann testest mit curl example.com (sollte gehen via 443) oder nmap -p 22 localhost (sollte fehlschlagen). Für Server: Erweitere mit tcp dport 22 from 192.168.1.0/24 accept für LAN-only SSH.

Um Rules dynamisch zu managen, nutz den CLI – super für Testing oder Skripte.

# Regel hinzufügen: Temporär HTTP allow
sudo nft add rule inet filter input tcp dport 8080 accept

# Regel listen und nummerieren
sudo nft -a list chain inet filter input

# Regel löschen, z.B. handle 5 (aus -a Output)
sudo nft delete rule inet filter input handle 5

# Tabelle flushen (Vorsicht!)
sudo nft flush ruleset
Bash

Was passiert? add rule inserted eine Accept für Port 8080; -a zeigt Handles für Delete. flush wiped alles – nützlich für Resets. Warum? CLI erlaubt On-the-Fly-Changes, z.B. nach Deploy eines Web-Dienstes. Achte auf handle – es ist position-basiert, ändert sich bei Inserts. In der Praxis: Für Dev-Setups skriptest du nft add rule ... in Post-Hooks, um Ports bei Service-Start zu öffnen; check mit tcpdump -i any port 2222 ob Traffic fließt.

Port-Shielding und DoS-Schutz: Mit nftables kannst du solche Mechanismen sehr effizient umsetzen. Sets ermöglichen es, erlaubte IP-Adressen zentral zu definieren, während Rate-Limits SYN-Floods und andere volumetrische Angriffe wirkungsvoll eindämmen.

# Erweiterte Conf: /etc/nftables.conf mit Sets und Limits
# ... (bestandene input chain erweitern)

# In der input chain, nach ICMP:
comment "DoS Protection: SYN Flood limit"
tcp flags syn limit rate 10/second burst 20 accept
comment "Allowed IPs Set for SSH"
ip saddr { 192.168.1.0/24, 10.0.0.0/8 } tcp dport 2222 accept
comment "Drop rest for SSH"
tcp dport 2222 drop

# Sets definieren oben in table:
set allowed_ssh {
    type ipv4_addr;
    elements = { 192.168.1.100, 203.0.113.5 }
}
EOF

# Reload
sudo nft -f /etc/nftables.conf
sudo nft list set inet filter allowed_ssh
Bash

Was passiert? limit rate caps Syn-Pakete; set allowed_ssh limitiert SSH auf IPs. Der Drop danach schützt den Rest. Warum? Shields vor Floods (Kernel buffer overflow) und unauthorized Access. Achte auf burst 20 – erlaubt Peaks, aber throttelt. In der Praxis: Für Webserver setzt du http dport 80 limit rate 100/second anti-DoS; update Sets via nft add element inet filter allowed_ssh { 192.168.2.50 } für neue Clients.

🔧 Praktisches Beispiel:

Du hostest einen lokalen Webserver: Add tcp dport 3000 from 192.168.1.0/24 accept – nur LAN kann’s sehen. Test: Von interner IP curl localhost:3000 works; von außen telnet external_ip 3000 timeouts. Perfekt für Dev-Testing, ohne Internet-Exposer.

Nun zu firewalld – einer Alternative, wenn du mit zonenbasierten Modellen arbeitest. Firewalld ordnet Interfaces vordefinierten Zonen wie public, internal oder home zu und verwaltet darauf basierend erlaubte Dienste. Es eignet sich besonders für dynamische Setups und verwendet im Hintergrund entweder nftables oder iptables als Backend.

# firewalld installieren und starten
sudo pacman -S firewalld
sudo systemctl enable --now firewalld

# Default-Zone checken und setzen
sudo firewall-cmd --get-default-zone  # Oft public
sudo firewall-cmd --set-default-zone=internal

# Services adden: SSH und HTTP zu public
sudo firewall-cmd --permanent --zone=public --add-service=ssh
sudo firewall-cmd --permanent --zone=public --add-port=8080/tcp
sudo firewall-cmd --permanent --zone=public --add-source=192.168.1.0/24 --add-port=2222/tcp

# Interface zu Zone zuweisen
sudo firewall-cmd --permanent --zone=internal --change-interface=enp0s3

# Reload und Status
sudo firewall-cmd --reload
sudo firewall-cmd --list-all-zones
sudo firewall-cmd --info-zone=public
Bash

Was passiert? --add-service=ssh öffnet Port 22 (oder custom via --add-port=2222/tcp); --add-source limits auf Subnet. --change-interface assigned enp0s3 zu internal (trusted). reload applied permanent Changes. Warum? Zonen trennen Traffic: Public für WLAN (restrictive), internal für Ethernet (open). Achte auf --permanent – ohne speichert’s nicht. In der Praxis: Für Laptops switchst du Zonen via firewall-cmd --zone=public --change-interface=wlan0; list mit --get-active-zones zeigt aktive.

Für DoS in firewalld: Nutz Rich-Rules für Limits.

# Rich Rule für Rate-Limit auf SSH
sudo firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" destination address="0.0.0.0/0" port protocol="tcp" port="2222" accept limit value="5/m"'

# Für IP-Bans dynamisch
sudo firewall-cmd --permanent --zone=public --add-source=203.0.113.99 --remove-service=ssh  # Block IP

# Reload
sudo firewall-cmd --reload
sudo firewall-cmd --list-rich-rules
Bash

Was passiert? Die Rich-Rule limits SSH zu 5/Min; --add-source --remove-service blocks spezifische IP. Warum? Einfacher als nft für Per-Service-Limits. Achte auf family="ipv4" für IPv6 separate. In der Praxis: Kombiniere mit Fail2Ban – firewalld Hooks ban IPs automatisch; check Logs mit journalctl -u firewalld.

Firewall-Architektur mit nftables:

Incoming Traffic (Internet/LAN)
         |
         v
+-------------------+
| Kernel Netfilter  |  <- Hooks: Input (prerouting -> forward -> postrouting)
| Hooks (priority)  |
+-------------------+
         |
         | Packet Inspection
         v
+--------------------+      +-------------------+
| Table: inet filter |      | Chain: input      |
| (IPv4/IPv6 unified)| <--  | Policy: drop      |
+--------------------+      | - ct state accept |
                            | - lo accept       |
         |                  | - ICMP limit      |
         v                  | - SSH 2222 accept |
+-------------------+       | - HTTP 80/443     |
| Chain: forward    |       | - reject rest     |
| Policy: drop      |       +-------------------+
| (No forwarding)   |
+-------------------+
         |
         v
+--------------------+
| Output Chain       |  <- Allow all outgoing
| Policy: accept     |
+--------------------+
         |
         v
Outgoing Traffic (OK)
Markdown

Das Diagramm skizziert den Flow: Traffic trifft Hooks, geht durch Table/Chain-Checks. Warum? Zeigt, wie Policy und Rules Pakete filtern – Input droppt 90%, Output passt für Responses.

Ein weiteres für firewalld Zonen:

Interface Traffic
     | Wired (enp0s3)     WLAN (wlan0)
     v                    v
+---------------+     +---------------+
| Zone: internal|     | Zone: public  |
| - Trust: high |     | - Trust: low  |
| - Services:   |     | - Services:   |
|   all open    |     |   ssh, http   |
+---------------+     +---------------+
     |                    |
     +----------+---------+
                |
                v
+---------------+
| Backend: nft/ |  <- Generates Rules
| iptables      |
+---------------+
                |
                v
Kernel Netfilter (Applied)
Markdown

Visualisiert Zonen als Layer über Backend. Warum? Macht klar, warum firewalld für Multi-Interface-Setups praktisch ist.

💡 Tipp: Für Testing: Install nmap (sudo pacman -S nmap) und scanne selbst: nmap -p 1-1000 localhost – sollte nur erlaubte Ports zeigen. Und: Integriere nft monitor trace für Live-Packet-Tracing, um Rules zu debuggen.
⚠️ Warnung: Bei Firewalld-Zone-Changes: --reload kann Sessions killen – verbinde via Console. Und: Vergiss nicht Output-Policy accept, sonst keine Responses.
❗ Typische Fehlerquelle: nft Syntax-Fehler crasht Load – Lösung: nft -c -f conf checkt ohne Apply. In firewalld: Port schon offen, Dupe – fix mit firewall-cmd --remove-port zuerst. Ein Klassiker: Kein ICMP, Ping failt – add ip protocol icmp icmp type echo-request accept.

Logging für Firewalls: Füg Counters oder Logs hinzu, um Attacks zu tracken.

# nft mit Log: In input chain vor reject
log prefix "FW_DROP: " flags len=0x1 level=7

# Firewalld Log: 
sudo firewall-cmd --permanent --zone=public --add-log-denied=all
sudo firewall-cmd --reload
sudo journalctl -u firewalld | grep denied
Bash

Was passiert? log prefix logs Drops mit Tag; firewalld --add-log-denied logs alle Rejects. Warum? Siehst Attempts in Logs für Analyse. Achte auf Level 7 (debug) – produziert Volume. In der Praxis: Pipe zu SIEM oder grep für FW_DROP: tcp dport 23 (Telnet-Probes).

Schritt-für-Schritt für Webserver: 1. Base-Chain drop. 2. Add SSH. 3. Add HTTP/HTTPS mit IP-Limit. 4. Test mit curl/nmap. 5. Log und monitor. Warum? Baut Defense in Depth – Firewall + AppArmor (später).

Mit nftables oder firewalld hast du nun eine robuste Schutzschicht aufgebaut – eingehender Traffic wird kontrolliert, unnötige Verbindungen blockiert und einfache DoS-Versuche abgefedert. Im nächsten Schritt geht es darum, dein System zuverlässig zu überwachen: Monitoring und Logging, damit du sicher erkennst, was im Netzwerk passiert und wann verdächtige Ereignisse auftreten.

Monitoring und Logging

Mit der Firewall im Einsatz fließt dein Netzwerkverkehr nun kontrolliert – doch ohne Monitoring und Logging würdest du nicht erkennen, ob Angriffe stattfinden oder Fehlkonfigurationen auftreten. In diesem Abschnitt richten wir strukturierte journalctl-Filter ein, passen rsyslog für detaillierte Netzwerk-Logs an und integrieren auditd, um sicherheitsrelevante Kernel-Ereignisse zuverlässig zu erfassen. So erkennst du frühzeitig Anomalien wie unerwartete Drops, auffällige Scans oder ungewöhnliche SSH-Versuche.

Was passiert hier? Du konfigurierst die Log-Dienste, filterst relevante Ereignisse heraus und ergänzt dein System um einfache Intrusion-Detection-Mechanismen, die sicherheitsrelevante Aktionen sichtbar machen. Warum machen wir das? Eine Firewall blockiert zwar unerwünschten Traffic, doch ohne Logs erkennst du nicht, wer anklopft, welche Ports angesprochen werden oder warum Pakete verworfen wurden. Monitoring verwandelt reines Reagieren in vorbeugende Sicherheit.

Worauf solltest du achten? Halte das Logvolumen unter Kontrolle, setze sinnvolle Rotation und Größenlimits und sichere kritische Log-Dateien, damit sie bei vollem Speicher nicht verloren gehen. In der Praxis brauchst du das, um als Server-Admin automatisierte Tagesreports zu erzeugen oder als Desktop-Nutzer Port-Scans, SSH-Probes oder ungewöhnliche Netzwerkaktivitäten sichtbar zu machen. Monitoring wird damit zu einem zentralen Bestandteil der Systemhärtung, der potenzielle Angriffe erkennt, bevor sie sich auswirken.

Fang mit journalctl an – Archs Default-Logger via systemd, der alles in binäre Journals packt, persistent unter /var/log/journal. Filter für Netzwerk: Greif auf Units wie sshd, nftables oder NetworkManager zu, um Events zu isolieren.

# Journal-Persistenz sicherstellen (falls nicht)
sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald

# SSH-Logs filtern: Letzte Fehlversuche
journalctl -u sshd -p err -S today | grep "Failed password\|Invalid user"

# Netzwerk-Status in Echtzeit
journalctl -u NetworkManager -f | grep -i "connect\|disconnect"

# Firewall-Drops via nftables logs (wenn enabled)
journalctl -t kernel | grep "NFLOG\|FW_DROP"
Bash

Was passiert? --create setupt persistente Journals; -u sshd -p err zeigt Errors seit heute, greift nach Auth-Fails; -f tails live für NetworkManager. Kernel-Filter holt NFT-Drops, wenn du Logs in der Conf hast. Warum? Binäre Logs sind effizient, aber Filter machen’s lesbar – du siehst, ob ein Login von fremder IP kam. Achte auf -S today für Zeitspannen, und rotate mit journalctl --vacuum-time=2weeks für Space. In der Praxis: Als DevOps pipe das in ein Skript: journalctl -u sshd --since "1 hour ago" | wc -l zählt Attempts; über 10? Alert via Mail. Für Home: Checkt nach WLAN-Drops in öffentlichen Spots.

Erweitere mit rsyslog: Es splittet systemd-Journals in textbasierte Files, leichter zu parsen oder zu shippen. Install und tweak für Netzwerk-spezifische Channels.

# rsyslog installieren und aktivieren
sudo pacman -S rsyslog
sudo systemctl enable --now rsyslog

# Config für Netzwerk-Logs: /etc/rsyslog.conf erweitern
sudo tee -a /etc/rsyslog.conf > /dev/null <<EOF

# Netzwerk und Auth separate
auth,authpriv.*                 /var/log/auth.log
kern.*                          /var/log/kern.log
daemon.*                        /var/log/daemon.log

# NFTables und Netzwerk
:programname, isequal, "nft"    /var/log/nftables.log
if $programname == "NetworkManager" then /var/log/network.log
& stop

# Rotation Template
$IncludeConfig /etc/rsyslog.d/*.conf
EOF

# rsyslog.conf reload und Test-Log
sudo systemctl restart rsyslog
logger -t testnet "Test Netzwerk Event"
tail -f /var/log/daemon.log | grep testnet
Bash

Was passiert? Die Rules routen Auth zu auth.log, Kernel zu kern.log; program-spezifisch NFT und NM zu eigenen Files. logger simuliert Entry; tail zeigt’s. Warum? Text-Logs sind grep-freundlich – suche nach „iptables denied“ in kern.log. Achte auf $IncludeConfig für Drops; setz in /etc/logrotate.d/rsyslog size 100M für Rotation. In der Praxis: Für Server shippe auth.log via rsysys remote (*.* @logserver:514), um zentrale Analyse zu haben; lokal: grep "Failed" /var/log/auth.log | mail -s "SSH Alert" admin@domain.

Für tiefere Intrusion-Detection: auditd, das Kernel-Audits trackt – file access, syscalls, Netzwerk-Calls. Es loggt in /var/log/audit/audit.log, parst mit ausearch.

# auditd installieren und starten
sudo pacman -S audit
sudo systemctl enable --now auditd

# Rules für Netzwerk: /etc/audit/rules.d/audit.rules
sudo tee /etc/audit/rules.d/network.rules > /dev/null <<EOF
# Netzwerk-Syscalls tracken
-a always,exit -F arch=b64 -S connect -k network_connect
-a always,exit -F arch=b64 -S bind -k network_bind
-w /etc/ssh/sshd_config -p wa -k ssh_config
-w /proc/net/arp -p wa -k arp_changes

# Firewall-Config Watches
-w /etc/nftables.conf -p wa -k nft_config
-w /etc/firewalld -p wa -k fw_config
EOF

# Rules laden und auditd restart
sudo augenrules --load
sudo systemctl restart auditd

# Logs checken
sudo ausearch -k network_connect -ts today | grep "syscall=connect"
sudo aureport --network -ts today
Bash

Was passiert? Rules audit connect/bind Syscalls (z.B. neue Connections), Watches sshd_config und ARP-Tab für Spoofing; -k tagt für Suche. augenrules kompiliert; ausearch filtert, aureport summarized. Warum? Zeigt, welches Programm wohin connectet – verdächtiger bind auf Port 23? Alarm. Achte auf arch=b64 für x86_64; disable unnötige Rules, da Volume hoch. In der Praxis: Für Server: ausearch -k ssh_config -p wa trackt Config-Changes; pipe zu Alert-Skript, das bei Edits mailt. Als User: Spotet Malware, die outbound connectet, z.B. nach China-IPs.

🔧 Praktisches Beispiel:

Du überwachst mit monitoring SSH: Nach Setup ausearch -k network_bind | grep sshd – siehst Binds auf 2222. Wenn Fail2Ban bannt, check tail /var/log/auth.log und aureport --auth für Korrelation: IP aus auth passt zu audit-Connect-Fails. Super, um Patterns zu sehen, z.B. 50 Attempts von einer Range – dann IP-Block via nft.

Log-Flow in einem gehärteten System:

Netzwerk Event (z.B. SSH Fail)
         |
         v
+-------------------+
| Kernel Auditd     |  <- Syscalls trackt (connect, bind)
| /var/log/audit/   |     Rules: -k network_*
+-------------------+
         |                 |
         | Audit-Logs      | Kernel Messages
         v                 v
+---------------+     +------------------+
| rsyslog Daemon|     | systemd-journald |
| /var/log/...  | <-- | /var/log/journal |
| - auth.log    |     | - -u sshd        |
| - kern.log    |     | - -p err         |
+---------------+     +------------------+
         |                 |
         +----------+------+
                    |
                    v
+---------------+     +----------------+
| Filter/Tools  |     | Alerts/Reports |
| journalctl    | <-- | ausearch       |
| grep/tail     |     | aureport       |
+---------------+     +----------------+
         |                 |
         +----------+------+
                    |
                    v
            +---------------+
            | Analysis      |
            | (Script/Mail) |
            +---------------+
Markdown

Das Diagramm zeigt den Flow: Events aus Kernel zu Loggers, dann Filter zu Insights. Warum? Verdeutlicht, wie auditd und rsyslog ergänzen – Audit tief, Journal breit; kombiniert gibts full Picture.

Für IPv6-Events: Erweitere audit mit ip6 Rules.

# IPv6-Audit in network.rules
-a always,exit -F arch=b64 -S connect -F a0=10 -k ipv6_connect  # Family 10 = IPv6

# Check
sudo ausearch -k ipv6_connect -ts recent
Bash

Was passiert? -F a0=10 filtert IPv6-Syscalls. Warum? Wenn IPv6 on, tracke separate, da Angreifer IPv6 scannen. Achte auf Family-Codes (man audit.rules). Praxis: In Dual-Stack-Setups: ausearch -k ipv6 | grep "address=fe80" spotet Link-Local-Probes.

💡 Tipp: Automatisiere mit Cron: 0 0 * * * /usr/bin/journalctl -u sshd --since yesterday | grep Fail | wc -l > /tmp/ssh_attempts; [ $(cat /tmp/ssh_attempts) -gt 20 ] && mail -s "High SSH Activity" admin@host. Oder integriere auditd mit ELK-Stack, aber in Arch einfach mit ausearch -o brief > /tmp/daily_audit.txt für Reviews.
⚠️ Warnung: Auditd kann Disk füllen – setz in /etc/audit/auditd.conf max_log_file=50 und max_log_file_action=ROTATE. Und: Log alle Events? Overkill – starte mit Key-Rules, erweitere bei Bedarf.
❗ Typische Fehlerquelle: Journal nicht persistent – Logs weg nach Reboot. Lösung: /var/log/journal setup und systemctl status systemd-journald check. In rsyslog: Syntax-Fehler in Conf crasht – fix mit rsyslogd -N1 validate. Audit: Rules nicht geladen post-Update – augenrules --check --load force.

Mit diesen Werkzeugen behältst du dein Netzwerk präzise im Blick: Du erkennst Ereignisse frühzeitig, kannst Anomalien zuverlässig identifizieren und verstehst, welche Verbindungen erlaubt oder verdächtig sind. Dein System ist damit nicht nur geschützt, sondern aktiv wachsam.

Weiterführende Ressourcen

Nachdem du die grundlegenden Schritte zur Systemhärtung umgesetzt hast, lohnt sich ein Blick auf weiterführende Quellen, um bestimmte Themen zu vertiefen oder komplexere Sicherheitsmechanismen weiter auszubauen. Die folgenden Ressourcen bieten fundierte Dokumentation, praktische Beispiele und aktuelle Best Practices rund um Firewalling, Logging, Monitoring und Arch-spezifische Sicherheitsthemen.

Offizielle Arch-Ressourcen
  • Arch Linux Wiki
    Die zentrale Referenz für alle Arch-spezifischen Themen. Besonders empfehlenswert:
  • Security – Überblick über Härtungsmaßnahmen von Benutzerverwaltung bis Kernel.
  • nftables – Beispiele zu Regeln, Sets, Logging und DoS-Schutz.
  • OpenSSH – Key-basierte Authentifizierung und Fail2Ban-Integration.
  • Audit framework – Grundlagen und Praxisbeispiele zu auditd.
    Das Wiki wird kontinuierlich aktualisiert und ist ideal für detaillierte Recherchen.
  • Arch Linux Homepage
    archlinux.org – Wichtige Hinweise zu sicherheitsrelevanten Änderungen, Schlüsselrotationen, Paketupdates und Mirror-Status. Der News-Bereich informiert früh über kritische Fixes.
  • Arch Build System (ABS)
    archlinux.org/abs – Dokumentation für das Erstellen und Prüfen eigener PKGBUILDs. Besonders hilfreich, um Risiken bei AUR-Paketen zu minimieren.
Logging- und Monitoring-Werkzeuge
Firewall und Netzwerk
Community und Foren
  • Arch Linux Forum (BBS)
    bbs.archlinux.org – Praxisnahe Lösungen, Troubleshooting und Diskussionen zu Sicherheitsfragen.
  • Reddit: /r/archlinux
    reddit.com/r/archlinux – Kurze Workarounds, Konfig-Beispiele und Community-Tipps.
  • Deutsches Arch Forum
    forum.archlinux.de – Hilfreich für deutschsprachige Nutzer, besonders bei Logging- und Netzwerk-Themen.
Weiterführende Tools, Benchmarks und Literatur
  • Lynis
    cisofy.com/lynis – Security-Auditing-Tool für regelmäßige Systembewertungen.
  • OSSEC
    ossec.net – Host-based Intrusion Detection mit Alerting und Log-Analyse.
  • CIS Benchmarks
    cisecurity.org/benchmark/linux_os – Richtlinien für sicherheitsrelevante Konfigurationen auf Linux-Systemen.
  • Fachliteratur
  • Mastering Linux Security and Hardening von Donald A. Tevault – Schwerpunkt Firewalls, Kernel und Logging.
  • Practical IoT Hacking – Nützliche Einsichten in Netzwerkangriffe und Abwehrmaßnahmen.

Diese Ressourcen bilden eine solide Grundlage, um dein Arch-System weiter zu optimieren und Sicherheitsmechanismen gezielt auszubauen. Viele der hier verlinkten Themen greifen unmittelbar in den nächsten Artikel dieser Serie hinein, in dem wir uns AppArmor, SELinux, Kernel-Härtung, sysctl-Tuning und regelmäßigen Sicherheits-Audits widmen.

Fazit

Du hast jetzt die wesentlichen Grundlagen der Systemhärtung unter Arch durchlaufen – von sauberer Benutzerverwaltung, die Root-Rechte minimiert, über Pacman-Signaturen und verschlüsselte Partitionen bis hin zu nftables-Firewalls und auditd-Regeln, die verdächtige Aktivitäten sichtbar machen. Das sind keine theoretischen Übungen, sondern erprobte Techniken aus dem Admin-Alltag, die dein Arch-System spürbar robuster gegen Brute-Force-Angriffe, DoS-Versuche und typische Exploits machen.

Warum der Aufwand? Weil Arch dir maximale Freiheit gibt – und damit auch die Verantwortung. Mit diesen Maßnahmen läuft dein System nicht nur stabiler, sondern blockiert bereits rund 90 % der üblichen Angriffsvektoren. Du weißt jetzt, wie du mit ss -tuln offene Ports prüfst, SSH auf Schlüssel-basierte Authentifizierung umstellst, Fail2Ban zur Abwehr automatisierter Scans nutzt und Logs so filterst, dass Anomalien früh auffallen. In der Praxis heißt das: Als Power-User bleibst du in öffentlichen WLANs entspannt, als DevOps-Admin schützt du deine Pipelines, und als Server-Betreiber schläfst du besser, weil deine Firewall zuverlässig den unerwünschten Traffic abfängt.

Achte darauf, diese Maßnahmen nicht als einmalige Aufgabe zu betrachten. Sicherheit ist ein fortlaufender Prozess. Lauf regelmäßig lynis audit system, prüfe Updates mit pacman -Qu, scanne dein eigenes System gelegentlich mit nmap localhost und dokumentiere wichtige Änderungen in einer Datei wie /etc/notes.txt, damit du später nachvollziehen kannst, warum bestimmte Entscheidungen getroffen wurden.

Ausblick auf den nächsten Artikel:
In „Arch Linux: Fortgeschrittene Sicherheitsfeatures und Wartung“ steigen wir tiefer ein: AppArmor und SELinux für Mandatory Access Control, Kernel-Härtung mit ASLR und restriktiven Sysctl-Parametern, GRUB-Passwörter gegen physische Angriffe, sowie erweiterte nftables-Regeln für isolierte Umgebungen und Container-Setups. Dazu kommen zentrale Log-Auswertungen für Multi-Host-Installationen, Backup-Strategien mit LUKS und rsync und regelmäßige Audits mit Tools wie checksec und OSSEC.

Der nächste Artikel baut direkt auf dem auf, was du hier umgesetzt hast – und führt dein Arch-System von „solide gehärtet“ in Richtung „langfristig wartbar, isoliert und widerstandsfähig“.

Bleib dran – dein Arch wird zum Bollwerk.

Stand: Arch Linux (Rolling Release, geprüft im November 2025)

Schlagwörter
# ArchLinux# ArchLinuxGuide# DevOps# LinuxAdmin# LinuxSecurity# Luks# SystemAdmin# SystemAdministration

Ähnliche Beiträge