SSH- und VPN-Eingangsregeln: Was die Allowlist wirklich steuert

Verfolgen Sie eine Verbindung vom Client zum Host: welchen Hook sie überquert, warum Hängen und Ablehnung verschiedene Regeln bedeuten und warum reject nie eine Policy ist.

Verbinden Sie sich einmal, bevor Sie eine Regel ändern, und notieren Sie, ob der Client hängt oder sofort abgelehnt wird. Dieser eine Unterschied sagt Ihnen, welche Entscheidung das Paket verworfen hat, und spart eine Stunde beim Lesen von Policy-Dateien. Der Rest des Wegs ist kurz: Das Paket überquert einen Hook, passt auf eine Regel und erreicht einen Listener oder nicht. Eine Allowlist ist nur Buchhaltung um diese drei Fakten.

Verfolgen Sie einen SSH-Versuch bis zum Input-Hook

Ein Client sendet ein SYN an die Adresse des Hosts auf Port 22, und der Kernel entscheidet, ob dieses Paket für einen lokalen Dienst bestimmt ist. Ist es das, läuft der Input-Pfad, und das Regelset nimmt das Paket an oder verwirft es. Stille bedeutet, dass das SYN starb, bevor der Listener es sah, während eine schnelle Ablehnung bedeutet, dass etwas mit einem Reset antwortete. Das sind verschiedene Urteile aus verschiedenen Regeln, und beides sind legitime Ergebnisse.

Prüfen Sie als Nächstes den Listener, denn keine Regel rettet einen Dienst, der nicht da ist. Führen Sie ss -ltnp aus und prüfen Sie, ob etwas an den erwarteten Port und die Adressfamilie gebunden ist, und lesen Sie dann ssh -v auf dem Client, um zu sehen, wo er stoppt.

Weiterleitung ist eine eigene Entscheidung

Auf einem VPN-Server ist der interessantere Hook forward, weil Client-Verkehr durch die Maschine geroutet statt an sie zugestellt wird. Ein Host, der nur seinen eigenen VPN-Client betreibt, braucht ein viel kleineres Regelset als einer, der Pakete anderer Leute weiterleitet. Beide Entwürfe auf einer Maschine zu mischen erzeugt Regeln, die korrekt aussehen und nichts durchlassen.

Schreiben Sie die innere Policy als eigene Frage: Welche Client-Adressen dürfen über den Tunnel welche Ziele erreichen. Behalten Sie den administrativen Pfad, etwa SSH, auf dem Input-Pfad mit eigener Quellbeschränkung. Eine großzügige forward-Regel, die während eines Tests hinzugefügt wurde, ist der klassische Defekt, der den Test überlebt, prüfen Sie deshalb nach einer Änderung das ganze Regelset statt der einen Zeile, die Sie bearbeitet haben. Den Tunnel-Listener zu öffnen ist keine Erlaubnis für jeden verbundenen Client, den Host zu administrieren.

Drop und Reject sind Aktionen, keine Policies

Die Policy einer Basiskette akzeptiert oder verwirft, und das ist die gesamte Auswahlliste, wie die nftables-Referenz festhält. Reject existiert als Regelaktion mit einer gewählten Antwort, weshalb das Schreiben als Policy sowohl auf nftables als auch auf iptables scheitert. In der Praxis gibt ein Drop dem Client keine Information, während ein Reject ihm einen Fehler gibt, mit dem er arbeiten kann.

table inet admin {
    chain input {
        type filter hook input priority filter; policy drop;
        ct state established,related accept
        ip saddr 203.0.113.0/28 tcp dport 22 accept
        udp dport 51820 accept
        icmp type { destination-unreachable, time-exceeded } accept
    }
}

Lesen Sie diese Skizze als Form einer Entscheidung und nicht als Datei zum Einfügen, denn die Adressbereiche sind Beispiele. Ein explizites Reject auf dem SSH-Port lässt einen unberechtigten Client in einer Sekunde scheitern, statt ein Timeout abzuwarten, was Ihr eigenes Debugging verkürzt. Stille schreckt beiläufiges Scannen ab und sagt einem berechtigten Nutzer überhaupt nichts. Wählen Sie pro Dienst und schreiben Sie auf warum, sonst ändert die nächste Person es zurück.

Behalten Sie den Kontrollverkehr, den Sie wirklich brauchen

Das Blockieren von sämtlichem ICMP ist eine beliebte Voreinstellung, die die Pfad-MTU-Erkennung bricht, und das Symptom ist eine Verbindung, die sich aufbaut und dann bei größeren Paketen stockt. Die Nachbarerkennung bei IPv6 hängt von eigenen ICMPv6-Typen ab, und deren Verwerfen bricht die Verbindung, bevor irgendeine TCP-Regel befragt wird. Beides gehört als benannte Abhängigkeit in die Allowlist und nicht als pauschale Erlaubnis. Eine Policy, die die Erkennung still bricht, ist schlechter als eine, die etwas Diagnoseverkehr zulässt.

Erlauben Sie die Zustände established und related für Verbindungen, die Sie selbst begonnen haben, und lassen Sie die zustandsbehaftete Engine die Antworten übernehmen. Prüfen Sie dann, ob der Antwortweg weiter außen blockiert ist, denn eine Beschränkung nur auf ausgehenden Verkehr weiter oben erzeugt genau das Timeout, das Sie dem Host anlasten wollten.

Beweisen Sie die Wiederherstellung, bevor Sie den alten Weg aufgeben

Halten Sie eine Konsolensitzung offen, wenden Sie die Änderung an und öffnen Sie eine ganz neue Verwaltungsverbindung von einem anderen Terminal. Eine bestehende Sitzung beweist nichts, denn sie kann eine Regel überleben, die jede neue Anmeldung blockiert, was sie zum überzeugendsten Fehlalarm in der Firewall-Arbeit macht. Wenn ein Überwachungssystem den Host prüft, tragen Sie dessen Quelladresse vor der Änderung ein und nicht erst nach dem ersten Alarm. Testen Sie dann ein großes und ein kleines Paket, um zu belegen, dass die Erkennung noch funktioniert.

Bei einem VPN-Dienst wiederholen Sie das von einem Client, der nie verbunden war, denn eine fortgesetzte Sitzung kann Zustand wiederverwenden, den eine frische aushandeln muss. Halten Sie das genaue Regelset fest, das bestanden hat, mit Prüfsumme oder Kopie, damit eine spätere Änderung verglichen statt geraten werden kann. Stimmen Sie sich mit dem ab, der die Regelreihenfolge besitzt, denn eine frühere Regel gewinnt still gegen die von Ihnen hinzugefügte.

Ähnliche Artikel