Novo pravilo UFW, stara povezava: zmaga vzpostavljeno stanje

Dodati pravilo zavrnitve in videti, da se odprt prenos nadaljuje, ni napaka UFW. Pravilo, ki ste ga dodali, stoji za pravili, ki so tok že sprejela, in prej vzpostavljena povezava se še vedno ujema z njimi. Popravek pomeni vstaviti na pravo mesto in razumeti, kaj obljubljajo prejšnja pravila. Ozka različica te spremembe je naslednja.

Odloča vrstni red, ne obstoj pravila

UFW je vmesnik, ki zapisuje pravila netfilterja po stopnjah: razdelek ogrodja, ki se izvede pred uporabniškimi pravili, nato sama uporabniška pravila, nato razdelek, ki se izvede za njimi. Standardna prejšnja pravila sprejmejo promet vzpostavljenih in povezanih povezav, ta pravila pa se ovrednotijo pred vsem, kar dodate z običajnim allow ali deny. Referenca ukazov UFW dokumentira sintakso vstavljanja in oštevilčen pogled stanja, od katerih je odvisna ta sprememba.

Ta vrstni red pojasni presenečenje. Vaše novo pravilo je resnično in je v pravi tabeli, vendar ni prva odločitev, na katero naleti paket. Povezava, ki je že sledena kot vzpostavljena, do njega nikoli ne pride.

Za to delo uporabite pravila route, ker se paket posreduje skozi prehod in ni naslovljen na storitve prehoda samega. Vhodno pravilo bi filtriralo napačen promet in bi izgledalo, kot da ne naredi ničesar.

Vstavite ga nad širokim dovoljenjem

Pred uporabo si vstavitev oglejte v predogledu in potrdite, da pravilo ne obstaja že kje drugje na seznamu. Podvajanje enake politike naredi poznejšo odstranitev dvoumno, oseba, ki odstrani napačno kopijo, pa tega tedne ne bo opazila.

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

Če predogled pokaže natanko eno pravilo na pričakovanem mestu, uporabite isti ukaz brez zastavice dry-run. Položaj 1 ga postavi nad širša uporabniška dovoljenja, ne nad prej obravnavana pravila ogrodja. Potrdite, da se ime vmesnika ujema s tunelsko napravo na tem prehodu, ker bo pravilo, vezano na vmesnik, ki ne obstaja več, ostalo na seznamu in izgledalo pravilno, ne da bi se z čim ujemalo. Preimenujte sklic na napravo pred uporabo, ne po neuspelem preskusu.

V tem pravilu ni ciljnih vrat, zato zavrne vsaka vrata TCP na tem naslovu in ne le HTTPS. Če je namen ena storitev, poimenujte vrata; pravilo, širše od politike, je prihodnji incident, ki čaka na svojega prvega bralca.

Omejite vir na en naslov le, če je ta naslov vezan na predvideno identiteto. Skupina VPN z dinamičnim dodeljevanjem lahko jutri dodeli isti naslov drugemu odjemalcu, zavrnitev pa bi sledila naslovu in ne osebi.

Vzpostavljeni tokovi preživijo novo pravilo

Sledenje povezavam je razlog, da se obstoječa seja nadaljuje. Ko je tok zabeležen kot vzpostavljen, prejšnja pravila sprejmejo njegove pakete, preden se vaša zavrnitev sploh pregleda, in prenos se konča, kot da se ni nič spremenilo. Zato preskušanje z brskalnikom, ki znova uporabi odprto povezavo, ne pove ničesar o novi politiki. Zavrnitev je lahko nekaj minut po uvedbi videti neuporabna in biti popolnoma učinkovita za naslednjega uporabnika, ki se poveže.

Če zahteva vključuje prekinitev živega prometa, ta sprememba uporabniškega pravila tega ne more zagotoviti. Preklic sledenega stanja je ločeno dejanje z lastnim dosegom in pripada lastniku požarnega zidu, ne pa tistemu, ki je pravilo dodal. Praznjenje vseh povezav na prehodu, da ena seja izgine, je vrsta popravka, ki ustvari drugi incident.

Ne pozabite tudi na meje. To pravilo ne pove ničesar o ICMP, UDP ali IPv6, zato uspešen ping ni dokaz, da zavrnitev ni uspela. Tudi en naslov IPv4 ni spletno mesto: ime se lahko razreši v več naslovov in pokrit je le tisti, ki ste ga navedli.

Preskusite s svežim tokom

Preberite oštevilčena uporabniška pravila in dejanski surovi pogled, nato odprite novo povezavo z izbranega odjemalca:

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

Surovi pogled je pomemben, ker status izpusti pravila ogrodja, napisana ročno, zato je lahko vrstni red videti drugačen od tistega, ki ga uveljavlja jedro. Primerjajte oba, preden sklepate, da je pravilo na napačnem mestu.

Nato preverite dve kontroli, ki dokazujeta, da je pravilo ozko in ne široko: dovoljeni cilj z istega odjemalca še deluje, drugi odjemalec pa še vedno doseže zavrnjeni cilj, če mu politika to dovoljuje. Zavrnitev, ki pokvari oba preskusa, je sprememba politike, ne ciljno usmerjen ukrep.

Ko je preskusa konec, odstranite le pravilo, ki ste ga dodali, tako da ga natančno ponovite. Če je politika trajna, jo predajte lastniku požarnega zidu z identiteto odjemalca, lastnikom cilja in datumom pregleda, da po prerazporeditvi naslova tunela ne ostane zastarela zavrnitev.