Zum Inhalt

Fortgeschrittene Linux-Netzwerkpraxis: OpenSSH-Tunneling, nftables-Firewalls, Kerndienste & tcpdump

Erstellt: 06.11.2026  ·  Zuletzt aktualisiert: 06.11.2026  ·  Nejat Hakan

Management Summary: Sobald physische Verbindungen und IP-Routing stehen, müssen Netzwerkperimeter gehärtet und zentrale Infrastrukturdienste aufgebaut werden. Dieser Leitfaden behandelt die kryptografische OpenSSH-Serverhärtung (ED25519-Schlüssel, ProxyJump-Bastions und verschlüsselte Portweiterleitungen), zustandsbehaftete Paketfilterung im Linux-Kernel mittels nftables und ufw, lokale DHCP/DNS- und mikrosekundengenaue NTP-Dienste (dnsmasq & chrony) sowie Paketanalysen auf Leitungsebene mittels tcpdump und Berkeley Packet Filters (BPF).

  • OpenSSH-Härtung & Tunnel

    Ed25519-Public-Key-Authentifizierung erzwingen, Bastion-Hosts transparent via ProxyJump traversieren und interne Ports (-L, -R, -D) tunneln.

  • Zustandsbehaftete nftables & ufw

    Pakete direkt in Kernel-Netfilter-Hooks (prerouting, input, forward, output) mit atomaren nftables-Sets und Rate-Limits filtern.

  • DHCP, DNS & Chrony NTP

    Automatische Subnetz-Leases und lokale Namensauflösung mit dnsmasq bereitstellen und Systemuhren für Log-Konsistenz via chrony synchronisieren.

  • Wire-Level tcpdump-Analyse

    TCP-3-Wege-Handshakes (SYN, SYN-ACK, ACK), Verbindungsabbrüche (RST) und TLS-Handshakes mit latenzfreien BPF-Ausdrücken analysieren.

1. Kryptografische OpenSSH-Architektur, Bastions & Portweiterleitung

OpenSSH bildet die administrative Lebensader jedes Linux-Servers. Passwortbasierte SSH-Logins oder direkte root-Anmeldungen sollten niemals im öffentlichen Internet erreichbar sein.

Schritt 1: Ed25519-Schlüssel generieren & ~/.ssh/config einrichten

Elliptische Kurvenschlüssel des Typs Ed25519 (Curve25519) bieten überlegene Sicherheit, deterministische Signaturen und deutlich kompaktere Schlüsselgrößen im Vergleich zu älteren RSA-2048/4096-Schlüsseln:

# Datei: /opt/net-ops/generate_ssh_ed25519.sh
# Ed25519-Schlüsselpaar mit 100 KDF-Runden und starker Passphrase generieren
ssh-keygen -t ed25519 -a 100 -C "nejat@workstation-mint" -f ~/.ssh/id_ed25519_infra

# Öffentlichen Schlüssel auf den Ziel-Debian-Server übertragen
ssh-copy-id -i ~/.ssh/id_ed25519_infra.pub nejat@192.168.1.50

Visualisierung von SSH-Local-Port-Forwarding (-L) & Bastion-ProxyJump (-J)

Statt interne Datenbank-Ports (:5432) oder Administrations-Dashboards (:8080) an öffentlichen Schnittstellen freizugeben, binden wir sie auf dem Zielserver strikt an 127.0.0.1 und tunneln über eine verschlüsselte SSH-Verbindung:

%%{init: {'flowchart': {'wrappingWidth': 600}}}%%
flowchart TB
    WORK["💻 Lokale Workstation<br/>127.0.0.1:15432<br/>(psql / DBeaver Client)"]
    BAST["🏰 Bastion-Host (DMZ)<br/>203.0.113.10:22<br/>(ProxyJump -J)"]
    DBSRV["🗄️ Interner DB-Server<br/>10.10.20.11:22<br/>PostgreSQL auf 127.0.0.1:5432"]

    WORK ==>|"1. Verschlüsselter SSH-Tunnel<br/>ssh -J bastion -L 15432:..."| BAST
    BAST ==>|"2. Weitergeleiteter Kanal"| DBSRV
# Datei: ~/.ssh/config
# Globales Connection-Multiplexing (wiederverwendet bestehenden TCP/SSH-Handshake)
Host *
    ControlMaster auto
    ControlPath ~/.ssh/cm-%r@%h:%p
    ControlPersist 10m
    ServerAliveInterval 30
    ServerAliveCountMax 3
    IdentitiesOnly yes

Host bastion
    HostName 203.0.113.10
    User nejat
    Port 22
    IdentityFile ~/.ssh/id_ed25519_infra

Host db-primary
    HostName 10.10.20.11
    User nejat
    ProxyJump bastion
    IdentityFile ~/.ssh/id_ed25519_infra
    # Leitet lokalen Port 15432 automatisch an entferntes localhost:5432 weiter
    LocalForward 127.0.0.1:15432 127.0.0.1:5432

# Datei: /etc/ssh/sshd_config.d/99-hardening.conf
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey

# SSH-Zugang strikt auf autorisierte Administrationsbenutzer beschränken
AllowUsers nejat

# Moderne Verschlüsselungsverfahren, MACs und Schlüsselaustausch-Algorithmen
KexAlgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha256
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

X11Forwarding no
MaxAuthTries 3
LoginGraceTime 20

Syntax prüfen vor dem Neuladen: sudo sshd -t && sudo systemctl reload ssh

2. Zustandsbehaftete Linux-Firewalls: Kernel Netfilter, nftables & ufw

Unter Debian 11/12+ ist nftables das native Kernel-Paketfiltersystem. Es ersetzt ältere Werkzeuge wie iptables, ip6tables, arptables und ebtables durch eine einheitliche, performante inet-Dual-Stack-Architektur (IPv4 + IPv6).

%%{init: {'flowchart': {'wrappingWidth': 600}}}%%
flowchart TB
    NIC_IN["📥 Eintreffendes Paket<br/>(NIC RX-Ring)"]
    PRE["1. Prerouting-Hook<br/>(DNAT / Port-Redirection)"]
    DEC{"Routing-Entscheidung<br/>Lokale IP oder Weiterleiten?"}
    INP["2. Input-Hook<br/>(Lokale Host-Firewall)"]
    FWD["3. Forward-Hook<br/>(Gerouteter / VM-Traffic)"]
    OUT["4. Output-Hook<br/>(Lokaler App-Ausgang)"]
    POST["5. Postrouting-Hook<br/>(SNAT / Masquerade)"]

    NIC_IN --> PRE
    PRE --> DEC
    DEC -->|"Lokale IP"| INP
    DEC -->|"Geroutete IP"| FWD
    INP --> OUT
    FWD --> POST
    OUT --> POST

Produktions-Firewall-Konfigurationen (nftables vs. ufw)

#!/usr/bin/env nft -f
# Datei: /etc/nftables.conf

flush ruleset

table inet filter {
    # Rate-Limited SSH-Brute-Force-Schutzmenge
    set ssh_ratelimit {
        type ipv4_addr
        flags dynamic, timeout
        timeout 1m
    }

    chain input {
        type filter hook input priority filter; policy drop;

        # 1. Loopback-Traffic und bestehende/zugehörige Verbindungen akzeptieren
        iifname "lo" accept
        ct state vmap { established : accept, related : accept, invalid : drop }

        # 2. Essentielles ICMP und ICMPv6 Neighbor Discovery zulassen (IPv6 NDP nie blockieren!)
        ip protocol icmp icmp type { echo-request, destination-unreachable, time-exceeded } limit rate 10/second accept
        ip6 nexthdr icmpv6 icmpv6 type { echo-request, nd-neighbor-solicit, nd-router-advert, nd-neighbor-advert } accept

        # 3. SSH (Port 22) mit Ratenbegrenzung erlauben (max. 6 neue Verbindungen/Min pro IP)
        tcp dport 22 ct state new add @ssh_ratelimit { ip saddr limit rate 6/minute } accept

        # 4. HTTP/HTTPS (80/443) für Web-/Reverse-Proxy-Dienste öffnen
        tcp dport { 80, 443 } accept

        # 5. Alles andere erfassen und verwerfen
        counter drop
    }

    chain forward {
        type filter hook forward priority filter; policy drop;
    }

    chain output {
        type filter hook output priority filter; policy accept;
    }
}

Dauerhaft aktivieren: sudo nft -c -f /etc/nftables.conf && sudo systemctl enable --now nftables

# Datei: /opt/net-ops/configure_ufw_server.sh
#!/usr/bin/env bash
set -euo pipefail

# 1. Strikte Standardrichtlinien festlegen
sudo ufw default deny incoming
sudo ufw default allow outgoing

# 2. SSH mit Ratenbegrenzung und HTTPS freigeben
sudo ufw limit 22/tcp comment 'Rate-limited OpenSSH'
sudo ufw allow 80/tcp comment 'HTTP ACME / Redirect'
sudo ufw allow 443/tcp comment 'HTTPS TLS 1.3'
sudo ufw allow 443/udp comment 'HTTP/3 QUIC'

# 3. Firewall aktivieren und Status anzeigen
sudo ufw --force enable
sudo ufw status numbered

3. Zentrale Netzwerkinfrastruktur: dnsmasq (DHCP/DNS) & chrony (NTP)

Kryptografische Zeitsynchronisation mit chrony

Eine hochpräzise Systemzeit (< 1 ms Abweichung) ist essenziell für TLS-Zertifikatsvalidierung, Kerberos- und WireGuard-Handshakes, TOTP-2FA-Codes und Transaktionsreihenfolgen in verteilten Datenbanken. Unter Debian übertrifft chrony den klassischen ntpd und unterstützt Network Time Security (NTS):

# Datei: /etc/chrony/chrony.conf
# Authentifizierte NTS-Server (Network Time Security) nutzen
server time.cloudflare.com iburst nts
server nts.netnod.se iburst nts
pool 2.debian.pool.ntp.org iburst

driftfile /var/lib/chrony/chrony.drift
ntsdumpdir /var/lib/chrony
rtcsync
makestep 1.0 3

Synchronisationsgenauigkeit im Terminal prüfen:

# Datei: /opt/net-ops/verify_chrony_sync.sh
chronyc tracking
chronyc sources -v
chronyc authdata

Leichtgewichtiger VLAN-DHCP & Split-Horizon-DNS mit dnsmasq

Für isolierte Labornetze, KVM-Management-Bridges oder kleinere Zweigstellen bietet dnsmasq einen extrem schnellen All-in-One-Server für DHCP, lokale autoritative DNS-Auflösung und PXE/TFTP:

# Datei: /etc/dnsmasq.d/10-lab-subnet.conf
# Strikt an die interne Lab-Bridge binden
interface=br-lab0
bind-interfaces

# Reine Hostnamen ohne Domainpunkt niemals an Upstream-Server weiterleiten
domain-needed
bogus-priv
domain=lab.nejat-hakan.de
local=/lab.nejat-hakan.de/

# DHCP-Vergabebereich (10.10.20.100 - 10.10.20.200, 12h Lease-Dauer)
dhcp-range=10.10.20.100,10.10.20.200,255.255.255.0,12h
dhcp-option=option:router,10.10.20.1
dhcp-option=option:dns-server,10.10.20.1

# Statische MAC-zu-IP-Reservierungen
dhcp-host=52:54:00:a1:b2:c3,db-primary,10.10.20.11,infinite

4. Paketanalyse auf Leitungsebene mit tcpdump

Wenn Firewall-Logs und Anwendungs-Fehlermeldungen widersprüchlich wirken, liefern die realen Netzwerkpakete auf der Leitung die Wahrheit. Nutzen Sie tcpdump mit -nn (keine Namensauflösung während der Aufzeichnung – verhindert DNS-Rückkopplungsschleifen!) und Berkeley Packet Filters (BPF).

%%{init: {'flowchart': {'wrappingWidth': 600}}}%%
flowchart TB
    CLIENT["💻 Client-Socket<br/>(Ephemerer Port 54312)"]
    SRV["🖥️ Server-Socket<br/>(Lauschender Port 443)"]

    CLIENT -->|"1. [S] SYN (seq=0)"| SRV
    SRV -->|"2. [S.] SYN-ACK (seq=0, ack=1)"| CLIENT
    CLIENT -->|"3. [.] ACK (ack=1) -> ESTABLISHED"| SRV

Wichtige tcpdump-Befehle für die Praxis

Diagnoseziel Exakter tcpdump-Befehl Worauf in der Ausgabe zu achten ist
HTTPS- / SSH-Handshakes prüfen (SYN / RST) sudo tcpdump -i eth0 -nn -c 50 'tcp port 443 and (tcp-syn\|tcp-rst) != 0' [S] gefolgt von [S.] = Port offen und erreichbar; [S] gefolgt von [R.] = Connection refused; [S] ohne Antwort = Firewall verwirft Pakete.
Fehlgeschlagene DNS-Abfragen analysieren sudo tcpdump -i any -nn port 53 Prüfen, ob UDP/53-Anfragen das Interface verlassen und ob NXDOMAIN oder SERVFAIL zurückgemeldet wird.
ICMP-Ping & Path-MTU analysieren (Frag Needed) sudo tcpdump -i any -nn icmp or icmp6 Auf Rückmeldungen wie ICMP unreachable - need to frag (mtu 1420) bei VPN/WireGuard-Strecken achten.
Vollständiges PCAP für Wireshark aufzeichnen sudo tcpdump -i eth0 -nn -s 0 -w /tmp/capture.pcap 'host 10.10.20.11' Zeichnet vollständige Paket-Payloads (-s 0) in /tmp/capture.pcap für Offline-Analysen auf.

Nächste Schritte

Vertiefen Sie Ihr Wissen mit komplexem Kernel-Routing, VLAN-Trunking, Netzwerk-Namespaces und KVM-Netzwerksimulationen:

  • Erweitertes Routing, VLANs & Namespaces

    Policy-Based Routing, 802.1Q-VLAN-Trunks, LACP-802.3ad-Bonding, Linux-Bridges und isolierte ip netns-Namespaces.

    Zum Advanced-Leitfaden

  • KVM/QEMU-Netzwerk-Infrastrukturlabor

    Geroutete Multi-VM-DMZ- und interne Servertopologien unter Debian mit KVM/QEMU und virt-manager aufbauen.

    Zum KVM/QEMU-Labor

  • WireGuard Kernel-VPN-Server

    Hochperformante, moderne Point-to-Point- und Road-Warrior-VPN-Tunnel mit nativer WireGuard-Kernelintegration betreiben.

    Zum WireGuard-Guide