Измена правила заштитног зида не ради: редослед правила и стање везе

Изменили сте правило, поново учитали скуп правила, а тунел се понаша тачно као раније. Овај исход има два честа узрока и они траже различите тестове. Или ново правило стоји после ранијег правила које је већ прихватило пакет, или је размена коју посматрате праћена веза коју измена никада не преоцењује. Правило у датотеци изражава намеру; о судбини пакета одлучује активни пут на који наиђе. Прођите кроз провере испод редом и притом држите отворен пут назад.

Редослед правила и стање везе су различити дефекти

Уређени ланци се оцењују одозго надоле и прво правило које дође до коначне пресуде завршава пролаз кроз тај ланац. Поставите широко одобрење изнад пажљиво написаног правила закључавања и правило закључавања постаје документација: оно је у скупу, његов бројач је нула и ниједан пакет га никада неће достићи. Исти текст примењен на други ланац такође ништа не доказује. У nftables основне ланце се каче на куке по приоритетима, па одобрење у једном ланцу не спречава други ланац на другој куци или приоритету да види исти пакет.

Праћење веза ствара други симптом и споља изгледа исто. Када је ток у табели стања, одобрење за established-or-related близу врха ланца се враћа пре него што се ваше ново правило уопште размотри. NAT пресликавања имају исто својство: превод је био фиксиран када је ток почео, па измењено правило postrouting не преписује сесију која већ траје. Зато измена изгледа да ради у 09:00 за нову везу и изгледа да не чини ништа за сесију коју је неко отворио у 08:55.

Безбедносне групе у облаку додају трећи модел који хвата људе који су учили на iptables. Њихова улазна правила су списак дозвола који се оцењује као скуп, а не као пролаз по првом подударању, имају стање и уклањање правила дозволе не прекида токове који се већ прате. Претпостављање семантике првог подударања на платформи која је нема води до самоуверених, погрешних закључака.

Читајте активни скуп правила, а не датотеку коју сте изменили

Почните од онога што језгро управо сада спроводи. Сачувана конфигурација која никада није примењена објашњава изненађујуће много непромењеног понашања, а њено искључивање кошта једне команде:

nft list ruleset
iptables-save

Затим питајте да ли се ваше правило уопште достиже. Бројачи пакета одговарају на то директно и одговарају боље од било каквог размишљања о намери:

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

Правило закључавања са нула пакета после стварног покушаја теста није проблем политике, то је проблем позиције. Премештање је измена у једном реду, а синтакса је тачно оно што је изазвало првобитну грешку. Са iptables -I умеће, а -A додаје на крај; са nftables insert поставља правило на почетак ланца, а add додаје на крај. Када правило мора да победи, реците то изричито уместо да се поуздате у редослед који се случајно учитао.

Докажите да ли се ток прати

Пре него што окривите правило, проверите да ли је саобраћај уопште праћена веза. Питајте табелу стања за конкретан ток уместо да је целу исуручете:

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

Списак показује стање и преостали рок и тако разликујете успостављену сесију од новог покушаја; режим догађаја штампа ажурирања док се дешавају, што је корисно док поново повезујете клијента. Ако је ток присутан са успостављеним стањем пре него што сте било шта дотакли, ниједна измена филтерских правила неће променити његову судбину. То није дефект у заштитном зиду, то је уговор филтрирања са стањем.

Одуприте се краћем путу да исчистите целу табелу на производном пролазу. conntrack -F је доступно и такође уништава сваки праћени ток на машини, укључујући административну сесију из које ради и тунел који носи вашу љуску. Појединачни уноси могу се брисати када заиста треба, али нов ток са новог изворног порта обично је чистији експеримент.

Неки путеви се не прате и понашају се обрнуто. Саобраћај означен као notrack у табели raw, неки тунели који заобилазе уобичајене куке и асиметрично усмеравање које дели ток између два пролаза сви стварају пакете који се оцењују један по један, или стање које се никада не ствара на оба краја. Ако се бројачи померају за сваки пакет, сумњајте на такав пут пре него на редослед.

Тестирајте из новог тока са путем назад

Пре него што тестирате правило које може да одсече удаљени приступ, успоставите пут за опоравак: конзолу добављача, серијску конзолу, адресу за управљање изван опсега или други интерфејс који правило не може да погоди. Тајмер за враћање је разуман пратилац, јер ће вратити претходни скуп правила чак и ако ваша сесија умре усред теста.

Затим тестирајте разменом коју стање није могло већ да покрије. Искључите и поново повежите клијента да настане нова петица и посматрајте оба краја док се то дешава:

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

Изведите тест у оба смера. Правило које блокира ново долазно руковање ипак може да дозволи пут одговора, или обрнуто, а једносмерни резултат је уобичајен разлог зашто закључавање ради на пола. Поново се повежите једном после теста да потврдите стабилно стање и проверите да ли је легитимни приступ управљању преживео; правило написано за један порт има навику да се подудари са ширим опсегом него што је предвиђено.

Забележите сврху и позицију заједно са правилом

Правило без забележене сврхе је правило које нико не сме да уклони. Поред сваког уноса закључавања држите ток који штити, ланац и куку у којој живи, позицију коју мора да држи према ширим одобрењима и тест који је то доказао. Када неко после шест месеци измени околни скуп правила, та белешка је једино упозорење да је позиција била намерна.

Пре него што затворите измену, потврдите четири ствари: скуп правила који ради одговара датотеци, ново правило има бројаче различите од нуле после новог покушаја, супротни смер и приступ управљању још раде и једном сте се поново повезали да докажете стабилно стање, а не стање сесије старије од измене. Ако било шта од тога није проверено, измена није завршена, шта год тунел радио.