Практический разбор · Docker
Docker: как служебный порт случайно становится публичным
Публикация порта Docker без адреса хоста обычно открывает его на всех интерфейсах. Проверьте привязки контейнеров и правила сети: привычный запрет ufw может не остановить трафик к опубликованному порту.
Кому нужно проверить
Администраторам сайтов в Docker, рядом с которыми работают базы, кеши, панели управления и другие служебные контейнеры. Основная задача — найти лишние публикации без остановки нужного веб-трафика. Важна не только марка продукта, но и конкретная версия, способ установки, операционная система и конфигурация.
В чём риск
Публикация связывает порт хоста с портом контейнера. Если адрес хоста не указан, служба может стать доступной через внешний интерфейс. Это отдельный маршрут, который может обходить HTTP-прокси и его проверки. На Linux Docker перенаправляет такой трафик до цепочек INPUT и OUTPUT, которыми пользуется ufw, поэтому обычный запрет ufw нельзя считать достаточным доказательством блокировки. Отключать управление firewall со стороны Docker без полноценной замены правил тоже опасно: это может нарушить сеть и изоляцию.
Затронутые версии
Руководство прежде всего для Docker Engine на Linux с bridge-сетью и публикацией портов. Настройки host, macvlan, ipvlan, Swarm и прямой маршрутизации требуют отдельной проверки. Публикация без адреса по умолчанию использует все адреса хоста; итоговая внешняя доступность зависит также от маршрутов и сетевых правил.
Исправленные версии
Для случайной публикации нет единственного исправляющего выпуска: удалите ненужную публикацию или задайте подходящий адрес и сетевые ограничения. В Docker до 28.0.0 даже порт, опубликованный на localhost, мог быть доступен соседям в том же L2-сегменте. Используйте поддерживаемый Engine с этим исправлением и проверяйте фактическую сеть.
Что сделать
- 1На нужном Docker-хосте проверьте текущий контекст CLI, версию Engine и список контейнеров с портами. Сопоставьте каждую публикацию с назначением службы. Не путайте запись вида 6379/tcp без адреса хоста с опубликованным отображением порта.
- 2Проверьте исходную конфигурацию развёртывания и все IPv4/IPv6-привязки. Для служебного обмена между контейнерами одной сети публикация на хост часто не нужна. Учитывайте прямую маршрутизацию и нестандартные режимы сети.
- 3Удалите ненужную публикацию в конфигурации. Если доступ нужен только программе на самом хосте, используйте явную loopback-привязку и проверьте версию Engine. Если прокси находится в другом контейнере, спланируйте общую сеть: loopback хоста и контейнера не одно и то же.
- 4Сохраните конфигурацию, перечень образов и резервные копии важных томов. На тестовой среде пересоздайте контейнер с новым отображением портов и проверьте приложение. Изменение файла конфигурации без пересоздания уже запущенного контейнера не меняет его публикацию.
- 5Примените изменение в рабочей среде и повторите просмотр портов. С разрешённой внешней точки проверьте соединение только со своим известным служебным портом; оно должно блокироваться. Отдельно проверьте, что нужный веб-сервис и внутренние клиенты работают.
- 6Проверьте результат после штатного повторного развёртывания: старый compose-файл или автоматизация не должны вернуть публикацию. Если требуется откат, сохраняйте блокировку на внешнем сетевом уровне и восстанавливайте только необходимую связность.
- 7Если служба была открыта без нужной аутентификации, проверьте её журналы, данные и секреты. Закрытие порта не отменяет возможные предыдущие изменения. Не отключайте правила Docker целиком ради попытки заставить ufw работать ожидаемым образом.
Что связывает публикация порта
Статичная схема объясняет путь соединения; текст достаточен без движения и цвета.
- 1Клиент обращается к адресу и порту хоста
- 2Правила Docker направляют соединение в контейнер
- 3Служба контейнера применяет собственную проверку доступа
- 4Администратор проверяет и публикацию, и внешние сетевые ограничения
Примеры конфигурации и проверки
docker context show
docker ps --format 'table {{.Names}}\t{{.Ports}}'Для установленного Docker CLI с уже разрешённым доступом к нужному Engine. Проверьте контекст первой командой: он может указывать на удалённый сервер. Вторая выводит имена и порты запущенных контейнеров, ничего не меняя. Доступ к Docker socket привилегирован: не выдавайте его новому пользователю только ради примера. Список не доказывает внешнюю доступность и не охватывает отдельную конфигурацию Swarm или host-сети. Откат не нужен; внутренние имена не публикуйте.
Как не подпустить ботов к сайту
BotProtection принимает запросы перед вашим сайтом и фильтрует автоматизированные обращения. Поэтому ботам сложнее добраться до уязвимого компонента и начать его проверять или атаковать, а вероятность успешной автоматизированной атаки становится значительно ниже. Это дополнительный слой защиты: обновление уязвимых компонентов, проверка журналов и реагирование на инциденты остаются обязательными.
Первоисточники
Снизьте шанс атаки до того, как бот дойдёт до сайта
Подключите BotProtection как фильтр перед сайтом: подозрительные автоматизированные запросы отсекаются до обращения к вашему серверу. Это значительно снижает вероятность автоматизированной атаки, но не исправляет саму уязвимость, поэтому обновление и настройка компонентов остаются обязательными.