Ndryshimi i rregullit të firewall-it nuk funksionon: renditja e rregullave dhe gjendja e lidhjes

Redaktuat rregullin, ringarkuat grupin e rregullave dhe tuneli sillet saktësisht si më parë. Ky rezultat ka dy shkaqe të zakonshme dhe ato kërkojnë teste të ndryshme. Ose rregulli i ri qëndron pas një rregulli të mëparshëm që e ka pranuar tashmë paketën, ose shkëmbimi që po vëzhgoni është një lidhje e gjurmuar që ndryshimi nuk e rivlerëson kurrë. Një rregull në një skedar shpreh qëllimin; atë që vendos paketën e përcakton rruga aktive që ajo takon. Kaloni nëpër kontrollet më poshtë me radhë dhe gjatë kësaj mbani një rrugë kthimi të hapur.

Renditja e rregullave dhe gjendja e lidhjes janë defekte të ndryshme

Zinxhirët e renditur vlerësohen nga lart poshtë dhe rregulli i parë që arrin një verdikt përfundimtar e përfundon kalimin nëpër atë zinxhir. Vendosni një leje të gjerë mbi një rregull bllokimi të shkruar me kujdes dhe rregulli i bllokimit bëhet dokumentacion: është në grup, numëruesi i tij është zero dhe asnjë paketë nuk do ta arrijë kurrë. I njëjti tekst i aplikuar në një zinxhir tjetër gjithashtu nuk provon asgjë. Në nftables zinxhirët bazë lidhen me hook-e sipas prioriteteve, kështu që një leje në një zinxhir nuk e pengon një zinxhir tjetër në një hook ose prioritet tjetër të shohë të njëjtën paketë.

Gjurmimi i lidhjeve prodhon simptomën e dytë dhe nga jashtë duket identike. Pasi një rrjedhë është në tabelën e gjendjeve, një leje për established-or-related afër majës së zinxhirit kthehet para se rregulli juaj i ri të konsultohet fare. Mapimet NAT kanë të njëjtën veti: përkthimi u fiksua kur rrjedha filloi, kështu që një rregull postrouting i redaktuar nuk e rishkruan një sesion që tashmë po ecën. Kjo është arsyeja pse një ndryshim duket se funksionon në 09:00 për një lidhje të re dhe duket se nuk bën asgjë për sesionin që dikush e hapi në 08:55.

Grupet e sigurisë në re shtojnë një model të tretë që kap njerëzit që mësuan në iptables. Rregullat e tyre hyrëse janë një listë lejesh që vlerësohet si bashkësi dhe jo si kalim me përputhjen e parë, janë me gjendje dhe heqja e një rregulli lejeje nuk i ndërpret rrjedhat që tashmë gjurmohen. Të supozosh semantikën e përputhjes së parë në një platformë që nuk e ka çon në përfundime të sigurta dhe të gabuara.

Lexoni grupin aktiv të rregullave, jo skedarin që redaktuat

Filloni me atë që kerneli po zbaton tani. Një konfigurim i ruajtur që nuk u aplikua kurrë shpjegon një numër befasues sjelljesh të pandryshuara dhe përjashtimi i tij kushton një komandë të vetme:

nft list ruleset
iptables-save

Pastaj pyesni nëse rregulli juaj arrihet fare. Numëruesit e paketave përgjigjen drejtpërdrejt dhe përgjigjen më mirë se çdo arsyetim për qëllimin:

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

Një rregull bllokimi me zero paketa pas një përpjekjeje reale testimi nuk është problem politike, është problem pozicioni. Zhvendosja e tij është një ndryshim prej një rreshti dhe sintaksa është pikërisht ajo që shkaktoi gabimin origjinal. Me iptables -I fut dhe -A shton në fund; me nftables insert vendos një rregull në fillim të zinxhirit ndërsa add shton në fund. Kur një rregull duhet të fitojë, thojeni shprehimisht në vend që të mbështeteni në renditjen që u ngarkua rastësisht.

Provoni nëse rrjedha po gjurmohet

Përpara se të fajësoni rregullin, kontrolloni nëse trafiku është fare lidhje e gjurmuar. Pyetni tabelën e gjendjeve për rrjedhën specifike në vend që ta derdhni të gjithë:

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

Listimi tregon gjendjen dhe afatin e mbetur, dhe kështu e dalloni një sesion të vendosur nga një përpjekje e re; modaliteti i ngjarjeve shtyp përditësimet ndërsa ndodhin, gjë që është e dobishme ndërsa rilidhni një klient. Nëse rrjedha është e pranishme me gjendje të vendosur përpara se të keni prekur gjë, asnjë redaktim i rregullave të filtrimit nuk do ta ndryshojë fatin e saj. Ky nuk është defekt në firewall, ky është kontrata e filtrimit me gjendje.

Rezistoni tundimit për të zbrazur të gjithë tabelën në një portë prodhimi. conntrack -F është në dispozicion dhe gjithashtu shkatërron çdo rrjedhë të gjurmuar në makinë, duke përfshirë sesionin e menaxhimit nga i cili punoni dhe tunelin që mban shell-in tuaj. Regjistrimet individuale mund të fshihen kur ju nevojiten vërtet, por një rrjedhë e re nga një port i ri burimi është zakonisht një eksperiment më i pastër.

Disa rrugë nuk gjurmohen dhe sillen në të kundërt. Trafiku i shënuar si notrack në tabelën raw, disa tunele që anashkalojnë hook-et normale dhe rrugëzimi asimetrik që ndan një rrjedhë mes dy portave prodhojnë të gjitha paketa të vlerësuara një nga një, ose gjendje që nuk krijohet kurrë në të dy skajet. Nëse numëruesit lëvizin për çdo paketë, dyshoni për një rrugë të tillë përpara se të dyshoni për renditjen.

Testoni nga një rrjedhë e re me një rrugë kthimi

Përpara se të testoni një rregull që mund të presë aksesin në distancë, vendosni një rrugë rikuperimi: konsolën e ofruesit, një konsolë serike, një adresë menaxhimi jashtë brezit ose një ndërfaqe të dytë që rregulli nuk mund ta përputhë. Një kohëmatës rikthimi është një shok i arsyeshëm, sepse do të rivendosë grupin e mëparshëm të rregullave edhe nëse sesioni juaj vdes në mes të testit.

Pastaj testoni me një shkëmbim që gjendja nuk mund ta kishte mbuluar tashmë. Shkëputni dhe rilidhni klientin që të krijohet një pesëshe e re dhe vëzhgoni të dy skajet ndërsa kjo ndodh:

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

Kryeni testin në të dy drejtimet. Një rregull që bllokon shtrëngimin e dorës hyrëse të re mund të lejojë ende rrugën e përgjigjes, ose anasjelltas, dhe një rezultat njëdrejtuesh është arsyeja e zakonshme pse një bllokim funksionon gjysmë. Rilidhuni një herë pas testit për të konfirmuar gjendjen e qëndrueshme dhe kontrolloni nëse aksesi legjitim i menaxhimit mbijetoi; një rregull i shkruar për një port ka zakon të përputhet me një interval më të gjerë se sa synohej.

Regjistroni qëllimin dhe pozicionin bashkë me rregullin

Një rregull pa qëllim të regjistruar është një rregull që askush nuk guxon ta heqë. Pranë çdo regjistrimi bllokimi mbani rrjedhën që mbron, zinxhirin dhe hook-un ku jeton, pozicionin që duhet të mbajë ndaj lejeve më të gjera dhe testin që e provoi. Kur dikush redakton grupin e rregullave përreth gjashtë muaj më vonë, ai shënim është i vetmi paralajmërim se pozicioni ishte i qëllimshëm.

Përpara se ta mbyllni ndryshimin, konfirmoni katër gjëra: grupi i rregullave që po ecën përputhet me skedarin, rregulli i ri ka numërues jo zero pas një përpjekjeje të re, drejtimi i kundërt dhe aksesi i menaxhimit ende funksionojnë dhe jeni rilidhur një herë për të provuar gjendjen e qëndrueshme dhe jo gjendjen e një sesioni më të vjetër se ndryshimi. Nëse ndonjë prej këtyre nuk është verifikuar, ndryshimi nuk është përfunduar, çfarëdo që bën tuneli.