A tűzfal-szabály módosítása nem működik: szabálysorrend és kapcsolatállapot

Szerkesztette a szabályt, újratöltötte a szabálykészletet, és az alagút pontosan úgy viselkedik, mint korábban. Ennek az eredménynek két gyakori oka van, és különböző teszteket igényelnek. Vagy az új szabály egy korábbi szabály után áll, amely már elfogadta a csomagot, vagy a figyelt csere egy követett kapcsolat, amelyet a módosítás soha nem értékel újra. A fájlban lévő szabály szándékot fejez ki; a csomag sorsáról az az aktív útvonal dönt, amellyel találkozik. Vegye sorra az alábbi ellenőrzéseket, és közben tartson nyitva egy visszautat.

A szabálysorrend és a kapcsolatállapot két különböző hiba

A rendezett láncok felülről lefelé értékelődnek, és az első szabály, amely végleges döntésre jut, befejezi az adott láncon való végighaladást. Tegyen egy széles engedélyt egy gondosan megírt zárolási szabály fölé, és a zárolási szabály dokumentációvá válik: ott van a szabálykészletben, a számlálója nulla, és egyetlen csomag sem fogja elérni. Ugyanaz a szöveg egy másik láncra alkalmazva sem bizonyít semmit. Az nftablesben az alapláncok prioritások szerint kapcsolódnak hookokhoz, így az egyik láncban adott engedély nem akadályozza meg egy másik hookon vagy prioritáson lévő láncot abban, hogy ugyanazt a csomagot lássa.

A kapcsolatkövetés hozza létre a második tünetet, és kívülről teljesen azonosnak látszik. Amint egy folyam bekerül az állapottáblába, a lánc tetejéhez közeli established-or-related engedély visszatér, mielőtt az új szabályát egyáltalán megkérdeznék. A NAT-leképezéseknek ugyanez a tulajdonságuk: a fordítás a folyam indulásakor rögzült, ezért a szerkesztett postrouting szabály nem írja át a már futó munkamenetet. Ezért tűnik úgy, hogy a módosítás 09:00-kor működik egy új kapcsolatnál, és úgy tűnik, hogy semmit sem tesz annál a munkamenetnél, amelyet valaki 08:55-kor nyitott.

A felhő biztonsági csoportok egy harmadik modellt adnak hozzá, amely elkapja azokat, akik iptablesen tanultak. Bejövő szabályaik engedélyezési lista, amelyet halmazként értékelnek, nem első egyezés szerinti végighaladásként, állapottal rendelkeznek, és egy engedélyezési szabály eltávolítása nem szünteti meg a már követett folyamokat. Az első egyezés szemantikáját feltételezni olyan platformon, amely nem rendelkezik vele, magabiztos, hibás következtetésekhez vezet.

Az aktív szabálykészletet olvassa, ne a szerkesztett fájlt

Kezdje azzal, amit a kernel éppen kikényszerít. Egy mentett konfiguráció, amelyet soha nem alkalmaztak, meglepően sok változatlan viselkedést magyaráz, és kizárása egyetlen parancsba kerül:

nft list ruleset
iptables-save

Ezután kérdezze meg, egyáltalán elérhető-e a szabálya. A csomagszámlálók erre közvetlenül válaszolnak, és jobban válaszolnak, mint bármilyen okfejtés a szándékról:

iptables -L FORWARD -v -n --line-numbers
nft list chain inet filter forward

Egy zárolási szabály nulla csomaggal egy valódi próbálkozás után nem házirend-probléma, hanem pozícióprobléma. Áthelyezése egyetlen sor módosítása, és a szintaxis pontosan az, ami az eredeti hibát okozta. Az iptablesnél -I beszúr, a -A pedig hozzáfűz; az nftablesnél insert a lánc elejére tesz egy szabályt, a add pedig hozzáfűz. Amikor egy szabálynak győznie kell, mondja ki egyértelműen, ahelyett hogy a véletlenül betöltött sorrendre bízna.

Bizonyítsa, hogy a folyam követett-e

Mielőtt a szabályt hibáztatná, ellenőrizze, hogy a forgalom egyáltalán követett kapcsolat-e. A teljes állapottábla kiöntése helyett az adott folyamról kérdezzen:

conntrack -L -p tcp --dport 1194
conntrack -E -p tcp --dport 1194

A lista mutatja az állapotot és a hátralévő időkorlátot, és így különbözteti meg a létrejött munkamenetet egy friss kísérlettől; az eseménymód kiírja a frissítéseket, ahogy történnek, ami hasznos, miközben újracsatlakoztat egy klienst. Ha a folyam már létrejött állapotban jelen van, mielőtt bármihez hozzányúlna, a szűrőszabályok egyetlen módosítása sem változtat a sorsán. Ez nem hiba a tűzfalban, hanem az állapottal rendelkező szűrés szerződése.

Álljon ellen a kísértésnek, hogy egy éles átjárón kiürítse a teljes táblát. conntrack -F elérhető, és az összes követett folyamot is elpusztítja a gépen, beleértve azt a felügyeleti munkamenetet, amelyből dolgozik, és az alagutat, amely a shelljét szállítja. Az egyes bejegyzések törölhetők, amikor valóban szükséges, de egy új forrásportról induló friss folyam általában tisztább kísérlet.

Egyes útvonalak nem követettek, és ellenkezően viselkednek. A raw táblában notrack jelöléssel ellátott forgalom, a normál hookokat megkerülő egyes alagutak és a folyamot két átjáró között felosztó aszimmetrikus útválasztás mind olyan csomagokat eredményeznek, amelyeket egyenként értékelnek, vagy olyan állapotot, amely soha nem jön létre mindkét végén. Ha a számlálók minden csomagnál mozdulnak, gyanakodjon az ilyen útvonalra, mielőtt a sorrendre gyanakodna.

Teszteljen friss folyamból, visszauttal

Mielőtt olyan szabályt tesztel, amely elvághatja a távoli hozzáférést, alakítson ki helyreállítási útvonalat: a szolgáltató konzolját, soros konzolt, sávon kívüli felügyeleti címet vagy egy második interfészt, amelyet a szabály nem tud eltalálni. Egy visszaállítási időzítő ésszerű kísérő, mert visszaállítja az előző szabálykészletet akkor is, ha a munkamenete meghal a teszt közepén.

Utána olyan cserével teszteljen, amelyet az állapot már nem fedhetett le. Bontsa és létesítse újra a kliens kapcsolatát, hogy új ötös jöjjön létre, és figyelje mindkét véget, miközben ez történik:

tcpdump -ni eth0 'tcp port 1194'
journalctl -k -n 50 --no-pager

Futtassa a tesztet mindkét irányban. Egy szabály, amely blokkolja az új bejövő kézfogást, továbbra is engedheti a válasz útvonalát, vagy fordítva, és az egyirányú eredmény a szokásos oka annak, hogy egy zárolás félmunkát végez. A teszt után még egyszer csatlakozzon, hogy megerősítse az állandósult állapotot, és ellenőrizze, hogy a jogszerű felügyeleti hozzáférés túlélte-e; egy portra írt szabálynak megvan az a szokása, hogy a szándékosnál szélesebb tartományra illeszkedik.

Rögzítse a célt és a pozíciót a szabállyal együtt

A rögzített cél nélküli szabály olyan szabály, amelyet senki sem mer eltávolítani. Minden zárolási bejegyzés mellett tartsa meg a védett folyamot, a láncot és hookot, amelyben él, a pozíciót, amelyet a szélesebb engedélyekhez képest be kell töltenie, és a tesztet, amely ezt bizonyította. Amikor valaki hat hónappal később szerkeszti a környező szabálykészletet, ez a feljegyzés az egyetlen figyelmeztetés arra, hogy a pozíció szándékos volt.

Mielőtt lezárja a módosítást, erősítsen meg négy dolgot: a futó szabálykészlet megegyezik a fájllal, az új szabálynak friss próbálkozás után nullától eltérő számlálói vannak, a fordított irány és a felügyeleti hozzáférés továbbra is működik, és egyszer újracsatlakozott, hogy az állandósult állapotot bizonyítsa, ne egy módosítás előtti munkamenet állapotát. Ha ezek bármelyike ellenőrizetlen, a módosítás nincs kész, bármit is tesz az alagút.