Ny UFW-regel, gammel tilkobling: den etablerte tilstanden vinner

Å legge til en avvisningsregel og se en åpen nedlasting fortsette er ikke en UFW-feil. Regelen du la til, står etter regler som allerede har godtatt strømmen, og en tilkobling som ble etablert tidligere, fortsetter å matche dem. Å rette det betyr å sette den inn på riktig plass og forstå hva de tidligere reglene lover. Den smale versjonen av den endringen følger.

Rekkefølgen avgjør, ikke regelenes eksistens

UFW er et grensesnitt som skriver netfilter-regler i trinn: en rammedel som kjører før brukerreglene, deretter selve brukerreglene, deretter en del som kjører etter dem. Standardreglene før godtar trafikk fra etablerte og relaterte tilkoblinger, og disse reglene vurderes før noe du legger til med en vanlig allow eller deny. UFW-kommandoreferansen dokumenterer innsettingssyntaksen og den nummererte statusvisningen som denne endringen avhenger av.

Den rekkefølgen forklarer overraskelsen. Den nye regelen din er ekte, og den står i riktig tabell, men den er ikke den første avgjørelsen pakken møter. En tilkobling som allerede spores som etablert, når aldri fram til den.

Bruk route-regler til denne jobben, fordi pakken videresendes gjennom gatewayen i stedet for å være adressert til gatewayens egne tjenester. En inndataregel ville filtrert feil trafikk og sett ut som om den ikke gjorde noe.

Sett inn over den brede tillatelsen

Forhåndsvis innsettingen før du bruker den, og bekreft at regelen ikke allerede finnes et annet sted i listen. Å duplisere en identisk policy gjør senere fjerning tvetydig, og den som fjerner feil kopi, merker det ikke på ukevis.

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

Hvis forhåndsvisningen viser nøyaktig én regel på posisjonen du forventer, bruker du samme kommando uten dry-run-flagget. Posisjon 1 plasserer den over de bredere brukertillatelsene, ikke over rammereglene som ble gjennomgått tidligere. Bekreft at grensesnittnavnet samsvarer med tunnel-enheten på denne gatewayen, fordi en regel som er bundet til et grensesnitt som ikke finnes lenger, vil stå i listen og se riktig ut mens den ikke matcher noe. Gi enhetsreferansen nytt navn før du bruker den, ikke etter at testen feiler.

Det står ingen destinasjonsport i den regelen, så den avviser hver TCP-port på den adressen i stedet for bare HTTPS. Hvis hensikten er én tjeneste, navngi porten; en regel som er bredere enn policyen, er en fremtidig hendelse som venter på sin første leser.

Begrens kilden til én adresse bare hvis den adressen er bundet til den tiltenkte identiteten. En VPN-pool med dynamisk tildeling kan gi samme adresse til en annen klient i morgen, og avvisningen vil følge adressen i stedet for personen.

Etablerte strømmer overlever den nye regelen

Tilkoblingssporing er grunnen til at den eksisterende økten fortsetter. Når en strøm er registrert som etablert, godtar reglene før pakkene dens før avvisningen din blir konsultert, og overføringen fullføres som om ingenting var endret. Derfor sier en test med en nettleser som gjenbruker en åpen tilkobling deg ingenting om den nye policyen. En avvisning kan virke ubrukelig minutter etter utrulling og være helt effektiv for den neste brukeren som kobler til.

Hvis kravet innebærer å kutte levende trafikk, kan denne brukerregelendringen ikke levere det. Å tilbakekalle sporet tilstand er en egen handling med sin egen radius, og den tilhører brannmureieren snarere enn den som la til regelen. Å tømme alle tilkoblinger på en gateway for å få én økt til å forsvinne er den typen rettelse som skaper en annen hendelse.

Husk grensene også. Denne regelen sier ingenting om ICMP, UDP eller IPv6, så en vellykket ping er ikke bevis på at avvisningen mislyktes. Én IPv4-adresse er heller ikke et nettsted: et navn kan slås opp til flere adresser, og bare den du navnga, er dekket.

Test med en frisk strøm

Les de nummererte brukerreglene og den effektive rå visningen, og åpne deretter en ny tilkobling fra den valgte klienten:

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

Den rå visningen er viktig fordi status utelater rammeregler som er skrevet for hånd, så den kan få rekkefølgen til å se annerledes ut enn det kjernen håndhever. Sammenlign de to før du konkluderer med at en regel står på feil sted.

Kontroller deretter de to kontrollene som beviser at regelen er avgrenset og ikke bred: en tillatt destinasjon fra samme klient virker fortsatt, og en annen klient når fortsatt den avviste destinasjonen hvis policyen tillater det. En avvisning som bryter begge testene, er en policyendring, ikke en målrettet handling.

Når testen er over, fjerner du bare regelen du la til, ved å gjenta den nøyaktig. Hvis policyen er permanent, overleverer du den til brannmureieren med klientidentiteten, eieren av destinasjonen og en revideringsdato, slik at en gjenbrukt tunneladresse ikke etterlater en foreldet avvisning.