Comments 12
Также оператор защищает весь канал, а не отдельно взятые приложения и сервисы, что позволяет получить полноценную защиту для всей IT-инфраструктуры.Это не совсем так. Вернее, с точностью до наоборот :-) Оператор защищает только канал, от низкоуровневых атак, а для полноценной защиты необходимо ещё и анализировать трафик вплоть до прикладного уровня для отдельных сервисов, чего оператор (почти) никогда не делает.
В частности, вы сами предлагаете детектировать атаки с помощью средств сетевой телеметрии. Например, атаку прикладного уровня на HTTPS-сервис таким образом не детектировать, а это один из самых токсичных методов атаки: если забитый канал начнёт работать тут же, как очистится, то после атаки в правильное место Web-приложения может потребоваться даже перезагрузка сервера :-( Так что даунтайм будет огромный.
При выборе решения по защите, особенно новичку (для которых заявлена ваша статья), этот аспект и сферу применения решений операторского уровня в целом понимать нужно обязательно.
В статье написано, что есть две фазы: детектирование и фильтрация. В ходе фильтрации используется в том числе прикладной анализ. В ходе же детектирования, прикладной уровень в _простом случае_ не анализируется, но это не мешает детектировать отклонения от нормы по netflow для high rate application атак, причем достаточно быстро — десятки секунд. Для slow rate можно делать интересные вещи, о которых некоторые могли не знать, например, анализировать не скорость bps/pps, а число new/concurent session, которое опять же будет отклоняться от нормы. Вы безусловно правы, что netflow не лучшее для этого средство, но для тех случаев, где важно иметь еще более высокую скорость реакции и точность детектирования — используются схемы:
1. с WAF, который выступает в качестве Reverse-proxy, а также добавлят механизмы защиты отличные от DDoS
2. Установка на площадке клиента дополнительного устройства, которое стоит в inline и проводит анализ на прикладном уровне в real-time.
Но «токсичность», на самом деле, не в детектировании и вы это прекрасно понимаете, а в возможности отфильтровать, когда клиент не готов отдавать закрытый SSL/TLS ключ и схема с keyless SSL его не устраивает. В данном случае многие облачные провайдеры (почти все) вынуждены будут развести руками и сказать, что атаку видим, но помочь ничем не можем. И из этой ситуации есть выход, но это всегда «инфраструктурные» истории: отдавать лог; ставить анализатор лога у заказчика; встраивание в приложение и.т.д. Нужно эту тему шире раскрывать…
И да, статья не о том как новичку выбирать сервис, она скорее для тех, кто интересуется технологией.
1. с WAF, который выступает в качестве Reverse-proxy, а также добавлят механизмы защиты отличные от DDoS
2. Установка на площадке клиента дополнительного устройства, которое стоит в inline и проводит анализ на прикладном уровне в real-time.
Но «токсичность», на самом деле, не в детектировании и вы это прекрасно понимаете, а в возможности отфильтровать, когда клиент не готов отдавать закрытый SSL/TLS ключ и схема с keyless SSL его не устраивает. В данном случае многие облачные провайдеры (почти все) вынуждены будут развести руками и сказать, что атаку видим, но помочь ничем не можем. И из этой ситуации есть выход, но это всегда «инфраструктурные» истории: отдавать лог; ставить анализатор лога у заказчика; встраивание в приложение и.т.д. Нужно эту тему шире раскрывать…
И да, статья не о том как новичку выбирать сервис, она скорее для тех, кто интересуется технологией.
число new/concurent session, которое опять же будет отклоняться от нормы… по любому поводу, включая рекламные и маркетинговые кампании для одних, закрытие квартала для других, горячую новость для третьих…
Я не говорю, что эта методика вообще неработоспособна. Вопрос в том, что она не обеспечивает полное покрытие и потому подходит только для случаев, когда целевых атак не ожидается, все угрозы являются спорадическими и маловероятными («да кому нас нужно атаковать»), а даунтайм в случае нападения рассматривается как приемлемый риск.
А вот если риск оценивается как вероятный и/или даунтайм совершенно неприемлем, то необходимо использовать гарантированно надёжные методы: анализ всего трафика вплоть до layer 7 в inline и real time и постоянная непрерывная фильтрация.
Ну и замечу, что если таки риск маловероятен и даунтайм приемлем, то в таких случаях обычно эффективнее вообще не подключаться ни к какому оператору защиты, дабы не платить абонентскую плату, а ограничиться составлением регламента реагирования на инцидент и заключением соглашения о намерениях с каким-нибудь надёжным вендором. Бюджет у NOC/CISO обычно не резиновый, чтобы им разбрасываться, особенно в кризисные годы.
для тех случаев, где важно иметь еще более высокую скорость реакции и точность детектирования — используются схемыЕсли требуется высокая реакция и точность, то проще и надёжнее всего просто настроить постоянную маршрутизацию через узлы очистки. Схемы с дополнительными CPE на каждой площадке клиента и постоянными переключениями туда-сюда не только сложны и менее надёжны, но ещё и обычно более дороги.
Но «токсичность», на самом деле, не в детектировании [..], а в возможности отфильтровать, когда клиент не готов отдавать закрытый SSL/TLS ключРечь не совсем об этом. «Токсичность» в данном случае заключается в том, что атака длительностью 2-10 минут приводит ОС и/или СУБД приложения в полностью неработоспособное состояние, для ликвидации которого может требоваться перезагрузка сервера.
Это достаточно типичная ситуация, например, для приложений, работающих под ОС серверного семейства Windows: в результате повышенной нагрузки ОС может перестать реагировать на внешние раздражители или вообще показать «синий экран смерти» (красный в последних версиях). И на практике на семействе ОС от Microsoft проблема не заканчивается.
«Поинцидентное» переключение под защиту поможет справиться с «школьными» атаками типа amplification, однако в случае вышеописанной атаки оно окажется неэффективным. Так что, повторюсь, главный вопрос — в оценке рисков и в управлении ими.
Именно исходя из оценки рисков, вырабатывается та или иная стратегия защиты и реагирования. Технологии служат инструментом реализации этой стратегии и поэтому вторичны. Рассказывать о технологиях, не упоминая области их применимости — это как рассказывать про инженерное устройство мостов, не рассказав перед этим про сопромат :-) Поэтому «сопромат» в статьях такого уровня необходим.
ximaera — отличные комментарии, но статья не про это.
Cтатья про то как Ростелеком решает проблему DDoS для себя и своих заказчиков. И с этой целью она отлично справляется. Очень хочется прочитать Часть2. Коллеги молодцы.
Cтатья про то как Ростелеком решает проблему DDoS для себя и своих заказчиков. И с этой целью она отлично справляется. Очень хочется прочитать Часть2. Коллеги молодцы.
Рассказывать о технологиях, не упоминая области их применимости — это как рассказывать про инженерное устройство мостов, не рассказав перед этим про сопромат :-) Поэтому «сопромат» в статьях такого уровня необходим.
Не совсем согласен, т.к. у любой статьи всегда имеется определенный уровень абстракции, на который она изначально рассчитана.
Про мосты можно тоже по-разному рассказывать, можно «на-пальцах», а можно так глубоко свалиться в детали, что вообще уйти в петлевую квантовую гравитацию. :-)
UFO just landed and posted this here
Как с помощью flowspec можно отличить валидный dns-ответ с udp 53 порта от невалидного?
Если никак, то технология мертворождённая. А если блокировать всё, то и ЦОТ не нужны.
Если никак, то технология мертворождённая. А если блокировать всё, то и ЦОТ не нужны.
Никак, не для этих целей. FS имеет смысл использовать для volumetric атак, но не для всех. Например, он не подходит для защиты от атак типа DNS Amplification на DNS сервер, при этом вам не нужно анализировать пакет на валидность, если этот тип атаки идет на любой другой сервис, можно блокировать не задумываясь.
Один из сложных сценариев: защита рекурсивного DNS сервера от DNS Amplification. В этом случае трафик нужно гнать в ЦОТ и там фильтровать на прикладном уровне. Но и тут сложность не в написании/разработке контрмер, зачастую все примитивно и достаточно применить фильтрацию по регулярному выражению. Основная задача — иметь достаточно производительные ЦОТ и широкие каналы.
p.s. некоторые SYN-флуд (100mpps+), по тому к какому эффекту приводят, можно легко отнести к volumetric. FS для TCP сервиса тоже будет бесполезен в таком случае.
Один из сложных сценариев: защита рекурсивного DNS сервера от DNS Amplification. В этом случае трафик нужно гнать в ЦОТ и там фильтровать на прикладном уровне. Но и тут сложность не в написании/разработке контрмер, зачастую все примитивно и достаточно применить фильтрацию по регулярному выражению. Основная задача — иметь достаточно производительные ЦОТ и широкие каналы.
p.s. некоторые SYN-флуд (100mpps+), по тому к какому эффекту приводят, можно легко отнести к volumetric. FS для TCP сервиса тоже будет бесполезен в таком случае.
можете похвастаться статистикой отражённых атак?
мы подготовим отдельную статью или в рамках одной из статей осветим подробнее статистику с распределением по типам атак, а пока можем привести такие цифры:
1. В среднем в сутки наблюдаем до 700 атак.
2. Максимальная мощность атаки в bps — 214Gbps
3. Максимальная мощность атаки в pps — 100Mpps
4. В среднем в месяц 1-2 атаки выше 50 Гбит/с
1. В среднем в сутки наблюдаем до 700 атак.
2. Максимальная мощность атаки в bps — 214Gbps
3. Максимальная мощность атаки в pps — 100Mpps
4. В среднем в месяц 1-2 атаки выше 50 Гбит/с
Sign up to leave a comment.
Защита от DDoS-атак с точки зрения оператора связи. Часть 1