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 <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!
    Поделиться публикацией

    Комментарии 10

      0
      Проделывали подобные махинации по поиску настоящего адреса при проведении нагрузочного тестирования.
      Добавлю, что настоящие диапазоны можно получить ещё из общедоступной whois-базы по имени компании. Вот, к примеру, ежедневно обновляемый снапшот базы RIPE: ftp.ripe.net/ripe/dbase.
      Также, помимо писем, адрес могут спалить, к примеру, сценарии загрузки аватары или другого файла с удалённого адреса (привет, SSRF).
        0
        … что настоящие диапазоны можно получить ещё из общедоступной whois-базы по имени компании

        Ну если адреса свои, то да. А если арендована стка /25 у хостера, то нет. Если у компании свои IP и AS — столько перспектив сразу открывается для DDoS
        +1
        Приятно, что облачные сервисы anti-DDoS ассоциируются с Qator )
        Автору спасибо за разъяснительную работу по ряду сопутствующих мер — все верно, несмотря на эффективность работы чьего-либо облака, отдаем себе отчет, что сайт все равно «cмотрит» в паблик со всеми вытекающими (если не делаем VPN от облака). Эффективная защита — всегда комплекс мер, желательно заблаговременных, и статистика четко показывает, что если придерживаться списка рекомендаций по построению инфраструктуры, выдаваемых при подключении, атака сайта становится просто экономически невыгодной для заказчика. Предвидя вопросы, рекомендации — не для публикации, к сожалению
          0
          Простое решение — иметь почтовую машину вне ДЦ и вне боевой подсети, которая будет работать почтовым релеем и отрезать весь «Received», что у неё есть.


          Даже при перечисленных мерах, IP утечет в DNS-запросе при разрешении имени почтового домена. И вообще IP не обязательно утекает через письмо, это может быть любая server side активность, например запрос аватарки по урлу.

          Чтобы подобного избежать, необходимо идентифицировать и перенаправить весь трафик, который создается сервером, не только письма.
            0
            Да это просто пример который есть сходу. Вообще, по уму — VPN/vlan с площадки в другое место, все гонять по серым адресам VPN-а, а наружу ходить из другого места. Большинство проблем с палевом решит.
            +1
            Недавно попросили посмотреть насколько качественно был закрыт внешним анти-ддос фильтром подобный проект.

            Каково же было мое удивление когда по адресу http:// example.com/info.php лежал просто тестовый скрипт с phpinfo();

            так что «уйти» скрытый адрес может и изза банальной невнимательности.
              0
              А что делать, если атакуют API?
              Как тут Qrator может помочь?
                0
                Qrator работает фактически как обратный прокси между вами и внешней сетью и отрезает все, что похоже на флуд, в том числе и request flood к API. Если у вас сервер от одного запроса ложится — тогда да, Qrator вряд ли поможет.
                  0
                  А есть ли механизмы для скрытия реального IP сервера в случаях, где сервер является инициатором соединения? Например, Instant Payment Notification?
                  Наверное, это должен быть какой-то прокси на вашей стороне.
                    0
                    Я не из Qrator'а, но да, обычно так и делается.

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое