Nieuwe UFW-regel, oude verbinding: de gevestigde status wint

Een weigeringsregel toevoegen en zien dat een openstaande download doorgaat is geen UFW-bug. De regel die u toevoegde staat na regels die de stroom al hebben toegestaan, en een eerder opgezette verbinding blijft daaraan voldoen. Dat oplossen betekent op de juiste positie invoegen en begrijpen wat de eerdere regels beloven. De smalle versie van die wijziging volgt.

De volgorde beslist, niet het bestaan van de regel

UFW is een front-end die netfilterregels in fasen schrijft: een raamwerkdeel dat vóór de gebruikersregels loopt, dan de gebruikersregels zelf, dan een deel dat daarna loopt. De standaardregels ervoor accepteren verkeer van gevestigde en gerelateerde verbindingen, en die regels worden geëvalueerd vóór alles wat u met een gewone allow of deny toevoegt. De UFW-opdrachtreferentie documenteert de invoegsyntaxis en de genummerde statusweergave waarvan deze wijziging afhangt.

Die volgorde verklaart de verrassing. Uw nieuwe regel is echt en staat in de juiste tabel, maar het is niet de eerste beslissing die het pakket tegenkomt. Een verbinding die al als gevestigd wordt gevolgd, bereikt hem nooit.

Gebruik route-regels voor deze taak, omdat het pakket via de gateway wordt doorgestuurd in plaats van aan de eigen diensten van de gateway te zijn gericht. Een inputregel zou het verkeerde verkeer filteren en lijken niets te doen.

Voeg in boven de brede toestemming

Bekijk de invoeging als voorbeeld voordat u hem toepast, en controleer of de regel niet al elders in de lijst staat. Een identiek beleid dupliceren maakt het latere verwijderen dubbelzinnig, en wie de verkeerde kopie verwijdert, merkt dat wekenlang niet.

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

Als de voorbeeldweergave precies één regel toont op de positie die u verwacht, past u dezelfde opdracht toe zonder de dry-run-vlag. Positie 1 plaatst hem boven de bredere gebruikerstoestemmingen, niet boven de eerder besproken raamwerkregels. Controleer of de interfacenaam overeenkomt met het tunnelapparaat op deze gateway, want een regel die aan een niet meer bestaande interface is gebonden, blijft in de lijst staan en ziet er correct uit terwijl hij niets matcht. Wijzig de apparaatverwijzing vóór u toepast, niet nadat de test is mislukt.

Er staat geen bestemmingspoort in die regel, dus weigert hij elke TCP-poort op dat adres en niet alleen HTTPS. Als het de bedoeling is één dienst te doen, noem dan de poort; een regel die breder is dan het beleid is een toekomstig incident dat op zijn eerste lezer wacht.

Beperk de bron tot één adres alleen als dat adres aan de bedoelde identiteit is gebonden. Een VPN-pool met dynamische toewijzing kan hetzelfde adres morgen aan een andere client geven, en de weigering volgt dan het adres in plaats van de persoon.

Gevestigde stromen overleven de nieuwe regel

Verbindingsregistratie is de reden dat de bestaande sessie doorgaat. Zodra een stroom als gevestigd is vastgelegd, accepteren de regels ervoor de pakketten voordat uw weigering wordt bekeken, en de overdracht eindigt alsof er niets is veranderd. Daarom zegt een test met een browser die een open verbinding hergebruikt niets over het nieuwe beleid. Een weigering kan minuten na uitrol nutteloos lijken en volledig effectief zijn voor de volgende gebruiker die verbinding maakt.

Als de eis omvat dat live verkeer wordt afgekapt, kan deze wijziging van de gebruikersregel dat niet leveren. Het intrekken van gevolgde status is een aparte actie met een eigen impactradius, en die hoort bij de firewalleigenaar en niet bij wie de regel toevoegde. Alle verbindingen op een gateway leegmaken om één sessie te laten verdwijnen is het soort oplossing dat een tweede incident veroorzaakt.

Denk ook aan de grenzen. Deze regel zegt niets over ICMP, UDP of IPv6, dus een geslaagde ping is geen bewijs dat de weigering faalde. Eén IPv4-adres is ook geen website: een naam kan naar meerdere adressen verwijzen, en alleen het adres dat u noemde is gedekt.

Test met een verse stroom

Lees de genummerde gebruikersregels en de effectieve ruwe weergave, en open dan een nieuwe verbinding vanaf de gekozen client:

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

De ruwe weergave is belangrijk omdat status met de hand geschreven raamwerkregels weglaat, waardoor de volgorde anders kan lijken dan wat de kernel afdwingt. Vergelijk beide voordat u concludeert dat een regel op de verkeerde plek staat.

Controleer daarna de twee controles die bewijzen dat de regel smal en niet breed is: een toegestane bestemming vanaf dezelfde client werkt nog, en een tweede client bereikt de geweigerde bestemming nog als zijn beleid dat toestaat. Een weigering die beide tests breekt, is een beleidswijziging en geen gerichte maatregel.

Als de test voorbij is, verwijdert u alleen de regel die u toevoegde, door hem exact te herhalen. Is het beleid permanent, geef het dan aan de firewalleigenaar met de clientidentiteit, de eigenaar van de bestemming en een beoordelingsdatum, zodat een opnieuw toegewezen tunneladres geen verouderde weigering achterlaat.