Új UFW-szabály, régi kapcsolat: a létrejött állapot nyer

Elutasító szabály hozzáadása és egy nyitott letöltés folytatódása nem UFW-hiba. A hozzáadott szabály olyan szabályok után áll, amelyek már elfogadták a folyamot, és egy korábban létrejött kapcsolat továbbra is illeszkedik rájuk. A javítás a megfelelő helyre szúrást és a korábbi szabályok ígéretének megértését jelenti. A változtatás szűk változata következik.

A sorrend dönt, nem a szabály létezése

Az UFW egy felület, amely a netfilter-szabályokat szakaszokban írja: egy keretrendszer-szakasz, amely a felhasználói szabályok előtt fut, majd maguk a felhasználói szabályok, majd egy szakasz, amely utánuk fut. Az alapértelmezett előtte szabályok elfogadják a létrejött és kapcsolódó kapcsolatok forgalmát, és ezek a szabályok minden olyan dolog előtt kiértékelődnek, amit közönséges allow vagy deny paranccsal hozzáad. Az UFW-parancsreferencia dokumentálja a beszúrási szintaxist és azt a számozott állapotnézetet, amelytől ez a változtatás függ.

Ez a sorrend magyarázza a meglepetést. Az új szabály valódi, és a megfelelő táblában van, mégsem az első döntés, amellyel a csomag találkozik. Egy már létrejöttként követett kapcsolat soha nem ér el hozzá.

Ehhez a feladathoz route-szabályokat használjon, mert a csomag az átjárón keresztül továbbítódik, nem az átjáró saját szolgáltatásaihoz címzett. Egy bemeneti szabály a rossz forgalmat szűrné, és úgy tűnne, mintha semmit sem tenne.

A széles engedély fölé szúrja be

A beszúrást alkalmazás előtt nézze meg előnézetben, és győződjön meg róla, hogy a szabály nem szerepel már máshol a listában. Egy azonos szabályzat megkettőzése kétértelművé teszi a későbbi eltávolítást, és aki a rossz példányt távolítja el, hetekig nem veszi észre.

sudo ufw --dry-run route insert 1 deny in on tun0 proto tcp from 10.88.0.55/32 to 192.0.2.88/32

Ha az előnézet pontosan egy szabályt mutat a várt helyen, ugyanazt a parancsot futtassa a dry-run kapcsoló nélkül. Az 1-es pozíció a szélesebb felhasználói engedélyek fölé teszi, nem a korábban tárgyalt keretrendszer-szabályok fölé. Győződjön meg róla, hogy az interfész neve megegyezik az ezen az átjárón lévő alagúteszközzel, mert egy olyan interfészhez kötött szabály, amely már nem létezik, a listában ülve helyesnek látszik, miközben semmihez sem illeszkedik. Az eszközhivatkozást alkalmazás előtt nevezze át, ne a sikertelen teszt után.

Ebben a szabályban nincs célport, tehát minden TCP-portot elutasít azon a címen, nem csak a HTTPS-t. Ha a szándék egyetlen szolgáltatás, nevezze meg a portot; a szabályzatnál szélesebb szabály jövőbeli incidens, amely az első olvasójára vár.

Csak akkor korlátozza a forrást egyetlen címre, ha az a cím a szándékolt identitáshoz kötött. Egy dinamikus kiosztású VPN-készlet holnap ugyanazt a címet adhatja egy másik ügyfélnek, és az elutasítás a cím után menne, nem a személy után.

A létrejött folyamok túlélik az új szabályt

A kapcsolatkövetés az oka annak, hogy a meglévő munkamenet folytatódik. Amint egy folyam létrejöttként rögzül, az előtte szabályok elfogadják a csomagjait, mielőtt az elutasítását egyáltalán megnéznék, és az átvitel úgy fejeződik be, mintha semmi sem változott volna. Ezért egy nyitott kapcsolatot újrahasználó böngészővel végzett teszt semmit sem mond az új szabályzatról. Egy elutasítás használhatatlannak tűnhet a bevezetés után percekkel, és teljesen hatásos lehet a következő csatlakozó felhasználónak.

Ha a követelmény magában foglalja az élő forgalom elvágását, ez a felhasználói szabály módosítás nem tudja teljesíteni. A követett állapot visszavonása külön művelet saját hatókörrel, és a tűzfal tulajdonosához tartozik, nem ahhoz, aki a szabályt hozzáadta. Egy átjáró összes kapcsolatának kiürítése, hogy egy munkamenet eltűnjön, olyan javítás, amely második incidenst szül.

A határokra is emlékezzen. Ez a szabály semmit sem mond az ICMP-ről, UDP-ről vagy IPv6-ról, tehát egy sikeres ping nem bizonyítja, hogy az elutasítás kudarcot vallott. Egyetlen IPv4-cím sem webhely: egy név több címre oldódhat fel, és csak az van lefedve, amelyet megnevezett.

Teszteljen friss folyammal

Olvassa el a számozott felhasználói szabályokat és a tényleges nyers nézetet, majd nyisson új kapcsolatot a kiválasztott ügyfélről:

sudo ufw status numbered
sudo ufw show raw
# from 10.88.0.55, a new TCP connection to 192.0.2.88 should fail

A nyers nézet azért számít, mert a status kihagyja a kézzel írt keretrendszer-szabályokat, így a sorrend másképp nézhet ki, mint amit a kernel kényszerít. Hasonlítsa össze a kettőt, mielőtt arra jutna, hogy egy szabály rossz helyen van.

Ezután ellenőrizze a két kontrollt, amely bizonyítja, hogy a szabály szűk és nem széles: egy engedélyezett cél ugyanattól az ügyféltől továbbra is működik, és egy második ügyfél továbbra is eléri az elutasított célt, ha a szabályzata engedi. Az az elutasítás, amely mindkét tesztet elrontja, szabályzatváltozás, nem célzott intézkedés.

Amikor a teszt véget ér, csak a hozzáadott szabályt távolítsa el, pontosan újrafogalmazva. Ha a szabályzat állandó, adja át a tűzfal tulajdonosának az ügyfél identitásával, a cél tulajdonosával és felülvizsgálati dátummal, hogy egy újrakiosztott alagútcím ne hagyjon maga után elavult elutasítást.