Промяна на правило в защитна стена не работи: ред на правилата и състояние на връзката

Редактирахте правилото, презаредихте набора от правила, а тунелът се държи точно както преди. Този резултат има две чести причини и те изискват различни тестове. Или новото правило стои след по-ранно правило, което вече е приело пакета, или обменът, който наблюдавате, е проследявана връзка, която промяната никога не преоценява. Правилото във файл изразява намерение; това, което решава съдбата на пакета, е активният път, който среща. Минете през проверките по-долу по ред и през цялото време пазете път за връщане.

Редът на правилата и състоянието на връзката са различни повреди

Подредените вериги се оценяват отгоре надолу и първото правило, което стигне до окончателна присъда, прекратява обхождането на тази верига. Поставете широко разрешение над внимателно написано правило за блокиране и правилото за блокиране се превръща в документация: то е в набора от правила, броячът му е нула и нито един пакет няма да го достигне. Същият текст, приложен към друга верига, също не доказва нищо. В nftables базовите вериги се прикачват към куки с приоритети, така че разрешение в една верига не пречи на друга верига на различна кука или приоритет да види същия пакет.

Проследяването на връзки създава втория симптом и отвън той изглежда идентичен. След като потокът е в таблицата на състоянията, разрешение за установени или свързани близо до върха на веригата се връща, преди новото ви правило да бъде разгледано. 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

Изпълнете теста в двете посоки. Правило, което блокира новото входящо ръкостискане, все още може да разрешава пътя за отговор или обратното, а едностранният резултат е обичайната причина блокировката да работи наполовина. Свържете се отново веднъж след теста, за да потвърдите устойчивото състояние, и проверете дали законният достъп за управление е оцелял; правило, написано за един порт, има навика да съвпада с по-широк диапазон от предвиденото.

Записвайте целта и позицията заедно с правилото

Правило без записана цел е правило, което никой не смее да премахне. До всеки запис за блокиране пазете потока, който защитава, веригата и куката, в която живее, позицията, която трябва да заема спрямо по-широките разрешения, и теста, който го е доказал. Когато някой редактира околния набор от правила шест месеца по-късно, тази бележка е единственото предупреждение, че позицията е била умишлена.

Преди да затворите промяната, потвърдете четири неща: работещият набор от правила съвпада с файла, новото правило има ненулеви броячи след нов опит, обратната посока и достъпът за управление все още работят и сте се свързали отново веднъж, за да докажете устойчивото състояние, а не състоянието на сесия, която е по-стара от промяната. Ако нещо от това не е проверено, промяната не е завършена, каквото и да прави тунелът.