Firewallregel aanpassen werkt niet: regelvolgorde en verbindingsstatus

U hebt de regel bewerkt, de regelset opnieuw geladen, en de tunnel gedraagt zich precies zoals voorheen. Dat resultaat heeft twee veelvoorkomende oorzaken, en ze vragen verschillende tests. Ofwel staat de nieuwe regel na een eerdere regel die het pakket al heeft geaccepteerd, ofwel is de uitwisseling die u bekijkt een gevolgde verbinding die de wijziging nooit opnieuw beoordeelt. Een regel in een bestand drukt bedoeling uit; wat het pakket beslist, is het actieve pad dat het tegenkomt. Werk de controles hieronder op volgorde af en houd daarbij een weg terug open.

Regelvolgorde en verbindingsstatus zijn verschillende fouten

Geordende ketens worden van boven naar beneden beoordeeld, en de eerste regel die een definitief oordeel bereikt, beëindigt de wandeling door die keten. Zet een brede acceptatie boven een zorgvuldig geschreven blokkeerregel, en de blokkeerregel wordt documentatie: hij staat in de regelset, zijn teller is nul, en geen pakket zal hem ooit bereiken. Dezelfde tekst op een andere keten toegepast bewijst ook niets. In nftables hangen basisketens aan hooks met prioriteiten, dus een acceptatie in de ene keten verhindert niet dat een andere keten op een andere hook of prioriteit hetzelfde pakket ziet.

Verbindingstracking veroorzaakt het tweede symptoom, en van buitenaf ziet het er identiek uit. Zodra een flow in de statustabel staat, keert een acceptatie voor established-or-related nabij de top van de keten terug voordat uw nieuwe regel zelfs maar wordt geraadpleegd. NAT-mappings hebben dezelfde eigenschap: de vertaling werd vastgelegd toen de flow begon, dus een bewerkte postrouting-regel herschrijft geen sessie die al loopt. Daarom lijkt een wijziging om 09:00 te werken voor een nieuwe verbinding en lijkt hij niets te doen voor de sessie die iemand om 08:55 opende.

Cloudbeveiligingsgroepen voegen een derde model toe dat mensen vangt die op iptables hebben geleerd. Hun inkomende regels zijn een acceptatielijst die als verzameling wordt beoordeeld in plaats van als een wandeling op eerste match, ze zijn stateful, en het verwijderen van een acceptatieregel beëindigt geen flows die al worden gevolgd. Eerste-match-semantiek aannemen op een platform dat die niet heeft, leidt tot zelfverzekerde, verkeerde conclusies.

Lees de actieve regelset, niet het bestand dat u hebt bewerkt

Begin met wat de kernel nu daadwerkelijk afdwingt. Een opgeslagen configuratie die nooit is toegepast verklaart verrassend veel ongewijzigd gedrag, en het kost één opdracht om die uit te sluiten:

nft list ruleset
iptables-save

Vraag dan of uw regel eigenlijk wordt bereikt. Pakkettellers antwoorden daar direct op, en ze antwoorden beter dan welke redenering over bedoeling dan ook:

iptables -L FORWARD -v -n --line-numbers
nft list chain inet filter forward

Een blokkeerregel met nul pakketten na een echte testpoging is geen beleidsprobleem, het is een positieprobleem. Hem verplaatsen is een wijziging van één regel, en de syntaxis is precies wat de oorspronkelijke bug veroorzaakte. Met iptables -I voegt in en -A voegt toe aan het eind; met nftables insert plaatst een regel aan het begin van de keten terwijl add toevoegt aan het eind. Als een regel moet winnen, zeg dat dan expliciet in plaats van te vertrouwen op de volgorde die toevallig is geladen.

Bewijs of de flow wordt gevolgd

Voordat u de regel de schuld geeft, controleer of het verkeer eigenlijk een gevolgde verbinding is. Vraag de statustabel naar de specifieke flow in plaats van hem helemaal leeg te gooien:

conntrack -L -p tcp --dport 1194
conntrack -E -p tcp --dport 1194

De lijst toont de status en de resterende time-out, en zo onderscheidt u een gevestigde sessie van een nieuwe poging; de gebeurtenismodus drukt updates af zodra ze gebeuren, wat handig is terwijl u een client opnieuw verbindt. Als de flow al aanwezig is met een gevestigde status voordat u iets hebt aangeraakt, zal geen enkele bewerking van de filterregels zijn lot veranderen. Dat is geen bug in de firewall, het is het contract van stateful filteren.

Weerststa de snelkoppeling om de hele tabel op een productie-gateway te legen. conntrack -F is beschikbaar, en het vernietigt ook elke gevolgde flow op de machine, inclusief de beheersessie van waaruit u werkt en de tunnel die uw shell draagt. Afzonderlijke vermeldingen kunnen worden verwijderd wanneer u ze echt nodig hebt, maar een nieuwe flow vanaf een nieuwe bronpoort is meestal een schoner experiment.

Sommige paden worden niet gevolgd, en die gedragen zich omgekeerd. Verkeer dat als notrack in de raw-tabel is gemarkeerd, sommige tunnels die de normale hooks omzeilen, en asymmetrische routing die een flow over twee gateways verdeelt, produceren allemaal pakketten die één voor één worden beoordeeld, of een status die aan beide uiteinden nooit ontstaat. Als de tellers bij elk pakket bewegen, verdenk dan dat soort pad voordat u de volgorde verdenkt.

Test vanuit een nieuwe flow met een weg terug

Voordat u een regel test die de toegang op afstand kan afsnijden, leg een herstelpad aan: de console van de provider, een seriële console, een out-of-band beheeradres of een tweede interface dat de regel niet kan raken. Een rollback-timer is een redelijke metgezel, want die herstelt de vorige regelset zelfs als uw sessie midden in de test sterft.

Test daarna met een uitwisseling die de status nog niet kon dekken. Verbreek en herstel de verbinding van de client zodat een nieuwe vijf-tuple ontstaat, en kijk naar beide uiteinden terwijl dat gebeurt:

tcpdump -ni eth0 'tcp port 1194'
journalctl -k -n 50 --no-pager

Voer de test in beide richtingen uit. Een regel die de nieuwe inkomende handshake blokkeert, kan het antwoordpad nog steeds toestaan, of omgekeerd, en een eenzijdig resultaat is de gebruikelijke reden dat een blokkade maar half werkt. Verbind na de test nog één keer opnieuw om de stabiele toestand te bevestigen, en controleer of legitieme beheerstoegang het heeft overleefd; een regel die voor één poort is geschreven, heeft de gewoonte een breder bereik te raken dan bedoeld.

Leg doel en positie vast samen met de regel

Een regel zonder vastgelegd doel is een regel die niemand durft te verwijderen. Houd bij elke blokkade-vermelding de flow vast die hij beschermt, de keten en hook waarin hij leeft, de positie die hij ten opzichte van bredere acceptaties moet houden, en de test die dat bewees. Wanneer iemand zes maanden later de omliggende regelset bewerkt, is die notitie de enige waarschuwing dat de positie bewust was.

Voordat u de wijziging sluit, bevestig vier dingen: de draaiende regelset komt overeen met het bestand, de nieuwe regel heeft tellers die niet nul zijn na een nieuwe poging, de tegenrichting en beheerstoegang werken nog, en u hebt één keer opnieuw verbonden om de stabiele toestand te bewijzen in plaats van de toestand van een sessie die ouder is dan de wijziging. Als iets daarvan niet is geverifieerd, is de wijziging niet klaar, wat de tunnel ook doet.