Firewall на Linux: ufw и iptables простыми словами

Зачем серверу firewall, если порты и так закрыты по умолчанию

На новом сервере до установки любого ПО открытыми оказываются только порты уже запущенных системных сервисов — как правило, это SSH на 22-м порту. Проблема начинается позже: по мере установки веб-сервера, базы данных, панели управления, Docker и других инструментов каждый из них может открывать собственный сетевой порт, доступный всему интернету, если не позаботиться об обратном.

Firewall — это компонент операционной системы, который решает, какие сетевые пакеты вообще допускаются до конкретного порта или процесса, независимо от того, что делает сам процесс. Даже если база данных настроена слушать только локальные подключения, ошибка в конфигурации однажды может открыть её наружу — и правильно настроенный firewall остаётся вторым рубежом защиты, который перехватывает такую ошибку прежде, чем она станет проблемой.

Defense in depth: ни одна отдельная мера защиты не должна быть единственной линией обороны — firewall существует именно как независимый уровень, который продолжает работать, даже если что-то другое настроено неправильно.

Принцип эшелонированной защиты в информационной безопасности

Эта статья разбирает, как устроен сетевой firewall на Linux на уровне концепции, чем ufw отличается от iptables, и даёт готовые команды для типичных сценариев — от базовой защиты веб-сервера до ограничения доступа к административным интерфейсам по IP-адресу.

Разбор построен от простого к сложному: сначала — практические команды ufw, которых достаточно для подавляющего большинства сайтов на CMS, затем — что происходит под капотом на уровне iptables для тех случаев, когда стандартной абстракции недостаточно, и отдельно — типичные ловушки вроде взаимодействия Docker с firewall, в которые попадают даже опытные администраторы, не разобравшиеся в этой конкретной особенности заранее.

ufw: простой firewall для типичных задач

ufw (Uncomplicated Firewall) — стандартный инструмент управления firewall на Ubuntu и Debian, спроектированный так, чтобы закрыть 90% типичных задач простыми командами без необходимости разбираться в синтаксисе iptables напрямую. Для подавляющего большинства веб-серверов возможностей ufw более чем достаточно.

ufw status verbose

Философия ufw по умолчанию — запретить весь входящий трафик и разрешить весь исходящий, а затем добавлять точечные разрешения только для тех портов, которые реально должны быть доступны извне. Это гораздо безопаснее, чем обратный подход «разрешить всё, кроме явно запрещённого», где легко забыть закрыть что-то лишнее.

ufw default deny incoming\nufw default allow outgoing

Базовые команды ufw для типичного веб-сервера

Минимальный набор правил для сервера с сайтом на HTTPS и доступом по SSH состоит всего из трёх разрешений — для SSH, HTTP и HTTPS. Порядок команд важен: правило для SSH должно быть добавлено и подтверждено до включения firewall, иначе следующее подключение может не пройти.

ufw allow OpenSSH
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

Если SSH настроен на нестандартный порт, вместо ufw allow OpenSSH нужно указать этот порт явно, например ufw allow 2222/tcp. Посмотреть список всех активных правил с их порядковыми номерами можно командой ufw status numbered — номера удобны для удаления конкретного правила без пересоздания всех остальных.

ufw status numbered\nufw delete 3

Для временного тестирования конфигурации без риска зарезать себе доступ насовсем полезна команда ufw enable в связке с отложенным откатом — например, через at или cron с командой ufw disable через 5 минут: если что-то пошло не так, firewall отключится сам, даже если SSH-сессия уже потеряна.

iptables: что скрывается за упрощённым интерфейсом ufw

iptables — это интерфейс к встроенной в ядро Linux системе фильтрации пакетов netfilter. Правила организованы в таблицы (filter, nat, mangle) и цепочки внутри каждой таблицы: INPUT обрабатывает входящие пакеты, OUTPUT — исходящие, FORWARD — транзитные пакеты, проходящие через сервер как через маршрутизатор.

Когда команда ufw allow 443/tcp выполняется, под капотом она добавляет строку в цепочку INPUT таблицы filter — именно поэтому опытные администраторы иногда напрямую смотрят вывод iptables -L, чтобы понять, что реально происходит с трафиком, даже если повседневная работа ведётся через ufw.

iptables -L -n -v --line-numbers

ufw не заменяет iptables, а генерирует iptables-правила за вас — понимание того, что происходит под капотом, становится критичным именно в момент, когда что-то не работает так, как ожидалось.

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

Прямое использование iptables вместо ufw оправдано в сценариях, которые не укладываются в упрощённую модель ufw: сложная маршрутизация трафика (NAT, port forwarding), тонкая настройка правил для конкретных сетевых интерфейсов, интеграция с системами вроде Docker, которые сами управляют цепочками iptables.

Практический пример на чистом iptables

Для понимания того, что абстрагирует ufw, полезно один раз увидеть эквивалентный набор правил на чистом iptables. Ниже — тот же минимальный набор для веб-сервера: разрешить установленные и связанные соединения, SSH, HTTP, HTTPS, всё остальное входящее запретить.

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -P INPUT DROP

Обратите внимание на строку с интерфейсом lo (loopback) — без неё локальные процессы, обращающиеся друг к другу через 127.0.0.1 (например, PHP-FPM к локальной базе данных), могут перестать работать, потому что правило по умолчанию DROP в конце цепочки блокирует всё, что не разрешено явно, включая локальный трафик.

Правила iptables, установленные вручную командами вроде iptables -A, не сохраняются автоматически после перезагрузки сервера — для сохранения нужен отдельный пакет вроде iptables-persistent на Debian/Ubuntu, который восстанавливает правила при старте системы. Именно эта деталь — частая причина того, почему «firewall был настроен, но после перезагрузки правила пропали».

Ограничение доступа по IP-адресу к чувствительным сервисам

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

ufw allow from 203.0.113.50 to any port 8443 proto tcp

Такой подход резко снижает поверхность атаки: даже если в интерфейсе панели администрирования обнаружится уязвимость, воспользоваться ей смогут только те, кто уже находится в разрешённом списке адресов, а не любой сканер в интернете. Это особенно актуально для интерфейсов баз данных (например, phpMyAdmin) и панелей мониторинга, которые не всегда рассчитаны на прямое воздействие из открытого интернета.

Ограничение по IP не заменяет надёжный пароль или двухфакторную аутентификацию, а дополняет их — если IP-адрес администратора динамический и часто меняется, вместо жёсткого списка адресов разумнее рассмотреть VPN с фиксированным внутренним адресом, к которому уже применяется правило firewall.

Rate limiting: защита от подбора без полного закрытия порта

Некоторые порты — прежде всего SSH — должны оставаться открытыми для входа с любого адреса, но это не означает, что нужно мириться с неограниченным числом попыток подключения от одного источника. В ufw для этого есть встроенная команда ufw limit, которая автоматически блокирует IP-адрес при слишком частых попытках подключения за короткий промежуток времени.

ufw limit OpenSSH

Правило limit в ufw по умолчанию блокирует адрес, если с него было более 6 попыток подключения за 30 секунд — этого достаточно, чтобы не мешать нормальному использованию (человек не подключается по SSH раз в несколько секунд), но эффективно замедляет автоматизированный перебор паролей.

Rate limiting на уровне firewall — не замена, а дополнение к fail2ban, который анализирует именно логи аутентификации и умеет банить за неудачные попытки входа конкретно, а не просто за частоту сетевых подключений. Подробнее о настройке fail2ban — в статье «SSH: ключи, порт и защита от брутфорса».

Docker и firewall: скрытая ловушка

Одна из самых частых причин, почему «порт вроде бы закрыт в ufw, но сервис всё равно доступен извне» — это Docker. При публикации порта контейнера (например, docker run -p 5432:5432) Docker по умолчанию добавляет собственные правила напрямую в таблицу iptables, в цепочку DOCKER, минуя обычную логику ufw INPUT.

Docker и ufw управляют одной и той же системой netfilter независимо друг от друга — правило ufw deny не гарантирует, что порт контейнера будет действительно недоступен, если он опубликован через -p.

Известная особенность взаимодействия Docker и firewall-фронтендов, задокументированная в issue-трекере Docker

Практическое следствие: если на сервере используется Docker, нельзя полагаться только на правила ufw для портов, опубликованных контейнерами — нужно либо публиковать порты только на localhost (-p 127.0.0.1:5432:5432), либо явно настраивать правила в цепочке DOCKER-USER, которая уважает решения администратора и обрабатывается до основной логики публикации портов Docker.

Для сервера, где Docker используется наравне с обычными системными сервисами, разумная практика — держать все порты баз данных и служебных интерфейсов контейнеров привязанными только к 127.0.0.1, и наружу пробрасывать через firewall и обратный прокси только реально нужные веб-порты 80 и 443.

docker run -p 127.0.0.1:5432:5432 postgres

В более новых версиях Docker появилась возможность настроить движок так, чтобы он уважал существующие пользовательские правила iptables вместо того, чтобы вставлять свои собственные раньше цепочки INPUT — соответствующая опция называется iptables: false в конфигурации демона в сочетании с ручной настройкой сетевых правил, но это уже требует заметно более глубокого понимания сетевой части Docker и подходит скорее для production-окружений с выделенным администратором инфраструктуры, чем для типичного небольшого проекта.

firewalld: аналог ufw на CentOS и AlmaLinux

На дистрибутивах семейства RHEL — CentOS, AlmaLinux, Rocky Linux — стандартным инструментом управления firewall по умолчанию является firewalld, а не ufw. Концептуально он ближе к iptables, чем ufw, но также абстрагирует прямую работу с цепочками через понятие «зон» — предустановленных профилей с разным уровнем доверия к сети.

firewall-cmd --permanent --add-service=https\nfirewall-cmd --permanent --add-port=2222/tcp\nfirewall-cmd --reload

Разница в подходе: firewalld требует явного вызова --reload после изменений или использования флага --permanent для того, чтобы правило сохранилось после перезагрузки, тогда как в ufw изменения применяются сразу и автоматически сохраняются. Эта деталь — частый источник путаницы при переходе между дистрибутивами.

IPv6: не забытый ли порт

Многие серверы сегодня получают не только IPv4, но и IPv6-адрес, и firewall должен фильтровать оба стека независимо — правило, добавленное только для IPv4, не защищает от подключений по IPv6, если он включён на сервере.

ufw по умолчанию обрабатывает и IPv4, и IPv6 одновременно при условии, что в конфигурационном файле /etc/default/ufw параметр IPV6 установлен в yes — это значение по умолчанию на большинстве современных дистрибутивов, но стоит явно проверить его после установки ufw, особенно если сервер использовался ранее с другой конфигурацией.

grep IPV6 /etc/default/ufw

Если провайдер не выдаёт серверу IPv6-адрес, вопрос неактуален — но проверить стоит один раз при настройке, чтобы не полагаться на предположение, которое может оказаться неверным для конкретной конфигурации сети.

Как проверить firewall извне, а не поверить ему на слово

Локальная проверка правил командой ufw status показывает, что должно происходить по замыслу конфигурации, но не гарантирует, что сервер реально ведёт себя так с точки зрения внешнего наблюдателя — расхождение случается из-за конфликтующих правил Docker, ошибок в конфигурации сетевого интерфейса или банально забытого второго firewall на уровне облачного провайдера.

Самый надёжный способ проверки — просканировать сервер снаружи, с другой машины или через специализированный онлайн-сканер портов, и сравнить фактический результат с тем, что ожидалось увидеть согласно настроенным правилам. Утилита nmap, запущенная с другого сервера, показывает реальную картину открытых портов так, как её видит любой сканер в интернете.

nmap -Pn -p 22,80,443,3306,5432,6379 203.0.113.10

Если сканирование показывает открытым порт, который должен быть закрыт — прежде всего стоит проверить, не публикует ли его напрямую Docker в обход ufw, описанное выше, и не осталась ли на сервере запущенной служба, слушающая на всех интерфейсах (0.0.0.0) вместо localhost (127.0.0.1), что делает её доступной снаружи независимо от правил firewall при определённых сетевых конфигурациях контейнеризации.

Полезная привычка — проводить такую внешнюю проверку не только сразу после настройки firewall, но и периодически в дальнейшем, особенно после установки нового ПО или изменения конфигурации Docker: список реально открытых портов имеет свойство расширяться незаметно по мере роста проекта.

Типичные ошибки при настройке firewall

Включение firewall с политикой deny incoming без предварительно добавленного и проверенного правила для SSH — самая частая причина полной потери доступа к серверу сразу после настройки firewall, требующая восстановления через веб-консоль провайдера.

Открытие портов «на всякий случай», которые реально не используются — например, порт базы данных, разработческого дашборда или временного инструмента, который забыли закрыть после того, как он больше не нужен. Каждый забытый открытый порт — это лишняя точка входа, о которой никто уже не помнит.

Полное доверие ufw в связке с Docker без учёта того, что Docker может создавать собственные правила iptables в обход обычной логики ufw для явно опубликованных портов контейнеров.

Отсутствие сохранения правил iptables при ручной настройке без ufw или firewalld — после перезагрузки сервера правила пропадают, и администратор может не заметить этого до следующего инцидента, ошибочно считая, что защита всё ещё активна.

Игнорирование логов firewall при расследовании странного поведения сети — счётчики заблокированных пакетов (iptables -L -v) часто дают прямой ответ на вопрос, почему какой-то сервис недоступен, если проблема действительно в правилах, а не в самом сервисе.

Чек-лист базовой настройки firewall с нуля

Шаг 1. Определите список портов, которые реально должны быть доступны извне: как правило, это SSH (или его нестандартный порт), 80 и 443 для веб-сервера, и, возможно, отдельные порты для специфичных сервисов вроде VPN.

Шаг 2. Добавьте правила разрешения для каждого из этих портов через ufw allow, не включая firewall на этом шаге. Шаг 3. Проверьте список добавленных правил командой ufw show added, чтобы убедиться, что ничего важного не пропущено.

Шаг 4. Включите firewall командой ufw enable и сразу же, в новой сессии терминала, не закрывая текущую, проверьте, что подключение по SSH по-прежнему работает.

Шаг 5. Настройте rate limiting для SSH через ufw limit, чтобы снизить эффективность автоматизированного перебора паролей без блокировки легитимного доступа.

Шаг 6. Если на сервере используется Docker, проверьте, что порты баз данных и служебных интерфейсов контейнеров привязаны только к 127.0.0.1, а не опубликованы на все интерфейсы напрямую.

Шаг 7. Периодически — раз в несколько месяцев или при каждом добавлении нового сервиса на сервер — пересматривайте список открытых портов командой ufw status verbose и закрывайте те, что больше не нужны.

Итог: firewall — это про минимально необходимое, а не про максимум защиты

Правильно настроенный firewall не делает сервер неуязвимым сам по себе — он решает конкретную и важную задачу: сокращает поверхность атаки до минимально необходимого набора открытых портов. Комбинация ufw для повседневной работы и понимания того, что происходит на уровне iptables под капотом, покрывает подавляющее большинство практических задач на типичном веб-сервере.

Главное практическое правило, которое стоит унести из этой статьи: никогда не включайте firewall с политикой deny incoming, не добавив и не проверив заранее правило для того порта, через который вы сейчас подключены к серверу. Если восстановление доступа всё же понадобилось — используйте веб-консоль провайдера, а не пересоздавайте сервер с нуля.

Если настройка firewall и остального базового окружения сервера кажется избыточно технической задачей — оставьте заявку внизу страницы, настроим безопасный доступ и firewall под конкретный стек вашего проекта, включая корректную работу с Docker и другими особенностями конкретной инфраструктуры.