Распределенные атаки типа 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(как вариант —example.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.
Читайте также в нашем блоге:
