Egy célcím-tartomány blokkolása minden VPN-ügyfélkészlethez
Egyetlen nftables-szabály is megtagadhat egy célprefixet egy engedélyezett VPN-készlettől anélkül, hogy az átjáró saját forgalmát érintené. Hangolja össze a hookot és a pozíciót.
Egy szabály távol tarthat egy engedélyezett VPN-készletet egy célcím-tartománytól anélkül, hogy zavarná bármi mást, amit az átjáró tesz. Maga a szabály rövid; azt, hogy működik-e, az dönti el, melyik hookban él és hol áll a láncban. Ha e kettőt elvéti, olyan tűzfalat kap, amely helyesnek látszik és következetlenül viselkedik. Kezdje ott, hogy mit tesz a csomag, amikor a szabály látja.
Mit is illeszt a szabály valójában
A szabály egyszerre három dolgot illeszt: egy bemeneti interfészt, egy forrás-prefixet és egy célprefixet. Mindhármnak igaznak kell lennie ahhoz, hogy a drop érvényesüljön, és ez tartja szűken. Egyetlen kifejezésként olvasni könnyebb, mint három külön szabályként.
Az interfész-illesztés az, ami megkülönbözteti a továbbított ügyfélforgalmat az átjáró saját kapcsolataitól. Nélküle egy csak a forráskészletet megnevező szabály azokat a csomagokat is érintené, amelyeket maga az átjáró állít elő arról a címről, ha erre valaha sor kerül. A forrás-prefix a politikát az engedélyezett ügyfelekre szűkíti, a célprefix pedig egyetlen tartományra. A szabályt metszetként olvassa, ne listaként.
Írja fel a három értéket, mielőtt bármit szerkesztene: az alagútinterfész nevét, a készletet, amelyet a kiszolgáló kioszt, és a prefixet, amelyet meg kíván tagadni. Bármelyikük elírása olyan szabályt ad, amely tisztán feldolgozható és semmit nem véd. Tartsa ezt a három értéket a változásjegyzékben a szabály mellett.
A hook dönti el, kire vonatkozik a szabály
A netfilter-lánc egy hookhoz csatlakozik, és a hook dönti el, mely csomagokat látja egyáltalán a lánc. A forward hook az átjárón átirányított forgalmat látja, és pontosan ez az ügyféltől a cél felé menő forgalom. A lánc minden egyéb eleme más közönségre irányul.
Az input hook az átjáróhoz címzett forgalmat látja, így az ott elhelyezett szabály a saját szolgáltatásaihoz való hozzáférést szabályozza, nem a tranzitot. Az output hook az átjáró által létrehozott forgalmat látja, ami éppen az ellenkezője annak, amire egy ügyfélkészlet-politikának szüksége van. A láncnevek önkényes címkék, amelyeket a szabálykészlet írója választott, ezért ne a névből következtessen a hookra. Ellenőrizze, hova van csatlakoztatva a lánc, mielőtt feltételezi, mit illeszthet.
| Hook | Traffic it sees | Right for this policy |
|---|---|---|
| input | Addressed to the gateway | No, that is the host's own services |
| forward | Routed through the gateway | Yes, for client-to-destination traffic |
| output | Generated by the gateway | No, that is the opposite direction |
A csatlakozás elolvasása egyetlen soros ellenőrzés, amely megakadályozza, hogy a szabály olyan láncba kerüljön, amely soha nem látja a csomagot.
Helyezze a szabályt a széles accept elé
A szabályok sorrendben értékelődnek, és az első döntés nyer. Egy korábbi széles accept lezárja az értékelést azokra a csomagokra, amelyeket illeszt, így a később hozzáfűzött drop soha nem fut le rájuk. Ez a sorrendi szabály az egész oka annak, hogy egy helyesnek látszó szabály hatástalan lehet.
Szúrja be a szabályt az accept elé ahelyett, hogy a végéhez fűzné. Ha a lánc már tartalmaz általános acceptet az alagútinterfészre, az új szabálynak azt meg kell előznie, különben csak dísz. Az eredményül kapott sorrendet ellenőrizze, ne a szerkesztett fájlt, mert egy több fájlból összeállított szabálykészlet esetleg egyikkel sem egyezik. Ezután erősítse meg egy a készletből jövő teszttel.
sudo nft list chain inet filter forward
sudo nft insert rule inet filter forward iifname "tun0" ip saddr 10.90.0.0/24 ip daddr 198.51.100.0/24 drop
sudo nft -c -f /etc/nftables.confA harmadik parancs alkalmazás nélkül elemzi a fájlt, ami elkapja a szintaktikai hibákat, mielőtt kimaradássá válnak. Visszaállítási tervvel alkalmazza, mert egy hibás szabály a forward láncban elvághatja az alagutat, amelyen dolgozik.
A meglévő folyamokat nem érdekli az új szabálya
A szabály létezése előtt létrejött conntrack-bejegyzés továbbra is a korábbi elfogadásra illeszkedik. Ezért tűnik úgy néha egy új drop, hogy működik az új kapcsolatokra, és semmit nem tesz azzal, amelyet éppen tesztel.
Olvassa el az állapot-illesztést a lánc elején. Ha az established és related forgalmat a szabálya előtt elfogadja, minden már futó folyam tovább folyik, amíg be nem zárul. Ez általában az a viselkedés, amelyet vészhelyzeti szabálynál szeretne, és zavaró, amikor azonnali megszakításra számít. Döntse el, milyen hatást szeretne, mielőtt telepít. Egy nyitott kapcsolatot újrahasználó teszt rossz történetet fog mesélni.
sudo conntrack -L -s 10.90.0.14 -d 198.51.100.20
sudo nft list ruleset | grep -n -A3 'ct state'Az első parancs megmutatja, létezik-e folyam, a második pedig azt, hogy egy korai állapotszabály továbbra is elfogadja-e. Mindkettő csak olvasásra való és biztonságos incidens közben futtatni.
Mi nem ez a szabály
A szabály nem domain-feketelista, nem IPv6-politika és nem egyetlen alkalmazásfiókra vonatkozó korlátozás.
Mindegyikük saját mechanizmust igényel. Egy domainblokknak neveket kell feloldania, amit egy csomagszűrő nem tesz. Az IPv6-forgalomnak saját illesztés kell, mert az ip kifejezés semmit nem mond az ip6 csomagokról. Az alkalmazásszintű korlátozás a szolgáltatáshoz vagy egy hitelesített proxyhoz tartozik, nem prefixillesztéshez. Éppen e követelmények szétválasztása akadályozza meg, hogy egyetlen szűk szabálytól négy munkát kérjenek.
A szerződés, amelyet ez a szabály nyújt, pontos: az engedélyezett készletből egy célprefix felé menő forgalom megtagadva, míg az átjáró nem kapcsolódó forgalma megtartja meglévő politikáját. Írja ezt a mondatot a szabály mellé, és a következő ember tudni fogja, mire volt való.