Dodati pravilo odbijanja i gledati kako otvoreno preuzimanje nastavlja nije greška u UFW-u. Pravilo koje ste dodali stoji poslije pravila koja su tok već prihvatila, a veza uspostavljena ranije nastavlja im odgovarati. Popravka znači umetanje na pravo mjesto i razumijevanje šta ranija pravila obećavaju. Uža verzija te promjene slijedi.

Redoslijed odlučuje, ne postojanje pravila

UFW je prednji sloj koji zapisuje netfilter pravila u fazama: dio okvira koji se izvršava prije korisničkih pravila, zatim sama korisnička pravila, zatim dio koji se izvršava poslije njih. Standardna prethodna pravila prihvataju saobraćaj uspostavljenih i povezanih veza, i ta pravila se ocjenjuju prije svega što dodate običnim allow ili deny. Referenca UFW komandi dokumentuje sintaksu umetanja i numerisani prikaz stanja o kojem ova promjena zavisi.

Taj redoslijed objašnjava iznenađenje. Vaše novo pravilo je stvarno i nalazi se u pravoj tabeli, ali nije prva odluka na koju paket nailazi. Veza koja je već praćena kao uspostavljena nikada ne stiže do njega.

Koristite route pravila za ovaj posao, jer se paket prosljeđuje kroz mrežni prolaz, a ne adresira na vlastite servise prolaza. Ulazno pravilo filtriralo bi pogrešan saobraćaj i izgledalo bi kao da ne radi ništa.

Umetnite iznad široke dozvole

Pregledajte umetanje prije primjene i potvrdite da pravilo već ne postoji negdje drugo na listi. Dupliciranje identične politike čini kasnije uklanjanje dvosmislenim, a osoba koja ukloni pogrešnu kopiju neće to primijetiti sedmicama.

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

Ako pregled pokaže tačno jedno pravilo na poziciji koju očekujete, primijenite istu komandu bez dry-run zastavice. Pozicija 1 ga stavlja iznad širih korisničkih dozvola, a ne iznad pravila okvira pregledanih ranije. Potvrdite da naziv interfejsa odgovara tunelskom uređaju na ovom prolazu, jer pravilo vezano za interfejs koji više ne postoji stajaće na listi i izgledati ispravno dok se ne poklapa ni sa čim. Promijenite referencu na uređaj prije primjene, ne poslije neuspjelog testa.

U tom pravilu nema odredišnog porta, pa ono odbija svaki TCP port na toj adresi, a ne samo HTTPS. Ako je namjera jedan servis, imenujte port; pravilo šire od politike budući je incident koji čeka prvog čitaoca.

Ograničite izvor na jednu adresu samo ako je ta adresa vezana za predviđeni identitet. VPN bazen s dinamičkom dodjelom može sutra dati istu adresu drugom klijentu, a odbijanje bi slijedilo adresu, a ne osobu.

Uspostavljeni tokovi preživljavaju novo pravilo

Praćenje veza razlog je zašto postojeća sesija traje. Kada se tok zabilježi kao uspostavljen, prethodna pravila prihvataju njegove pakete prije nego se pogleda vaše odbijanje, i prijenos završava kao da se ništa nije promijenilo. Zato testiranje preglednikom koji ponovo koristi otvorenu vezu ne govori ništa o novoj politici. Odbijanje može izgledati beskorisno minutama nakon primjene i potpuno djelotvorno za sljedećeg korisnika koji se poveže.

Ako zahtjev uključuje prekid živog saobraćaja, ova promjena korisničkog pravila to ne može isporučiti. Opovrgavanje praćenog stanja zasebna je radnja s vlastitim dometom i pripada vlasniku firewall-a, a ne onome ko je pravilo dodao. Ispiranje svih veza na prolazu da bi jedna sesija nestala vrsta je popravke koja stvara drugi incident.

Upamtite i granice. Ovo pravilo ne govori ništa o ICMP-u, UDP-u ili IPv6, pa uspješan ping nije dokaz da je odbijanje podbacilo. Jedna IPv4 adresa takođe nije web stranica: ime se može razriješiti u nekoliko adresa, a pokrivena je samo ona koju ste naveli.

Testirajte sa svježim tokom

Pročitajte numerisana korisnička pravila i djelotvoran sirovi prikaz, pa otvorite novu vezu s odabranog klijenta:

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

Sirovi prikaz je važan jer status izostavlja pravila okvira napisana ručno, pa redoslijed može izgledati drukčije od onoga što kernel primjenjuje. Uporedite oba prije nego zaključite da je pravilo na pogrešnom mjestu.

Zatim provjerite dvije kontrole koje dokazuju da je pravilo ograničeno, a ne široko: dozvoljeno odredište s istog klijenta još radi, a drugi klijent još stiže do odbijenog odredišta ako mu politika to dopušta. Odbijanje koje ruši oba testa je promjena politike, a ne ciljana.

Kad test završi, uklonite samo pravilo koje ste dodali, ponovivši ga tačno. Ako je politika trajna, predajte je vlasniku firewall-a s identitetom klijenta, vlasnikom odredišta i datumom pregleda, kako preraspoređena adresa tunela ne bi ostavila zastarjelo odbijanje.

Povezani članci