SSH- en VPN-ingangsregels: wat de allowlist echt bestuurt

Maak één keer verbinding voordat je een regel wijzigt en noteer of de client blijft hangen of direct wordt geweigerd. Dat ene verschil vertelt je welke beslissing het pakket heeft laten vallen en bespaart een uur beleidsbestanden lezen. De rest van de tocht is kort: het pakket kruist een hook, past bij een regel en bereikt een luisteraar of niet. Een allowlist is niet meer dan boekhouding rond die drie feiten.

Volg één SSH-poging tot de input-hook

Een client stuurt een SYN naar het adres van de host op poort 22, en de kernel beslist of dat pakket voor een lokale dienst is. Is het dat, dan loopt het inputpad en de regelset accepteert het pakket of gooit het weg. Stilte betekent dat de SYN stierf voordat de luisteraar hem zag, terwijl een snelle weigering betekent dat iets met een reset antwoordde. Dat zijn verschillende vonnissen uit verschillende regels, en beide zijn legitieme uitkomsten.

Bevestig daarna de luisteraar, want geen regel redt een dienst die er niet is. Voer ss -ltnp uit en controleer of iets aan de poort en adresfamilie gebonden is die je verwacht, en lees dan ssh -v op de client om te zien waar hij stopt.

Doorsturen is een aparte beslissing

Op een VPN-server is de interessantere hook forward, omdat clientverkeer via de machine wordt gerouteerd in plaats van eraan te worden afgeleverd. Een host die alleen zijn eigen VPN-client draait, heeft een veel kleinere regelset nodig dan een die pakketten van anderen doorstuurt. Het mengen van beide ontwerpen op één machine levert regels op die er juist uitzien en niets doorlaten.

Schrijf het interne beleid als een eigen vraag: welke clientadressen mogen via de tunnel welke bestemmingen bereiken. Houd het beheerpad, zoals SSH, op het inputpad met zijn eigen bronbeperking. Een toegeeflijke forward-regel die tijdens het testen is toegevoegd, is het klassieke defect dat de test overleeft, dus herzie na een wijziging de hele regelset in plaats van de regel die je hebt bewerkt. De luisteraar van de tunnel openzetten is geen toestemming voor elke verbonden client om de host te beheren.

Drop en reject zijn acties, geen beleid

Het beleid van een basisketen accepteert of dropt, en dat is de hele lijst keuzes, zoals de nftables-referentie zegt. Reject bestaat als regelactie met een gekozen antwoord, en daarom faalt het schrijven ervan als beleid zowel op nftables als op iptables. In de praktijk geeft een drop de client geen informatie, terwijl een reject hem een fout geeft waarop hij kan handelen.

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

Lees die schets als de vorm van een beslissing en niet als een bestand om te plakken, want de adresbereiken zijn voorbeelden. Een expliciete reject op de SSH-poort laat een onbevoegde client binnen een seconde falen in plaats van een time-out af te wachten, wat je eigen debugging verkort. Stilte ontmoedigt toevallige scans en vertelt een bevoegde gebruiker helemaal niets. Kies per dienst en schrijf op waarom, want anders draait de volgende persoon het terug.

Behoud het controleverkeer dat je echt nodig hebt

Al het ICMP blokkeren is een populaire standaardinstelling die pad-MTU-ontdekking breekt, en het symptoom is een verbinding die tot stand komt en vervolgens vastloopt op grotere pakketten. Buurontdekking op IPv6 hangt af van zijn eigen ICMPv6-typen, en die weggooien breekt de link voordat enige TCP-regel wordt geraadpleegd. Beide horen als benoemde afhankelijkheden in de allowlist en niet als algemene toestemmingen. Een beleid dat ontdekking stilzwijgend breekt, is slechter dan een dat een beetje diagnostisch verkeer toestaat.

Sta de toestanden established en related toe voor verbindingen die je zelf bent begonnen, en laat de toestandsbewuste engine de antwoorden afhandelen. Controleer daarna dat het antwoordpad verder naar buiten niet is geblokkeerd, want een beperking alleen voor uitgaand verkeer stroomopwaarts levert dezelfde time-out op die je de host wilde verwijten.

Bewijs herstel voordat je het oude pad opgeeft

Houd een consolesessie open, pas de wijziging toe en open een volledig nieuwe beheerverbinding vanaf een andere terminal. Een bestaande sessie bewijst niets, want die kan een regel overleven die elke nieuwe login blokkeert, wat hem de meest overtuigende valse positieve in firewallwerk maakt. Als een monitoringsysteem de host controleert, voeg dan het bronadres toe vóór de wijziging en niet na de eerste melding. Test daarna één groot en één klein pakket om te bewijzen dat ontdekking nog werkt.

Voor een VPN-dienst herhaal je dat vanaf een client die nooit verbonden is geweest, want een hervatte sessie kan toestand hergebruiken die een verse moet onderhandelen. Noteer de exacte regelset die slaagde, met een controlesom of een kopie, zodat een latere wijziging kan worden vergeleken in plaats van geraden. Stem af met wie de regelvolgorde bezit, want een eerdere regel wint stilzwijgend van de regel die jij toevoegde.