Ny UFW-regel, gammal anslutning: det etablerade tillståndet vinner

Att lägga till en avvisningsregel och se en öppen nedladdning fortsätta är inte en UFW-bugg. Regeln du lade till står efter regler som redan har accepterat flödet, och en anslutning som etablerades tidigare fortsätter att matcha dem. Att rätta det innebär att infoga på rätt plats och förstå vad de tidigare reglerna lovar. Den smala versionen av den ändringen följer.

Ordningen avgör, inte regelns existens

UFW är ett gränssnitt som skriver netfilterregler i steg: en ramdel som körs före användarreglerna, sedan själva användarreglerna, sedan en del som körs efter dem. Standardreglerna före accepterar trafik från etablerade och relaterade anslutningar, och dessa regler utvärderas före allt du lägger till med en vanlig allow eller deny. UFW-kommandoreferensen dokumenterar infogningssyntaxen och den numrerade statusvyn som ändringen bygger på.

Den ordningen förklarar överraskningen. Din nya regel är verklig och står i rätt tabell, men den är inte det första beslut som paketet möter. En anslutning som redan spåras som etablerad når aldrig fram till den.

Använd route-regler för det här jobbet, eftersom paketet vidarebefordras genom gatewayen i stället för att adresseras till gatewayens egna tjänster. En indataregel skulle filtrera fel trafik och se ut som om den inte gjorde något.

Infoga ovanför den breda tillåtelsen

Förhandsgranska infogningen innan du tillämpar den och bekräfta att regeln inte redan finns någon annanstans i listan. Att duplicera en identisk policy gör senare borttagning tvetydig, och den som tar bort fel kopia märker det inte på veckor.

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

Om förhandsgranskningen visar exakt en regel på den position du förväntar dig, tillämpa samma kommando utan dry-run-flaggan. Position 1 placerar den ovanför de bredare användartillåtelserna, inte ovanför ramreglerna som behandlades tidigare. Bekräfta att gränssnittsnamnet matchar tunnelenheten på denna gateway, eftersom en regel bunden till ett gränssnitt som inte längre finns kommer att stå i listan och se korrekt ut medan den inte matchar något. Byt namn på enhetsreferensen innan du tillämpar, inte efter att testet misslyckats.

Det finns ingen destinationsport i den regeln, så den avvisar varje TCP-port på den adressen och inte bara HTTPS. Om avsikten är en enda tjänst, namnge porten; en regel som är bredare än policyn är en framtida incident som väntar på sin första läsare.

Begränsa källan till en enda adress bara om den adressen är bunden till den avsedda identiteten. En VPN-pool med dynamisk tilldelning kan ge samma adress till en annan klient i morgon, och avvisningen skulle följa adressen i stället för personen.

Etablerade flöden överlever den nya regeln

Anslutningsspårning är anledningen till att den befintliga sessionen fortsätter. När ett flöde registreras som etablerat accepterar reglerna före dess paket innan din avvisning ens konsulteras, och överföringen slutförs som om ingenting hade ändrats. Därför säger ett test med en webbläsare som återanvänder en öppen anslutning ingenting om den nya policyn. En avvisning kan verka värdelös minuter efter utrullning och vara helt effektiv för nästa användare som ansluter.

Om kravet omfattar att kapa livetrafik kan den här användarregeländringen inte leverera det. Att återkalla spårat tillstånd är en separat åtgärd med egen påverkansradie, och den tillhör brandväggsägaren snarare än den som lade till regeln. Att tömma alla anslutningar på en gateway för att en session ska försvinna är den typ av åtgärd som skapar en andra incident.

Kom också ihåg gränserna. Den här regeln säger ingenting om ICMP, UDP eller IPv6, så en lyckad ping är inte bevis på att avvisningen misslyckades. En enda IPv4-adress är inte heller en webbplats: ett namn kan slås upp till flera adresser, och bara den du namngav täcks.

Testa med ett färskt flöde

Läs de numrerade användarreglerna och den effektiva råvyn och öppna sedan en ny anslutning från den valda 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

Råvyn spelar roll eftersom status utelämnar ramregler som skrivits för hand, så ordningen kan se annorlunda ut än den kärnan genomdriver. Jämför de två innan du drar slutsatsen att en regel står på fel plats.

Kontrollera sedan de två kontrollerna som bevisar att regeln är smal och inte bred: en tillåten destination från samma klient fungerar fortfarande, och en andra klient når fortfarande den avvisade destinationen om dess policy tillåter det. En avvisning som bryter båda testerna är en policyändring, inte en riktad åtgärd.

När testet är över tar du bara bort regeln du lade till, genom att upprepa den exakt. Om policyn är permanent överlämnar du den till brandväggsägaren med klientidentiteten, ägaren av destinationen och ett granskningsdatum, så att en omfördelad tunneladress inte lämnar en inaktuell avvisning efter sig.