Распределенные атаки типа 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.
Читайте также в нашем блоге:
ссылка на оригинал статьи https://habr.com/ru/company/flant/blog/506016/
Добавить комментарий