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

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

Цей посібник охоплює архітектуру правил брандмауера, UFW на Linux, firewalld, Windows Defender Firewall, nftables, а також операційні практики, що відрізняють захищене середовище від неправильно налаштованого.

Що насправді контролюють правила брандмауера

Кожне правило в наборі правил брандмауера оцінюється відносно п’яти основних атрибутів пакета, які зазвичай називають 5-кортежем:

• IP-адреса джерела — вихідний хост або підмережа (наприклад, 192.168.1.0/24)
• IP-адреса призначення — цільовий хост або діапазон
• Порт джерела — ефемерний порт на стороні ініціатора
• Порт призначення — сервісний порт на стороні отримувача (наприклад, 443 для HTTPS, 22 для SSH)
• Протокол — TCP, UDP, ICMP або номер протоколу

Окрім 5-кортежу, stateful-брандмауери також відстежують стан з’єднання (NEW, ESTABLISHED, RELATED, INVALID), що дозволяє їм дозволяти зворотний трафік для вихідних з’єднань без написання явних вхідних правил для кожної відповіді.

Stateful vs. Stateless брандмауери

Для практично всіх серверних розгортань — включаючи VPS Хостинг та Виділені сервери — stateful хостовий брандмауер є правильним вибором за замовчуванням.

Обробка правил брандмауера: проблема порядку

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

• Широке правило ALLOW, розміщене вище конкретного правила DENY, мовчки перевизначить його.
• Правило DENY ALL на початку ланцюжка блокує все, незалежно від того, що йде далі.
• Дублікати або затінені правила витрачають цикли обробки та створюють плутанину під час аудиту.

Найкраща практика: Завжди розміщуйте конкретні правила перед загальними. Розміщуйте явні правила DENY для відомих шкідливих джерел на початку, потім конкретні правила ALLOW для довірених сервісів, і завершуйте кожен ланцюжок стандартною політикою DENY.

Налаштування правил брандмауера на Linux за допомогою UFW

UFW (Uncomplicated Firewall) — це інтерфейс для iptables та nftables на системах на основі Debian/Ubuntu. Він абстрагує низькорівневий синтаксис ланцюжків у зрозумілі людині команди, зберігаючи повний контроль над фільтрацією портів, протоколів, IP та інтерфейсів.

Крок 1: Встановлення та увімкнення UFW

UFW попередньо встановлено на Ubuntu. Перевірте його статус перед увімкненням:

sudo ufw status verbose

Якщо неактивний, увімкніть його:

sudo ufw enable

Критичне попередження: Якщо ви підключені через SSH і ще не дозволили порт 22, увімкнення UFW заблокує вам доступ. Завжди дозволяйте SSH перед увімкненням брандмауера на віддаленому сервері.

Крок 2: Встановлення стандартних політик

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

sudo ufw default deny incoming
sudo ufw default allow outgoing

Це відкидає всі небажані вхідні з’єднання, дозволяючи весь вихідний трафік. Якщо ваша політика безпеки вимагає фільтрації вихідного трафіку (наприклад, для запобігання витоку даних або зворотних з’єднань C2), змініть стандартне правило для вихідного трафіку:

sudo ufw default deny outgoing

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

Крок 3: Дозвіл конкретних сервісів і портів

UFW підтримує імена сервісів із /etc/services або явні номери портів:

# Allow SSH by service name
sudo ufw allow ssh

# Allow HTTP and HTTPS
sudo ufw allow http
sudo ufw allow https

# Allow a custom application port
sudo ufw allow 8080/tcp

# Allow a UDP service (e.g., DNS resolver)
sudo ufw allow 53/udp

Щоб дозволити діапазон портів (наприклад, пасивний FTP):

sudo ufw allow 49152:65535/tcp

Крок 4: Обмеження доступу до конкретних IP-адрес джерела

Відкриття адміністративних портів для 0.0.0.0/0 є однією з головних причин компрометації методом грубої сили. Обмежте SSH відомою IP-адресою управління:

sudo ufw allow from 203.0.113.50 to any port 22 proto tcp

Щоб дозволити всю підмережу управління:

sudo ufw allow from 10.0.0.0/8 to any port 22 proto tcp

Крок 5: Блокування трафіку з конкретних IP-адрес або підмереж

Заблокуйте відому шкідливу IP-адресу:

sudo ufw deny from 198.51.100.77

Заблокуйте всю підмережу (наприклад, географічне блокування або діапазон зловживаючої ASN):

sudo ufw deny from 198.51.100.0/24

Граничний випадок: Правила deny UFW надсилають відповідь TCP RST або ICMP port-unreachable, що підтверджує існування хоста. Використовуйте reject для мовчазного відкидання пакетів:

sudo ufw reject from 198.51.100.0/24

Крок 6: Перегляд активних правил

sudo ufw status numbered

Прапор numbered присвоює індекс кожному правилу, що необхідно для цільового видалення:

[ 1] 22/tcp                     ALLOW IN    203.0.113.50
[ 2] 80/tcp                     ALLOW IN    Anywhere
[ 3] 443/tcp                    ALLOW IN    Anywhere

Для повного детального виводу, включаючи стандартні політики та прив’язки інтерфейсів:

sudo ufw status verbose

Крок 7: Видалення правил

Видалення за номером правила (рекомендовано — уникає неоднозначності):

sudo ufw delete 3

Видалення за специфікацією правила:

sudo ufw delete allow 8080/tcp

Крок 8: Перезавантаження та збереження правил

Правила UFW автоматично зберігаються після перезавантаження. Після масових змін перезавантажте без розриву існуючих з’єднань:

sudo ufw reload

Щоб повністю скинути всі правила і почати з нуля:

sudo ufw reset

Розширений UFW: профілі застосунків

UFW підтримує іменовані профілі застосунків, що зберігаються в /etc/ufw/applications.d/. Це дозволяє визначати правила для кількох портів під одним іменем:

sudo ufw app list
sudo ufw allow 'Nginx Full'
sudo ufw app info 'Nginx Full'

Створення власного профілю для Node.js API:

[NodeAPI]
title=Node.js API Server
description=Custom Node.js application
ports=3000,3001/tcp

Потім застосуйте його:

sudo ufw allow NodeAPI

Налаштування правил брандмауера за допомогою firewalld (RHEL/CentOS/Fedora)

firewalld використовує модель на основі зон, а не плаский набір правил. Кожен мережевий інтерфейс призначається зоні (наприклад, public, internal, dmz), і правила застосовуються для кожної зони окремо. Це архітектурно більш гнучко для серверів із кількома мережевими інтерфейсами.

Основні операції firewalld

# Check status
sudo firewall-cmd --state

# List all active zones and their interfaces
sudo firewall-cmd --get-active-zones

# List rules in the public zone
sudo firewall-cmd --zone=public --list-all

Дозвіл і видалення сервісів

# Allow HTTPS permanently
sudo firewall-cmd --zone=public --add-service=https --permanent

# Allow a custom port
sudo firewall-cmd --zone=public --add-port=8443/tcp --permanent

# Remove a service
sudo firewall-cmd --zone=public --remove-service=http --permanent

# Reload to apply permanent changes
sudo firewall-cmd --reload

Розширені правила для IP-специфічних політик

Розширені правила firewalld забезпечують деталізацію iptables з більш читабельним синтаксисом:

# Allow SSH only from a specific IP
sudo firewall-cmd --zone=public 
  --add-rich-rule='rule family="ipv4" source address="203.0.113.50" service name="ssh" accept' 
  --permanent

# Block all traffic from a subnet
sudo firewall-cmd --zone=public 
  --add-rich-rule='rule family="ipv4" source address="198.51.100.0/24" drop' 
  --permanent

sudo firewall-cmd --reload

Налаштування правил брандмауера за допомогою nftables

nftables — це сучасна заміна iptables, що пропонує уніфіковану структуру для фільтрації IPv4, IPv6, ARP і мостів із значно кращою продуктивністю та атомарною заміною правил.

Базовий набір правил nftables

# Flush existing ruleset
sudo nft flush ruleset

# Create a basic filtering table
sudo nft add table inet filter

# Add input, forward, and output chains
sudo nft add chain inet filter input { type filter hook input priority 0 ; policy drop ; }
sudo nft add chain inet filter forward { type filter hook forward priority 0 ; policy drop ; }
sudo nft add chain inet filter output { type filter hook output priority 0 ; policy accept ; }

# Allow established and related connections
sudo nft add rule inet filter input ct state established,related accept

# Allow loopback
sudo nft add rule inet filter input iif lo accept

# Allow SSH from a specific IP
sudo nft add rule inet filter input ip saddr 203.0.113.50 tcp dport 22 accept

# Allow HTTP and HTTPS from anywhere
sudo nft add rule inet filter input tcp dport { 80, 443 } accept

Щоб зробити набір правил постійним, збережіть його у файл конфігурації за замовчуванням:

sudo nft list ruleset > /etc/nftables.conf
sudo systemctl enable nftables

Налаштування правил брандмауера на Windows

Windows Defender Firewall з розширеною безпекою надає як графічний інтерфейс, так і інтерфейси командного рядка (netsh, PowerShell) для керування правилами.

Використання графічного інтерфейсу

1. Відкрийте Windows Defender Firewall з розширеною безпекою через wf.msc.
2. Виберіть Вхідні правила або Вихідні правила на лівій панелі.
3. Натисніть Нове правило на правій панелі.
4. Виберіть тип правила:

• Порт — фільтрація за номером порту TCP/UDP
• Програма — фільтрація за шляхом до виконуваного файлу
• Попередньо визначене — використання вбудованого визначення служби Windows
• Власне — повний контроль над усіма параметрами

1. Вкажіть порт або програму, виберіть Дозволити або Заблокувати, виберіть відповідні профілі (Домен, Приватний, Публічний) і назвіть правило.

Використання PowerShell (рекомендовано для автоматизації)

# Allow inbound HTTPS
New-NetFirewallRule -DisplayName "Allow HTTPS Inbound" `
  -Direction Inbound -Protocol TCP -LocalPort 443 -Action Allow

# Allow inbound SSH (Windows OpenSSH)
New-NetFirewallRule -DisplayName "Allow SSH Inbound" `
  -Direction Inbound -Protocol TCP -LocalPort 22 -Action Allow `
  -RemoteAddress 203.0.113.50

# Block inbound traffic from a specific IP
New-NetFirewallRule -DisplayName "Block Malicious IP" `
  -Direction Inbound -RemoteAddress 198.51.100.77 -Action Block

# View all inbound rules
Get-NetFirewallRule -Direction Inbound | Select-Object DisplayName, Enabled, Action

# Remove a rule by name
Remove-NetFirewallRule -DisplayName "Allow HTTPS Inbound"

Використання netsh (застарілий, але широко підтримуваний)

:: Allow inbound port 443
netsh advfirewall firewall add rule name="Allow HTTPS" protocol=TCP dir=in localport=443 action=allow

:: Block a specific IP
netsh advfirewall firewall add rule name="Block IP" dir=in remoteip=198.51.100.77 action=block

:: Delete a rule
netsh advfirewall firewall delete rule name="Allow HTTPS"

Критичні підводні камені та граничні випадки правил брандмауера

Неявний дозвіл для трафіку ESTABLISHED

На stateful-брандмауерах відсутність явного дозволу для з’єднань ESTABLISHED та RELATED у вхідному ланцюжку порушить усі сесії, ініційовані вихідним трафіком (наприклад, apt update, curl, DNS-запити), навіть якщо вихідний ланцюжок налаштований на ACCEPT. Це найпоширеніша помилка конфігурації при роботі з iptables або nftables.

# This rule MUST appear before any DROP rules in the input chain
sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Паритет IPv6

Багато адміністраторів ретельно налаштовують правила IPv4 і повністю забувають про IPv6. Якщо ваш сервер має IPv6-адресу і підтримку IPv6 у UFW не увімкнено, зловмисник може обійти всі правила IPv4, підключившись через ::. Перевірте, що /etc/default/ufw містить:

IPV6=yes

Інтерфейс зворотного зв’язку

Завжди явно дозволяйте трафік на інтерфейсі зворотного зв’язку (lo). Багато локальних сервісів (бази даних, черги повідомлень, внутрішні API) спілкуються через 127.0.0.1 або ::1. Блокування зворотного зв’язку мовчки порушує міжпроцесну комунікацію.

sudo ufw allow in on lo
sudo ufw allow out on lo

Обмеження швидкості для запобігання атакам грубої сили

UFW підтримує обмеження швидкості з’єднань нативно, що є необхідним для SSH та інших сервісів автентифікації:

sudo ufw limit ssh

Це дозволяє максимум 6 спроб підключення за 30 секунд з однієї IP-адреси перед активацією автоматичного тимчасового блокування — легковагова альтернатива fail2ban для базових розгортань.

ICMP і діагностичний трафік

Блокування всього ICMP є поширеною, але контрпродуктивною практикою. Це порушує ping, traceroute, виявлення MTU шляху та деякі протоколи маршрутизації. Правильний підхід — дозволяти конкретні типи ICMP:

• Тип 0 (Echo Reply) та Тип 8 (Echo Request) — для ping
• Тип 3 (Destination Unreachable) — для виявлення MTU шляху
• Тип 11 (Time Exceeded) — для traceroute

Блокуйте Тип 17 (Address Mask Request) та Тип 18 (Address Mask Reply), які не мають законного сучасного використання.

Правила брандмауера та хостингові середовища

Правильна стратегія брандмауера значною мірою залежить від рівня вашої інфраструктури.

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

На VPS з cPanel, cPanel/WHM включає ConfigServer Security & Firewall (CSF), який обгортає iptables високорівневим інтерфейсом, автоматичним виявленням атак грубої сили та підтримкою port knocking. CSF є стандартним рішенням брандмауера для середовищ cPanel і повинен використовуватися замість звичайного UFW на таких системах.

На некерованому VPS Хостингу або Виділених серверах ви маєте повний контроль над брандмауером ядра. Саме тут UFW, firewalld та nftables є відповідними інструментами. Базова конфігурація захисту повинна включати:

• Стандартну політику заборони вхідного трафіку
• SSH обмежений відомими IP-адресами управління або VPN-шлюзом
• Усі несуттєві порти закриті
• Обмеження швидкості на портах автентифікації
• Журналювання увімкнено для відхиленого трафіку

Якщо ви запускаєте GPU-навантаження або сервіси ML-інференції на GPU Хостингу, приділіть особливу увагу портам, відкритим Jupyter notebooks, TensorBoard та API для обслуговування моделей — вони часто стають мішенями ботів для криптомайнінгу, які сканують відкриті порти з великими номерами.

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

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

Завдання аудиту для щоквартального виконання:

• Запустіть sudo ufw status numbered або еквівалент і перегляньте кожне правило відносно поточного інвентарю сервісів
• Видаліть правила для виведених з експлуатації сервісів, старих IP-адрес і тимчасових винятків, які так і не були прибрані
• Перевірте, що стандартні політики все ще deny incoming
• Переконайтеся, що правила IPv6 відповідають правилам IPv4
• Підтвердіть, що журналювання увімкнено і що журнали відхиленого трафіку надходять до вашої SIEM або агрегатора журналів
• Протестуйте правила за допомогою nmap із зовнішнього хоста, щоб переконатися, що поверхня атаки відповідає вашим намірам

# Scan your own server from an external host to verify exposed ports
nmap -sS -sV -p 1-65535 --open YOUR_SERVER_IP

• Перевірте наявність правил ESTABLISHED/RELATED і правильність їх порядку
• Перегляньте правила обмеження швидкості та скоригуйте пороги на основі спостережуваних шаблонів трафіку

Матриця рішень: вибір правильного інструменту брандмауера

Практичні ключові висновки

• Встановіть стандартну заборону вхідного трафіку перед написанням будь-яких правил дозволу. Це гарантує, що будь-яке правило, яке ви забули написати, призведе до заблокованого з’єднання, а не відкритого.
• Ніколи не відкривайте SSH для 0.0.0.0/0 на виробничому сервері. Обмежте його IP-адресою управління, підмережею VPN або використовуйте port knocking.
• Пишіть правила дозволу якомога конкретніше. Надавайте перевагу from 203.0.113.50 to any port 22 proto tcp над allow 22.
• Дублюйте правила IPv4 в IPv6. Брандмауер, який фільтрує лише IPv4, — це половина брандмауера.
• Увімкніть обмеження швидкості з’єднань на всіх портах автентифікації як базовий захист від атак грубої сили.
• Реєструйте відхилений трафік. Мовчазне відкидання без журналювання робить реагування на інциденти практично неможливим.
• Проводьте аудит правил за розкладом. Застарілі правила — це відповідальність, а не захисна мережа.
• Тестуйте ззовні. Використовуйте nmap або зовнішній сканер портів після кожної значної зміни правил, щоб підтвердити ефективну поверхню атаки.
• Використовуйте ufw reload замість ufw disable && ufw enable, щоб уникнути розриву активних з’єднань під час оновлення правил.
• На nftables та iptables завжди розміщуйте правило прийняття ESTABLISHED/RELATED на початку вхідного ланцюжка, щоб уникнути порушення сесій, ініційованих вихідним трафіком.

Часті запитання

У чому різниця між правилом брандмауера та групою безпеки в хмарних середовищах?

Група безпеки (AWS, GCP, Azure) — це stateful хмарний фільтр пакетів, що застосовується на рівні гіпервізора до того, як трафік досягне вашої VM. Правило хостового брандмауера (UFW, firewalld) виконується всередині ядра ОС. Обидва слід використовувати одночасно для глибокого захисту — хмарна група безпеки як зовнішній периметр, а хостовий брандмауер як внутрішній рівень захисту.

Чому UFW показує правило як активне, але трафік все одно блокується?

Найпоширенішою причиною є порядок правил. Правило DENY раніше в ланцюжку спрацьовує раніше вашого правила ALLOW. Запустіть sudo ufw status numbered і перевірте порядок. Також переконайтеся, що правила IPv6 існують, якщо клієнт підключається через IPv6, і підтвердіть, що цільовий інтерфейс правильний, якщо сервер має кілька мережевих інтерфейсів.

Чи слід повністю блокувати ICMP з міркувань безпеки?

Ні. Блокування всього ICMP порушує виявлення MTU шляху, що призводить до зависання TCP-сесій у мережах із нестандартними MTU. Це також порушує traceroute і значно ускладнює мережеву діагностику. Блокуйте лише типи ICMP, які не мають законного операційного використання (типи 17 та 18). Дозволяйте echo request/reply, destination unreachable та time exceeded.

Що відбувається з активними SSH-з’єднаннями при перезавантаженні UFW?

sudo ufw reload перезавантажує набір правил без очищення існуючих записів стану conntrack. Активні SSH-сесії залишаються підключеними, оскільки таблиця відстеження з’єднань ядра все ще зберігає їх стан ESTABLISHED. Лише sudo ufw disable з наступним sudo ufw enable очистить стан і потенційно розірве активні з’єднання.

Як запобігти втраті правил брандмауера після перезавантаження системи?

UFW автоматично зберігає правила після перезавантаження через конфігураційні файли /etc/ufw/. Для firewalld використовуйте прапор --permanent для кожного правила та запустіть sudo firewall-cmd --reload. Для звичайного nftables збережіть набір правил за допомогою sudo nft list ruleset > /etc/nftables.conf і переконайтеся, що systemd-сервіс nftables увімкнено. Для iptables використовуйте iptables-save > /etc/iptables/rules.v4 та встановіть пакет iptables-persistent.