Налаштування UFW / firewalld / iptables / nftables: аудит і конфігурація

Налаштування UFW: де ламається фільтрація трафіку

Налаштування UFW виглядає як кілька команд allow — і тому фільтрація трафіку на хості часто виявляється декоративною. UFW — не самостійний фільтр, а надбудова над iptables і nftables: він збирає ланцюжки з файлів у /etc/ufw і застосовує їх цілком під час reload.

Збій — це зазвичай не «забули правило», а хибна політика за замовчуванням, порядок правил фільтрації або втрата стану під час перезавантаження.

Порядок вирішує більше, ніж склад: фільтр спрацьовує за першим збігом, тому дозвіл, доданий раніше за блокувальне правило, перекриває його.

Друга тиха помилка — прив'язка до інтерфейсу: правило висить на зовнішньому, а трафік приходить через тунель або внутрішній міст і під нього просто не потрапляє.

Окремий клас — обхід правил контейнерами. Docker і оркестратор вставляють свої ланцюжки вище за користувацькі, тому опублікований порт відкривається на всіх інтерфейсах незалежно від того, що показує ufw status.

Туди ж IPv6: при вимкненому стеку правила для нього не створюються, і частина трафіку йде повз фільтр.

Нарешті, живучість конфігурації: правила, додані вручну через iptables, після перезавантаження зникають, а ufw без автозапуску піднімається порожнім. Перевіряти це потрібно за фактичним набором ланцюжків у момент завантаження, а не за виводом status.

Починаємо з аудиту: знімаємо поточний стан, звіряємо його з заявленою політикою за замовчуванням і перевіряємо доступ ззовні — так видно, де саме обхід.

Далі — як це закривається: порядок правил, прив'язка до інтерфейсів, інтеграція з контейнерною мережею і збереження конфігурації.

Що змінюється після аудиту правил: вимірювані ефекти

Аудит починається зі звірки трьох списків: що слухає на інтерфейсах, що справді потрібно ззовні, що дозволено в правилах. Розбіжність між ними і є поверхня атаки — налагоджувальні порти, панелі адміністратора, СУБД, відкриті «на пару днів».

Після чистки назовні залишається лише трафік користувачів, а доступ інженерів переходить в окремий контур.

Другий результат — передбачувана конфігурація. Правила переїжджають з ручних правок у декларативний опис у системі контролю версій і застосовуються цілком, а не порядково.

Зміна проходить стенд і один вузол, потім розходиться на решту: поведінка під час наступної правки перестає залежати від того, хто і коли чіпав файл.

Час відновлення доступу вимірюється хвилинами замість годин. Типовий збій — правило, що відрізає адміністратора від вузла; за збереженого консольного доступу і зафіксованого порядку застосування доступ повертає відкат конфігурації, без перезбирання сервера. Заборона за замовчуванням тут не заважає, а допомагає: причина втрати доступу видно відразу.

Зникає і цілий клас відмов: сервіс, випадково опублікований назовні після оновлення, різні версії правил на вузлах, правило, яке ніхто не наважується видалити.

У UFW і надбудовах того ж рівня це закривається профілями, явним порядком застосування і перевіркою стану портів як регулярною процедурою.

Налаштування UFW та альтернативи: порівняння режимів фільтрації

Фільтрація всередині хоста і на периметрі хмари вирішують різні завдання, тому вибирати між ними доводиться рідко — частіше їх поєднують.

На машині доступні штатні засоби: UFW як проста надбудова з готовими профілями застосунків, firewalld із зонами довіри і прив'язкою інтерфейсів, nftables для складної маршрутизації і трансляції адрес, iptables там, де залишилися неперенесені модулі. Ззовні трафік ріже група безпеки хмарної мережі.

Порядок застосування важливіший за вибір інструмента: хмарний фільтр відсікає зайве до того, як пакет дійде до машини, а правила хоста залишаються другим рубежем і єдиним місцем, де видно взаємодію локальних сервісів.

Коли правила продубльовані на двох рівнях і розходяться, пошук причини відмови розтягується — тому фіксуємо джерело істини і звіряємо обидва шари за кожної зміни.

Етапи робіт: аудит правил, схема, налаштування, перевірка, передача

Аудит конфігурації починається не з правки правил, а з інвентаризації: які сервіси слухають порти, хто і звідки до них звертається, де трафік іде через балансувальник, а де напряму.

Без схеми проходження трафіку будь-яка зміна — здогад, і перший закритий порт ламає робочий сценарій. Тому порядок впровадження жорсткий: спочатку фіксуємо стан як є, потім змінюємо — групами, з готовим відкатом.

1. Інвентаризація сервісів. Збираємо список портів, що слухають, і їхніх споживачів, включно з внутрішніми мережами й офісом. Тут випливають забуті адміністративні порти й діапазони, відкриті «про всяк випадок».
2. Зняття поточних правил. Вивантажуємо чинні набори ufw, firewalld, iptables або nftables, звіряємо з фактичною поведінкою вузла, позначаємо дублі й правила, які вже ні на що не впливають.
3. Схема проходження трафіку. За кожним маршрутом фіксуємо ланцюжок «периметр — балансувальник — застосунок — база» з джерелом, призначенням і портом. Схема стає основою і для політики, і для розбору інцидентів.
4. Проєктування політики. Заборона за замовчуванням, точкові дозволи під підтверджені маршрути, окремі зони для службових мереж і порядок, за якого часткові правила спрацьовують раніше за загальні.
5. Впровадження. Застосовуємо групами — за сервісом або сегментом, спочатку на тестовому вузлі, потім на продуктивному, у погоджене вікно і з підготовленим відкатом.
6. Перевірка правил. Проганяємо трафік ззовні та зсередини: потрібне доступне, зайве закрито, відмови потрапляють у журнал. Окремо переконуємося, що правила переживають перезавантаження.
7. Передача регламентів. Віддаємо конфігурації в системі контролю версій, схему трафіку, опис політики і порядок погодження змін — щоб наступна правка не починалася з нуля.

Політики доступу, конфігурації та регламенти на виході

Аудит не закінчується звітом: результат — відтворюваний набір артефактів, за якими інфраструктуру можна перезібрати й безпечно змінювати. Усе, що ми правимо на серверах, осідає у файлах, а не в історії команд і пам'яті процесу. Нижче — те, що залишається в замовника.

• Конфігураційні файли правил у синтаксисі вашого стеку (ufw, firewalld, nftables) — з коментарем до кожного винятку, а не лише рядки правил.
• Політики доступу за замовчуванням: явно зафіксовано, що закрито, що дозволено і за якою ознакою правило вважається зайвим.
• Карта сервісів: які порти й адреси кому потрібні, хто власник сервісу і до якого вікна обслуговування він прив'язаний.
• Адресні групи й ролі: іменовані набори адрес замість розрізнених підмереж — правка групи оновлює правила одразу в усіх місцях.
• Регламент змін: хто погоджує нове правило, які перевірки обов'язкові до публікації і через який термін правило переглядають.
• Схема мережевих зон і порядок проходження трафіку між ними — у вигляді, придатному для передачі новому інженеру.
• Процедура відкату: знімок робочої конфігурації і послідовність повернення до нього за хвилини, а не за години розбору.
• Перелік знятих правил із причиною: застарілі дозволи не залишаються в конфігурації «про всяк випадок».

Набір самодостатній: за ним можна провести повторний аудит і побачити, що змінилося з минулого разу.

Кейс: як закрили обхід фільтрації на хості з контейнерами

Що було

Цей кейс впровадження почався із зовнішнього сканування: на хості з контейнерним середовищем ззовні відповідали 23 сервіси, хоча міжмережевий екран налаштований і політика за замовчуванням забороняла вхідні.

Причина виявилася не в помилці в правилах, а в порядку обробки трафіку: Docker під час публікації портів пише власні ланцюжки проброски, які спрацьовують раніше за користувацькі.

У результаті панель метрик, адмінка черги і внутрішній реєстр образів були доступні будь-кому, хто знав адресу.

Що змінили

Публікацію сервісів розділили за ролями: те, що приймає зовнішній трафік, залишилося на зовнішньому інтерфейсі, решту перевели на локальну адресу з доступом через зворотний проксі.

Власні ланцюжки для контейнерів описали явно — заборона за замовчуванням, білий список джерел, окремі дозволи на обмін між контейнерами і на доступ до бази.

Правила винесли в конфігурацію з версіонуванням: розкатка автоматизована, відкат — однією зміною, без правок на живому хості з ризиком відрізати собі доступ.

Метрики до і після

Доступних ззовні сервісів стало 4 замість 23, решта відповідають лише всередині контейнерної мережі. Внесення наступної зміни у фільтрацію займає кілька хвилин замість ручної перевірки ланцюжків по всьому хосту.

Повторний аудит проводимо раз на квартал: звіряємо фактичні правила з описаними, перевіряємо, чи не відкрив новий сервіс порт назовні, і переглядаємо ланцюжки після оновлення контейнерного середовища.

Що робити, якщо вже розгорнуто iptables і правила живуть нарізно

Накопичений набір правил — це проблема не синтаксису, а відсутності моделі: читаючи ланцюжок за ланцюжком, неможливо зрозуміти, навіщо правило додано і що зламається за його видалення. Лічильники показують обсяг трафіку, що проходить, але не власника сервісу.

Тому перший крок — інвентаризація: знімаємо чинні набори з усіх вузлів, зіставляємо правила із сервісами і позначаємо ті, що справді пропускають з'єднання.

Далі вибір із трьох стратегій, і розрізняються вони не обсягом роботи, а ціною помилки.

Ризик змін за будь-якого варіанту той самий: застосовуючи політику на живому вузлі, легко відрізати собі доступ до нього. Знімається це відкладеним відкатом — правило повертає попередній набір через заданий інтервал, якщо ми не підтвердили доступність вузла.

Другий контур захисту — тестовий стенд з тим самим набором сервісів, де політику проганяють до продакшену.

Завершуємо не разовою правкою, а переведенням конфігурації у версіонований вигляд: набір лежить у файлі, застосування автоматизоване, зміни проходять перевірку до застосування. Тоді наступний аудит займає хвилини, а не день.

Часті технічні сумніви перед стартом робіт

Сумніви перед стартом зазвичай одні й ті самі: чи не відріже нове правило віддалений доступ, як відкотитися, якщо зв'язок зникне. Побоювання обґрунтоване — фільтр починає працювати одразу, і помилка в одному рядку закриває вхід раніше, ніж ви встигаєте це помітити.

Тому правила застосовуємо поетапно: спочатку дозвільні для поточної сесії, потім обмежувальні, з перевіркою на окремому контурі й таймером, який поверне попередній набір, якщо зв'язок не підтвердився.

Конфігурація живе в репозиторії, тому будь-яка зміна відкочується однією командою, а не відновленням доступу через консоль провайдера.

Як ви версіонуєте правила?

Усі набори зберігаються в системі контролю версій: видно, хто і навіщо змінював правило, а відкат до робочого стану займає хвилини. Історія змін залишається у вас, а не в листуванні.

Чи враховуєте ви контейнери під час публікації портів?

Так. Правила контейнерного середовища і системного фільтра налаштовуються узгоджено, інакше сервіс виявляється відкритим в обхід обмежень. Ми зводимо обидва шари до однієї моделі доступу і перевіряємо результат скануванням портів ззовні.

Чи працює це з адресацією нового покоління?

Так, набори для нового протоколу адресації налаштовуються окремо від звичних. Часта проблема — відкритий доступ за одним типом адрес при закритому за іншим, тому перевіряємо обидва варіанти.

Чи обмежуєте ви панелі керування?

За замовчуванням панелі й адміністративні інтерфейси закриті від зовнішньої мережі й доступні лише через довірений контур або захищений тунель. Це прибирає найчастіший вектор — перебір пароля до відкритої панелі.

Обговоримо задачу: аудит правил і план змін

Задача зазвичай звучить як «закрийте зайві порти», але по суті це приведення політик фільтрації до стану, який можна пояснити колезі й відтворити на новій машині. Чим точніші вихідні дані на старті, тим менше ітерацій «змінили правило — втратили доступ». Нижче — що прискорює обговорення задачі й підготовку плану змін.

• Доступи: як заходимо на вузол — ключ чи консоль, чи є проміжний хост, чи вистачає прав, хто ще ходить на машину. Від цього залежить порядок правок, щоб не відрізати собі вхід.
• Схема мережі: інтерфейси, адресація і підмережі, балансувальник, VPN, зворотний проксі. Без неї не можна коректно описати джерела трафіку в правилах.
• Список сервісів: що слухає назовні, а що доступне лише всередині вузла, де TCP, а де UDP, кому ззовні справді потрібен доступ.
• Поточний стан: виводи конфігурації, лічильники спрацьовувань, порядок ланцюжків і зон, чи не працюють два менеджери правил одночасно.
• Обмеження: вимоги аудиту і внутрішніх регламентів, погоджені винятки, сервіси, які чіпати не можна.
• Вікно змін: припустимий простій, години низького навантаження, черговий на зв'язку, порядок відкату.

За цими даними збираємо план змін: послідовність правок, перевірки до і після кожного кроку, точку повернення і критерії, за якими вважаємо результат досягнутим. Резервна копія правил готується до початку робіт, а саме вікно змін погоджуємо заздалегідь.

Оцінка робіт приходить разом із планом: етапи, терміни і те, хто підтверджує результат на боці замовника.