Att avvisa nya utgående anslutningar på WAN ser ut som en policy som stänger vid fel, men det är ett snävare löfte än det verkar. Paket som hör till flöden som redan finns matchar den inte, och det gör inte många svar heller. Detta gap är lätt att missa eftersom regeln läses som om den täcker gränssnittet och inte ett tillstånd på det. Och att läsa tillståndsmatchningen som en dom är det som skapar en falsk känsla av stängdhet.

Tillstånd är ett matchningsvillkor, inte en dom

Anslutningsspårning klassificerar paket efter vad brandväggen redan har sett, inte efter vad applikationen tror. Ett flöde som observeras i båda riktningarna är etablerat, och dess senare paket förblir etablerade även när vägen under det byter från en tunnel till den vanliga upplänken. Ett svar på en inkommande anslutning kan också vara etablerad trafik. Dessa paket blir aldrig nya igen.

Därför kan en regel som bara gäller nya anslutningar inte visa att varje skyddat paket blockeras. Den lämnar de andra tillstånden till vad resten av regelverket gör med dem, och det kan vara ett tillstånd som placerats tidigare i kedjan.

Läs regeln i dess omgivning

Ett brett tillstånd för etablerad och relaterad trafik placerat före blockeringen släpper igenom ett paket innan blockeringen ens utvärderas. Att ta bort tillståndsvillkoret från en senare regel ändrar inte det, eftersom utvärderingen aldrig når dit. Ordningen avgör resultatet, och tillståndsmatchningen avgör vilka paket som når den ordningen.

Granska det effektiva regelverket i stället för filen du redigerade, inklusive hopp till andra kedjor och allt som plattformen genererar. På en iptables-styrd router visar listningen av kedjan regeldefinitionerna, och kedjorna den refererar till måste också följas. Ett inbyggt nftables-system kräver granskning av sitt eget regelverk och hookprioriteringar, eftersom firmware sällan genererar identiska kedjor.

Räknare visar vilken regel som faktiskt matchade, och de är oftast mer informativa än en paketinsamling som tagits efter beslutet. En regel med räknare på noll har inte nåtts, vad dess position än antyder.

Uttryck förbudet oberoende av tillstånd

Om en grupp klienter aldrig får nå internet utanför tunneln, säg det direkt i stället för att närma sig det med ett enda tillstånd. Regeln måste välja på källa, utgång och destination utan att bero på anslutningstillstånd, och den måste stå där inget tidigare tillstånd kan kringgå den. Då får administrativ åtkomst och undantag för lokalnätet egna uttryckliga regler, så att avsikten syns i policyn.

Att välja reject i stället för drop ändrar hur den matchade trafiken misslyckas, och det utökar inte den mängd paket som regeln väljer. En avvisad anslutning och en tyst tidsgräns är olika symtom som pekar på samma val.

En policy som medvetet tillåter svar på fjärrinitierad åtkomst över WAN är försvarbar. Den måste bara beskrivas så i stället för att presenteras som fullständig isolering enbart genom tunneln.

Kontrollera vem som faktiskt finns i gruppen

Exemplet omfattar vidarebefordrad IPv4-trafik från ett prefix ut ur ett gränssnitt. Det säger ingenting om IPv6, en andra upplänk eller trafik som routern själv startar. En router som fungerar som DNS-lösare skickar sina egna uppströmsfrågor, och de passerar inte alls forward-kedjan.

Bekräfta att de skyddade klienterna fortfarande har adresser inom det valda prefixet, eftersom en enhet som flyttat ut ur det är direkt av misstag och inte enligt policy. Att utöka blockeringen till hela LAN utan att granska undantagsdesignen brukar också ta bort din egen administrativa väg.

iptables -S FORWARD
iptables -L FORWARD -v -n
cat /proc/net/nf_conntrack | grep -c ESTABLISHED

Testa sedan ett gammalt flöde bredvid ett nytt. Ett färskt anslutningsförsök och en redan aktiv dubbelriktad överföring beter sig olika under denna regel, och bara att testa båda visar vilken policy du faktiskt har.

Relaterade artiklar