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

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

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

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

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

• Shodan ^[1] — поисковая система, позволяющая с помощью различных фильтров находить компьютеры, подключенные к интернету.
• Censys.io ^[2] — новая поисковая система по интернету вещей, которая, подобно Shodan, отправляет запросы на все публично доступные IP-адреса и сохраняет их ответы. Получается список устройств (карта), где можно искать различные уязвимости или наблюдать за актуальным состоянием сетевой инфраструктуры.
• CloudFail ^[3] — инструмент «тактической разведки», цель которого — собрать достаточно информации о сервисе, защищенном Cloudflare, в надежде обнаружить местоположение сервера.
• SecurityTrails ^[4] специализируется на сборе сведений о доменном имени, IP-адресе и данных, связанных с WHOIS. Часть данных предоставляется бесплатно на одноименной веб-платформе для исследований, а больше информации доступно через платный API.
• Project Sonar ^[5] «исследует Интернет» по 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 ^[6]:

Как видно из скриншота выше, 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-адрес сервера на новый.

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

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

1. После того, как сайт поставлен под защиту внешнего сервиса (вроде уже упомянутого Cloudflare), измените IP-адрес сервера. С использованием прокси адрес, который будет отдавать DNS, станет другим, а оригинальный важно оставить не «засвеченным».
2. Посредством белого списка разрешите прямой доступ к своему сайту только с IP-адресов проксирующего сервиса (Cloudflare). Запрет для остального мира лишит сканеры возможности видеть, какой контент отдается на определенный IP-адрес/хост.
3. В целях анонимности для веб-сервера лучше установить vhost по умолчанию, не относящийся к вашей компании/веб-сайту, и использовать самоподписанный сертификат на какой-нибудь домен вроде youshallnotpass.com (как вариант — youshallnotpass.com).

   

4. Хорошая идея — использовать страницу по умолчанию вроде «It works!» у Apache или nginx. При этом, конечно же, скрыть версию самого веб-сервера (для nginx ^[7], для Apache ^[8]).

   Таким образом, вы не будете проиндексированы сканерами, которые получают доступ к IP-адресам, и это усложнит задачу для злоумышленников, ищущих реальный адрес веб-сервиса.

5. Использование SSL-сертификата — хорошее и простое решение. Однако имейте в виду, что при выдаче SSL-сертификата данные о нем публикуются в журнале Certificate Transparency ^[9] (системе регистрации и мониторинга выдачи сертификатов), который является общедоступным. Таким образом, если вы выдадите новый сертификат для своего домена, он будет опубликован и может быть легко найден, а новое имя хоста раскрыто.

   В качестве иллюстрации посмотрите, какие данные выведет поисковик crt.sh ^[10] для домена example.com:

   

   Можно не только увидеть, когда обновлялся сертификат, но и посмотреть содержимое всех предыдущих.

6. Удалите все DNS-записи, которые не используются. В интернете всё так или иначе архивируется — это справедливо и для DNS. Помимо онлайн-сервисов, с которыми легко найти старые DNS-записи для домена (вроде упомянутого SecurityTrails), исторические наборы данных можно найти в базе Project Sonar.
7. Для лучшей безопасности можно поместить перед сервером облачный балансировщик нагрузки (например, Amazon ELB) — с ним появится дополнительный уровень защиты. Впрочем, эта рекомендация применима только в тех случаях, когда для сервиса (точнее, для его конечных пользователей) допустимо увеличение задержки.

Заключение

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

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

P.S.

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

• «SSL-сертификаты от Let's Encrypt с cert-manager в Kubernetes ^[11]»;
• «11 способов (не) стать жертвой взлома в Kubernetes ^[12]»;
• «Из жизни с Kubernetes: Как HTTP-сервер испанцев не жаловал ^[13]»;
• «Успех социального эксперимента с поддельным эксплойтом для nginx ^[14]».

Автор: Юлия Шарафитдинова

Источник ^[15]