Файрвол на сервері: як побудувати стіну, яку поважатимуть навіть наполегливі боти

Уявіть: ви повернулися з відпустки, відкрили панель моніторингу сервера - а там 47 000 спроб з'єднання з невідомих IP за останню добу. Половина - на SSH-порт, чверть - на порт бази даних, решта просто стукає у все підряд, наче п'яний сусід, який забув номер своєї квартири. Сервер тримається, але навантаження на процесор підозріло високе. Знайомо? Якщо ні - ви або геній безпеки, або просто ще не дивилися логи. Файрвол - це перший і найважливіший кордон між вашим проєктом та океаном ботів, сканерів і тих, хто вважає ваш сервер безкоштовним шведським столом.

Чому «закрити все і відкрити потрібне» - це не параноя, а здоровий глузд

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

Принцип «deny all, allow explicit» - золотий стандарт. Спочатку забороняєте абсолютно весь вхідний трафік, потім точково відкриваєте лише те, що реально потрібно. Порт 80 для HTTP? Відкрили. 443 для HTTPS? Так. SSH на 22? Тільки для конкретних IP. Все інше - стіна.

За даними Akamai, у 2024 році кількість автоматизованих атак на веб-сервери зросла на 34% порівняно з попереднім роком. Більшість цих атак навіть не цільові - боти просто сканують інтернет і стукають у кожні відчинені двері.

iptables, nftables чи UFW: що обрати і чому це не байдуже

Якщо ви хоч раз гуглили «як налаштувати файрвол на Linux», ви натрапляли на три імені. Давайте розберемося, хто з них хто.

iptables - ветеран. Його знають усі, під нього написано мільйони мануалів. Але синтаксис настільки багатослівний, що одна помилка в ланцюжку правил може або заблокувати вас самих, або залишити дірку розміром з вантажівку.

nftables - наступник iptables, вбудований у ядро Linux з версії 3.13. Синтаксис чистіший, продуктивність краща, можна об'єднувати правила для IPv4 та IPv6 в одній таблиці. Якщо починаєте з нуля - це ваш вибір.

UFW (Uncomplicated Firewall) - обгортка, яка перетворює складні команди на щось на кшталт ufw allow 443/tcp. Ідеально для одного-двох сайтів на VPS. Але коли потрібно фільтрувати трафік між контейнерами або налаштовувати складний NAT - UFW швидко стає тісним.

«Файрвол - це не продукт, це процес. Ви не налаштовуєте його один раз і забуваєте. Ви постійно переглядаєте правила, адаптуєте під нові загрози і перевіряєте, чи не з'явилося щось зайве.» - Marcus Ranum, один із піонерів мережевої безпеки

Покрокова побудова стіни: від голого сервера до фортеці

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

1. Аудит відкритих портів. Перш ніж щось закривати, зрозумійте, що відкрито. Команда ss -tlnp або netstat -tlnp покаже всі сервіси, які слухають з'єднання. Вас може здивувати, скільки всього тихо працює «за замовчуванням».
2. Складіть список необхідного. Для типового веб-сервера це зазвичай: 22 (SSH), 80 (HTTP), 443 (HTTPS). Може, ще 3306 для MySQL, але тільки з localhost або конкретного IP аплікації.
3. Встановіть політику «deny all» для вхідного трафіку. У UFW - ufw default deny incoming. У nftables - створіть ланцюжок з policy drop.
4. Відкрийте лише потрібні порти. Кожен порт - окреме правило. Ніяких діапазонів «на всяк випадок».
5. Обмежте SSH. Перенесіть його на нестандартний порт (наприклад, 2222), дозвольте доступ тільки з ваших IP, увімкніть rate limiting - не більше 6 з'єднань за хвилину.
6. Увімкніть логування заблокованих з'єднань. Без логів ви не побачите, хто стукав і куди. У UFW - ufw logging medium.
7. Тестуйте перед тим, як заблокувати себе. Завжди тримайте запасний доступ - KVM-консоль або IPMI від хостера. Серйозно. Я бачив, як люди блокували самих себе і потім годинами чекали на тікет у підтримку.

Типові помилки, що перетворюють файрвол на декорацію

Налаштувати файрвол - половина справи. Набагато складніше - не зіпсувати його потім. Ось що я бачу раз за разом на серверах клієнтів:

• Забутий порт бази даних, відкритий на весь інтернет. MySQL на 3306 без обмежень по IP - це запрошення на вечерю для зловмисників. У 2023 році Shodan індексував понад 3,6 мільйона відкритих MySQL-серверів у світі.
• Правила-«франкенштейни». Адмін додає нове правило, потім ще одне, потім виняток із винятку. Через рік ніхто не розуміє, що і чому дозволено. Раз на квартал проводьте повний аудит правил.
• Ігнорування вихідного трафіку. Всі думають про вхідний, але якщо ваш сервер скомпрометовано - саме через вихідний трафік він буде надсилати спам або брати участь у DDoS.
• Rate limiting тільки на SSH. А як щодо HTTP? Тисячі запитів за секунду на один URL - і ваш Apache чи Nginx лягає. Fail2ban у зв'язці з файрволом вирішує це елегантно.
• Відсутність правил для IPv6. Ви можете ідеально налаштувати iptables для IPv4, а потім виявити, що ip6tables взагалі не налаштований. Боти це знають і використовують.

Кожен відкритий порт без явної потреби - це не «зручність», це вразливість. Якщо ви не можете пояснити за 10 секунд, навіщо конкретний порт відкритий - закривайте його.

Fail2ban та GeoIP: коли файрвол потребує розумного напарника

Чистий файрвол працює на рівні «дозволити-заборонити». Але сучасні загрози потребують динамічної реакції. Тут на сцену виходить Fail2ban - інструмент, який моніторить логи і автоматично блокує IP після N невдалих спроб.

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

А GeoIP-фільтрація - це ще один рівень. Якщо ваш сайт працює для аудиторії з Німеччини та Польщі, навіщо приймати з'єднання з IP-адрес, зареєстрованих у В'єтнамі чи Бразилії? Так, це не панацея - VPN обходить обмеження. Але 90% автоматизованих ботів не використовують VPN. Вони йдуть шляхом найменшого опору.

Ось що я рекомендую як мінімальний набір для будь-якого продакшн-сервера:

• Fail2ban для SSH, HTTP-авторизації та поштових сервісів
• GeoIP-блокування на рівні nftables або через модуль для iptables
• Автоматичне оновлення списків відомих шкідливих IP (наприклад, через AbuseIPDB або Spamhaus DROP)

Хмарний файрвол vs файрвол на сервері: чи потрібно обирати?

Більшість хмарних провайдерів - AWS, DigitalOcean, Hetzner, Vultr - пропонують зовнішній файрвол на рівні інфраструктури. Security Groups у AWS, Cloud Firewalls у DigitalOcean. Виникає спокуса: «Навіщо мені iptables, якщо є хмарний файрвол?»

Відповідь проста: вам потрібні обидва. Це як замок на дверях під'їзду і замок на дверях квартири. Хмарний файрвол фільтрує трафік ще до того, як він досягне мережевого інтерфейсу сервера - це знижує навантаження. Але він грубіший: зазвичай лише IP + порт, без rate limiting, без аналізу вмісту пакетів.

Локальний файрвол на сервері дає тонке налаштування: обмеження кількості з'єднань, фільтрація за станом пакета (stateful inspection), інтеграція з Fail2ban, логування на рівні ОС. Разом вони створюють ешелоновану оборону, де проскочити крізь обидва рівні значно складніше, ніж крізь один.

Є ще один аргумент. Хмарний файрвол прив'язаний до конкретного провайдера. Якщо ви мігруєте - всі правила доведеться переписувати. Локальна конфігурація nftables або iptables переїжджає разом із сервером. Один файл. Копіювання. Готово.

Знаєте, що найбільше дратує у темі безпеки серверів? Усі знають, що файрвол потрібен. Усі кивають. І більшість залишає стандартні налаштування, бо «потім налаштую» або «хто мій маленький VPS буде атакувати?». А потім бачать 47 000 спроб з'єднань за добу і дивуються. Тож запитання до вас: скільки портів на вашому сервері відкрито прямо зараз - і скільки з них дійсно потрібні?