A csak NEW szabályok nem zárják le az összes WAN-útvonalat
A NEW kapcsolatok elutasítása érintetlenül hagyja a létrejött folyamokat és a válaszokat. Olvassa el a conntrack-állapotot, a szabályok sorrendjét és a kivételeket, mielőtt lezártnak nevez egy szabályzatot.
Az új kimenő kapcsolatok elutasítása a WAN-on zárt hibakezelésű szabályzatnak látszik, de szűkebb ígéret annál, mint amilyennek tűnik. A már létező folyamokhoz tartozó csomagok nem illeszkednek rá, és sok válasz sem. Ezt a rést könnyű elkerülni, mert a szabály úgy olvasódik, mintha a csatolót fedné le, nem egy kapcsolatállapotot rajta. És az állapotegyezés ítéletként olvasása az, ami hamis lezártságérzetet kelt.
Az állapot egyeztetési feltétel, nem ítélet
A kapcsolatkövetés aszerint osztályozza a csomagokat, mit látott már a tűzfal, nem aszerint, mit hisz az alkalmazás. A mindkét irányban megfigyelt folyam létrejött, és későbbi csomagjai létrejöttek maradnak akkor is, amikor az alatta lévő útvonal alagútról a szokásos felfelé irányuló kapcsolatra vált. Egy bejövő kapcsolatra adott válasz is lehet létrejött forgalom. Ezek a csomagok soha nem válnak újra újja.
Ezért az új kapcsolatokra szűkített szabály nem tudja bizonyítani, hogy minden védett csomag blokkolva van. A többi állapotot meghagyja annak, amit a szabálykészlet többi része tesz velük, és az lehet egy korábban a láncba helyezett engedélyezés.
Olvassa a szabályt a környezetében
A blokk elé helyezett széles engedélyezés a létrejött és kapcsolódó forgalomra átengedi a csomagot, mielőtt a blokkot egyáltalán kiértékelnék. Az állapotfeltétel eltávolítása egy későbbi szabályból nem változtat ezen, mert a kiértékelés soha nem ér el odáig. Az eredményt a sorrend dönti el, és az állapotegyezés dönti el, mely csomagok érnek el ahhoz a sorrendhez.
A hatályos szabálykészletet vizsgálja, ne a szerkesztett fájlt, beleértve a más láncokba való ugrásokat és mindent, amit a platform generál. Egy iptables által kezelt routeren a lánc listázása megmutatja a szabálydefiníciókat, és a hivatkozott láncokat is követni kell. Egy natív nftables rendszernek a saját szabálykészletét és hook-prioritásait kell megvizsgálnia, mert a firmware ritkán generál azonos láncokat.
A számlálók megmondják, melyik szabály illeszkedett valójában, és általában többet árulnak el, mint a döntés után készült csomagrögzítés. Egy nulla számlálójú szabályhoz nem értek el, bármit sugall is a helyzete.
Az állapottól függetlenül fejezze ki a tilalmat
Ha egy ügyfélcsoport soha nem érheti el az internetet az alagúton kívül, mondja ki egyenesen, ahelyett hogy egyetlen állapottal közelítené. A szabálynak forrás, kimenet és cél szerint kell választania a kapcsolatállapottól függetlenül, és ott kell állnia, ahol semmilyen korábbi engedélyezés nem kerülheti meg. Ekkor a kezelési hozzáférés és a helyi hálózat kivételei saját kifejezett szabályokat kapnak, így a szándék látható a szabályzatban.
A drop helyett reject választása megváltoztatja, hogyan hiúsul meg az illeszkedő forgalom, és nem bővíti a szabály által kiválasztott csomagok halmazát. Az elutasított kapcsolat és a csendes időtúllépés különböző tünetek, amelyek ugyanarra a választásra mutatnak.
Védhető az a szabályzat, amely szándékosan engedélyezi a WAN-on át távolról kezdeményezett hozzáférésre adott válaszokat. Csak így kell leírni, ahelyett hogy teljes, kizárólag alagúton át való elkülönítésként mutatná be.
Ellenőrizze, ki van valójában a csoportban
A példa egy előtagból egy csatolón kimenő továbbított IPv4-forgalmat fed le. Nem mond semmit az IPv6-ról, egy második felfelé irányuló kapcsolatról vagy a router által maga indított forgalomról. A DNS-feloldóként működő router a saját felfelé irányuló lekérdezéseit küldi, és azok egyáltalán nem haladnak át a forward láncon.
Erősítse meg, hogy a védett ügyfelek továbbra is a kiválasztott előtagon belüli címekkel rendelkeznek, mert az onnan kikerült eszköz véletlenül, nem szabályzat alapján közvetlen. A blokk egész LAN-ra való kiterjesztése a kivételek tervezésének áttekintése nélkül szintén hajlamos eltávolítani a saját adminisztratív útvonalát.
iptables -S FORWARD
iptables -L FORWARD -v -n
cat /proc/net/nf_conntrack | grep -c ESTABLISHED
Ezután próbáljon ki egy régi folyamot egy új mellett. Egy friss kapcsolódási kísérlet és egy már aktív kétirányú átvitel eltérően viselkedik e szabály alatt, és csak mindkettő tesztelése mutatja meg, milyen szabályzata van valójában.