Чому налаштування фаєрвола Linux дає збої на проді
Правила фільтрації накопичуються роками: ланцюжки правляться під конкретний інцидент, старі записи ніхто не знімає, і поступово налаштування фаєрвола Linux перетворюється на археологію.
Інженер, який відкриває конфігурацію, бачить сотні рядків, але не може відповісти, який з них закриває який сервіс і що станеться, якщо його видалити.
Звідси два постійні наслідки. На периметрі залишаються відкриті порти «на всякий випадок» — під налагодження, старий стенд, інтеграцію, яка давно не потрібна; кожен такий порт переживає зміну команди й випадає з огляду.
І тут же зворотна біда: блокування легітимного трафіку після правки одного правила — закриваєш доступ для однієї підмережі, а разом з ним відвалюється моніторинг, вивантаження логів або резервне копіювання, що ходили по тому ж діапазону.
Корінь — правила без власника. У запису немає прив'язки до сервісу, коментаря та дати ревізії, тому його бояться чіпати й залишають як є.
Хаос у правилах фільтрації зростає не через неакуратність інженерів, а через те, що зміна не перевіряється на тестовому контурі й не відкочується за хвилину, коли щось пішло не так.
Навіть перехід на декларативний опис у nftables сам по собі завдання не вирішує: якщо правила не пов'язані з реальним трафіком, сервісами та власниками, порядок залишиться попереднім. Розбираємо, як це закривається — від інвентаризації портів до змін, які перевіряються до проду.
Що дає єдиний звід правил фільтрації трафіку
Правила фільтрації, розкидані по вузлах і правлені вручну через консоль, живуть до першої аварії: ніхто не пам'ятає, навіщо відкрито порт і хто його закриє.
Єдиний звід — це один опис політики, який застосовується на всіх серверах однаково й зберігається поруч із конфігурацією інших сервісів.
Керована фільтрація трафіку перетворює мережеві доступи на версіонований набір: зміни проходять перевірку, а не вносяться «на живу» на бойовому вузлі.
Ключовий ефект — скорочення вікна простою при змінах.
Набір правил збирається повністю й застосовується однією транзакцією: nftables підміняє таблицю атомарно, тому з'єднання не рвуться на середині правки, а невдалий варіант відкочується за таймером, якщо сервіс не підтвердив доступність.
Вікно зменшується з хвилин ручної роботи до секунд, а частина змін проходить взагалі без розриву вже встановлених з'єднань.
З переліку інцидентів зникає цілий клас відмов: правила, забуті після зняття сервісу з вузла; дублі та перетини, де останній збіг перекриває потрібний; порти, відкриті «на час налагодження» й залишені назавжди.
Прозорість мережевих доступів досягається тим, що карта «хто до кого і на якому порту» збирається з самих правил і журналів, а не відновлюється з пам'яті в момент аварії.
Час відновлення сервісу перестає залежати від того, хто з інженерів на зміні: стан фільтрації відтворюється на новому вузлі з того ж зводу за хвилини, а повернення до попередньої ревізії — це відкат набору, а не пошук помилки в довгому списку рядків.
Політика заборони за замовчуванням при цьому гарантує, що забуте правило закриває доступ, а не відкриває його.
Пакетний, зонний та хмарний режими фільтрації
Вибір інструменту фільтрації визначає, де живуть правила, хто їх змінює й чи переживуть вони оновлення системи. При налаштуванні фаєрвола Linux зазвичай обирають між чотирма режимами — від ручних ланцюжків до зовнішніх груп безпеки.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| iptables | Готові скрипти, точкові правила на одному хості | Таблиці читаються лінійно: зі зростанням кількості правил зростає затримка, синтаксис не розвивається |
| nftables | Складні набори правил, потрібні множини адрес і загальна логіка для IPv4 та IPv6 | Старі конфігурації доводиться переписувати, частина панелей керування з ним ще не працює |
| firewalld і зонна модель фільтрації | Хости зі змінним профілем: офіс, VPN, публічний інтерфейс — перемикання без перезбирання ланцюжків | Абстракція зон приховує низькорівневі можливості, правила-винятки складніше налагоджувати |
| Групи безпеки хмари | Машини в хмарі, де фільтрація задається на рівні мережі | Не закривають трафік всередині хоста й між контейнерами, залежать від майданчика — локальний фаєрвол все одно потрібен |
На практиці режими комбінують: зовнішні групи безпеки відсікають зайве до машини, локальний фаєрвол закриває решту всередині. Розбір починаємо з карти сервісів і напрямків трафіку.
Порядок впровадження: від інвентаризації до регламенту
Правила не пишуться «на око»: спочатку потрібно зрозуміти, що реально ходить по мережі, інакше закритий порт — це або діра, або сервіс, що впав. Роботу ведемо від інвентаризації до регламенту, щоб після передачі зміни вносили ваші інженери без нашої участі.
- Аудит мережевих правил — знімаємо поточні ланцюжки iptables, nftables та зони firewalld, звіряємо з фактично працюючими сервісами. Знаходимо дублі та дозволи «any-any», що залишилися від видалених сервісів.
- Схема мережевих потоків — фіксуємо, хто з ким спілкується: джерело, призначення, порт, протокол, сенс потоку. Схему узгоджуємо з власниками сервісів, а не тільки з адміністраторами.
- Налаштування правил — заборона за замовчуванням плюс явні дозволи, згруповані за призначенням, з коментарем до кожного правила.
- Перевірка на тестовому контурі — копія топології, реальний трафік і негативні сценарії: що саме відвалиться, якщо закрити зайве.
- Контрольоване перенесення правил — застосовуємо поетапно, зі скриптом відкату та вікном, коли повернення займає хвилини, а не години.
- Регламент змін — порядок узгодження правки, фіксація в системі контролю версій, періодичний перегляд застарілих дозволів.
Після передачі залишається не набір команд, а відтворюваний процес: правка проходить перевірку на контурі й не перетворюється на сюрприз о третій годині ночі. Регламент описує, хто і як вносить зміни, — це знімає залежність від конкретної людини.
Що передаємо на руки: схеми, політики, регламенти
Здаємо не працюючий фаєрвол, а набір артефактів, за яким ваша команда зможе змінювати конфігурацію без нас. Усе, що йде в бойове середовище, спочатку фіксується в репозиторії та описі — інакше наступна правка перетворюється на археологію за історією команд на сервері.
- Конфігурації набору правил — у репозиторії, а не тільки на хості: версіонуються як код, з поміткою, який знімок застосовано зараз і чим він відрізняється від попереднього.
- Матриця мережевих доступів: джерело, призначення, порт, протокол, хто ініціює з'єднання й навіщо — по кожному дозвільному рядку; заборони за замовчуванням описані окремим блоком.
- Політики обмеження трафіку: ліміти швидкості та кількості одночасних з'єднань за сервісами, окремі умови для службових підмереж і адмінського доступу, поведінка при сплесках.
- Порядок відкату змін: як повернути попередній набір, за який час і що перевірити після повернення, включаючи сценарій втрати доступу до сервера.
- Документація з інфраструктури: схема проходження трафіку, зони та ланцюжки, місця стикування з балансувальником і зворотним проксі.
- Регламент внесення змін: хто узгоджує нове правило, де воно перевіряється до бойового середовища й як фіксується в журналі змін.
- Журналювання та приймання: які події пишуться й куди, плюс чек-ліст перевірок, який ваша команда проганяє сама й підтверджує відтворюваність конфігурації.
Так конфігурація перестає залежати від одного інженера: її можна прочитати, перевірити й змінити за документом, а не з пам'яті.
Кейс: як закрили периметр і прибрали клас відмов
До: правила без власника
Периметр ріс стихійно: близько чотирьохсот правил, накопичених різними командами, третина з них — без власника. Ніхто не міг пояснити, навіщо відкрито порт і що зламається при його закритті, тому «на всякий випадок» залишали як є.
Порядок обробки не дотримувався: дозвільні правила стояли вище заборонних, і частина трафіку блокувалася не там, де очікували. Аудит доступу розтягувався на дні, а відновлення після збою йшло руками з пам'яті.
Що змінили
Ми звели правила в єдиний реєстр, зіставили кожне з сервісом і відповідальним, а логіку перенесли в декларативні набори nftables — конфігурація стала однаковою на всіх середовищах і версіонованою.
Усе, що не підтверджено власником, закрили за замовчуванням, доступ видаємо за шаблоном під конкретний сервіс, а не правкою вручну.
Метрики до та після
- Сервісів, доступних ззовні: 46 → 11, вчетверо менше точок входу
- Правил із підтвердженим власником: 31% → 100%
- Взаємні блокування: 9 випадків за квартал → 0
- Відновлення конфігурації після збою: ~45 хвилин руками → 6 хвилин розгортанням з реєстру
- Перевірка доступу перед релізом: 2 дні → 20 хвилин
Головний результат не в кількості закритих портів, а в передбачуваності: кожне правило має обґрунтування, зміна відкочується однією операцією, а новий сервіс отримує доступ за шаблоном. Саме це прибрало клас відмов, пов'язаних із взаємними блокуваннями.
Чим відрізняється налаштування фільтрації вузла та периметра мережі?
Фільтрація на вузлі відповідає на питання «хто може звернутися до цього сервісу». Правила в nftables, iptables або firewalld описують, які порти слухають назовні, які адреси допущені до керуючих інтерфейсів, як обробляються встановлені з'єднання. Це останній рубіж: якщо вхідний контур пропустив зайве, відмову приймає вже сам сервер.
Захист периметра мережі працює на іншому рівні — там вирішується, які підмережі взагалі бачать одна одну й які сервіси публікуються назовні.
Один хост із відкритим портом не повинен ставати точкою входу в усю мережу, тому периметр описує маршрутизацію та трансляцію адрес, а не тільки перелік дозволених портів.
Сегментація внутрішніх сервісів додає третій рівень: база даних, черга та внутрішній API живуть у різних сегментах, а доступ між ними відкривається точково, за зв'язкою «джерело — призначення — порт». Тоді компроміс одного вузла не віддає під удар інші, і межа поширення атаки відома заздалегідь.
Конфлікт рівнів фільтрації виникає не в самих правилах, а в їх неузгодженості. Вузол із політикою «забороняти все, крім явно дозволеного» перестає приймати трафік при зміні периметра, а сегмент, відкритий «на час налагодження», залишається відкритим назавжди.
Тому політику ми описуємо зверху вниз — від периметра до вузла — і перевіряємо, що кожен рівень забороняє за замовчуванням, а дозволи збігаються з реальним трафіком, а не з вихідними припущеннями.
Питання щодо сумісності та відкату правил
Ядро Linux допускає співіснування різних інструментів фільтрації: поки один набір правил працює, другий збирається й перевіряється паралельно. Тому перехід між iptables, nftables і firewalld не потребує вікна простою — відкриті з'єднання та маршрути не рвуться.
Будь-яку правку ведемо за однією схемою: правило перевіряється на копії конфігурації, застосовується в працюючому наборі, а попередній стан зберігається окремим знімком. Нижче — типові сумніви, які виникають перед такою правкою.
Чи можна тримати iptables і nftables на одному вузлі?
Так. Інструменти працюють із різними наборами всередині ядра й не заважають один одному, поки одне з'єднання не описано двічі. Старий набір залишається активним, поки новий не перевірено, — тільки потім знімаємо дублі.
Що буде, якщо нове правило відріже доступ до сервера?
Знімок поточного набору зберігається до застосування, а правка вноситься з окремої сесії. Відкат повертає попередній стан за секунди й не потребує перезавантаження вузла.
Чи потрібно зупиняти сервіс на час правок?
Ні. Правила додаються й знімаються в працюючому наборі, встановлені з'єднання продовжують жити. Зупинка потрібна тільки при зміні самого механізму фільтрації — і то після перевірки нового набору.
Як переконатися в безпеці правила до застосування?
Проганяємо конфігурацію в тестовому режимі: дивимося, які пакети вона пропускає й блокує, звіряємо з матрицею доступів. Зайві блокування прибираємо до того, як правило потрапить на робочий вузол.
Обговоримо задачу: розберемо схему й повернемося з планом
Щоб оцінка обсягу робіт спиралася на факти, а не на здогадки, нам корисно побачити вашу поточну картину: діючі набори правил, схему зон та інтерфейсів, список сервісів із вхідним трафіком і те, що вже заважає роботі — блокування легітимних з'єднань або відкриті порти, про які ніхто не пам'ятає.
У відповідь повертаємо не «розберемося на місці», а конкретний набір:
- розбір поточних ланцюжків і таблиць: що фактично пропускається, що блокується й де правила дублюють одне одного;
- карта сервісів, портів і джерел трафіку — з поміткою, які з них підтверджені власниками систем;
- оцінка обсягу робіт: скільки правил переписуємо, що переносимо без змін, де потрібні нові зони;
- план впровадження з порядком переведення правил — від периферійних вузлів до критичних, щоб не втратити доступ до сервера;
- схема фіксації та відкату: набори правил зберігаються до змін, повернення до попереднього стану займає хвилини;
- порядок перевірок після переведення: які з'єднання підтверджуємо вручну, які шляхи тримаємо під наглядом;
- відповідальний інженер на зв'язку та точка, куди стікаються журнали спрацьованих правил.
Пропонуємо обговорити задачу фільтрації предметно — за вашою схемою, а не за шаблоном. Інженерна команда на зв'язку: розберемо спірні ділянки, покажемо, як ті самі задачі закривалися на схожих контурах, і повернемося з оцінкою обсягу робіт і планом впровадження.
