SSH- en VPN-ingangsreëls: wat die toelatingslys werklik beheer

Maak een keer verbinding voordat jy ’n reël verander en let op of die kliënt hang of dadelik geweier word. Daardie enkele verskil vertel jou watter beslissing die pakkie laat val het en spaar jou ’n uur se lees van beleidlêers. Die res van die wandeling is kort: die pakkie kruis ’n haak, pas by ’n reël, en bereik ’n luisteraar of nie. ’n Toelatingslys is boekhouding rondom daardie drie feite.

Volg een SSH-poging tot by die invoerhaak

’n Kliënt stuur ’n SYN na die gasheer se adres op poort 22, en die kern besluit of daardie pakkie vir ’n plaaslike diens is. As dit so is, loop die invoerpad en die reëlversameling aanvaar die pakkie of verwerp dit. Stilte beteken die SYN het gesterf voordat die luisteraar dit ooit gesien het, terwyl ’n vinnige weiering beteken iets het met ’n reset geantwoord. Dit is verskillende uitsprake van verskillende reëls, en albei is wettige uitkomste.

Bevestig daarna die luisteraar, want geen reël kan ’n diens red wat nie daar is nie. Voer ss -ltnp uit en kyk of iets aan die poort en adresfamilie gebind is wat jy verwag, en lees dan ssh -v op die kliënt om te sien waar dit stop.

Aanstuur is ’n aparte besluit

Op ’n VPN-bediener is die interessanter haak die aanstuurhaak, want kliëntverkeer word deur die masjien gerouteer eerder as aan dit gelewer. ’n Gasheer wat net sy eie VPN-kliënt laat loop, het ’n veel kleiner reëlversameling nodig as een wat ander mense se pakkies deurstuur. Om die twee ontwerpe op een boks te meng lewer reëls wat korrek lyk en niks deurlaat nie.

Skryf die binneste beleid as sy eie vraag: watter kliëntadresse watter bestemmings deur die tonnel mag bereik. Hou die administratiewe pad, soos SSH, op die invoerpad met sy eie bronbeperking. ’n Toegeeflike aanstuurreël wat tydens toetsing bygevoeg is, is die klassieke fout wat die toets oorleef, so hersien die hele reëlversameling ná ’n verandering eerder as die een lyn wat jy geredigeer het. Om die tonnellaaier oop te maak is nie toestemming vir elke gekoppelde kliënt om die gasheer te administreer nie.

Laat val en verwerp is aksies, nie beleide nie

’n Basiskettingbeleid aanvaar of laat val, en dit is die hele lys keuses, soos die nftables-verwysing sê. Verwerping bestaan as ’n reëlaksiem met ’n gekose antwoord, en daarom misluk dit as beleid op beide nftables en iptables. In die praktyk gee ’n drop die kliënt geen inligting nie, terwyl ’n reject vir hom ’n fout gee waarop hy kan reageer.

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 daardie skets as die vorm van ’n besluit eerder as ’n lêer om te plak, want die adresreekse is voorbeelde. ’n Eksplisiete reject op die SSH-poort laat ’n ongemagtigde kliënt binne ’n sekonde misluk in plaas daarvan om ’n tydverloop uit te wag, wat jou eie ontfouting verkort. Stilte ontmoedig toevallige skandering en sê vir ’n gemagtigde gebruiker heeltemal niks. Kies per diens en skryf neer waarom, want die volgende persoon sal dit andersins terugverander.

Hou die beheerverkeer wat jy werklik nodig het

Om alle ICMP te blokkeer is ’n gewilde verstek wat pad-MTU-ontdekking breek, en die simptoom is ’n verbinding wat tot stand kom en dan op groter pakkies vassteek. Buurontdekking op IPv6 hang van sy eie ICMPv6-tipes af, en om dié te laat val breek die skakel voordat enige TCP-reël geraadpleeg word. Albei hoort in die toelatingslys as genoemde afhanklikhede eerder as as oorkoepelende toestemmings. ’n Beleid wat ontdekking stilweg breek, is slegter as een wat ’n bietjie diagnostiese verkeer toelaat.

Laat die established- en related-toestand toe vir verbindings wat jy begin het, en laat die toestandbewuste enjin die antwoorde hanteer. Bevestig dan dat die antwoordpad nie verder uit geblokkeer is nie, want ’n slegs-uitwaartse beperking stroomop produseer dieselfde tydverloop wat jy op die gasheer wou blameer.

Bewys herstel voordat jy die ou pad aftree

Hou ’n konsole-sessie oop, pas die verandering toe en maak ’n heeltemal nuwe bestuursverbinding van ’n ander terminaal oop. ’n Bestaande sessie bewys niks, want dit kan ’n reël oorleef wat elke nuwe aanmelding blokkeer, wat dit die mees oortuigende valspositief in firewall-werk maak. As ’n moniteringstelsel die gasheer nagaan, voeg sy bronadres voor die verandering by eerder as ná die eerste waarskuwing. Toets dan een groot pakkie en een klein een om te bewys dat ontdekking nog werk.

Vir ’n VPN-diens, herhaal dit vanaf ’n kliënt wat nog nooit gekoppel het nie, want ’n hervatte sessie kan toestand hergebruik wat ’n vars een moet beding. Teken die presiese reëlversameling aan wat geslaag het, met ’n kontrolesom of ’n kopie, sodat ’n latere wysiging vergelyk kan word eerder as geraai. Koördineer met wie ook al die reëlorde besit, want ’n vroeër reël wen stilweg oor die een wat jy bygevoeg het.