Как настроить правила Firewall: полное техническое руководство

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

Это руководство охватывает архитектуру правил брандмауэра, UFW на Linux, firewalld, Windows Defender Firewall, nftables, а также операционные практики, отличающие защищённую среду от неправильно настроенной.

Что на самом деле контролируют правила брандмауэра

Каждое правило в наборе правил брандмауэра оценивается по пяти основным атрибутам пакета, которые обычно называют 5-кортежем:

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

Помимо 5-кортежа, межсетевые экраны с отслеживанием состояния также отслеживают состояние соединения (NEW, ESTABLISHED, RELATED, INVALID), что позволяет им разрешать обратный трафик для исходящих соединений без написания явных входящих правил для каждого ответа.

Брандмауэры с отслеживанием состояния и без него

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

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

Одним из наиболее распространённых источников неправильной настройки является непонимание порядка правил. Большинство брандмауэров оценивают правила сверху вниз и применяют первое совпадающее правило, после чего останавливаются. Это означает:

• Широкое правило 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

Граничный случай: Правила UFW deny отправляют TCP RST или ICMP-ответ о недоступности порта, что подтверждает существование хоста. Используйте 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

На брандмауэрах с отслеживанием состояния отсутствие явного разрешения соединений 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) — это управляемый облаком фильтр пакетов с отслеживанием состояния, применяемый на уровне гипервизора до того, как трафик достигает вашей 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.