Ugunsmūra noteikuma maiņa nedarbojas: noteikumu secība un savienojuma stāvoklis

Jūs mainījāt noteikumu, pārlādējāt noteikumu kopu, un tunelis uzvedas tieši tāpat kā iepriekš. Šim rezultātam ir divi bieži cēloņi, un tiem vajadzīgi atšķirīgi testi. Vai nu jaunais noteikums atrodas aiz iepriekšēja noteikuma, kas jau ir pieņēmis paketi, vai arī novērojamā apmaiņa ir izsekots savienojums, ko izmaiņas nekad nepārvērtē. Noteikums failā izsaka nodomu; paketes likteni nosaka aktīvais ceļš, ar ko tā sastopas. Izpildiet tālāk minētās pārbaudes secīgi un tikmēr turiet atvērtu atgriešanās ceļu.

Noteikumu secība un savienojuma stāvoklis ir dažādi bojājumi

Sakārtotas ķēdes tiek vērtētas no augšas uz leju, un pirmais noteikums, kas sasniedz galīgo spriedumu, pārtrauc gājienu pa šo ķēdi. Ievietojiet plašu atļauju virs rūpīgi uzrakstīta bloķēšanas noteikuma, un bloķēšanas noteikums kļūst par dokumentāciju: tas ir kopā, tā skaitītājs ir nulle, un neviena pakete to nekad nesasniegs. Tas pats teksts, piemērots citai ķēdei, arī neko nepierāda. nftables bāzes ķēdes tiek piesaistītas āķiem pēc prioritātēm, tāpēc atļauja vienā ķēdē neliedz citai ķēdei citā āķī vai prioritātē redzēt to pašu paketi.

Savienojumu izsekošana rada otro simptomu, un no ārpuses tas izskatās identiski. Kad plūsma ir stāvokļu tabulā, atļauja established-or-related netālu no ķēdes augšas atgriežas vēl pirms jūsu jaunais noteikums tiek izskatīts. NAT kartējumiem ir tāda pati īpašība: tulkojums tika fiksēts, kad plūsma sākās, tāpēc mainīts postrouting noteikums nepārraksta jau darbojošos sesiju. Tāpēc izmaiņas šķiet darbojamies 09:00 jaunam savienojumam un šķiet neko nedarām sesijai, ko kāds atvēra 08:55.

Mākoņa drošības grupas pievieno trešo modeli, kas noķer cilvēkus, kuri mācījušies uz iptables. To ienākošie noteikumi ir atļauju saraksts, kas tiek vērtēts kā kopa, nevis kā gājiens pēc pirmās atbilstības, tie ir stāvokļa, un atļaujas noteikuma noņemšana neizbeidz jau izsekotās plūsmas. Pirmās atbilstības semantikas pieņemšana platformā, kurai tās nav, noved pie pārliecinātiem, nepareiziem secinājumiem.

Lasiet aktīvo noteikumu kopu, nevis failu, ko mainījāt

Sāciet ar to, ko kodols izpilda tieši tagad. Saglabāta konfigurācija, kas nekad nav piemērota, izskaidro pārsteidzoši daudz nemainītas uzvedības, un tās izslēgšana maksā vienu komandu:

nft list ruleset
iptables-save

Tad pajautājiet, vai jūsu noteikums vispār tiek sasniegts. Pakešu skaitītāji atbild tieši, un atbild labāk nekā jebkura spriešana par nodomu:

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

Bloķēšanas noteikums ar nulli pakešu pēc reāla testa mēģinājuma nav politikas problēma, tā ir pozīcijas problēma. Tā pārvietošana ir vienas rindas izmaiņa, un sintakse ir tieši tas, kas izraisīja sākotnējo kļūdu. Ar iptables -I ievieto, bet -A pievieno beigās; ar nftables insert ievieto noteikumu ķēdes sākumā, bet add pievieno beigās. Kad noteikumam ir jāuzvar, sakiet to skaidri, nevis paļaujieties uz secību, kas tika ielādēta nejauši.

Pierādiet, vai plūsma tiek izsekota

Pirms vainojat noteikumu, pārbaudiet, vai plūsma vispār ir izsekots savienojums. Jautājiet stāvokļu tabulai par konkrēto plūsmu, nevis izlejiet to visu:

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

Saraksts parāda stāvokli un atlikušo laika limitu, un tā jūs atšķirat nodibinātu sesiju no jauna mēģinājuma; notikumu režīms izdrukā atjauninājumus, tiklīdz tie notiek, kas ir noderīgi, kamēr atkārtoti pievienojat klientu. Ja plūsma jau pastāv nodibinātā stāvoklī pirms jūs kaut ko aiztiecat, neviena filtra noteikumu izmaiņa nemainīs tās likteni. Tā nav ugunsmūra kļūda, tā ir stāvokļa filtrēšanas līgums.

Pretojieties kārdinājumam iztīrīt visu tabulu ražošanas vārtejā. conntrack -F ir pieejama, un tā iznīcina arī katru izsekoto plūsmu mašīnā, tostarp pārvaldības sesiju, no kuras strādājat, un tuneli, kas nes jūsu čaulu. Atsevišķus ierakstus var dzēst, kad tas tiešām nepieciešams, bet jauna plūsma no jauna avota porta parasti ir tīrāks eksperiments.

Daži ceļi netiek izsekoti, un tie uzvedas pretēji. Trafiks, kas atzīmēts notrack raw tabulā, daži tuneļi, kas apiet parastos āķus, un asimetriska maršrutēšana, kas sadala plūsmu starp divām vārtēm, visi rada paketes, kas tiek vērtētas pa vienai, vai stāvokli, kas nekad netiek izveidots abos galos. Ja skaitītāji kustas ar katru paketi, aizdomās turiet šādu ceļu, pirms aizdomās turam secību.

Testējiet no jaunas plūsmas ar atgriešanās ceļu

Pirms testējat noteikumu, kas varētu pārtraukt attālinātu piekļuvi, izveidojiet atkopšanas ceļu: pakalpojumu sniedzēja konsoli, seriālo konsoli, ārpusjoslas pārvaldības adresi vai otru saskarni, kam noteikums nevar atbilst. Atritināšanas taimeris ir saprātīgs pavadonis, jo tas atjaunos iepriekšējo noteikumu kopu arī tad, ja jūsu sesija nomirs testa vidū.

Pēc tam testējiet ar apmaiņu, ko stāvoklis vēl nevarēja noklāt. Atvienojiet un pievienojiet klientu no jauna, lai izveidotos jauns piecinieks, un vērojiet abus galus, kamēr tas notiek:

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

Veiciet testu abos virzienos. Noteikums, kas bloķē jauno ienākošo rokasspiedienu, joprojām var atļaut atbildes ceļu, vai otrādi, un vienvirziena rezultāts ir parastais iemesls, kāpēc bloķēšana darbojas uz pusi. Pēc testa pievienojieties vēlreiz, lai apstiprinātu stabilo stāvokli, un pārbaudiet, vai likumīgā pārvaldības piekļuve izdzīvoja; noteikums, kas rakstīts vienam portam, mēdz atbilst plašākam diapazonam nekā paredzēts.

Pierakstiet mērķi un pozīciju kopā ar noteikumu

Noteikums bez pierakstīta mērķa ir noteikums, ko neviens neuzdrošinās noņemt. Blakus katram bloķēšanas ierakstam glabājiet plūsmu, ko tas aizsargā, ķēdi un āķi, kurā tas dzīvo, pozīciju, kas tam jāieņem attiecībā pret plašākām atļaujām, un testu, kas to pierādīja. Kad pēc pusgada kāds rediģēs apkārtējo noteikumu kopu, šī piezīme būs vienīgais brīdinājums, ka pozīcija bija apzināta.

Pirms aizverat izmaiņas, apstipriniet četras lietas: darbojošā noteikumu kopa atbilst failam, jaunajam noteikumam pēc jauna mēģinājuma ir skaitītāji, kas nav nulle, pretējais virziens un pārvaldības piekļuve joprojām darbojas, un jūs vienreiz pievienojāties no jauna, lai pierādītu stabilo stāvokli, nevis sesijas, kas vecāka par izmaiņām, stāvokli. Ja kaut kas no tā nav pārbaudīts, izmaiņas nav pabeigtas, lai ko arī tunelis darītu.