Odmietanie nových odchádzajúcich spojení na WAN vyzerá ako politika uzatvárajúca sa pri zlyhaní, ale je to užší prísľub, než sa zdá. Pakety patriace už existujúcim tokom jej nezodpovedajú, rovnako ako mnohé odpovede. Túto medzeru možno ľahko prehliadnuť, pretože pravidlo sa číta, akoby pokrývalo rozhranie a nie jeden stav spojenia na ňom. A čítanie zhody stavu ako rozsudku je to, čo vytvára falošný pocit uzavretia.

Stav je podmienka zhody, nie rozsudok

Sledovanie spojení klasifikuje pakety podľa toho, čo firewall už videl, nie podľa toho, čomu verí aplikácia. Tok pozorovaný v oboch smeroch je nadviazaný a jeho neskoršie pakety zostávajú nadviazané, aj keď sa trasa pod ním zmení z tunela na bežné odchádzajúce rozhranie. Odpoveď na prichádzajúce spojenie môže byť tiež nadviazaná prevádzka. Tieto pakety už nikdy nebudú nové.

Preto pravidlo obmedzené na nové spojenia nemôže dokázať, že každý chránený paket je zablokovaný. Ostatné stavy necháva na to, čo s nimi robí zvyšok sady pravidiel, a to môže byť povolenie umiestnené skôr v reťazci.

Čítajte pravidlo v jeho okolí

Široké povolenie pre nadviazanú a súvisiacu prevádzku umiestnené pred blokovaním pustí paket skôr, než sa blokovanie vôbec vyhodnotí. Odstránenie podmienky stavu z neskoršieho pravidla to nezmení, pretože vyhodnotenie sa k nemu nikdy nedostane. Výsledok určuje poradie a zhoda stavu určuje, ktoré pakety sa k tomuto poradiu dostanú.

Preskúmajte účinnú sadu pravidiel, nie súbor, ktorý ste upravili, vrátane skokov do iných reťazcov a všetkého, čo platforma generuje. Na smerovači spravovanom cez iptables výpis reťazca zobrazuje definície pravidiel a reťazce, na ktoré odkazuje, treba tiež sledovať. Natívny systém nftables vyžaduje kontrolu vlastnej sady pravidiel a priorít hákov, pretože firmware len zriedka generuje rovnaké reťazce.

Počítadlá ukazujú, ktoré pravidlo skutočne zodpovedalo, a zvyčajne sú informatívnejšie ako zachytenie paketov urobené po rozhodnutí. Pravidlo s nulovým počítadlom nebolo dosiahnuté, nech jeho pozícia naznačuje čokoľvek.

Vyjadrite zákaz nezávisle od stavu

Ak sa skupina klientov nikdy nesmie dostať na internet mimo tunela, povedzte to priamo, namiesto približovania jedným stavom. Pravidlo musí vyberať podľa zdroja, výstupu a cieľa bez závislosti od stavu spojenia a musí stáť tam, kde ho žiadne skoršie povolenie nemôže obísť. Potom administratívny prístup a výnimky pre miestnu sieť dostanú vlastné výslovné pravidlá, takže je zámer v politike viditeľný.

Voľba reject namiesto drop mení spôsob, akým zlyháva zodpovedajúca prevádzka, a nerozširuje množinu paketov, ktoré pravidlo vyberá. Odmietnuté spojenie a tiché vypršanie času sú rôzne príznaky ukazujúce na tú istú voľbu.

Politika, ktorá zámerne povoľuje odpovede na prístup iniciovaný zvonku cez WAN, je obhájiteľná. Len sa musí opísať práve tak, namiesto toho, aby sa vydávala za úplnú izoláciu iba cez tunel.

Skontrolujte, kto je v skupine naozaj

Príklad pokrýva preposielanú prevádzku IPv4 z jedného prefixu cez jedno rozhranie. Nič nehovorí o IPv6, druhom odchádzajúcom rozhraní ani o prevádzke, ktorú vytvára samotný smerovač. Smerovač pôsobiaci ako DNS rozkladač posiela svoje vlastné dotazy smerom von a tie vôbec neprechádzajú reťazcom forward.

Overte, že chránení klienti stále majú adresy v rámci zvoleného prefixu, pretože zariadenie, ktoré z neho vyšlo, je priame náhodou, nie politikou. Rozšírenie blokovania na celú LAN bez preskúmania návrhu výnimiek tiež zvyčajne odstráni vašu vlastnú administratívnu cestu.

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

Potom vyskúšajte starý tok vedľa nového. Nový pokus o spojenie a už aktívny obojsmerný prenos sa pod týmto pravidlom správajú odlišne, a len testovanie oboch ukáže, akú politiku vlastne máte.

Súvisiace články