Комментарии 41
Вообще-то все Anti-DDOS компании открытым текстом у себя пишут «рекомендуем забанить всех в firewall нафиг, кроме нас».
Настройка firewall без смены ip адреса не спасает, необходим комплекс мер.
Firewall не решает проблем с DDoS L3&4
Firewall не решает проблем с DDoS L3&4
Без смены ip вставать под защиту вовсе не имеет смысла, как бы — это само собой понятно.
Но anyway, в плохом случае можно хостера попросить пофильтровать — ему этот трафик внутри сети тоже не нужен.
Но anyway, в плохом случае можно хостера попросить пофильтровать — ему этот трафик внутри сети тоже не нужен.
Когда мы вставали под защиту одного из анти-ddos сервисов, нам так сразу и говорили: выделите НОВЫЙ IP-адрес, который ранее не светили в проекте, дайте к нему доступ только с этого списка IP и мы будем проксировать запросы на него. Так что или один из лидеров какой-то странный, или заказчик получал подобные инструкции, но пренебрег ими.
А про подводные камни при защите с использованием BGP будет пост?
.
Надо также помнить про отпечаток сервера, начиная от списка открытых или закрытых портов и версий сервисов и заканчивая такой экзотикой, как публичный ключ на 22 порту (если вдруг он катается вместе со всем остальным). Также иногда встречается вариант, когда атака бьет по всем адресам в истории по очереди, стараясь найти нужный, поэтому шаги с переездом на предыдущие адреса лучше не предпринимать.
Во-первых вы забыли про третий тип атаки, DNS Amplifying. Этот тип я бы назвал самым простым для реализации.
Также есть еще SMURF и ACK атаки, которые тоже явно можно вынести в отдельные.
Как правило любая защита начинается со смены IP адреса сервера. Опять же не забываем сменить IP почтового сервера, иначе через заголовки писем злоумышленники могут узнать ваш новый IP. Если IP не сменить, проксирование, как самая распространенная защита, может просто не сработать.
А вот о чем действительно не договаривают сервисы по защите от Ддос, это о том, что при выборе не совсем чистого на руку партнера, можно попасть к стекольщикам (это я имею ввиду тех, кто стекла сначала бъет, а потом предлагает услуги по их замене). Выглядит это так. Сайт под нагрузкой спасается у антиддосера. Проходит оплаченный месяц, владелец сайта понимает, что стоимость хоста для него порядком выросла. Либо он уходит обратно и тогда через какое-то время опять получает ддос атаку и возвращается к антиддосеру уже надолго. Либо тупо продолжает платить дальше. А у антиддосера в руках получается новый клиент и огромный шланг с кучей паразитного траффика, который можно всегда на кого-то направить.
Такой вот бизнес. Стоимость расследования атаки без гарантий порядка 100k рублей. Так, удовлетворить любопытство.
Недавно ддосили одного из клиентов, вот и пришлось немного разобраться в вопросе. Если кому интересен опыт и порядок действий при первом ддосе — могу накатать статью. Ну вы знаете, как мне дать это понять, да?
Также есть еще SMURF и ACK атаки, которые тоже явно можно вынести в отдельные.
Как правило любая защита начинается со смены IP адреса сервера. Опять же не забываем сменить IP почтового сервера, иначе через заголовки писем злоумышленники могут узнать ваш новый IP. Если IP не сменить, проксирование, как самая распространенная защита, может просто не сработать.
А вот о чем действительно не договаривают сервисы по защите от Ддос, это о том, что при выборе не совсем чистого на руку партнера, можно попасть к стекольщикам (это я имею ввиду тех, кто стекла сначала бъет, а потом предлагает услуги по их замене). Выглядит это так. Сайт под нагрузкой спасается у антиддосера. Проходит оплаченный месяц, владелец сайта понимает, что стоимость хоста для него порядком выросла. Либо он уходит обратно и тогда через какое-то время опять получает ддос атаку и возвращается к антиддосеру уже надолго. Либо тупо продолжает платить дальше. А у антиддосера в руках получается новый клиент и огромный шланг с кучей паразитного траффика, который можно всегда на кого-то направить.
Такой вот бизнес. Стоимость расследования атаки без гарантий порядка 100k рублей. Так, удовлетворить любопытство.
Недавно ддосили одного из клиентов, вот и пришлось немного разобраться в вопросе. Если кому интересен опыт и порядок действий при первом ддосе — могу накатать статью. Ну вы знаете, как мне дать это понять, да?
Целью статьи было привлечь внимание к проблеме построения защиты от DDoS с помощью внешних сервисов, поэтому я упростил описание DDoS атак, что бы не уходить сильно глубоко в детали, иначе можно было запутать читателей.
Понятно, что статья рассчитана на не специалистов в области ИБ, для них это прописные истины, но для многих, это повод задумать о безопасности своих ресурсов.
Если вы напишете статью про действия при первом DDoS, то это будет многим полезно, люди часто ищут здесь ответы на свои вопросы.
Понятно, что статья рассчитана на не специалистов в области ИБ, для них это прописные истины, но для многих, это повод задумать о безопасности своих ресурсов.
Если вы напишете статью про действия при первом DDoS, то это будет многим полезно, люди часто ищут здесь ответы на свои вопросы.
Мда, вроде народу интересно, но после открытия гиктаймс, вся моя возможность писать статьи укатила туда. Кто-то один влепил в профиль невозможность мне писать статьи, хотя 9 человек хотели бы эту статью видеть. Так что простите, до лучших времен.
НЛО прилетело и опубликовало эту надпись здесь
А зачем?
Во первых, у каждого сервиса свои наработки, во вторых, это будут только общие подходы к решению задачи.
Во первых, у каждого сервиса свои наработки, во вторых, это будут только общие подходы к решению задачи.
По идее должны стоять самообучаемые железки которые анализируют трафик и реагируют на аномальные изменения. К примеру на ваш сайт постоянно ходят пользователи из РФ с примерно одинаковой сетевой активностью, а потом внезапно начался огромный поток запросов из Китая. Железка это определит и среагирует нужным образом.
А можно такой вопрос: допустим есть PHP-сайт на VPS, и он сидит за стенами CloudFlare. Есть какая-то возможность узнать настоящий IP-адрес VPS'ки?
Помимо того, что уже описано в статье можно вспомнить, что PHP — несколько более динамический язык, чем HTML. :) Если на сайте есть какая-нибудь фигня вроде «загрузить картинку из внешнего источника» и при этом картинку PHP грузит себе с того же IP, с которого происходит обмен с CloudFlare — то никто не мешает попытаться сделать загрузку с какого-то подконтрольного сервера. Доступный кому попало phpinfo — тоже не самая хорошая идея, там выводятся в том числе и всякие переменные окружения и тот же Apache передает в php переменную окружения SERVER_ADDR.
Из практики: можно посмотреть историю домена, например, на whoisrequest.org/history/, владельцы VPS-ок часто не меняют IP после перехода на CloudFlare. Кроме того, достаточно часто криво настроенные почтовые сервера выплёвывают реальный адрес машины в заголовках письма (например, на подтверждении регистрации). Иногда вообще старый IP остаётся в MX по невнимательности владельца.
Есть. Элементарно. Но тут не напишу.
Вот вам мой грязный рецептик: если у вас на сайте есть регистрация с подтверждением в почту, я посмотрю заголовки письма с вашего сервера и в одном из первых Received: найду адрес вашего сервера
Кстати, отличным вариантом будет хостить атакуемый сайт на сервере имеющем только ipv6-адрес и на фаерволе закрыть все входящие подключения на портах от всех адресов кроме пула адресов проксирующего сервера.
Таким образом даже если вдруг вы засветите ipv6-адрес сервера то в ближайшее время атакующие не смогут провести атаку 3 и 4 уровня т.к. просто не найдут такое количество ботов поддерживающих ipv6. Да и менять такие адреса проще и дешевле чем ipv4.
Таким образом даже если вдруг вы засветите ipv6-адрес сервера то в ближайшее время атакующие не смогут провести атаку 3 и 4 уровня т.к. просто не найдут такое количество ботов поддерживающих ipv6. Да и менять такие адреса проще и дешевле чем ipv4.
да бред, есть же teredo
это может у вас бред.
по вашему многотысячная армия ботов на потрояненных системах вдруг разом должна начать поддерживать ipv6? А teredo-серверы вдруг разом смогут переварить еще пару десятков гигабит для вашей атаки и администратор сервера под ддосом не сможет забанить этот teredo-сервер?
по вашему многотысячная армия ботов на потрояненных системах вдруг разом должна начать поддерживать ipv6? А teredo-серверы вдруг разом смогут переварить еще пару десятков гигабит для вашей атаки и администратор сервера под ддосом не сможет забанить этот teredo-сервер?
Как минимум, вам необходимо сменить сетку, которую вам выдал провайдер.
Современная ситуация с адресным пространством IPv4 заставляет меня очень скептически отнестись к данному совету.
> Как ни странно, но ни один из популярных — как на Западе,
> так и в России сервисов по защите от DDoS — не дает никаких
> рекомендации по этому вопросу своим клиентам.
Обижаете, мы первым делом говорим клиентам об этом.
> так и в России сервисов по защите от DDoS — не дает никаких
> рекомендации по этому вопросу своим клиентам.
Обижаете, мы первым делом говорим клиентам об этом.
Артем, мы говорили с парой ваших клиентов — один только настроил firewall, а этого не достаточно.
Более того, часть хостеров, если на ip их клиента идет DDoS просто отключают клиентов.
Более того, часть хостеров, если на ip их клиента идет DDoS просто отключают клиентов.
Алексей, ну врать просто нехорошо ;)
Эти рекомендации приходят заказчику первым письмом в момент регистрации. Это я вас как краевед заверяю.
В искусстве считать собеседника идиотом — самое главное не перестараться, иначе эффект может получиться прямо обратный ожидаемому.
Эти рекомендации приходят заказчику первым письмом в момент регистрации. Это я вас как краевед заверяю.
В искусстве считать собеседника идиотом — самое главное не перестараться, иначе эффект может получиться прямо обратный ожидаемому.
Александр, ваши клиенты (по крайней мере с которыми мы разговаривали) не знают о рекомендациях, так же как и клиенты Incapsula.
Если вы считаете рекомендацией — «настроить Firewall», то это, мягко говоря, не совсем корректное отношение к ваших клиентам!
А еще проще — опубликуйте шаблон вашего письма клиентам здесь!
Если вы считаете рекомендацией — «настроить Firewall», то это, мягко говоря, не совсем корректное отношение к ваших клиентам!
А еще проще — опубликуйте шаблон вашего письма клиентам здесь!
Пожалуйста:
Какие-то нюансы могут отличаться от случая к случаю, но в целом — так.
Здравствуйте,
Домену 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.
Какие-то нюансы могут отличаться от случая к случаю, но в целом — так.
Здравствуйте,
Домену 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.
Спасибо!
Можно обсуждать, насколько явно здесь прописана рекомендация, однако могу вас заверить: наша техподдержка работает с каждым клиентом до тех пор, пока атака не будет отражена. Не всегда при этом на выходе получается идеальный сетап, но довести его потом до ума обычно несложно, нужно лишь иметь желание и приложить усилия.
В то же время смена IP-адреса сервера (или оператора связи, или датацентра) во время атаки чревата целым рядом проблем — ведь в это время системный администратор ресурса обычно находится в состоянии сильного стресса, часто после бессонной ночи, и велик риск человеческой ошибки. Поэтому мы рекомендуем сменить IP-адрес, но не настаиваем на этом. На IP-адрес часто слишком многое завязано, лучше производить такие операции, отдохнув и выспавшись.
В то же время смена IP-адреса сервера (или оператора связи, или датацентра) во время атаки чревата целым рядом проблем — ведь в это время системный администратор ресурса обычно находится в состоянии сильного стресса, часто после бессонной ночи, и велик риск человеческой ошибки. Поэтому мы рекомендуем сменить IP-адрес, но не настаиваем на этом. На IP-адрес часто слишком многое завязано, лучше производить такие операции, отдохнув и выспавшись.
Вопрос был: дают ли сервисы по защите от DDoS рекомендации сменить IP-адрес? Мы — даём. Но силой заставить своих клиентов сделать это мы не можем :-) В конце концов, каждый сам оценивает свои риски и трудозатраты.
На самом деле, клиентам Qrator необязательно менять ДЦ в случае атаки «напрямую». Есть и другой вариант: MPLS VPN до оборудования клиента. Это небесплатно, но точно дешевле и быстрее, чем в условиях цейтнота везти 5 стоек через пол-Москвы или подключаться к новому оператору связи.
Про «часть хостеров» — не совсем так. Любой хостер отключит своего клиента, если тот будет испытывать масштабную L3-атаку и откажется оплачивать услуги по защите. У любого ДЦ есть свой болевой порог, у кого-то он физический (канальная ёмкость ограничена), у кого-то он финансовый (нет стимула оплачивать трафик атаки и работать себе в убыток).
На самом деле, клиентам Qrator необязательно менять ДЦ в случае атаки «напрямую». Есть и другой вариант: MPLS VPN до оборудования клиента. Это небесплатно, но точно дешевле и быстрее, чем в условиях цейтнота везти 5 стоек через пол-Москвы или подключаться к новому оператору связи.
Про «часть хостеров» — не совсем так. Любой хостер отключит своего клиента, если тот будет испытывать масштабную L3-атаку и откажется оплачивать услуги по защите. У любого ДЦ есть свой болевой порог, у кого-то он физический (канальная ёмкость ограничена), у кого-то он финансовый (нет стимула оплачивать трафик атаки и работать себе в убыток).
Более того, я не знаю анти-DDOS сервисов, которые не дают таких рекомендаций, а работал с десятком точно.
А вот с типизацией атак Алексей, на мой взгляд, излишне упрощает. Я-бы выделил 4 больших класса атак:
1. Bandwidth — здесь живут флуды большими пакетами, атаки типа amplification и reflection.
2. Infrastructure — атаки направленные на сетевую инфраструктуру — мозги которые обрабатывают пакеты и принимают решения куда их дальше отправить. Сюда входят высокоскоростные флуды мелкими пакетами, атаки на ре-фрагментацию, атаки на открытые внешнему миру control plane и всевозможные манипуляции с маршрутизацией (подмена, cache fanout)
3. TCP/IP stack — атаки на стек endpoint оборудования. Классический synflood, ackflood, игры с таймаутами и некорректными закрытиями соединений и, как ни странно, slowlorris.
4. L7 (Application layer) — все атаки в которых используются семантически законченные конструкции протокола приложения. Это самое сладкое — поскольку именно на этом уровне можно получить плечо атаки (соотношение ресурсов затраченных атакующим к ресурсам потребленным жертвой) может достигать астрономических величин.
1. Bandwidth — здесь живут флуды большими пакетами, атаки типа amplification и reflection.
2. Infrastructure — атаки направленные на сетевую инфраструктуру — мозги которые обрабатывают пакеты и принимают решения куда их дальше отправить. Сюда входят высокоскоростные флуды мелкими пакетами, атаки на ре-фрагментацию, атаки на открытые внешнему миру control plane и всевозможные манипуляции с маршрутизацией (подмена, cache fanout)
3. TCP/IP stack — атаки на стек endpoint оборудования. Классический synflood, ackflood, игры с таймаутами и некорректными закрытиями соединений и, как ни странно, slowlorris.
4. L7 (Application layer) — все атаки в которых используются семантически законченные конструкции протокола приложения. Это самое сладкое — поскольку именно на этом уровне можно получить плечо атаки (соотношение ресурсов затраченных атакующим к ресурсам потребленным жертвой) может достигать астрономических величин.
Коллеги из Qrator, вы меня убеждаете в том, что вы полностью информируете заказчика, тогда, пожалуйста, про комментируйте страницу со своего сайта:
Оригинал тут — qrator.net/ru/ddos/how-to-get-protected
Как подключиться
Хотите подключиться для тестирования нашей услуги, или защитить сайт от 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
(я не из Qrator)
Простите, но, по-моему, вы вцепились в один нюанс защиты от DDoS. Например, flx упомянул атаки типа Infrastructure. Почему вы не пишите, что абсолютно все защитники от DDoS не доводят до вас, что вам необходимо проверить, не открыт ли, например, SNMP на бордерах ваших аплинков? Допустим, вы закрыли всё с помощью firewall, ваши аплинки блэкхолят весь неправильный трафик, но в один момент на их бордерах возрастает CPU до 100%, они теряют пиры и ваш ресурс лежит от DDoS. А SNMP это только капля в море возможных нюансов.
В сети можно найти фото двух сторон банковских карт. На сайте вашего любимого банка в разделе «как легко и быстро получить карту с доставкой» написано про опасности размещения фото карты в социальных сетях?
В сети можно найти много открытых сетевых жестких дисков на public IP. Производители дисков не договаривают?
Список «недоговариваний» можно продолжать очень долго и не только про Интернет.
В защиту именно Qrator хочу сказать, что они (по-моему, единственные в стране) бесплатно и часто делятся своей статистикой по DDoS, что помогает правильно готовиться к атакам.
Простите, но, по-моему, вы вцепились в один нюанс защиты от DDoS. Например, flx упомянул атаки типа Infrastructure. Почему вы не пишите, что абсолютно все защитники от DDoS не доводят до вас, что вам необходимо проверить, не открыт ли, например, SNMP на бордерах ваших аплинков? Допустим, вы закрыли всё с помощью firewall, ваши аплинки блэкхолят весь неправильный трафик, но в один момент на их бордерах возрастает CPU до 100%, они теряют пиры и ваш ресурс лежит от DDoS. А SNMP это только капля в море возможных нюансов.
В сети можно найти фото двух сторон банковских карт. На сайте вашего любимого банка в разделе «как легко и быстро получить карту с доставкой» написано про опасности размещения фото карты в социальных сетях?
В сети можно найти много открытых сетевых жестких дисков на public IP. Производители дисков не договаривают?
Список «недоговариваний» можно продолжать очень долго и не только про Интернет.
В защиту именно Qrator хочу сказать, что они (по-моему, единственные в стране) бесплатно и часто делятся своей статистикой по DDoS, что помогает правильно готовиться к атакам.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Что не договаривают сервисы по защите от DDoS или почему защита не работает