Есть сервисы, защищающие нас от 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 <mymail@yandex.ru>; Sun, 10 May 2015 15:58:47 +0300
Received: from srv1.example.com (srv1.example.com [xxx.xx.xx.xxx])
	by mxfront8j.mail.yandex.net (nwsmtp/Yandex) with ESMTPS id FpRuMcFeJH-wksakWfe;
	Sun, 10 May 2015 15:58:46 +0300
	(using TLSv1 with cipher AES128-SHA (128/128 bits))
	(Client certificate not present)
Received: from srv1.example.com (localhost [127.0.0.1])
	by srv1.example.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id t4ACvd6T026304
	for <mymail@yandex.ru>; Sun, 10 May 2015 15:57:39 +0300
Received: (from www-data@localhost)
	by srv1.example.com (8.14.3/8.14.3/Submit) id t4ACvdQX026302;
	Sun, 10 May 2015 15:57:39 +0300

Ну вот мы и нашли машину в подсети настоящего сервера в настоящем ДЦ, а не прокси. Вот она: srv1.example.com, xxx.xx.xx.xxx. С большой вероятностью эта машина находится в том же ДЦ и в той же подсети, что и www сервер. Обычно такие проекты не имеют больших сетей, не больше /24. Давайте просканим сетку и найдем все машины с открытым 80/tcp портом. Нуб отлично, есть список машин — зайдем на каждую браузером. На машине с адресом xxx.xx.xx.xxy с нами приключился редирект на www.example.com — это та самая машина, они отредиректила нас на проксю-защитника.

Теперь мы можем смело атаковать эту машину. Канал на машине вряд ли будет более 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!