Налаштування серверного фаєрвола: захист сервера від DDoS-атак та шкідливих ботів

Налаштування серверного фаєрвола — це процес, який полягає у відкритті лише необхідних портів і блокуванні всіх зайвих доступів до сервера. Це перший рівень захисту від DDoS-атак, brute force спроб та шкідливого бот-трафіку. Практично мета полягає у обмеженні доступу до SSH, контрольованому відкритті веб-сервісів, обмеженні підозрілих запитів за допомогою лімітів, моніторингу логів та, за можливості, фільтрації трафіку на рівні CDN або WAF до його надходження на сервер.

Як тільки ви підключаєте веб-сервер до інтернету, вже за кілька хвилин він піддається порт-скануванню, спробам SSH-доступу, атакам ботів та підробленим User-Agent’ам. Особливо це актуально для серверів з WordPress, e-commerce, панелями управління, API або ігровими серверами. Наявність фаєрвола — це не просто технічний вибір, а необхідна умова стабільної роботи. У цій статті ми крок за кроком розглянемо архітектуру серверного фаєрвола для Linux: UFW, firewalld, nftables, Fail2ban, веб-фаєрвол та підходи до зниження DDoS-атак.

Важливо розуміти: локальний серверний фаєрвол не може повністю зупинити великі DDoS-атаки. Якщо атака обсягом 20, 80 Гбіт/с або більше досягає дата-центру або мережевого ядра, вона може заповнити пропускну здатність ще до того, як пакети потраплять у правила операційної системи. Тому найкраща стратегія — багаторівневий захист: DDoS-фільтрація на рівні провайдера, CDN/WAF, серверний фаєрвол ОС, обмеження запитів на рівні додатків та регулярний аналіз логів. Для вибору оптимальної інфраструктури рекомендуємо ознайомитися з Hostragons рішення для VPS та VDS серверів, а для безпечного розміщення сайтів — з Hostragons пакети веб-хостингу.

Для чого потрібен серверний фаєрвол?

Серверний фаєрвол — це безпековий шар, який фільтрує мережевий трафік за IP-адресами, портами, протоколами, станом з’єднання та іноді за характеристиками пакетів. Простіше кажучи: для вашого сайту мають бути відкриті порти 80 і 443, а для бази даних порт 3306 повинен бути закритим для інтернету. Для SSH (порт 22) безпечніше дозволяти підключення лише з IP-адрес вашого офісу, а не відкривати доступ усім.

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

Розуміння DDoS-атак та трафіку ботів

Чому DDoS-атаки відрізняються?

DDoS (розподілена відмова в обслуговуванні) — це атака, яка спрямована на унеможливлення доступу до цільового сервісу шляхом переповнення його трафіком з багатьох джерел. Вона може перевантажувати пропускну здатність каналу, виснажувати CPU та оперативну пам’ять сервера або запускати дорогі обчислювальні операції на рівні додатків. Наприклад, невеликий сервер із 50 000 HTTP-запитів на секунду може не впоратися з навантаженням через обмеження PHP-FPM, Node.js або пулу підключень до бази даних, навіть якщо канал не заповнений.

Чи всі боти шкідливі?

Ні. Googlebot, Bingbot та деякі інші індексуючі боти приносять користь. Проте шкідливі боти сканують панелі керування, шукають відкриті каталоги, розсилають спам через форми, копіюють контент, зловживають XML-RPC, створюють фейкові акаунти та здійснюють спроби входу. Тому мета керування ботами — не блокувати всіх, а розрізняти поведінку. Високий відсоток помилок, велика кількість запитів за короткий час, нелогічні заголовки і підозрілі URL — це сигнал для обмежень.

Контрольний список перед налаштуванням

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

• Не закривайте активний SSH-сеанс; використовуйте інший термінал для тестів.
• Переконайтеся, що ваш провайдер надає консольний, VNC або аварійний доступ.
• Перевірте відкриті порти командами ss -tulpn або netstat -tulpn.
• Занотуйте порти веб-сервісів, пошти, DNS, баз даних, панелей і моніторингу.
• Якщо використовуєте IPv6, сплануйте правила фаєрвола і для нього.
• Спершу застосовуйте правила дозволу (allow), потім блокування (deny).
• Переконайтеся, що правила зберігаються після перезавантаження сервера.

Наприклад, для типового сервера з вебсайтом зазвичай достатньо відкрити порти 80, 443 і обмежений порт SSH. Якщо поштовий сервер не працює, порти 25, 465, 587, 993 не потрібно відкривати. Якщо база даних використовується лише локально, порти 3306 або 5432 мають бути закриті для інтернету.

Який інструмент фаєрвола обрати?

У світі Linux існує кілька інструментів, більшість із яких базуються на одному ядровому фільтрі, але відрізняються зручністю використання. Для початківців UFW — найпростіший і швидкий варіант. У корпоративних або Red Hat-подібних системах популярний firewalld. Для просунутих сценаріїв найкраще підійде nftables — сучасний і гнучкий інструмент. Нижче таблиця для порівняння.

Покрокове налаштування серверного фаєрвола

1. Визначте відкриті порти та сервіси

Перший крок — з’ясувати, які сервіси слухають на яких портах. Команда ss -tulpn покаже, на яких інтерфейсах і портах працюють сервіси. Наприклад, якщо nginx слухає на 0.0.0.0:80 і 0.0.0.0:443 — це означає, що веб-трафік приймається з усіх інтерфейсів. Якщо MariaDB слухає на 0.0.0.0:3306 — це потенційна загроза, бо база даних має бути доступна лише локально (127.0.0.1).

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

2. Встановіть політику за замовчуванням — закрита

У безпечних конфігураціях трафік, що надходить, за замовчуванням заборонений, а вихідний — дозволений за потребою. Такий підхід запобігає випадковому відкриттю нових сервісів в інтернет. Для Ubuntu з UFW логіка така: спочатку дозволяємо SSH, потім відкриваємо порти 80 і 443, після цього змінюємо політику на deny для вхідного трафіку і активуємо фаєрвол.

Приклад: дозвольте SSH лише з вашої IP-адреси, відкрийте HTTP/HTTPS для всіх, закрийте непотрібні порти і активуйте захист. Не давайте SSH-доступ до фаєрволу без попереднього налаштування — це одна з поширених помилок, особливо при віддаленому адмініструванні.

3. Обмежте доступ до SSH

SSH — одна з найчастіших цілей атак. Сервер з відкритим портом 22 може отримувати сотні або тисячі спроб входу щодня. Найкраще обмежити доступ до SSH певними IP-адресами. Якщо у вас статична IP-адреса офісу або VPN — дозволяйте лише їй. Якщо статичної IP немає — використовуйте ключі SSH і вимикайте парольний вхід.

• Відключіть прямий вхід під root.
• Використовуйте SSH-ключі замість паролів.
• Обмежуйте користувачів через AllowUsers або AllowGroups.
• Впровадьте Fail2ban для автоматичного блокування невдалих спроб.
• Обмежте доступ до портів панелі управління за IP.

Зміна порту SSH з 22 допомагає знизити шум від автоматичних атак, але не є повним захистом. Важливіше — це IP-фільтрація, сильна аутентифікація та моніторинг логів.

4. Контрольовано відкрийте порти веб-сервера

Для більшості вебсерверів потрібні порти 80 і 443. Однак сьогодні 443 (HTTPS) має бути основним портом, а 80 використовувати лише для перенаправлення на HTTPS. Відсутність SSL-сертифіката погано впливає на довіру користувачів і SEO. Тут доречно вставити Hostragons SSL сертифікати для безпечного налаштування HTTPS.

Якщо ви використовуєте CDN або зворотний проксі, замість відкриття портів 80 і 443 для всіх краще дозволити лише IP-адреси CDN. Це приховає реальну IP сервера і знизить ризик прямих атак.

5. Закрийте порти баз даних та внутрішніх сервісів для інтернету

Сервери MySQL, MariaDB, PostgreSQL, Redis, Elasticsearch, MongoDB та інші не повинні бути відкриті в інтернет. Відсутність аутентифікації в Redis, небезпечний доступ до індексів Elasticsearch або відкритий порт MongoDB неодноразово призводили до витоків даних. Ці сервіси мають слухати лише localhost або приватну мережу.

Наприклад, база даних WordPress повинна приймати підключення лише з 127.0.0.1. Якщо додаток і база розміщені на різних серверах, дозвольте підключення лише з IP додатка. Відкриття портів 3306 або 5432 для інтернету — типова помилка, яку сканують боти.

6. Використовуйте Fail2ban для блокування brute force атак

Fail2ban аналізує логи і блокує IP-адреси з численними невдалими спробами входу. Можна налаштувати правила для SSH, nginx, Apache, Postfix, Dovecot, WordPress та панелей керування. Наприклад, заблокувати IP на годину після 5 невдалих спроб SSH за 10 хвилин — ефективний базовий захід.

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

7. Додайте обмеження швидкості та кількості підключень

На рівні ОС можна обмежити кількість з’єднань з одного IP, щоб знизити ефект DDoS та бот-атак. У вебсерверів є власні механізми: nginx підтримує limit_req і limit_conn, Apache — модулі mod_evasive або подібні. На рівні додатків варто вводити ліміти для логінів, пошуку, кошика, оплати та API.

Наприклад: на сторінці входу ліміт 10 спроб на хвилину для одного IP цілком розумний. Для пошуку — 2-5 запитів на секунду. Для API — ліміти токенів, IP та поведінковий аналіз. Це не дозволить атакуючому просто змінювати IP для обходу обмежень.

Приклад безпечного налаштування на Ubuntu з UFW

Для серверів на Ubuntu чи Debian можна застосувати просту схему: спочатку перевірте відкриті сервіси, дозвольте SSH лише для вашої IP, відкрийте порти 80 і 443, встановіть політику deny для вхідних з’єднань і активуйте UFW. Якщо у вас немає статичної IP, тимчасово дозволяйте SSH з будь-яких IP, а згодом переходьте на VPN або статичний IP.

Припустимо, ваш IP — 203.0.113.10. Налаштуйте SSH тільки для нього, веб-трафік 80 і 443 — відкритий для всіх, порти бази даних, Redis, панелі та тестові порти — закриті. Це хороший старт для малого та середнього бізнесу. Для правильного налаштування домену і DNS можна скористатися Hostragons перевірка домену та реєстрація.

Зони у firewalld

Для AlmaLinux, Rocky Linux, RHEL популярним є firewalld, який працює із зонами. Public — для інтерфейсів, відкритих в інтернет, trusted — для довірених приватних мереж, drop — для тих, що мають відкидати небажаний трафік без відповіді. Важливо розуміти різницю між runtime (тимчасовими) і permanent (постійними) правилами. Runtime застосовується негайно, але зникає після перезавантаження, а permanent — зберігається, але для оновлення потрібне перезавантаження або reload.

У корпоративних мережах firewalld зручний за рахунок сервісних профілів. Наприклад, http і https можна відкрити у public zone, а ssh — лише з певних IP. Якщо мережеві інтерфейси розділені для управління, резервування і користувацького трафіку — зони підвищують безпеку і зручність адміністрування.

CDN, WAF та захист на рівні провайдера

Локальний фаєрвол приймає рішення про трафік уже після його надходження на сервер. При масштабних DDoS-атаках важливо фільтрувати трафік ще раніше — на рівні CDN, WAF та мережі провайдера. CDN роздає статичний контент із географічно розподілених точок, WAF відсіює шкідливі запити на рівні додатків, а провайдерський захист справляється з великими обсягами трафіку на мережевому рівні.

Ідеальна модель: DNS налаштовані на проходження через CDN, справжня IP-адреса сервера прихована, фаєрвол приймає трафік лише з IP CDN на портах 80 і 443, адміністративні порти доступні лише через VPN або зі статичних IP. Така схема знижує ризик прямих атак на IP і допомагає відсіяти ботів ще до додатку. Для поглибленого ознайомлення з прискоренням та безпекою сайтів дивіться Посібники з прискорення та безпеки веб-сайту.

Захист від ботів на рівні додатків

Блокування ботів — це не лише IP-блоки. Сучасні боти використовують проксі, мобільні мережі, дата-центри і змінні User-Agent. Тому потрібен поведінковий аналіз. Висока кількість спроб входу з однієї IP, масове сканування 404, підвищена активність wp-login.php або xmlrpc.php, незвичні патерни кліків і підозрілі заголовки повинні аналізуватися.

• Використовуйте ліміти запитів на сторінках входу і реєстрації.
• Обмежуйте або вимикайте непотрібний XML-RPC.
• Захищайте панелі керування за допомогою зміни URL, IP-фільтрації та двофакторної автентифікації.
• Фільтруйте підозрілі User-Agent і referer на рівні WAF.
• Застосовуйте CAPTCHA або невидимі механізми верифікації для форм.
• Додайте ключі, підписи, квоти та часові позначки для API-запитів.

Важливо не погіршувати користувацький досвід: надмірні CAPTCHA, агресивні блокування або помилкові блоки по країнах можуть нашкодити реальним клієнтам. Тому тестування, поступове посилення правил і моніторинг — найкращі підходи.

Моніторинг логів та налаштування сповіщень

Не думайте, що після налаштування фаєрвола робота закінчена. Це живий механізм, який треба регулярно контролювати. Перевіряйте auth.log чи secure на спроби входу, access-логи nginx на аномальну активність, error-логи на збільшення помилок 404 і 500, а також системні метрики CPU і кількості з’єднань. Навіть просте сповіщення може за кілька хвилин попередити про початок атаки.

Приклади порогів: більше 100 404 від одного IP за 5 хвилин, понад 20 спроб входу за хвилину, CPU понад 90% протягом 10 хвилин, кількість з’єднань у 3 рази вище норми. Ці значення залежать від конкретного сайту, тому важливо знати нормальний профіль трафіку.

Поширені помилки та як їх уникнути

• Включити фаєрвол без дозволу SSH: це призведе до втрати доступу до віддаленого сервера. Завжди тестуйте через друге з’єднання.
• Забути про IPv6: при закритті IPv4 сервіси можуть залишатися відкритими через IPv6.
• Залишити базу даних відкритою в інтернет: порти 3306, 5432, 6379, 9200 постійно скануються ботами.
• Використовувати CDN, але не приховувати реальний IP: атакуючий може обійти CDN і атакувати сервер напряму.
• Змінювати правила без документації: у разі проблем важко зрозуміти, які налаштування викликали збій.
• Не мати резервного плану доступу: якщо консоль недоступна через помилки в правилах, час простою збільшується.

Приклад простої політики безпеки фаєрвола

Для невеликого корпоративного сайту можна застосувати таку політику: вхідний трафік за замовчуванням заборонений; порт 443 відкритий для всіх; порт 80 відкритий лише для перенаправлення на HTTPS; SSH доступний лише через VPN або зі статичного IP; база даних доступна лише локально або у приватній мережі; при використанні CDN порти 80 і 443 відкриті лише для IP CDN; Fail2ban моніторить SSH та логіни на сайті; логи відправляються до централізованої системи моніторингу.

Для середніх e-commerce проектів додають: allowlist IP для callback платежів, панель керування за VPN, ліміти користувачів для API, активований WAF з правилами проти SQL ін’єкцій та XSS, тимчасові блокування по країнах чи ASN. Важливо мати письмові процедури, щоб у випадку атаки не приймати рішення на ходу, а діяти за планом, що зменшує час простою.

Як протестувати роботу фаєрвола?

Після налаштування обов’язково перевірте: проведіть сканування портів з іншої мережі, переконайтеся, що SSH доступний лише з дозволених IP, сайт працює через HTTPS, порт бази даних закритий для зовнішнього трафіку. Якщо використовуєте CDN — спробуйте звернутися до реального IP сервера напряму HTTP-запитом і переконайтеся, що доступ заблокований.

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

План обслуговування та оновлень

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

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

Висновок

Налаштування серверного фаєрвола не зробить ваш сервер повністю невидимим для DDoS і ботів, але суттєво знижує площу атаки, зменшує ризики несанкціонованого доступу і дозволяє оперативніше реагувати на інциденти. Найкращий результат дає комплексний підхід: захист на рівні провайдера, CDN/WAF, суворі правила портів, обмеження SSH, Fail2ban, ліміти трафіку і регулярний моніторинг логів.

Якщо ви запускаєте новий проект, краще відразу спланувати політику фаєрвола, ніж потім виправляти помилки. При виборі сервера, хостингу, доменів і SSL на Hostragons розглядайте безпеку як невід’ємну частину інфраструктури. Почніть з простої перевірки: закрийте зайві порти, обмежте SSH, вимагайте HTTPS та стежте за логами.

Поширені запитання

Чи повністю серверний фаєрвол блокує DDoS-атаки?

Ні. Локальний фаєрвол може зменшити вплив малих атак і деяких протокольних зловживань, але для великих DDoS потрібен захист на рівні провайдера, CDN і WAF.

Які порти мають залишатися відкритими на вебсервері?

Зазвичай це порти 80 і 443. SSH повинен бути доступним лише для адміністративних IP. Порти баз даних та внутрішніх сервісів мають бути закриті для зовнішнього світу.

Що краще — UFW чи firewalld?

UFW простіший і підходить для Ubuntu та Debian. Firewalld поширений на AlmaLinux, Rocky Linux і RHEL. Для складних сценаріїв можна використовувати nftables.

Чи можна зупинити ботів лише IP-блокуванням?

Зазвичай ні. Сучасні боти використовують різні IP, проксі та інші методи обходу. Потрібні обмеження швидкості, WAF, аналіз поведінки, CAPTCHA і обмеження на рівні додатка.

Який найбільший ризик при налаштуванні фаєрвола?

Втрата доступу до сервера через помилкові правила, особливо для SSH. Тому спочатку потрібно дозволити SSH, протестувати через друге з’єднання і мати аварійний доступ через провайдера.