Docker и UFW: как контейнеры обходят брандмауэр и как это исправить

Многие администраторы сталкиваются с неожиданным поведением системы, когда после установки Docker привычные правила брандмауэра перестают работать. На экране UFW отображается запрет (deny), но порт контейнера остается доступным извне. Это не ошибка и не «поломка» UFW, а особенность сетевой архитектуры Docker. В этой статье мы разберем причины этой проблемы и предложим практичные решения для восстановления полного контроля над сетевым трафиком.

Содержание

Почему стандартный `ufw deny` не работает: архитектура сетей в Docker

Суть проблемы заключается в том, как Docker взаимодействует с сетевым стеком Linux (Netfilter). UFW по умолчанию управляет правилами в цепочке INPUT, которая отвечает за трафик, направленный непосредственно к процессам на хосте.

Когда вы публикуете порт контейнера с помощью опции -p 8080:80, Docker не просто «открывает» порт. Он изменяет адрес назначения пакета с помощью механизма DNAT (Destination Network Address Translation). После этого пакет направляется не в цепочку INPUT, а сразу в цепочку FORWARD, которая обрабатывает транзитный трафик.

Схема движения трафика:

Входящий пакет (IP_сервера:8080)
       ↓
Цепочка PREROUTING (DNAT) — изменение адреса на 172.17.0.2:80
       ↓
Маршрутизация (ip_forward) — пакет перенаправляется на внутренний интерфейс Docker
       ↓
Цепочка FORWARD (здесь срабатывают правила Docker)
       ↓
Доставка в контейнер (172.17.0.2:80)

Таким образом, ваше запрещающее правило в цепочке INPUT (ufw deny 8080) просто игнорируется, так как пакет туда даже не попадает. Это создает ложное чувство безопасности.

Как проверить проблему на практике

Для наглядной демонстрации проблемы выполните следующие шаги. Этот тест подтвердит, что стандартные средства UFW не контролируют трафик к контейнерам.

Запустите тестовый веб-сервер:bashdocker run -d —name test-web -p 8080:80 nginx:alpine
Добавьте запрещающее правило в UFW:bashsudo ufw deny 8080/tcp sudo ufw status verbose
Проверьте доступность порта с внешнего компьютера:bashcurl -v http://<IP_адрес_вашего_сервера>:8080Вы увидите, что контейнер все еще отвечает, несмотря на добавленный запрет.
Проанализируйте правила iptables:bashsudo iptables -L DOCKER -n -vЭта команда покажет автоматически созданные Docker-правила, которые маршрутизируют трафик в обход ваших запретов.

Основное решение: цепочка DOCKER-USER

Самый надежный и официально рекомендованный способ восстановить контроль над брандмауэром — использование специальной цепочки DOCKER-USER. Docker создает ее для того, чтобы администраторы могли вставлять собственные правила фильтрации до того, как сработают автоматические правила, генерируемые Docker для контейнеров.

Настройка правил в DOCKER-USER

Для этого необходимо отредактировать конфигурационный файл UFW и добавить в него правила для цепочки DOCKER-USER.

Откройте файл /etc/ufw/after.rules:bashsudo nano /etc/ufw/after.rules
Добавьте в конец файла следующий блок:bash# НАЧАЛО БЛОКА DOCKER-USER *filter :DOCKER-USER — [0:0] -A DOCKER-USER -j RETURN COMMIT # КОНЕЦ БЛОКА DOCKER-USER
Перезагрузите UFW для применения изменений:bashsudo ufw reload

Схема работы после настройки:

Входящий пакет
       ↓
Цепочка PREROUTING (DNAT)
       ↓
Цепочка FORWARD
       ↓
Цепочка DOCKER-USER (Пользовательские правила UFW) ← Контроль здесь!
       ↓
Цепочка DOCKER (Автоматические правила Docker)
       ↓
Доставка в контейнер

Теперь весь транзитный трафик к контейнерам будет проходить через цепочку DOCKER-USER, где вы можете применять свою политику безопасности.

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

После того как контроль над трафиком перешел в DOCKER-USER, стандартная команда ufw allow больше не работает для контейнеров, так как она продолжает управлять цепочкой INPUT. Для управления транзитным трафиком к контейнерам используется команда ufw route.

Важное замечание: В правиле для ufw route нужно указывать внутренний порт контейнера, а не внешний порт, который вы опубликовали на хосте.

Примеры использования ufw route:

Разрешить доступ к любому контейнеру на порт 80:bashsudo ufw route allow proto tcp from any to any port 80
Разрешить доступ к конкретному контейнеру по его IP-адресу:bashsudo ufw route allow proto tcp from any to 172.17.0.2 port 80
Разрешить доступ к контейнеру MySQL только с конкретного IP-адреса:bashsudo ufw route allow proto tcp from 203.0.113.50 to any port 3306
Удалить ранее созданное правило:bashsudo ufw route delete allow proto tcp from any to any port 80

Автоматизация управления с помощью ufw-docker

Для тех, кто не хочет вручную редактировать системные файлы и запоминать синтаксис ufw route, существует утилита ufw-docker от Chaifeng. Она автоматизирует настройку цепочек и предоставляет удобный интерфейс для управления доступом.

Установка и использование:

Скачайте скрипт:bashsudo wget -O /usr/local/bin/ufw-docker https://github.com/chaifeng/ufw-docker/raw/master/ufw-docker sudo chmod +x /usr/local/bin/ufw-docker
Установите интеграцию с UFW:bashsudo ufw-docker install sudo systemctl restart ufw
Управляйте доступом, указывая имя контейнера или его порт:bash# Разрешить доступ к контейнеру my-web на порт 80 sudo ufw-docker allow my-web 80 # Запретить доступ к контейнеру my-db с подсети 192.168.1.0/24 sudo ufw-docker deny my-db from 192.168.1.0/24

Этот инструмент минимизирует риск ошибок и избавляет от необходимости работать с динамическими IP-адресами контейнеров.

Лучшие практики для безопасной архитектуры

Помимо настройки брандмауэра, существуют архитектурные приемы, которые делают вашу инфраструктуру более безопасной.

1. Привязка к локальному хосту (127.0.0.1)

Самый простой способ защитить критичные сервисы, такие как базы данных, — привязать их только к локальному интерфейсу. Это гарантирует, что порт будет доступен исключительно с самого хоста (например, для подключения других контейнеров).

Для Docker:

bash

docker run -d -p 127.0.0.1:5432:5432 postgres:16-alpine

Для Docker Compose:

yaml

services:
  db:
    image: postgres:16
    ports:
      - "127.0.0.1:5432:5432"

2. Использование обратного прокси (Reverse Proxy)

Вместо того чтобы публиковать порты каждого сервиса наружу, лучше создать единую точку входа. Только один контейнер с прокси-сервером (например, Nginx, Traefik или Caddy) имеет открытые внешние порты 80 и 443. Все внутренние приложения работают в изолированных Docker-сетях и не имеют доступа извне.

Схема работы с Reverse Proxy:

text

Интернет
   ↓
[Host:80/443] → Контейнер Nginx (публичный)
   ↓              ↓
[Внутренняя сеть Docker]
   ↓              ↓
Контейнер App 1   Контейнер App 2 (приватные, без опубликованных портов)

Этот подход упрощает управление SSL-сертификатами, лимитами запросов и аутентификацией.

Почему не стоит отключать iptables

Иногда встречаются советы отключить управление iptables со стороны Docker, установив в /etc/docker/daemon.json параметр "iptables": false. Хотя это и решает проблему конфликта с UFW, последствия будут катастрофическими для сетевой функциональности:

Перестанет работать NAT и маскарадинг для контейнеров.
Публикация портов (-p) станет неэффективной.
Сломается сетевая изоляция между контейнерами.
Вся сеть Docker (bridge, overlay) потребует ручной настройки.

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

Взгляд в будущее: nftables и Docker 29+

Современные дистрибутивы Linux (например, Ubuntu 22.04 и новее) все активнее переходят на nftables как замену классическому iptables. Начиная с версии 29, Docker поддерживает nftables в качестве бэкенда (экспериментальная функция). В этом случае знакомой цепочки DOCKER-USER может не существовать, и фильтрацию придется строить через отдельные таблицы nftables.

Что это значит для администратора?
В краткосрочной перспективе большинство систем работают через уровень совместимости iptables-nft, поэтому текущие решения остаются актуальными. Однако будущее за nftables, и важно быть готовым к изучению нового синтаксиса для написания правил фильтрации.

Комплексная безопасность контейнеров

Настройка брандмауэра — это лишь первый шаг. Безопасность контейнерной инфраструктуры должна быть комплексной. Вот дополнительные меры, которые стоит внедрить:

Ограничение ресурсов: Используйте флаги --memory, --cpus, --ulimit, чтобы защитить хост от атак типа «отказ в обслуживании» (DoS) внутри контейнера.
Неизменяемая файловая система: Запускайте контейнеры с флагом --read-only, чтобы предотвратить запись в файловую систему.
Ограничение привилегий: Избегайте запуска процессов из-под root внутри контейнера. Используйте опцию --user.
Минимальные образы: Выбирайте легковесные дистрибутивы (например, alpine) для уменьшения поверхности атак.
Сканирование уязвимостей: Включите сканирование образов на CVE (Common Vulnerabilities and Exposures) в ваш CI/CD пайплайн.
Регулярный аудит: Используйте инструменты вроде Docker Bench for Security для проверки конфигурации хоста и контейнеров.

Итоги

Использование Docker на сервере с UFW требует четкого понимания сетевых механизмов. Полагаться только на стандартные команды ufw deny — рискованно и неэффективно.

Ключевые выводы для обеспечения безопасности:

Перехватите управление: Используйте цепочку DOCKER-USER для фильтрации трафика к контейнерам.
Применяйте ufw route: Точечно разрешайте доступ к контейнерам, указывая их внутренние порты.
Скрывайте критические сервисы: Привязывайте базы данных и внутренние API к 127.0.0.1.
Используйте Reverse Proxy: Создайте единую точку входа для всех публичных сервисов.

Только сочетание этих подходов даст вам предсказуемую, управляемую и, что самое главное, безопасную контейнерную инфраструктуру, защищенную как на уровне хоста, так и на уровне отдельных сервисов.