Firewallreëlverandering werk nie: reëlvolgorde en verbindingstatus

Jy het die reël verander, die reëlstel herlaai, en die tonnel gedra hom presies soos voorheen. Daardie uitkoms het twee algemene oorsake, en hulle verg verskillende toetse. Óf die nuwe reël sit ná 'n vroeëre reël wat die pakkie al aanvaar het, óf die uitruiling wat jy dophou is 'n gevolgde verbinding wat die verandering nooit herwaardeer nie. 'n Reël in 'n lêer stel bedoeling; wat die pakkie beslis, is die aktiewe pad wat dit ontmoet. Werk die kontroles hieronder in volgorde deur, en hou 'n weg terug oop terwyl jy dit doen.

Reëlvolgorde en verbindingstatus is verskillende foute

Geordende kettings word van bo na onder geëvalueer, en die eerste reël wat 'n beëindigende uitspraak bereik, beëindig die wandeling deur daardie ketting. Plaas 'n breë aanvaarding bo 'n sorgvuldig geskrewe inperkingsreël, en die inperkingsreël word dokumentasie: dit is in die reëlstel, dit het 'n teller van nul, en geen pakkie sal dit ooit bereik nie. Dieselfde teks wat op 'n ander ketting toegepas word, bewys ook niks. In nftables heg basiskettings by hooks teen prioriteite, so 'n aanvaarding in een ketting verhoed nie dat 'n ander ketting op 'n ander hook of prioriteit dieselfde pakkie sien nie.

Verbindingnasporing lewer die tweede simptoom, en dit lyk van buite identies. Sodra 'n vloei in die toestandstabel is, keer 'n aanvaarding vir gevestigde-of-verwante naby die bokant van die ketting terug voordat jou nuwe reël geraadpleeg word. NAT-kaarte het dieselfde eienskap: die vertaling is vasgestel toe die vloei begin het, so 'n veranderde postrouting-reël herskryf nie 'n sessie wat al loop nie. Dit is hoekom 'n verandering om 09:00 vir 'n nuwe verbinding blyk te werk en vir die sessie wat iemand om 08:55 oopgemaak het, blyk niks te doen nie.

Wolkbeveiligingsgroepe voeg 'n derde model by wat mense vasvang wat op iptables geleer het. Hul inkomende reëls is 'n toelaatlys wat as 'n versameling geëvalueer word eerder as 'n eerste-treffer-wandeling, hulle is toestandsvol, en die verwydering van 'n toelaatreël beëindig nie vloeie wat al gevolg word nie. Om eerste-treffer-semantiek te aanvaar op 'n platform wat dit nie het nie, lei tot selfversekerde, verkeerde gevolgtrekkings.

Lees die aktiewe reëlstel, nie die lêer wat jy verander het nie

Begin met wat die kernel nou werklik afdwing. 'n Gestoor konfigurasie wat nooit toegepas is nie, verduidelik 'n verbasende aantal onveranderde gedragspatrone, en dit kos een opdrag om dit uit te sluit:

nft list ruleset
iptables-save

Vra dan of jou reël hoegenaamd bereik word. Pakkiemeters antwoord dit direk, en hulle antwoord dit beter as enige redenasie oor bedoeling:

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

'n Inperkingsreël met nul pakkies ná 'n werklike toetspoging is nie 'n beleidsprobleem nie, dit is 'n posisieprobleem. Om dit te verskuif is 'n eenreëlverandering, en die sintaksis is presies wat die oorspronklike fout veroorsaak het. Met iptables, -I voeg in en -A voeg by; met nftables, insert plaas 'n reël aan die begin van die ketting terwyl add byvoeg. Wanneer 'n reël moet wen, sê dit eksplisiet eerder as om die volgorde te vertrou wat toevallig gelaai is.

Bewys of die vloei gevolg word

Voordat jy die reël blameer, kyk of die verkeer hoegenaamd 'n gevolgde verbinding is. Vra die toestandstabel vir die spesifieke vloei eerder as om alles uit te stort:

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

Die lys wys die toestand en die oorblywende tydsperdatum, en dit is hoe jy 'n gevestigde sessie van 'n nuwe poging onderskei; die gebeurtenismodus druk bywerkings soos hulle gebeur, wat nuttig is terwyl jy 'n kliënt weer koppel. As die vloei teenwoordig is met 'n gevestigde toestand voordat jy iets aangeraak het, sal geen wysiging aan die filterreëls sy lot verander nie. Dit is nie 'n fout in die firewall nie, dit is die kontrak van toestandsvolle filtering.

Weerstaan die kortpad om die hele tabel op 'n produksiegateway te spoel. conntrack -F is beskikbaar, en dit vernietig ook elke gevolgde vloei op die boks, insluitend die bestuursessie waaruit jy werk en die tonnel wat jou dop dra. Individuele inskrywings kan uitgevee word wanneer jy dit regtig nodig het, maar 'n nuwe vloei vanaf 'n nuwe bronpoort is gewoonlik 'n skoner eksperiment.

Sommige paaie word nie gevolg nie, en hulle gedra hulle omgekeerd. Verkeer gemerk notrack in die raw-tabel, sommige tonnels wat die normale hooks omseil, en asimmetriese routering wat 'n vloei oor twee gateways verdeel, lewer almal pakkies wat een op 'n slag geëvalueer word, of toestand wat nooit aan beide kante geskep word nie. As die meters vir elke pakkie beweeg, vermoed daardie soort pad voordat jy volgorde vermoed.

Toets vanuit 'n nuwe vloei met 'n weg terug

Voordat jy 'n reël toets wat afgeleë toegang kan afsny, vestig 'n herstelpad: die verskafferkonsole, 'n reekskonsole, 'n buiteband-bestuursadres, of 'n tweede koppelvlak wat die reël nie kan pas nie. 'n Terugroltydhouer is 'n redelike metgesel, want dit sal die vorige reëlstel herstel selfs as jou sessie midde-in die toets sterf.

Toets dan met 'n uitruiling wat nie al deur toestand gedek kon word nie. Ontkoppel en herkoppel die kliënt sodat 'n nuwe vyf-tupel geskep word, en dophou beide kante terwyl dit gebeur:

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

Voer die toets in beide rigtings uit. 'n Reël wat die nuwe inkomende handdruk blokkeer, kan steeds die antwoordpad toelaat, of omgekeerd, en 'n eenrigtingresultaat is die gewone rede waarom 'n inperking half werk. Herkoppel nog een keer ná die toets om die bestendige toestand te bevestig, en kyk of wettige bestuurstoegang oorleef het; 'n reël wat geskryf is om een poort te pas, het die gewoonte om 'n wyer reeks as bedoel te pas.

Teken doel en posisie saam met die reël aan

'n Reël sonder 'n aangetekende doel is 'n reël wat niemand waag om te verwyder nie. Hou by elke inperkingsinskrywing die vloei wat dit beskerm, die ketting en hook waarin dit leef, die posisie wat dit relatief tot breër aanvaardings moet hou, en die toets wat dit bewys het. Wanneer iemand ses maande later die omliggende reëlstel verander, is daardie nota die enigste waarskuwing dat die posisie doelbewus was.

Voordat jy die verandering afsluit, bevestig vier dinge: die lopende reëlstel stem ooreen met die lêer, die nuwe reël het nie-nul meters ná 'n nuwe poging, die omgekeerde rigting en bestuurstoegang werk steeds, en jy het een keer weer gekoppel om die bestendige toestand te bewys eerder as die toestand van 'n sessie wat die verandering voorafdateer. As enigiets daarvan onbevestig is, is die verandering nie klaar nie, wat die tonnel ook al doen.