Что не договаривают сервисы по защите от DDoS или почему защита не работает

Поводом для этой статьи послужил аудит безопасности в одном интернет-проекте. Заказчик попросил разобраться с их системой безопасности и проверить, насколько они подвержены тем или иным атакам. При этом, нас уверяли, что от DDoS-атак они защищены полностью и нет повода беспокоиться, так как они под защитой одного из лидеров рынка – Incapsula.

Тут-то нас и ждало большое удивление — заказчик был абсолютно не защищен.

Давайте разберемся что же произошло, но сначала немного теории.

Не буду описывать, что такое DDoS атака, отмечу лишь, что они делятся на 2 типа:

— DDoS Layer 3&4 по модели OSI. Одна из характеристик данной атаки – большое количество пакетов, которыми атакуется ресурс. На данный момент средняя мощность атаки по миру – 9,7 Gb/s и 19 Mpps.
— DDoS Layer 7 по модели OSI, то есть атака на уровень приложений. Как правило, атака не содержит большое количество пакетов (на порядки ниже чем при DDoS L3&4), скорее характеризуется точечным ударом по слабому месту атакуемого сайта.

Подключение к сервисам защищающим от DDoS атак происходит следующим образом:

— Для защищаемого ресурса в DNS прописывается адрес защищающего;
— Клиент указывает, на какой ip адрес пересылать очищенный трафик (как правило, на тот же адрес, который и был до подключения к сервису). Возможно поднятие туннеля.

Сейчас я специально не разбираю случай подключения с помощью BGP, там тоже не все так хорошо, но основная масса клиентов подключаются именно через изменения в записи DNS.

Заказчик доволен, расслаблен и полностью уверен в завтрашнем дне! Но, на самом деле, именно в тот момент, когда заказчик расслабился, он стал еще менее защищенным!

Давайте рассмотрим, почему или как можно обойти защиту.

Действительно, при попытке получить ip-адрес заказчика по имени сайта мы получаем ip-адрес сервиса по защите:

$ nslookup www.XXXXXXXX.ru
www.XXXXXXXX.ru canonical name = xxx.incapdns.net.
Name: xxx.incapdns.net
Address: 149.126.xxx.xxx

Но нам никто не мешает посмотреть DNS history по данному имени. Заходим на любой сайт, предоставляющий подобную информацию. И что мы видим:

IP Address Location IP Address Owner Last seen on this IP
149.126.xxx.xxx Binghamton — United States Incapsula Inc. 2015
149.126.yyy.yyy Binghamton — United States Incapsula Inc. 2015
zzz.zzz.zzz.zzz United States HOSTER LTD 2014


В результате мы видим, что его предыдущий ip-адрес — zzz.zzz.zzz.zzz; более того, теперь мы знаем, что он находится на площадке HOSTER LTD в США (дальше будет понятно, почему это тоже важно).

Остается только внимательно посмотреть на сервер, который имеет этот ip-адрес и мы уже точно знаем, что это искомый нами сервер заказчика.

Все! Атакуем этот сервер по ip-адресу и заказчик лежит столько – сколько нам надо. На ветер потрачено большое количество денег, но затраты не окупились, защита не работает.

Ниже я опишу рекомендации по правильному использованию подобных сервисов.

Как ни странно, но ни один из популярных — как на Западе, так и в России сервисов по защите от DDoS — не дает никаких рекомендации по этому вопросу своим клиентам.

Так что же необходимо делать?


Как только вы хоть раз засветили свой ip-адрес в сервисе DNS, вы больше никогда не сможете удалить эту информацию – она всегда будет доступна в DNS history. Более того, вы засветили свое местоположение (хостер, коммерческий ЦОД и т.п.).
Хотите полностью обезопасить себя – уходите с этого места. Как только вы остались, ваш сервис будут атакован, если вы представляете хоть какую-нибудь ценность для атакующих.

Рассмотрим, как будут вести себя атакующие и попробуем понять, в зависимости от размера вашего проекта, что нужно делать в этой ситуации.

1) У вас небольшой сайт и вы изначально разместили его у hosting провайдера. Правильные действия – настроить http-server таким образом, что бы он принимал запросы только от ip-адресов защищающего (так вы точно снимите возможность атаки DDoS Layer 7) и сменить ip-адрес (защита от DDoS Layer 3&4). В этом случае, нападающие не смогут найти ваш сайт напрямую, но это не значит, что вы в безопасности. Средний хостер в России имеет каналы 1-5 Gb/s и если вы действительно интересны нападающим, то они предпримут атаку (DDoS Layer 3&4) на каналы хостера и положат его и вас вместе с ним.

2) У вас есть выделенный Virtual Private Server и на нем располагается ваш проект. Правильные действия:
— настроить http server таким образом, чтобы он принимал запросы только от ip-адресов защищающего (так вы точно снимите возможность атаки DDoS Layer 7);
— настроить firewall так, что бы все лишние порты были закрыты и/или принимали соединения только от известных вам ip-адресов. Если вы этого не сделали с самого начала при подключении к сервису защиты от DDoS, то, возможно, атакующие уже изучили ваш сервер и узнали, какие порты открыты, а какие нет (атакующие сделали fingerprint вашей системы). Это значит, что они знают, какую машину им надо искать в сети провайдера;
— сменить ip-адрес (защита от DDoS Layer 3&4).

Если вы остались на существующем облачном провайдере, вы все равно не в безопасности. Самая уязвимая часть облачного провайдера – консоль управления (даже у Amazon она не очень хорошо защищена). На каналы небольшого облачного провайдера атакующие могут провести атаку DDoS Layer 3&4 и положить все облако.

3) У вас большой проект и много серверов, стоящих в каком либо коммерческом ЦОДе. Такой проект самый сложный по защите. Необходимо подойти комплексно к этой задаче, сменой ip и настройкой firewall ничего не решить (но это не значит, что этого не надо делать). Как минимум, вам необходимо сменить сетку, которую вам выдал провайдер. Именно сменить, а не добавить новую, иначе, вас даже не надо искать – атакующие просто положат ваши каналы, атакуя старую сетку. Как правило, в таких проектах есть сервисы, которые нельзя или невозможно поставить под защиту от DDoS – подумайте как правильно разнести эти сервисы по разным сетям или даже площадкам, иначе вас найдут именно по ним (самый простой пример – MX записи почтовой службы).

Вывод


Сервисы по защите от DDoS не являются панацеей, но они могут сильно помочь, если вы сделаете еще ряд шагов в нужном направлении.

Удачи вам и вашим проектам.
Поделиться публикацией
Ой, у вас баннер убежал!

Ну. И что?
Реклама
Комментарии 41
    +2
    Вообще-то все Anti-DDOS компании открытым текстом у себя пишут «рекомендуем забанить всех в firewall нафиг, кроме нас».
      +7
      Настройка firewall без смены ip адреса не спасает, необходим комплекс мер.
      Firewall не решает проблем с DDoS L3&4
        +1
        Без смены ip вставать под защиту вовсе не имеет смысла, как бы — это само собой понятно.
        Но anyway, в плохом случае можно хостера попросить пофильтровать — ему этот трафик внутри сети тоже не нужен.
          +5
          Владислав, мы с тобой это понимаем, но очень часто заказчики об этом просто не думают!
          +3
          Когда мы вставали под защиту одного из анти-ddos сервисов, нам так сразу и говорили: выделите НОВЫЙ IP-адрес, который ранее не светили в проекте, дайте к нему доступ только с этого списка IP и мы будем проксировать запросы на него. Так что или один из лидеров какой-то странный, или заказчик получал подобные инструкции, но пренебрег ими.
        +3
        А про подводные камни при защите с использованием BGP будет пост?
          0
          Постараюсь написать, но не обещаю, что быстро
          0
          .
            0
            Надо также помнить про отпечаток сервера, начиная от списка открытых или закрытых портов и версий сервисов и заканчивая такой экзотикой, как публичный ключ на 22 порту (если вдруг он катается вместе со всем остальным). Также иногда встречается вариант, когда атака бьет по всем адресам в истории по очереди, стараясь найти нужный, поэтому шаги с переездом на предыдущие адреса лучше не предпринимать.
              +28
              Во-первых вы забыли про третий тип атаки, DNS Amplifying. Этот тип я бы назвал самым простым для реализации.
              Также есть еще SMURF и ACK атаки, которые тоже явно можно вынести в отдельные.

              Как правило любая защита начинается со смены IP адреса сервера. Опять же не забываем сменить IP почтового сервера, иначе через заголовки писем злоумышленники могут узнать ваш новый IP. Если IP не сменить, проксирование, как самая распространенная защита, может просто не сработать.

              А вот о чем действительно не договаривают сервисы по защите от Ддос, это о том, что при выборе не совсем чистого на руку партнера, можно попасть к стекольщикам (это я имею ввиду тех, кто стекла сначала бъет, а потом предлагает услуги по их замене). Выглядит это так. Сайт под нагрузкой спасается у антиддосера. Проходит оплаченный месяц, владелец сайта понимает, что стоимость хоста для него порядком выросла. Либо он уходит обратно и тогда через какое-то время опять получает ддос атаку и возвращается к антиддосеру уже надолго. Либо тупо продолжает платить дальше. А у антиддосера в руках получается новый клиент и огромный шланг с кучей паразитного траффика, который можно всегда на кого-то направить.

              Такой вот бизнес. Стоимость расследования атаки без гарантий порядка 100k рублей. Так, удовлетворить любопытство.

              Недавно ддосили одного из клиентов, вот и пришлось немного разобраться в вопросе. Если кому интересен опыт и порядок действий при первом ддосе — могу накатать статью. Ну вы знаете, как мне дать это понять, да?

                +2
                Целью статьи было привлечь внимание к проблеме построения защиты от DDoS с помощью внешних сервисов, поэтому я упростил описание DDoS атак, что бы не уходить сильно глубоко в детали, иначе можно было запутать читателей.

                Понятно, что статья рассчитана на не специалистов в области ИБ, для них это прописные истины, но для многих, это повод задумать о безопасности своих ресурсов.

                Если вы напишете статью про действия при первом DDoS, то это будет многим полезно, люди часто ищут здесь ответы на свои вопросы.
                  0
                  Мда, вроде народу интересно, но после открытия гиктаймс, вся моя возможность писать статьи укатила туда. Кто-то один влепил в профиль невозможность мне писать статьи, хотя 9 человек хотели бы эту статью видеть. Так что простите, до лучших времен.
                    0
                    recovery mode? Или уже тратили?
                      0
                      А, спасибо за идею, еще не тратил. Воспользуюсь!
                  +1
                  Вы лучше расскажите как эти сервисы определяют какой трафик досовский, а какой — пользовательский.
                    0
                    А зачем?
                    Во первых, у каждого сервиса свои наработки, во вторых, это будут только общие подходы к решению задачи.
                      0
                      По идее должны стоять самообучаемые железки которые анализируют трафик и реагируют на аномальные изменения. К примеру на ваш сайт постоянно ходят пользователи из РФ с примерно одинаковой сетевой активностью, а потом внезапно начался огромный поток запросов из Китая. Железка это определит и среагирует нужным образом.
                      0
                      А можно такой вопрос: допустим есть PHP-сайт на VPS, и он сидит за стенами CloudFlare. Есть какая-то возможность узнать настоящий IP-адрес VPS'ки?
                        +2
                        Помимо того, что уже описано в статье можно вспомнить, что PHP — несколько более динамический язык, чем HTML. :) Если на сайте есть какая-нибудь фигня вроде «загрузить картинку из внешнего источника» и при этом картинку PHP грузит себе с того же IP, с которого происходит обмен с CloudFlare — то никто не мешает попытаться сделать загрузку с какого-то подконтрольного сервера. Доступный кому попало phpinfo — тоже не самая хорошая идея, там выводятся в том числе и всякие переменные окружения и тот же Apache передает в php переменную окружения SERVER_ADDR.
                          +1
                          Из практики: можно посмотреть историю домена, например, на whoisrequest.org/history/, владельцы VPS-ок часто не меняют IP после перехода на CloudFlare. Кроме того, достаточно часто криво настроенные почтовые сервера выплёвывают реальный адрес машины в заголовках письма (например, на подтверждении регистрации). Иногда вообще старый IP остаётся в MX по невнимательности владельца.
                            0
                            Есть. Элементарно. Но тут не напишу.
                              0
                              Вот вам мой грязный рецептик: если у вас на сайте есть регистрация с подтверждением в почту, я посмотрю заголовки письма с вашего сервера и в одном из первых Received: найду адрес вашего сервера
                                0
                                Exim умеет в
                                headers_remove = Received
                                


                                Но почту придется отправлять через какой-то внешний smtp.
                              +1
                              Кстати, отличным вариантом будет хостить атакуемый сайт на сервере имеющем только ipv6-адрес и на фаерволе закрыть все входящие подключения на портах от всех адресов кроме пула адресов проксирующего сервера.
                              Таким образом даже если вдруг вы засветите ipv6-адрес сервера то в ближайшее время атакующие не смогут провести атаку 3 и 4 уровня т.к. просто не найдут такое количество ботов поддерживающих ipv6. Да и менять такие адреса проще и дешевле чем ipv4.
                                –2
                                да бред, есть же teredo
                                  –3
                                  это может у вас бред.
                                  по вашему многотысячная армия ботов на потрояненных системах вдруг разом должна начать поддерживать ipv6? А teredo-серверы вдруг разом смогут переварить еще пару десятков гигабит для вашей атаки и администратор сервера под ддосом не сможет забанить этот teredo-сервер?
                                    +1
                                    Если бот может отправить udp, он может отправить и тередо. вы хоть в курсе, как тередо работает-то? как вы собираетесь банить тередо-релей или тем более тередо-сервер?
                                      0
                                      В любом случае атака по ipv6 будет сильно отличаться от атаки по ipv4
                                      В первом случае боты ломанутся через ограниченный список доступных teredo-серверов, а во втором будут ломиться на атакуемый сервер напрямую.
                                +2
                                Как минимум, вам необходимо сменить сетку, которую вам выдал провайдер.

                                Современная ситуация с адресным пространством IPv4 заставляет меня очень скептически отнестись к данному совету.
                                  +2
                                  > Как ни странно, но ни один из популярных — как на Западе,
                                  > так и в России сервисов по защите от DDoS — не дает никаких
                                  > рекомендации по этому вопросу своим клиентам.

                                  Обижаете, мы первым делом говорим клиентам об этом.
                                    0
                                    Артем, мы говорили с парой ваших клиентов — один только настроил firewall, а этого не достаточно.

                                    Более того, часть хостеров, если на ip их клиента идет DDoS просто отключают клиентов.

                                      0
                                      Алексей, ну врать просто нехорошо ;)

                                      Эти рекомендации приходят заказчику первым письмом в момент регистрации. Это я вас как краевед заверяю.

                                      В искусстве считать собеседника идиотом — самое главное не перестараться, иначе эффект может получиться прямо обратный ожидаемому.
                                        –2
                                        Александр, ваши клиенты (по крайней мере с которыми мы разговаривали) не знают о рекомендациях, так же как и клиенты Incapsula.
                                        Если вы считаете рекомендацией — «настроить Firewall», то это, мягко говоря, не совсем корректное отношение к ваших клиентам!

                                        А еще проще — опубликуйте шаблон вашего письма клиентам здесь!
                                          0
                                          Пожалуйста:

                                          Здравствуйте,

                                          Домену example.com был выделен IP-адрес [SKIPPED] в сети QRATOR. Его следует указать
                                          в настройках DNS-зоны сайта следующим образом:

                                          @ IN A [SKIPPED]
                                          WWW IN A [SKIPPED]

                                          Описание проверки изменений в DNS-зоне Вашего сайта Вы можете найти
                                          разделе информационных материалов личного кабинета.

                                          После перестроения DNS запросы на ваш сайт должны приходить только от
                                          IP-адресов системы фильтрации трафика QRATOR:
                                          178.248.236.128/28
                                          178.248.237.128/28
                                          178.248.239.128/28

                                          Это письмо сформировано автоматически службой уведомлений QRATOR.
                                          Отвечать на него не нужно.

                                          Если у вас возникли вопросы, свяжитесь с сотрудником технической поддержки
                                          по телефону 8-800-3333-522 или по электронной почте mail@qrator.net.


                                          Какие-то нюансы могут отличаться от случая к случаю, но в целом — так.
                                            0
                                            Здравствуйте,

                                            Домену example.com был выделен IP-адрес [SKIPPED] в сети QRATOR. Его следует указать
                                            в настройках DNS-зоны сайта следующим образом:

                                            @ IN A [SKIPPED]
                                            WWW IN A [SKIPPED]

                                            Описание проверки изменений в DNS-зоне Вашего сайта Вы можете найти
                                            разделе информационных материалов личного кабинета.

                                            После перестроения DNS запросы на ваш сайт должны приходить только от
                                            IP-адресов системы фильтрации трафика QRATOR:
                                            178.248.236.128/28
                                            178.248.237.128/28
                                            178.248.239.128/28

                                            Это письмо сформировано автоматически службой уведомлений QRATOR.
                                            Отвечать на него не нужно.

                                            Если у вас возникли вопросы, свяжитесь с сотрудником технической поддержки
                                            по телефону 8-800-3333-522 или по электронной почте mail@qrator.net.


                                            Спасибо!
                                              +1
                                              Можно обсуждать, насколько явно здесь прописана рекомендация, однако могу вас заверить: наша техподдержка работает с каждым клиентом до тех пор, пока атака не будет отражена. Не всегда при этом на выходе получается идеальный сетап, но довести его потом до ума обычно несложно, нужно лишь иметь желание и приложить усилия.

                                              В то же время смена IP-адреса сервера (или оператора связи, или датацентра) во время атаки чревата целым рядом проблем — ведь в это время системный администратор ресурса обычно находится в состоянии сильного стресса, часто после бессонной ночи, и велик риск человеческой ошибки. Поэтому мы рекомендуем сменить IP-адрес, но не настаиваем на этом. На IP-адрес часто слишком многое завязано, лучше производить такие операции, отдохнув и выспавшись.
                                        0
                                        Вопрос был: дают ли сервисы по защите от DDoS рекомендации сменить IP-адрес? Мы — даём. Но силой заставить своих клиентов сделать это мы не можем :-) В конце концов, каждый сам оценивает свои риски и трудозатраты.

                                        На самом деле, клиентам Qrator необязательно менять ДЦ в случае атаки «напрямую». Есть и другой вариант: MPLS VPN до оборудования клиента. Это небесплатно, но точно дешевле и быстрее, чем в условиях цейтнота везти 5 стоек через пол-Москвы или подключаться к новому оператору связи.

                                        Про «часть хостеров» — не совсем так. Любой хостер отключит своего клиента, если тот будет испытывать масштабную L3-атаку и откажется оплачивать услуги по защите. У любого ДЦ есть свой болевой порог, у кого-то он физический (канальная ёмкость ограничена), у кого-то он финансовый (нет стимула оплачивать трафик атаки и работать себе в убыток).
                                        +2
                                        Более того, я не знаю анти-DDOS сервисов, которые не дают таких рекомендаций, а работал с десятком точно.
                                        +2
                                        А вот с типизацией атак Алексей, на мой взгляд, излишне упрощает. Я-бы выделил 4 больших класса атак:

                                        1. Bandwidth — здесь живут флуды большими пакетами, атаки типа amplification и reflection.

                                        2. Infrastructure — атаки направленные на сетевую инфраструктуру — мозги которые обрабатывают пакеты и принимают решения куда их дальше отправить. Сюда входят высокоскоростные флуды мелкими пакетами, атаки на ре-фрагментацию, атаки на открытые внешнему миру control plane и всевозможные манипуляции с маршрутизацией (подмена, cache fanout)

                                        3. TCP/IP stack — атаки на стек endpoint оборудования. Классический synflood, ackflood, игры с таймаутами и некорректными закрытиями соединений и, как ни странно, slowlorris.

                                        4. L7 (Application layer) — все атаки в которых используются семантически законченные конструкции протокола приложения. Это самое сладкое — поскольку именно на этом уровне можно получить плечо атаки (соотношение ресурсов затраченных атакующим к ресурсам потребленным жертвой) может достигать астрономических величин.
                                          0
                                          Коллеги из Qrator, вы меня убеждаете в том, что вы полностью информируете заказчика, тогда, пожалуйста, про комментируйте страницу со своего сайта:

                                          Как подключиться

                                          Хотите подключиться для тестирования нашей услуги, или защитить сайт от DDoS на постоянной основе — это не займет много времени и не потребует специальных навыков:

                                          1. Нажимаете на кнопку «Встать под защиту» или «Тест системы» — 1 секунда;

                                          2. Регистрируетесь в Личном Кабинете, получаете по электронной почте Имя пользователя и Пароль к Личному Кабинету — 1 минута;

                                          3. Заполняете контактную информацию, данные о компании и о защищаемом сайте в Личном Кабинете — 3 минуты;

                                          4. После модерации данных вам выделяется IP-адрес сети Qrator. Также по e-mail будет выслана инструкция по смене DNS-записи сайта — 10 минут;

                                          6. Меняете в соответствии с инструкцией А-запись DNS своего сайта — 5 минут;

                                          Итого, работа по подключению — менее 20 минут.

                                          7. Автоматическое обновление данных DNS-серверов в сети Интернет (Qrator не влияет на процесс) — в среднем 1-2 часа;

                                          8. Ваш сайт под защитой Qrator!


                                          Оригинал тут — qrator.net/ru/ddos/how-to-get-protected
                                            0
                                            (я не из Qrator)

                                            Простите, но, по-моему, вы вцепились в один нюанс защиты от DDoS. Например, flx упомянул атаки типа Infrastructure. Почему вы не пишите, что абсолютно все защитники от DDoS не доводят до вас, что вам необходимо проверить, не открыт ли, например, SNMP на бордерах ваших аплинков? Допустим, вы закрыли всё с помощью firewall, ваши аплинки блэкхолят весь неправильный трафик, но в один момент на их бордерах возрастает CPU до 100%, они теряют пиры и ваш ресурс лежит от DDoS. А SNMP это только капля в море возможных нюансов.

                                            В сети можно найти фото двух сторон банковских карт. На сайте вашего любимого банка в разделе «как легко и быстро получить карту с доставкой» написано про опасности размещения фото карты в социальных сетях?

                                            В сети можно найти много открытых сетевых жестких дисков на public IP. Производители дисков не договаривают?

                                            Список «недоговариваний» можно продолжать очень долго и не только про Интернет.

                                            В защиту именно Qrator хочу сказать, что они (по-моему, единственные в стране) бесплатно и часто делятся своей статистикой по DDoS, что помогает правильно готовиться к атакам.

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

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