Nftables op Linux, controleer de regels voordat u een poort opent

Een poort lijkt van buitenaf gesloten, en later ga je naar de applicatie of de router kijken. Voordat je iets wijzigt, kijk naar de regels die daadwerkelijk zijn geladen door nftables. Het bestand /etc/nftables.conf kan verschillen van de actieve status, en een lokale firewall verklaart niet alleen het hele netwerktraject.

Deze methode maakt het mogelijk om de ruleset te lezen, de keten te identificeren die het binnenkomende verkeer behandelt en een wijziging te testen zonder een SSH-sessie te verliezen. Houd een tweede verbinding open als je op afstand werkt.

Begin met het lezen van de geladen firewall

De volgende opdracht verandert niets. Het toont de tabellen, ketens, regels en eventuele telwerken die momenteel in de kernel aanwezig zijn:

sudo nft list ruleset

Als de output lang is, lijst dan eerst de tabellen en richt je vervolgens op degene die je interesseert:

sudo nft list tables
sudo nft list table inet filter

De familie inet kan zowel IPv4- als IPv6-regels bevatten. Een tabel kan ook behoren tot ip, ip6, bridge of netdev. Vervang een IPv6-regel niet door een IPv4-regel in de veronderstelling dat het probleem is opgelost.

In een filtertabel, zoek vooral naar een basis-keten met type filter hook input. Dit is degene die het verkeer ontvangt dat bestemd is voor de machine. De regel policy drop betekent dat pakketten die geen accept-regel tegenkomen, worden geweigerd.

Om de regels identificatienummers te zien, handig als je later een specifieke regel moet verwijderen, voeg -a toe:

sudo nft -a list chain inet filter input

Verwar input, forward en output niet. Een server die een SSH-verbinding ontvangt gebruikt meestal input. Een machine die verkeer naar een andere host routet kan het pakket blokkeren in forward. Een applicatie die naar het internet gaat, gaat door output.

Controleer de poort en de volgorde van regels

De regels in een keten worden in volgorde geëvalueerd. Een weigeringregel die vóór de toestemming van de poort staat, wint. Zoek naar het protocol, de poort en de verbindingsstatus:

sudo nft list chain inet filter input
sudo ss -lntup

Voor SSH lijkt een verwachte regel vaak op tcp dport 22 accept. De poort kan anders zijn als de daemon ergens anders luistert. De output van ss -lntup laat zien of een programma daadwerkelijk op de verwachte poort en het adres luistert. Een open firewall maakt een stopgezet service niet beschikbaar.

Bekijk ook de regels ct state established,related accept en de loopback interface iif lo accept. Deze voorkomen dat antwoorden op reeds gevestigde verbindingen en lokale uitwisselingen worden verbroken. Als de ruleset telwerken heeft, vergelijk ze dan voor en na een verbindings test om te zien welke regel het verkeer ziet.

Een weigering kan buiten de machine blijven: cloudbeveiligingsgroepen, routers, NAT-omleidingen, VLAN’s, bedrijfsfirewalls of diensten die alleen zijn gerelateerd aan 127.0.0.1. Test de poort vanaf een andere computer met nc -vz adres_van_de_server 22 of met je SSH-client. Controleer op de server of er geluisterd wordt met ss voordat je iets aan nftables wijzigt.

Identificeer de regel die daadwerkelijk blokkeert

Een keten kan een andere keten aanroepen met jump of goto. De toestemming voor de poort is daardoor niet noodzakelijk zichtbaar in de eerste weergegeven keten. Lees de aanroepen van ketens, de benoemde sets en de regels die een loggingsprefix dragen opnieuw door. Een regel van het type counter drop of reject die vóór de poort staat, verklaart vaak het resultaat.

Je kunt een gericht pakket volgen met nft monitor trace, maar deze opdracht produceert veel data op een actieve machine. Beperk het tot een korte diagnostische periode en filter het verkeer op adres of poort in een tijdelijke regel. Verwijder daarna deze regel met zijn handle zoals weergegeven door nft -a list ruleset.

Laat geen brede trace- of logregel op een blootgestelde server staan. Het kan de logboeken vullen of ruis aan de diagnose toevoegen. Voor een eerste controle zijn de telwerken van de keten en een test vanaf een andere computer vaak voldoende.

De actieve ruleset en het permanente bestand kunnen verschillen

nft list ruleset leest de actieve staat. Het zegt niet welke dienst de regels heeft geladen, noch welk bestand opnieuw zal worden geladen bij herstart. Op Debian en Ubuntu, kijk gewoonlijk naar /etc/nftables.conf en de status van de dienst:

sudo systemctl status nftables
sudo systemctl is-enabled nftables
sudo grep -nE '^(table|include|flush)' /etc/nftables.conf

Op een distributie die door firewalld, UFW, Docker of een hostingtool gaat, kunnen meerdere componenten regels schrijven. Kopieer geen ruleset gezien in een tutorial in /etc/nftables.conf als een andere dienst het al beheert. Identificeer eerst de beheerder die door jouw machine is verklaard en lees de regels opnieuw na herladen.

Regels die via de opdrachtregel zijn toegevoegd verdwijnen vaak bij de volgende herstart of de volgende herlaadactie van de dienst. Omgekeerd, het wijzigen van het permanente bestand verandert niets zolang het niet is geladen. Dit is precies de reden om beide kanten te controleren voordat je concludeert dat een poort open is.

Bewaar en test voordat je een regel toepast

Bewaar de huidige staat voordat je gaat schrijven. Het back-upbestand moet alleen leesbaar blijven voor de beheerder:

sudo install -m 600 /dev/null /root/nftables-before-change.nft
sudo nft list ruleset | sudo tee /root/nftables-before-change.nft > /dev/null

Bereid vervolgens de wijziging voor in een tijdelijk bestand. nft -c controleert de syntaxis zonder de regels te laden:

sudo nft -c -f /etc/nftables.conf

Deze controle bewijst niet dat de nieuwe ruleset je binnen zal laten. Houd een tweede SSH-sessie verbonden, pas het bestand in de eerste toe en probeer een nieuwe verbinding vanuit een andere terminal. Als je de toegang verliest, maakt de back-up sessie het mogelijk om de back-up te herstellen:

sudo nft -f /etc/nftables.conf
sudo nft list ruleset
# In geval van een onderbreking of een foutieve regel:
sudo nft -f /root/nftables-before-change.nft

Vermijd flush ruleset die alleen op een externe server wordt uitgevoerd. Het verwijdert alle actuele regels voordat je het vervangingsbestand hebt bevestigd. Laad een volledig en gecontroleerd bestand, en controleer dan onmiddellijk de actieve ruleset daarna.

Controles na de wijziging

• Herstart sudo nft list ruleset en controleer of de verwachte tabel en keten nog steeds aanwezig zijn.
• Test de service vanaf een andere machine met de werkelijk gebruikte poort.
• Controleer sudo ss -lntup als de poort ontoegankelijk blijft.
• Controleer de kernel log met sudo journalctl -k -b als je regels de geweigerde pakketten loggen.
• Controleer na een herstart of de nftables-service het permanente bestand van jouw distributie correct herlaadt.

Voor eenvoudige gevallen is het artikel over UFW onder Linux beter geschikt. Als je de beschikbaarheid van een service moet diagnosticeren voordat je de firewall wijzigt, controleer dan ook de open poorten met ss. De documentatie nft(8) geeft details over de families, de ketens en de optie -c.