Nuwe UFW-reël, ou verbinding: die gevestigde toestand wen

Om ’n weieringsreël by te voeg en te sien hoe ’n oop aflaai aanhou, is nie ’n UFW-fout nie. Die reël wat jy bygevoeg het, staan ná reëls wat die vloei reeds toegelaat het, en ’n verbinding wat vroeër gevestig is, bly by hulle pas. Om dit reg te maak, moet jy op die regte plek invoeg en verstaan wat die vroeëre reëls belowe. Die nou weergawe van daardie verandering volg hier.

Orde beslis, nie die bestaan van die reël nie

UFW is ’n voorkant wat netfilter-reëls in fases skryf: ’n raamwerkafdeling wat voor die gebruiker se reëls loop, dan die gebruiker se reëls self, dan ’n afdeling wat ná hulle loop. Die standaard voorafreëls aanvaar verkeer wat aan gevestigde en verwante verbindings behoort, en daardie reëls word geëvalueer voordat enigiets wat jy met ’n gewone allow of deny byvoeg, aan die beurt kom. Die UFW-bevelverwysing dokumenteer die invoegsintaksis en die genommerde status-aansig waarvan hierdie verandering afhang.

Daardie ordening verduidelik die verrassing. Jou nuwe reël is werklik en dit is in die regte tabel, maar dit is nie die eerste beslissing wat die pakkie teëkom nie. ’n Verbinding wat reeds as gevestig opgespoor is, bereik dit nooit.

Gebruik route-reëls vir hierdie werk, want die pakkie word deur die deurgang aangestuur eerder as aan die deurgang se eie dienste gerig. ’n Invoerreël sou die verkeerde verkeer filter en lyk of dit niks doen nie.

Voeg bo die breë toestemming in

Voorskou die invoeging voordat jy dit toepas, en bevestig dat die reël nie reeds elders in die lys bestaan nie. Om ’n identiese beleid te dupliseer maak latere verwydering dubbelsinnig, en die persoon wat die verkeerde kopie verwyder, sal dit weke lank nie agterkom nie.

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

As die voorskou presies een reël op die plek wys wat jy verwag, pas dieselfde bevel toe sonder die dry-run-vlag. Posisie 1 plaas dit bo die breër gebruikerstoelatings, nie bo die raamwerkreëls wat vroeër bespreek is nie. Bevestig dat die koppelvlaknaam by die tonneltoestel op hierdie deurgang pas, want ’n reël wat aan ’n koppelvlak gekoppel is wat nie meer bestaan nie, sal in die lys sit en korrek lyk terwyl dit niks pas nie. Verander die toestelverwysing voordat jy dit toepas, nie nadat die toets misluk het nie.

Geen bestemmingspoort verskyn in daardie reël nie, so dit weier elke TCP-poort by daardie adres eerder as net HTTPS. As die bedoeling een diens is, noem die poort; ’n reël wat breër as die beleid is, is ’n toekomstige voorval wat op sy eerste leser wag.

Beperk die bron tot ’n enkele adres net as daardie adres aan die bedoelde identiteit gebind is. ’n VPN-poel met dinamiese toewysing kan dieselfde adres môre aan ’n ander kliënt gee, en die weiering sal die adres volg eerder as die persoon.

Gevestigde vloeie oorleef die nuwe reël

Verbindingopsporing is die rede waarom die bestaande sessie voortduur. Sodra ’n vloei as gevestig aangeteken is, aanvaar die voorafreëls sy pakkies voordat jou weiering geraadpleeg word, en die oordrag eindig asof niks verander het nie. Om met ’n blaaier te toets wat ’n oop verbinding hergebruik, sê dus niks oor die nuwe beleid nie. ’n Weiering kan minute ná ontplooiing nutteloos lyk en heeltemal doeltreffend wees vir die volgende gebruiker wat aansluit.

As die vereiste insluit om lewendige verkeer af te sny, kan hierdie gebruikerreëlverandering dit nie lewer nie. Om opgespoorde toestand te herroep is ’n aparte aksie met sy eie impak, en dit hoort by die brandmuureienaar eerder as by wie die reël bygevoeg het. Om elke verbinding op ’n deurgang te spoel om een sessie te laat verdwyn, is die soort oplossing wat ’n tweede voorval skep.

Onthou ook die grense. Hierdie reël sê niks oor ICMP, UDP of IPv6 nie, so ’n suksesvolle ping is nie bewys dat die weiering misluk het nie. Een IPv4-adres is ook nie ’n webwerf nie: ’n naam kan na verskeie adresse oplos, en net die een wat jy genoem het, word gedek.

Toets met ’n vars vloei

Lees die genommerde gebruikerreëls en die effektiewe rou aansig, en open dan ’n nuwe verbinding vanaf die gekose kliënt:

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

Die rou aansig maak saak omdat status raamwerkreëls weglaat wat met die hand geskryf is, so dit kan die ordening anders laat lyk as wat die kern afdwing. Vergelyk die twee voordat jy tot die gevolgtrekking kom dat ’n reël op die verkeerde plek is.

Kontroleer dan die twee kontroles wat bewys die reël is beperk eerder as breed: ’n toegelate bestemming van dieselfde kliënt werk steeds, en ’n tweede kliënt bereik steeds die geweierde bestemming as sy beleid dit toelaat. ’n Weiering wat albei toetse breek, is ’n beleidsverandering, nie ’n gerigte een nie.

Wanneer die toets verby is, verwyder net die reël wat jy bygevoeg het, deur dit presies te herhaal. As die beleid permanent is, gee dit aan die brandmuureienaar met die kliëntidentiteit, die bestemmingseienaar en ’n hersieningsdatum, sodat ’n hertoegewysde tonneladres nie ’n verouderde weiering agterlaat nie.