Ingångsregler för SSH och VPN: vad tillåtelselistan egentligen styr

Anslut en gång innan du ändrar en regel och notera om klienten hänger eller avvisas direkt. Den enda skillnaden berättar vilket beslut som släppte paketet och sparar en timme av att läsa policyfiler. Resten av färden är kort: paketet korsar en krok, matchar en regel och når antingen en lyssnare eller inte. En tillåtelselista är bara bokföring kring de tre fakta.

Följ ett SSH-försök till ingångskroken

En klient skickar en SYN till värdens adress på port 22, och kärnan avgör om paketet är för en lokal tjänst. Är det det körs ingångsvägen och regeluppsättningen accepterar paketet eller kastar det. Tystnad betyder att SYN dog innan lyssnaren såg det, medan ett snabbt avvisande betyder att något svarade med en återställning. Det är olika domar från olika regler, och båda är legitima utfall.

Bekräfta sedan lyssnaren, för ingen regel räddar en tjänst som inte finns. Kör ss -ltnp och kontrollera att något är bundet till porten och adressfamiljen du förväntar dig, och läs sedan ssh -v på klienten för att se var den stannar.

Vidarebefordran är ett eget beslut

På en VPN-server är den intressantare kroken forward, eftersom klienttrafik dirigeras genom maskinen i stället för att levereras till den. En värd som bara kör sin egen VPN-klient behöver en mycket mindre regeluppsättning än en som vidarebefordrar andras paket. Att blanda de två designerna på en maskin ger regler som ser korrekta ut och inte släpper igenom något.

Skriv den inre policyn som en egen fråga: vilka klientadresser som får nå vilka mål genom tunneln. Håll den administrativa vägen, till exempel SSH, på ingångsvägen med sin egen källbegränsning. En eftergivlig forward-regel som läggs till under testning är den klassiska bristen som överlever testet, så granska hela regeluppsättningen efter en ändring i stället för raden du redigerade. Att öppna tunnelslyssnaren är inte tillstånd för varje ansluten klient att administrera värden.

Drop och reject är åtgärder, inte policys

En baskedjas policy accepterar eller droppar, och det är hela listan av val, som nftables-referensen säger. Reject finns som en regelåtgärd med ett valt svar, och därför misslyckas det att skriva den som policy både på nftables och på iptables. I praktiken ger en drop klienten ingen information, medan en reject ger den ett fel som den kan agera på.

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

Läs den skissen som formen av ett beslut och inte som en fil att klistra in, eftersom adressintervallen är exempel. En explicit reject på SSH-porten får en obehörig klient att misslyckas på en sekund i stället för att vänta ut en timeout, vilket förkortar din egen felsökning. Tystnad avskräcker tillfällig skanning och säger ingenting alls till en behörig användare. Välj per tjänst och skriv ned varför, annars ändrar nästa person tillbaka det.

Behåll den kontrolltrafik du faktiskt behöver

Att blockera all ICMP är en populär standard som bryter vägens MTU-upptäckt, och symptomet är en anslutning som etableras och sedan fastnar på större paket. Grannupptäckt på IPv6 beror på sina egna ICMPv6-typer, och att kasta dem bryter länken innan någon TCP-regel hinner konsulteras. Båda hör hemma i tillåtelselistan som namngivna beroenden och inte som generella tillstånd. En policy som tyst bryter upptäckten är sämre än en som tillåter lite diagnostiktrafik.

Tillåt tillstånden established och related för anslutningar du själv startade, och låt den tillståndsmedvetna motorn hantera svaren. Bekräfta sedan att svarsvägen inte är blockerad längre ut, eftersom en begränsning enbart för utgående trafik högre upp ger samma timeout som du var på väg att skylla på värden.

Bevisa återställning innan du pensionerar den gamla vägen

Håll en konsolsession öppen, tillämpa ändringen och öppna en helt ny administrationsanslutning från en annan terminal. En befintlig session bevisar ingenting, eftersom den kan överleva en regel som blockerar varje ny inloggning, vilket gör den till den mest övertygande falska positiva i brandväggsarbete. Om ett övervakningssystem kontrollerar värden, lägg till dess källadress före ändringen och inte efter det första larmet. Testa sedan ett stort och ett litet paket för att bevisa att upptäckten fortfarande fungerar.

För en VPN-tjänst upprepas det från en klient som aldrig har anslutit, eftersom en återupptagen session kan återanvända tillstånd som en ny måste förhandla. Skriv ned den exakta regeluppsättning som passerade, med en kontrollsumma eller en kopia, så att en senare ändring kan jämföras i stället för gissas. Samordna med den som äger regelordningen, eftersom en tidigare regel tyst vinner över den du lade till.