Гляди в оба: как не выставить наружу прокси для внутренних сервисов10.06.2020 13:17

Распределенные атаки типа DDoS весьма популярны. Зачастую для защиты от них используются сервисы вроде Cloudflare, позволяющие «поглотить» поток вредного трафика. Но даже применение дополнительных механизмов защиты в них (например, режима «I’m Under Attack» в сочетании с белым списком для упомянутого сервиса) не поможет, когда вы допустили неосторожность и, сами того не заметив, раскрыли всему миру свой IP-адрес. О случае из жизни и о том, как не допустить подобного (и, соответственно, ненужных DDoS-атак), — читайте под катом.

Предисловие. О сканерах

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

Вот несколько известных систем, помогающих найти уязвимые или неправильно настроенные устройства:

Shodan — поисковая система, позволяющая с помощью различных фильтров находить компьютеры, подключенные к интернету.
Censys.io — новая поисковая система по интернету вещей, которая, подобно Shodan, отправляет запросы на все публично доступные IP-адреса и сохраняет их ответы. Получается список устройств (карта), где можно искать различные уязвимости или наблюдать за актуальным состоянием сетевой инфраструктуры.
CloudFail — инструмент «тактической разведки», цель которого — собрать достаточно информации о сервисе, защищенном Cloudflare, в надежде обнаружить местоположение сервера.
SecurityTrails специализируется на сборе сведений о доменном имени, IP-адресе и данных, связанных с WHOIS. Часть данных предоставляется бесплатно на одноименной веб-платформе для исследований, а больше информации доступно через платный API.
Project Sonar «исследует Интернет» по 70+ различным службам и протоколам, чтобы понять глобальную подверженность распространенным уязвимостям.

Одним из них — Censys — мы воспользовались в реальной ситуации, речь о которой и пойдет далее.

Как было у нас

Инфраструктура проекта выглядела следующим образом:

домен test.com;
Cloudflare в качестве DNS;
один балансировщик nginx с сертификатами для 1.test.com, 2.test.com, *.test.com.

В чем же проблема? При сканировании IP-адресов по 443-му порту nginx отвечает сертификатом (в нем фигурирует домен test.com). Сопоставление домена с IP-адресом балансировщика приводит к возможности DDoS-атаки.

Например, наш домен (test.com) использует серверы GCORE. Просто введя эти данные в поисковую строку одного из известных сканеров, мы получим сопоставление IP-адресов с доменами из сертификата. Но ведь эти адреса должны быть скрыты из публичного доступа!

Иллюстрация на Censys:

Как видно из скриншота выше, IP-адрес сервера был получен путем сопоставления публичного IP адреса и домена из сертификата, которым «ответил» nginx. Любой злоумышленник сможет найти его таким образом и воспользоваться в своих целях.

Как мы решили проблему

В нашем случае помогло создание самоподписанного сертификата для default_server с доменом example.com. В конфиг nginx на балансировщике добавляется:

server {
  listen 443 default_server ssl http2;

  ssl_certificate /etc/nginx/ssl/examplecom/tls.crt;
  ssl_certificate_key /etc/nginx/ssl/examplecom/tls.key;
}

После этого при новых сканированиях IP-адреса nginx будет отдавать сертификат, в котором не будет упоминания реального домена (test.com). Вместо него покажется example.com, так что злоумышленник не сможет сопоставить домен с IP-адресом балансировщика.

Вместе с этим, конечно, потребуется заменить уже «засвеченный» IP-адрес сервера на новый.

Общие рекомендации

Если посмотреть на описанную проблему более глобально, то вот список рекомендаций, на которые стоит обратить внимание, если вы хотите предотвратить возникновение подобных ситуаций:

После того, как сайт поставлен под защиту внешнего сервиса (вроде уже упомянутого Cloudflare), измените IP-адрес сервера. С использованием прокси адрес, который будет отдавать DNS, станет другим, а оригинальный важно оставить не «засвеченным».
Посредством белого списка разрешите прямой доступ к своему сайту только с IP-адресов проксирующего сервиса (Cloudflare). Запрет для остального мира лишит сканеры возможности видеть, какой контент отдается на определенный IP-адрес/хост.
В целях анонимности для веб-сервера лучше установить vhost по умолчанию, не относящийся к вашей компании/веб-сайту, и использовать самоподписанный сертификат на какой-нибудь домен вроде youshallnotpass.com (как вариант — youshallnotpass.com).
Хорошая идея — использовать страницу по умолчанию вроде «It works!» у Apache или nginx. При этом, конечно же, скрыть версию самого веб-сервера (для nginx, для Apache).
Таким образом, вы не будете проиндексированы сканерами, которые получают доступ к IP-адресам, и это усложнит задачу для злоумышленников, ищущих реальный адрес веб-сервиса.
Использование SSL-сертификата — хорошее и простое решение. Однако имейте в виду, что при выдаче SSL-сертификата данные о нем публикуются в журнале Certificate Transparency (системе регистрации и мониторинга выдачи сертификатов), который является общедоступным. Таким образом, если вы выдадите новый сертификат для своего домена, он будет опубликован и может быть легко найден, а новое имя хоста раскрыто.
В качестве иллюстрации посмотрите, какие данные выведет поисковик crt.sh для домена example.com:
Можно не только увидеть, когда обновлялся сертификат, но и посмотреть содержимое всех предыдущих.
Удалите все DNS-записи, которые не используются. В интернете всё так или иначе архивируется — это справедливо и для DNS. Помимо онлайн-сервисов, с которыми легко найти старые DNS-записи для домена (вроде упомянутого SecurityTrails), исторические наборы данных можно найти в базе Project Sonar.
Для лучшей безопасности можно поместить перед сервером облачный балансировщик нагрузки (например, Amazon ELB) — с ним появится дополнительный уровень защиты. Впрочем, эта рекомендация применима только в тех случаях, когда для сервиса (точнее, для его конечных пользователей) допустимо увеличение задержки.

Заключение

SSL/TLS — основа безопасного интернета. В контексте защиты веб-сервисов он необходим не только для очевидных операций вроде обработки данных кредитных карт: он в целом обеспечивает конфиденциальность, критическую безопасность и целостность данных и для самих сайтов, и для личной информации их посетителей.

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

P.S.

Читайте также в нашем блоге: