Ainult NEW-i lubavad tulemüürireeglid ei sulge kõiki WAN-teid

Uute väljuvate ühenduste tagasilükkamine WAN-il näib fail-closed poliitikana, kuid on kitsam lubadus, kui tundub. Juba olemasolevatesse voogudesse kuuluvad paketid ei vasta sellele, nagu ka paljud vastused. See lünk on kergesti märkamatu, sest reeglit loetakse nii, nagu kataks see liidest, mitte üht ühenduse olekut sellel. Ja oleku vastavuse lugemine otsuseks on see, mis tekitab vale tunde suletusest.

Olek on vastavustingimus, mitte otsus

Ühenduste jälgimine liigitab pakette selle järgi, mida tulemüür on juba näinud, mitte selle järgi, mida rakendus usub. Mõlemas suunas vaadeldud voog on loodud ja selle hilisemad paketid jäävad looduks ka siis, kui marsruut selle all muutub tunnelist tavaliseks ülesvooluühenduseks. Saabuvale ühendusele antud vastus võib samuti olla loodud liiklus. Need paketid ei muutu enam kunagi uuteks.

Seetõttu ei saa ainult uutele ühendustele piiratud reegel tõestada, et iga kaitstud pakett on blokeeritud. See jätab teised olekud selle hooleks, mida reeglistik nendega teeb, ja selleks võib olla varem ahelasse paigutatud lubamine.

Lugege reeglit selle ümbruses

Loodud ja seotud liikluse lai lubamine, mis on paigutatud enne blokeeringut, laseb paketi läbi enne, kui blokeeringut üldse hinnatakse. Olekutingimuse eemaldamine hilisemast reeglist ei muuda seda, sest hindamine ei jõua sinna kunagi. Tulemuse otsustab järjekord ja oleku vastavus otsustab, millised paketid sellesse järjekorda jõuavad.

Uurige kehtivat reeglistikku, mitte faili, mida muutsite, sealhulgas hüpped teistesse ahelatesse ja kõik, mida platvorm genereerib. iptablesiga hallataval ruuteril näitab ahela loendamine reeglite definitsioone ja ka ahelaid, millele see viitab, tuleb jälgida. Päris nftablesi süsteem nõuab oma reeglistiku ja konksude prioriteetide uurimist, sest püsivara genereerib harva identseid ahelaid.

Loendurid näitavad, milline reegel tegelikult vastas, ja need on tavaliselt teavetrikkamad kui pärast otsust tehtud paketipüük. Nulli loenduriga reeglini ei ole jõutud, mida iganes selle asukoht vihjab.

Väljendage keeldu olekust sõltumatult

Kui klientide rühm ei tohi kunagi jõuda internetti väljaspool tunnelit, öelge seda otse, mitte lähendage seda ühe olekuga. Reegel peab valima allika, väljundi ja sihtkoha järgi ilma ühenduse olekust sõltumata ning see peab asuma seal, kus ükski varasem lubamine ei saa sellest mööda minna. Siis saavad haldusjuurdepääs ja kohaliku võrgu erandid oma selgesõnalised reeglid, nii et kavatsus on poliitikas nähtav.

Rejecti valimine dropi asemel muudab seda, kuidas vastav liiklus ebaõnnestub, ega suurenda pakettide hulka, mille reegel valib. Tagasilükatud ühendus ja vaikne aegumine on erinevad sümptomid, mis osutavad samale valikule.

Poliitika, mis lubab teadlikult vastuseid WAN-i kaudu kaugelt algatatud juurdepääsule, on kaitstav. Seda tuleb lihtsalt nii kirjeldada, mitte esitada täieliku isolatsioonina ainult tunneli kaudu.

Kontrollige, kes rühmas tegelikult on

Näide hõlmab edastatud IPv4-liiklust ühest prefiksist ühe liidese kaudu. See ei ütle midagi IPv6, teise ülesvooluühenduse ega ruuteri enda algatatud liikluse kohta. DNS-i lahendajana tegutsev ruuter saadab oma ülesvoolu päringud ja need ei läbi forward-ahelat üldse.

Kinnitage, et kaitstud kliendid hoiavad endiselt valitud prefiksi sees olevaid aadresse, sest sealt välja liikunud seade on otsene juhuslikult, mitte poliitika järgi. Blokeeringu laiendamine kogu LAN-ile ilma erandite disaini üle vaatamata kipub ka teie enda haldustee eemaldama.

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

Seejärel proovige vana voogu uue kõrval. Värske ühenduskatse ja juba aktiivne kahesuunaline ülekanne käituvad selle reegli all erinevalt ja ainult mõlema testimine näitab, milline poliitika teil tegelikult on.