Ny UFW-regel, gammel forbindelse: den etablerede tilstand vinder

At tilføje en afvisningsregel og se en åben download fortsætte er ikke en fejl i UFW. Reglen, du tilføjede, står efter regler, der allerede har accepteret strømmen, og en forbindelse, der blev etableret tidligere, bliver ved med at matche dem. At rette det betyder at indsætte på den rigtige position og forstå, hvad de tidligere regler lover. Den snævre version af den ændring følger.

Rækkefølgen afgør, ikke reglens eksistens

UFW er en frontend, der skriver netfilter-regler i faser: et rammeafsnit, der kører før brugerreglerne, derefter selve brugerreglerne og til sidst et afsnit, der kører efter dem. Standardreglerne før accepterer trafik fra etablerede og relaterede forbindelser, og de regler vurderes før noget, du tilføjer med en almindelig allow eller deny. UFW-kommandoreferencen dokumenterer indsættelsessyntaksen og den nummererede statusvisning, som denne ændring afhænger af.

Den rækkefølge forklarer overraskelsen. Din nye regel er reel, og den står i den rigtige tabel, men den er ikke den første beslutning, pakken møder. En forbindelse, der allerede spores som etableret, når aldrig frem til den.

Brug route-regler til dette arbejde, fordi pakken videresendes gennem gatewayen i stedet for at være adresseret til gatewayens egne tjenester. En inputregel ville filtrere den forkerte trafik og se ud, som om den intet gør.

Indsæt over den brede tilladelse

Forhåndsvis indsættelsen, før du anvender den, og bekræft, at reglen ikke allerede findes et andet sted på listen. At duplikere en identisk politik gør senere fjernelse tvetydig, og den person, der fjerner den forkerte kopi, opdager det ikke i ugevis.

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 præcis én regel på den position, du forventer, skal du anvende den samme kommando uden dry-run-flaget. Position 1 placerer den over de bredere brugertilladelser, ikke over rammereglerne, der blev gennemgået tidligere. Bekræft, at grænsefladenavnet matcher tunnel-enheden på denne gateway, fordi en regel, der er afgrænset til en grænseflade, som ikke findes længere, vil stå på listen og se korrekt ud, mens den ikke matcher noget. Omdøb enhedsreferencen, før du anvender, ikke efter testen fejler.

Der står ingen destinationsport i den regel, så den afviser hver TCP-port på den adresse i stedet for kun HTTPS. Hvis hensigten er én tjeneste, så navngiv porten; en regel, der er bredere end politikken, er en fremtidig hændelse, der venter på sin første læser.

Begræns kun kilden til én adresse, hvis den adresse er bundet til den tilsigtede identitet. En VPN-pulje med dynamisk tildeling kan give den samme adresse til en anden klient i morgen, og afvisningen vil følge adressen i stedet for personen.

Etablerede strømme overlever den nye regel

Forbindelsessporing er grunden til, at den eksisterende session fortsætter. Når en strøm er registreret som etableret, accepterer reglerne før dens pakker, før din afvisning bliver konsulteret, og overførslen slutter, som om intet var ændret. Derfor fortæller en test med en browser, der genbruger en åben forbindelse, dig intet om den nye politik. En afvisning kan virke ubrugelig minutter efter ibrugtagning og fuldstændig effektiv for den næste bruger, der opretter forbindelse.

Hvis kravet omfatter at afbryde live-trafik, kan denne ændring af brugerreglen ikke levere det. Tilbagekaldelse af sporet tilstand er en separat handling med sin egen radius, og den hører til firewall-ejeren snarere end til den, der tilføjede reglen. At skylle alle forbindelser på en gateway for at få én session til at forsvinde er den slags rettelse, der skaber en anden hændelse.

Husk også grænserne. Denne regel siger intet om ICMP, UDP eller IPv6, så en vellykket ping er ikke bevis for, at afvisningen fejlede. Én IPv4-adresse er heller ikke et websted: et navn kan slå op i flere adresser, og kun den, du navngav, er dækket.

Test med en frisk strøm

Læs de nummererede brugerregler og den effektive rå visning, og åbn derefter en ny forbindelse fra den valgte klient:

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å visning er vigtig, fordi status udelader rammeregler, der er skrevet i hånden, så den kan få rækkefølgen til at se anderledes ud end den, kernen håndhæver. Sammenlign de to, før du konkluderer, at en regel står det forkerte sted.

Kontroller derefter de to kontroller, der beviser, at reglen er afgrænset og ikke bred: en tilladt destination fra samme klient virker stadig, og en anden klient når stadig den afviste destination, hvis dens politik tillader det. En afvisning, der bryder begge tests, er en politikændring, ikke en målrettet.

Når testen er slut, skal du kun fjerne den regel, du tilføjede, ved at gentage den nøjagtigt. Hvis politikken er permanent, overdrag den til firewall-ejeren med klientidentitet, destinations-ejer og en revisionsdato, så en genanvist tunneladresse ikke efterlader en forældet afvisning.