Одна строка в docker-compose и открытый порт PostgreSQL: как пет-проект привёл к взлому сервера

История, описанная автором пет-проекта, начинается буднично: Telegram-бот для тренировки устного счёта, код которого писал Claude Code, а разработчик лишь задавал направление и проверял результат. На том же сервере параллельно работали другие проекты, один из которых следил за нагрузкой и присылал уведомления. Когда оповещения о возросшей нагрузке начали приходить несколько дней подряд, стало очевидно, что дело не в слабом железе и не в количестве запущенных сервисов.

Подробности

Первое уведомление о нагрузке автор пропустил, списав его на ограниченные ресурсы сервера, но сообщения приходили и на второй, и на третий день. Остановка нагруженных процессов и перезапуск сервисов давали лишь временный эффект: нагрузка падала, а затем снова росла. Разгадка обнаружилась на третий день — в docker-compose одного из проектов был опубликован порт PostgreSQL, то есть база данных оказалась доступна для подключений из интернета. Сервер действительно был взломан, однако установить точную точку входа не удалось: нужных логов не сохранилось. Автор прямо признаёт: ошибка была его. Он убедился, что бот запускается и отвечает на запросы, но не проверил, кому доступна база и нужен ли ей вообще внешний порт. Claude Code писал код по заданным указаниям, но ответственность за проверку результата оставалась на человеке. Отдельно отмечается, что восстановить картину получилось лишь по косвенным признакам — прямая доказательная база отсутствовала. Ситуация типична для проектов, где генерация кода ускоряет разработку, но не отменяет базовых требований к безопасному развёртыванию. Публикация порта СУБД во внешнюю сеть — классическая ошибка конфигурации, которая при слабых учётных данных или отсутствии ограничений по IP практически гарантирует компрометацию. В данном случае отсутствие логов дополнительно усложнило расследование и не позволило точно определить вектор атаки.

Что делать

Чтобы не повторить подобный сценарий, стоит придерживаться нескольких практических правил:

• Не публикуйте порты СУБД (PostgreSQL, MySQL, MongoDB и других) во внешнюю сеть. По умолчанию база должна быть доступна только внутри docker-сети или через localhost.
• Перед запуском проекта в продакшене проверяйте итоговый docker-compose и списки открытых портов — отдельно, а не только работоспособность приложения.
• Ограничивайте доступ на уровне firewall и security groups: даже если порт открыт по ошибке, внешние подключения должны блокироваться.
• Используйте сложные уникальные пароли и не оставляйте дефолтные учётные данные.
• Настройте и сохраняйте логи: без них восстановить хронологию инцидента и найти точку входа почти невозможно.
• Регулярно отслеживайте аномальную нагрузку и разбирайтесь в её причинах сразу, а не после третьего уведомления.
• Помните, что генерация кода ИИ не снимает с разработчика ответственности за безопасность конфигурации и инфраструктуры.

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

Источник: Хабр — Информационная безопасность