DDoS атака в обход Qrator. Как защитится?
Есть сервисы, защищающие нас от DDoS атак. Они работают по принципу прокси: в DNS прописывается их IP, они фильтруют трафик и проксируют на Ваш сервер. Все они настоятельно рекомендуют прятать свой IP и в публичном доступе давать только IP прокси-защитника. Вполне здравый подход, достаточный для успешной защиты. А я расскажу на чем можно проколоться и как от этого защитится.Исходящая почтаДавайте зарегистрируемся в таком сервисе и получим от него письмо о регистрации в почту. Откроем исходник письма и увидим:
Received: from mxfront8j.mail.yandex.net ([127.0.0.1])
by mxfront8j.mail.yandex.net with LMTP id c0MIOzBI
for
Теперь мы можем смело атаковать эту машину. Канал на машине врядли будет более 1GB, но есть материнки где встроены сетевые карты сразу с 4 мя интерфейсами — значит атака будет с запасом — 4GB. Мы не будем устраивать атаку на приложение, или атаку на nginx — можно просто залить канал трафиком. При том, то что мы зальем только входящее направление к серверу — не страшно — запросы от пользователей, тоже входящее направление. Много ли это 4 GB для DDoS атаки? Давайте посчитаем! В Москве у многих людей дома хороший интернет — 40Мб минимум. 4 GB / 40 MB = 100 машин. Это всего лишь 100 машин с ботом — такой ботнет можно организовать довольно быстро (если есть соответствующий навык), а для человека постоянно занимающегося DDoS — это вообще не проблема, современные ботнеты — это тысячи зараженных машин.
Как же защитится? Простое решение — иметь почтовую машину вне ДЦ и вне боевой подсети, которая будет работать почтовым релеем и отрезать весь «Received» что у неё есть. Сделать это не сложно, в том же postfix есть опция content_filter, где можно указать SMTP-прокси для фильтрации контента. На любом языке можно легко и просто написать smtp-proxy, который отрежет всё лишнее в письме. Я готовых инструментов не знаю если честно, но для меня задача написать smtp-proxy на python или ruby — задача на несколько часов.Украсть DNS зону Менее доступный, но тоже реальный способ. Утащив DNS-зону мы найдем в ней имена машин и IP адреса — обычно технические имена машин держат прямо в этой же зоне. Что что вродеsrv1.example.com IN A xxx.xx.xx.xxxЗащитится довольно просто — все технические DNS-ы, выносятся в отдельный поддомен и защищаются более тщательно. srv1.servers.example.com — как то так.
Непрямая атака Не сложно сделать вывод, что сайт без статики — не работает. Обычно сервисы для защиты от DDoS берут деньги за трафик, по этому статику с основного домена переносят на CDN. Завалить трафиком CDN — задача очень сложная, из за его распределенности. Но можно посмотреть, что за статика есть еще на сайте. О! С левого сервиса показываются баннеры и он не сидит за проксей-защитником — это просто удача. Можно залить канал к баннерной системе: не загрузится js, не случится DOM Ready — если на сайте куча js — пользоваться им почти невозможно.Это не универсальный способ, но он может прокатить, там где сайт без js не работает впринципе. Защита от этого тоже максимально тупая — асинхронный js к баннерам. Не смог — ну и ладно.
Финансовая атака Вот мы нашли на CDN интересный файлик: cdn-1.example.com/static/video/hardporn.flv и весит он аж 140 MB. Мы то помним, что прокси-защитники берут деньги за трафик. А откуда CDN возьмет этот файл? В простом случае с www.example.com/static/video/hardporn.flv, проверим и убедимся, что он отдается. Ну и отлично. В простом случае нам нужен очень маленький ботнет, который просто будет пару дней скачивать этот файл — без особой нагрузки, не привлекая к себе внимания прокси-защитника. Конечно это будет превышение предоплаченного трафика и фирме-владельцу сайта придется очень печально.Можно немного докрутить такую атаку — найти XSS и воткнуть туда html5 video с autoplay и display: none. Внешне ничего не меняется, но зато каждый пользователь тянет к себе большой трафик. Каждого пользователя, в отличие от ботнета не отфильтруешь.
Вообще финансовые атаки — наиболее опасные для бинзеса. Либо бизнес платит за огромный трафик, чтобы сайт работал (и тянул еще больший трафик), либо не платят и сервис ложится.
Защита от такого проста до глупости — возвращайте 403 со статики всем, кроме CDN-ки.
Атака на мобильное API Если сайт имеет еще и мобильное приложение — это сейчас модно, он значит современный сайт. Имея мобильное приложение, обычно сайт еще имеет и мобильное API. Установив себе приложение и собрав tcpdump-ом трафик (ну не сложно поднять wifi точка-точка на своем PC), можно найти api-mobile.example.com. Возможно из за желания экономить он тоже будет не за проксей-защитником, а прямо смотреть на сервер. Ну вот и спалился нужный нам IP.Защита, как Вы уже поняли простая — трафик API должен идти через проксю-защитника.
Заключение Все приведенные способы — простые. Они не требуют глубокого исследования сайта — просто потыкатся в него, не требуют даже получить на нем shell. Не все способы реальны на всех сайтах, но на большинстве сайтов, хотя бы один способ да будет работать.Защита от DDoS атак через сервисы-защитники — хороша, она оправдывает себя материально и технически. Осталась задача для админов сайта — да не спали свой IP!
