---
id: 2025-11-15-arch-linux-systemhaertung-sicherheit-best-practices
slug: arch-linux-systemhaertung-sicherheit-best-practices
title: "Arch Linux: Systemhärtung und Sicherheit - Best Practices"
excerpt: "Systemhärtung leicht gemacht - Schritt für Schritt zu mehr Sicherheit mit Benutzerrechten, LUKS, nftables, SSH-Härtung und professionellem Monitoring."
date: "2025-11-15T09:00:00+01:00"
updated: "2025-11-15T10:00:00+01:00"
author:
  name: "Sebastian Palencsar"
  handle: "spalencsar"
category: "arch-linux-serie"
tags: ["archlinux", "archlinuxguide", "devops", "linuxadmin", "linuxsecurity", "luks", "systemadmin", "systemadministration"]
toc: true
reading_time: 48
---

Nachdem du in unserem letzten Artikel zu den [Best Practices und Tipps für Arch Linux](/de/arch-linux-serie/arch-linux-best-practices-tipps) 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](/de/arch-linux-serie/arch-linux-der-umfassende-leitfaden-vom-paketmanager-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](/de/category/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 offener Port Hacker anlockt.

Achte darauf, immer mit Backups zu starten ([wie du's aus dem letzten Artikel kennst](/de/arch-linux-serie/arch-linux-best-practices-tipps)), 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.

<blockquote class="infobox infobox--important">
  ⚠️ **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: <code>sudo</code>-Nutzung und <code>pacman</code>-Updates. **Für Oldies:** Hier teile ich Tricks aus jahrelanger Server-Pflege - von Laptops bis zu produktiven Hosts.
</blockquote>

### 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](/de/arch-linux-serie/archlinux-installation-und-grundkonfiguration), 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](/de/category/devops) 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.

<blockquote class="infobox infobox--important">
💡 **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.
</blockquote>

**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.

<blockquote class="infobox infobox--important">
💡 **Info:** 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.
</blockquote>

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.

```Bash
# 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
```

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](https://dsgvo-gesetz.de/art-5-dsgvo/) zur Datenminimierung und [Artikel 32](https://dsgvo-gesetz.de/art-32-dsgvo/) 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
```

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).

<blockquote class="infobox infobox--important">
  ⚠️ **Warnung:** </strong> Beim Löschen mit <code>userdel -r</code> werden Home‑Verzeichnisse und E‑Mails gelöscht — prüfe vorher, ob wichtige Daten vorhanden sind. System‑User (UID &lt;1000) niemals löschen, sonst können Dienste wie Apache ausfallen.
</blockquote>

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:

```Bash
# 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
```

**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
```

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.

<blockquote class="infobox infobox--important">
💡 **Info:** 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.
</blockquote>

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
```

**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:**

```Markdown
+---------------+
| 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 &lt;1000)  |  <- Dienste: nobody, daemon
| z.B. apache (UID 48)     |     - Isoliert, keine Shell
+--------------------------+
```

**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.

<blockquote class="infobox infobox--important">
❗ 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.
</blockquote>

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

```Bash
# 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
```

**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](https://en.wikipedia.org/wiki/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
```

**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](https://de.wikipedia.org/wiki/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
```

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
```

**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.

<blockquote class="infobox infobox--important">
💡 **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.
</blockquote>

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
```

**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](/de/category/devops) nutzt du [AUR](/de/arch-linux-serie/arch-linux-der-umfassende-leitfaden-vom-paketmanager-pacman) 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        |
+-------------------+     +--------------------+
```

**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
```

**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
```

**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.

<blockquote class="infobox infobox--important">
⚠️ **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.
</blockquote>

<blockquote class="infobox infobox--important">
❗ **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.
</blockquote>

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
```

**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
```

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](https://de.wikipedia.org/wiki/Denial_of_Service) (Denial of Service) durch volle Disks zu mildern; als User verhindert es, dass ein Sketchy-Skript aus Downloads greift.

<blockquote class="infobox infobox--important">
⚠️ **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.
</blockquote>

##### 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
```

**Was passiert?** `luksFormat` initialisiert LUKS-Container mit Passwort; `open` mapped zu `/dev/mapper`, formatiert und mountet. fstab macht's persistent; [mkinitcpio](https://wiki.archlinux.de/title/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
```

**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
+-------------------+
```

**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.

<blockquote class="infobox infobox--important">
💡 **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.
</blockquote>

<blockquote class="infobox infobox--important">
❗ **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.
</blockquote>

**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
```

**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](/de/category/netzwerk) drehen sich um das Verständnis, wie dein System mit dem Netz kommuniziert, unnötige Dienste abschaltest und Tools wie [SSH](https://linuxcommand.dev/?query=ssh&category=&distro=) oder [NetworkManager](/de/arch-linux-serie/archlinux-installation-und-grundkonfiguration) richtig einrichtest. In Arch, das minimal startet, ohne fertige Firewall oder Manager, baust du das von Grund auf: Entscheide zwischen [systemd-networkd](https://wiki.archlinux.de/title/Systemd/systemd-networkd) für Server oder [NetworkManager](https://wiki.archlinux.de/title/Networkmanager) für Desktops, und härte SSH, um [Brute-Force](https://sosafe-awareness.com/de/glossar/brute-force-angriff/#:~:text=Im%20Bereich%20der%20Informationssicherheit%20versteht,auf%20Systeme%20oder%20Konten%20zuzugreifen.) 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 Webserver stabil.

##### 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
```

**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
```

**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
```

**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.

<blockquote class="infobox infobox--important">
💡 **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.
</blockquote>

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
```

**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
```

**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](/de/category/devops), 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
```

**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     |
+-------------------+
```

**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
```

**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
```

**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.

<blockquote class="infobox infobox--important">
⚠️ **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.
</blockquote>

##### 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
```

**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.

<blockquote class="infobox infobox--important">
❗ **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.
</blockquote>

**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
```

**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
```

**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](https://linuxcommand.dev/?query=Nmap&category=&distro=)-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'
```

**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
```

**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 }
}

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

**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
```

**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
```

**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)
```

**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)
```

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

<blockquote class="infobox infobox--important">
**💡 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.
</blockquote>

<blockquote class="infobox infobox--important">
⚠️ **Warnung:** Bei Firewalld-Zone-Changes: `--reload` kann Sessions killen - verbinde via Console. Und: Vergiss nicht Output-Policy accept, sonst keine Responses.
</blockquote>

<blockquote class="infobox infobox--important">
❗ **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`.
</blockquote>

**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
```

**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](https://linuxcommand.dev/?query=journalctl&category=&distro=)-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](/de/linux-administration/linux-administration-systemueberwachung-und-performance-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"
```

**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
```

**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 rsyslog 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
```

**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) |
            +---------------+
```

**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
```

**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.

<blockquote class="infobox infobox--important">
💡 **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.
</blockquote>

<blockquote class="infobox infobox--important">
⚠️ **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.
</blockquote>

<blockquote class="infobox infobox--important">
❗ **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.
</blockquote>

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](https://wiki.archlinux.org/title/Security) - Überblick über Härtungsmaßnahmen von Benutzerverwaltung bis Kernel.
- [nftables](https://wiki.archlinux.org/title/Nftables) - Beispiele zu Regeln, Sets, Logging und DoS-Schutz.
- [OpenSSH](https://wiki.archlinux.org/title/OpenSSH) - Key-basierte Authentifizierung und Fail2Ban-Integration.
- [Audit framework](https://wiki.archlinux.org/title/Audit_framework) - Grundlagen und Praxisbeispiele zu auditd. Das Wiki wird kontinuierlich aktualisiert und ist ideal für detaillierte Recherchen.
- **Arch Linux Homepage**
  [archlinux.org](https://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](https://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

- **systemd-Journal**
- [journalctl Manpage](https://man.archlinux.org/man/journalctl.1) - Filtertechniken, Prioritäten, Persistenz und Forwarding.
- [systemd_journal (Wiki)](https://wiki.archlinux.org/title/Systemd_journal) - Rotation, Speicherlimits, Forwarding-Mechanismen.
- **rsyslog**
- [rsyslog.com](https://www.rsyslog.com) - Offizielle Dokumentation zu Log-Routing, Modulen und Remote-Shipping.
- [Arch Wiki zu rsyslog](https://wiki.archlinux.org/title/Rsyslog) - Speziell für Arch-basierte Setups.
- **auditd**
- [linux-audit.com](https://www.linux-audit.com) - Praxisnahe Erklärungen und Regelbeispiele.
- [auditd Manpage](https://man.archlinux.org/man/auditd.8) - Referenz für Konfiguration und Parametersyntax.

##### Firewall und Netzwerk

- **nftables**
- [Offizielle nftables-Seite](https://nftables.org) - Vollständige Syntax, Tutorials, Sets, eBPF-Beispiele.
- [Arch Wiki: nftables](https://wiki.archlinux.org/title/Nftables) - Arch-spezifische Hinweise und Konfigurationsbeispiele.
- **firewalld**
- [firewalld.org](https://firewalld.org) - Dokumentation zu Zonen, Services und Rich Rules.
- [Arch Wiki: firewalld](https://wiki.archlinux.org/title/Firewalld) - Installationshinweise und bekannte Stolperfallen.
- **Fail2Ban**
- [fail2ban.org](https://www.fail2ban.org) - Konfigurationsguides und Jail-Beispiele.
- [Arch Wiki: Fail2ban](https://wiki.archlinux.org/title/Fail2ban) - Hinweise zu SSH-Jails und nftables-Support.

##### Community und Foren

- **Arch Linux Forum (BBS)**
  [bbs.archlinux.org](https://bbs.archlinux.org) - Praxisnahe Lösungen, Troubleshooting und Diskussionen zu Sicherheitsfragen.
- **Reddit: /r/archlinux**
  [reddit.com/r/archlinux](https://reddit.com/r/archlinux) - Kurze Workarounds, Konfig-Beispiele und Community-Tipps.
- **Deutsches Arch Forum**
  [forum.archlinux.de](https://forum.archlinux.de) - Hilfreich für deutschsprachige Nutzer, besonders bei Logging- und Netzwerk-Themen.

##### Weiterführende Tools, Benchmarks und Literatur

- **Lynis**
  [cisofy.com/lynis](https://cisofy.com/lynis) - Security-Auditing-Tool für regelmäßige Systembewertungen.
- **OSSEC**
  [ossec.net](https://ossec.net) - Host-based Intrusion Detection mit Alerting und Log-Analyse.
- **CIS Benchmarks**
  [cisecurity.org/benchmark/linux_os](https://www.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)*