Nové pravidlo UFW, staré pripojenie: vyhráva nadviazaný stav

Pridať pravidlo odmietnutia a sledovať, ako otvorené sťahovanie pokračuje, nie je chyba UFW. Pravidlo, ktoré ste pridali, stojí až za pravidlami, ktoré tok už prijali, a skôr nadviazané pripojenie im ďalej zodpovedá. Oprava znamená vložiť ho na správne miesto a pochopiť, čo skoršie pravidlá sľubujú. Úzka verzia tejto zmeny nasleduje.

Rozhoduje poradie, nie existencia pravidla

UFW je rozhranie, ktoré zapisuje pravidlá netfilteru po fázach: sekcia rámca, ktorá beží pred používateľskými pravidlami, potom samotné používateľské pravidlá a napokon sekcia, ktorá beží po nich. Štandardné predchádzajúce pravidlá prijímajú prevádzku nadviazaných a súvisiacich pripojení a tieto pravidlá sa vyhodnocujú skôr než čokoľvek, čo pridáte bežným allow alebo deny. Referencia príkazov UFW dokumentuje syntax vkladania a číslovaný pohľad na stav, na ktorých táto zmena závisí.

Toto poradie vysvetľuje prekvapenie. Vaše nové pravidlo je skutočné a je v správnej tabuľke, ale nie je prvým rozhodnutím, na ktoré paket narazí. Pripojenie, ktoré sa už sleduje ako nadviazané, sa k nemu nikdy nedostane.

Na túto prácu používajte pravidlá route, pretože paket sa preposiela cez bránu, namiesto toho aby bol adresovaný službám samotnej brány. Vstupné pravidlo by filtrovalo nesprávnu prevádzku a vyzeralo by, že nič nerobí.

Vložte ho nad široké povolenie

Pred použitím si vloženie pozrite v náhľade a overte, že pravidlo už inde v zozname nie je. Duplikovanie rovnakej politiky robí neskoršie odstránenie nejednoznačným a ten, kto odstráni nesprávnu kópiu, si to týždne nevšimne.

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

Ak náhľad ukáže presne jedno pravidlo na očakávanej pozícii, použite rovnaký príkaz bez prepínača dry-run. Pozícia 1 ho umiestni nad širšie používateľské povolenia, nie nad pravidlá rámca prebrané skôr. Overte, že názov rozhrania zodpovedá tunelovému zariadeniu na tejto bráne, pretože pravidlo zviazané s rozhraním, ktoré už neexistuje, zostane v zozname a bude vyzerať správne, no nebude zodpovedať ničomu. Prementujte odkaz na zariadenie pred použitím, nie po neúspešnom teste.

V tomto pravidle nie je cieľový port, takže odmieta každý port TCP na tejto adrese, nielen HTTPS. Ak je zámerom jedna služba, pomenujte port; pravidlo širšie než politika je budúci incident, ktorý čaká na svojho prvého čitateľa.

Obmedzte zdroj na jedinú adresu len vtedy, keď je táto adresa viazaná na zamýšľanú identitu. VPN bazén s dynamickým prideľovaním môže zajtra dať rovnakú adresu inému klientovi a odmietnutie by sledovalo adresu, nie osobu.

Nadviazané toky nové pravidlo prežijú

Sledovanie pripojení je dôvod, prečo existujúca relácia pokračuje. Keď sa tok zaznamená ako nadviazaný, predchádzajúce pravidlá prijmú jeho pakety skôr, než sa vaše odmietnutie vôbec zváži, a prenos sa skončí, akoby sa nič nezmenilo. Testovanie prehliadačom, ktorý znova používa otvorené pripojenie, preto o novej politike nič nehovorí. Odmietnutie môže pár minút po nasadení vyzerať zbytočne a byť pre ďalšieho pripájajúceho sa používateľa úplne účinné.

Ak požiadavka zahŕňa prerušenie živej prevádzky, táto zmena používateľského pravidla to nedokáže. Odvolanie sledovaného stavu je samostatná akcia s vlastným dosahom a patrí vlastníkovi firewallu, nie tomu, kto pravidlo pridal. Vyprázdniť všetky pripojenia na bráne, aby jedna relácia zmizla, je typ opravy, ktorý vyvolá druhý incident.

Pamätajte aj na hranice. Toto pravidlo nič nehovorí o ICMP, UDP ani IPv6, takže úspešný ping nie je dôkaz, že odmietnutie zlyhalo. Jedna adresa IPv4 tiež nie je web: meno sa môže preložiť na viac adries a pokrytá je len tá, ktorú ste uviedli.

Testujte s novým tokom

Prečítajte si očíslované používateľské pravidlá a efektívny surový pohľad, potom otvorte nové pripojenie z vybraného klienta:

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

Surový pohľad je dôležitý, pretože status vynecháva pravidlá rámca napísané ručne, takže poradie môže vyzerať inak než to, čo presadzuje jadro. Porovnajte oba, kým usúdite, že pravidlo je na nesprávnom mieste.

Potom skontrolujte dve kontroly, ktoré dokazujú, že pravidlo je úzke a nie široké: povolený cieľ z toho istého klienta stále funguje a druhý klient sa stále dostane na odmietnutý cieľ, ak to jeho politika dovoľuje. Odmietnutie, ktoré pokazí oba testy, je zmena politiky, nie cielený zásah.

Keď sa test skončí, odstráňte len pravidlo, ktoré ste pridali, presným zopakovaním. Ak je politika trvalá, odovzdajte ju vlastníkovi firewallu s identitou klienta, vlastníkom cieľa a dátumom revízie, aby po preradení tunelovej adresy nezostalo zastarané odmietnutie.