Новый сервер — это не чистый лист. Это незапертая дверь

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

От появления сервера в сети до первой атаки прошло меньше шести часов. До успешного взлома — меньше суток.

Три условия, которые это позволили: PostgreSQL торчал наружу, пароль был postgres, файрвол не был включён. Всё. Больше ничего не потребовалось.

Почему это происходит даже с опытными людьми

Есть определённая психология нового сервера. Ты только что его поднял, всё работает, приложение отвечает — и ты переключаешься на следующую задачу. Безопасность кажется чем-то, что можно настроить потом. Потом — когда будет время. Потом — перед продакшном. Потом — после релиза.

Потом не наступает. Или наступает, но уже в виде top, показывающего /tmp/mysql с 400% CPU.

Новый сервер в интернете — это не чистый лист. Это незапертая дверь в доме, который уже стоит на оживлённой улице. Сканеры находят его в течение часов, не дней.

Что реально произошло

Атакующий нашёл открытый порт 5432 в интернете. Запустил брутфорс. Пароль postgres — это даже не брутфорс, это первая строчка в любом словаре. Получил доступ к PostgreSQL с правами суперпользователя.

Дальше в дело вступает легальная функция PostgreSQL — COPY FROM PROGRAM. Она позволяет суперпользователю выполнить произвольную shell-команду прямо из SQL-запроса. Атакующий передал через неё bash-скрипт в base64, который скачал и запустил дроппер.

Но умнее всего оказалась механика персистенции. В базу были добавлены event triggers — триггеры, которые срабатывают при каждой DDL-операции (CREATE TABLE, ALTER, DROP…). При каждом таком событии они незаметно воссоздавали роль суперпользователя с известным атакующему паролем. То есть даже если бы администратор заметил и удалил вредоносную роль — следующая миграция или CREATE INDEX её восстановили бы автоматически.

Элегантно и по-настоящему противно.

Три правила, которые отсекают 99% таких атак

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

Базы данных не должны быть доступны из интернета. PostgreSQL, MySQL, Redis, MongoDB — ни одна из них не предназначена для прямого доступа извне. В docker-compose.yml строчка "5432:5432" для базы данных — это почти всегда ошибка. Приложение достучится до базы внутри Docker-сети по имени хоста. Снаружи этот порт не нужен никому, кроме атакующих.

Если нужен доступ для разработки — биндите только на localhost:

ports:
  - "127.0.0.1:5432:5432"

Для продакшна — убирайте ports полностью.

Дефолтные пароли — не пароли. postgres, password, root, admin — это первые строчки в любом словаре для брутфорса. Сканер подберёт их за секунды, не за часы. Генерируйте пароль при деплое:

POSTGRES_PASSWORD=$(openssl rand -base64 32)

Или используйте secret management: HashiCorp Vault, AWS Secrets Manager, Doppler. Главное — никогда не коммитьте пароли в репозиторий и не оставляйте дефолтные значения в .env.

Файрвол должен быть включён с первой минуты. Не перед релизом. Не после настройки. С первой минуты после создания сервера. Правильная модель — запрещено всё, открыто только необходимое:

ufw default deny incoming
ufw default allow outgoing
ufw allow ssh
ufw enable

После этого открывайте конкретные порты по мере необходимости. Не наоборот.

Про мониторинг, который стоит добавить

Три правила выше — это про предотвращение. Но если вы хотите ещё и видеть происходящее, добавьте в PostgreSQL минимальное логирование. По умолчанию он не пишет ни успешные подключения, ни DDL-команды. Это означает, что у вас нет никакой видимости в то, что происходит с базой.

В postgresql.conf:

log_connections = on
log_disconnections = on
log_statement = 'ddl'

И простой cron-скрипт для проверки аномалий:

#!/bin/bash
SUPERUSERS=$(psql -U postgres -t -c "SELECT count(*) FROM pg_user WHERE usesuper = true AND usename != 'postgres';")
if [ "$SUPERUSERS" -gt 0 ]; then
    echo "ALERT: обнаружены посторонние суперпользователи" | mail -s "Security Alert" admin@example.com
fi

Этого уже достаточно, чтобы заметить что-то подозрительное раньше, чем это заметит top.

Почему это важнее, чем кажется

По данным Shodan, в интернете открыто более 800 000 инстанций PostgreSQL. Значительная часть — с дефолтными или слабыми паролями. Никто не взламывает их вручную — это полностью автоматизированные сканеры, работающие круглосуточно. Они не выбирают жертв по размеру бизнеса или ценности данных. Они просто идут по списку открытых портов.

Ваш сервер — не исключение. Он уже в этом списке. Вопрос только в том, есть ли на двери замок.

Защита от этого не требует сложных технологий, дорогих инструментов или глубокой экспертизы в безопасности. Она требует трёх вещей, которые можно сделать за десять минут при первом входе на сервер. Просто не откладывайте их на потом.