мы подготовим отдельную статью или в рамках одной из статей осветим подробнее статистику с распределением по типам атак, а пока можем привести такие цифры:
1. В среднем в сутки наблюдаем до 700 атак.
2. Максимальная мощность атаки в bps — 214Gbps
3. Максимальная мощность атаки в pps — 100Mpps
4. В среднем в месяц 1-2 атаки выше 50 Гбит/с
Никак, не для этих целей. FS имеет смысл использовать для volumetric атак, но не для всех. Например, он не подходит для защиты от атак типа DNS Amplification на DNS сервер, при этом вам не нужно анализировать пакет на валидность, если этот тип атаки идет на любой другой сервис, можно блокировать не задумываясь.
Один из сложных сценариев: защита рекурсивного DNS сервера от DNS Amplification. В этом случае трафик нужно гнать в ЦОТ и там фильтровать на прикладном уровне. Но и тут сложность не в написании/разработке контрмер, зачастую все примитивно и достаточно применить фильтрацию по регулярному выражению. Основная задача — иметь достаточно производительные ЦОТ и широкие каналы.
p.s. некоторые SYN-флуд (100mpps+), по тому к какому эффекту приводят, можно легко отнести к volumetric. FS для TCP сервиса тоже будет бесполезен в таком случае.
В статье написано, что есть две фазы: детектирование и фильтрация. В ходе фильтрации используется в том числе прикладной анализ. В ходе же детектирования, прикладной уровень в _простом случае_ не анализируется, но это не мешает детектировать отклонения от нормы по 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 его не устраивает. В данном случае многие облачные провайдеры (почти все) вынуждены будут развести руками и сказать, что атаку видим, но помочь ничем не можем. И из этой ситуации есть выход, но это всегда «инфраструктурные» истории: отдавать лог; ставить анализатор лога у заказчика; встраивание в приложение и.т.д. Нужно эту тему шире раскрывать…
И да, статья не о том как новичку выбирать сервис, она скорее для тех, кто интересуется технологией.
Для блокировки HTTPS трафика, многие DPI также смотрят на поле SNI, что позволяет блокировать не по IP, а по доменному имени. Фильтровать конкретный URI в пределах домена «увы» не получиться.
Можно не называть, они всем известны. К некоторым отношусь с глубоким уважением.
Но если интересно, то откройте, например, bgp.he.net и посмотрите на граф связности их AS. Затем посмотрите на то, кто для них является апстримом и подумайте, что будет если один из них поймает даже 300Гбит/с. Для того, чтобы было проще рассуждать накину пару вопросов куда смотреть:
1. Сколько у AS апстримов (на удивление некоторые имеют одного, а значит апстриму придется есть в одиночку)?
2. Насколько широкий апстрим?
3. Что сделает апстрим, если флуд начнет аффектить на других не менее важных клиентов, трафик которых начнет дропаться в силу отсутствия полосы по каким-то направлениям?
4. А ловил ли кто-нибудь из них реально даже 200Gbps, чтобы вот так легко заявлять о своих способностях? Маршрутизация она такая, что даже наличие 500Gbps свободной полосы не означает равномерного распределения флуда по всем каналам.
а) а вы могли бы привести примеры antiddos сервиса от IX? Представляете себе как ее вообще можно организовать сервис на IX'е? Начните с простого, как выявлять флуд… Буду признателен за примеры. Либо вы предлагаете клиенту подключиться к IX и получив дешевую полосу самому фильтровать трафик, ну например тем же flowspec? А каким может оказаться реальное распределение amplification атак получаемых, например, через тот же MSK-IX? Вы уверены, что в отсутствии полной связности получаемой через IX вам прилетит именно оттуда, а не через upstream. Казалось бы купили полосу 100G на IX, а почему-то летит все в гигабитный линг вышестоящего провайдера.
б) предложите банкам или другим финансовым организациям в России использовать keyless-ssl, а потом расскажите нам, что услышите в ответ. А ведь как не странно они основные заказчики на защиту HTTPS.
Спасибо за статью, ждем продолжения.
Разрешите задать пару вопросов:
1. На чей опыт опирались при построении SOC и формировании структуры команды или строили исходя из своего видения и практического понимания, что должно быть именно так?
2. Каков уровень доверия со стороны клиентов аутсорсинговому SOC?
3. Подписываются какие-либо документы сотруднками SOC о не разглашении информации? Возможно, раз в какой-то период проходят проверку на полиграфе? Может отчасти надуманно, основное, что хочется понять, какие еще требования предъявляются к кандидатам, помимо технической компетенции?
4. Кто послужил драйвером появления коммерческого SOC в Jet? «Жирный» клиент, который захотел сервис и готов был платить или все же сначала строили, потом ходили по рынку? Расскажите об этом немного поподробнее.
5. Сталкиваетесь с ситуациями, когда дежурный инженер работает 24x7, а клиент нет, при этом события происходят глубокой ночью? Как в таких случаях происходит реагирование на инциденты?
И в чем заключается качество пакетов?
1. ttl=64 и не изменяется
2. id=0 и не изменяется
3. sport = dport = 0
4. исходя из:
tcp->th_ack = rand(); // Contains the acknowledgement number.
получаем ack != 0, а у SYN сегмента должно быть ack = 0, то на чем палиться старый добрый hping3.
5. win = 512 и не изменяется
6. зачем-то передаете 6 байт в payload?
7. из не существенного, почему-то в pkt-gen.c: ip->ip_tos = IPTOS_LOWDELAY;
tcp->th_seq = ntohl(rand()); // Contains the sequence number.
поправлюсь, ограничение числа сессий настраивается в Connection Limit, а не в Connection PPS Limit, но сути это не меняет, т.к в любом случае это не механизм продиводействия syn-flood
SYN Flood Protection
Тут ничего сложного. От SYN флуда спасает Connection Limit.
Настолько вольное трактование документации позволило TC ошибиться более чем полностью. Connection Limit работает в противомере под названием «Connection PPS Limit». А от spoofed syn-flood спасает syn-cookie/safe-reset/tcp-reset. Radware сюда еще притянули [http/js]- redirect.
Начнем с графиков, которые должны были лишить читателя всех сомнений в качестве устройства и прямоте рук администратора. Разница в Inbound и Discarded Inbound говорит о том, что DefencePro больше пропускал чем фильтровал. При том, что трафик любого веб-ресурса характерен бОльшим Outbound чем Inbound, о чем свидельствует последний график показывающий ровно тот момент когда атака закончилась.
Вы совсем недавно анонсировали свою услугу и на рынке не так много отзывов о качестве предоставляемого вами сервиса, поэтому хотелось бы понять проводилось ли сравнение antiddos услуг от других операторов/cloud-сервисов? Было бы очень интересно услышать чем вы лучше или хуже? А также в чем отличие услуги построенной на базе решения Radware?
Благодаря этому, можно сбалансировать трафик между точками присутствия и работать с фильтрами в режиме реального времени, настраивая их под защиту от актуальных техник DDoS-атак, которые постоянно видоизменяются и модернизируются.
Как связана распреленность сети фильтрации с настройкой фильтров в реальном времени и актуальными техниками атак, которые постоянно видоизменяются? Вам не кажется, что вы путаете причинно-следственные связи?
Ребят, прокомментируйте пож-та каким образом под вашей защитой берется столько «хлама»?
Ума не приложу, как www.reg.ru встал к вам под защиту, похоже бесплатность так манит, что на вашу репутацию можно закрыть глаза.
Ваша логика ясна: решили потихоньку становиться беленькими и пушистыми, поэтому решили взять и без денег, т.к. нужен пиар и поступления с «хлама» пока нормально в карман капают.
Сколько раз слышал: «лучше под ddos сутки пролежать раз месяц, чем весь месяц лежать под защитой ddos-guard и не разу не быть атакованным...»
Рад видеть Евгения на хабре. Несмотря на то, что статья аккумулирует практически все, что написано Луиджи, спасибо за систематизацию и перевод. Если последние пару лет все anti-ddos вендоры и сервисы рапортовали об интелектуализации ddos-атак и увелечении % L7, то после непрекращающейся волны dns-amplification атак нам стоит ожидать L3-4 флуд с использованием netmap/dpdk/etc, что не может не беспокоить. Нужно дать пару месяцев на освоение и результаты мы ощутим на себе. При этом масштабироваться так же быстро, как атакующим — не тривиально. Имхо, подобные статьи впервую очередь способствуют развитию инструментария атакующих, а не тех кто использует их в мирных целях.
туннельному интерфейсу клиента либо можно назнчить public ip из того самого пула и затем роутить его пакеты, либо NAT/PAT можно тем же round-robin. Вы хотите сказать, что выделяете адрес под каждого клиента?
спасибо, не внимателен. после того как сделал предположение по ASA, не удосужился снова заглянуть в ваш список софта и оборудования. но тогда вы товарищ лукавите, ни один коммутатор не уложить packet rate'ом с виртуалки.
1. В среднем в сутки наблюдаем до 700 атак.
2. Максимальная мощность атаки в bps — 214Gbps
3. Максимальная мощность атаки в pps — 100Mpps
4. В среднем в месяц 1-2 атаки выше 50 Гбит/с
Один из сложных сценариев: защита рекурсивного DNS сервера от DNS Amplification. В этом случае трафик нужно гнать в ЦОТ и там фильтровать на прикладном уровне. Но и тут сложность не в написании/разработке контрмер, зачастую все примитивно и достаточно применить фильтрацию по регулярному выражению. Основная задача — иметь достаточно производительные ЦОТ и широкие каналы.
p.s. некоторые SYN-флуд (100mpps+), по тому к какому эффекту приводят, можно легко отнести к volumetric. FS для TCP сервиса тоже будет бесполезен в таком случае.
1. с WAF, который выступает в качестве Reverse-proxy, а также добавлят механизмы защиты отличные от DDoS
2. Установка на площадке клиента дополнительного устройства, которое стоит в inline и проводит анализ на прикладном уровне в real-time.
Но «токсичность», на самом деле, не в детектировании и вы это прекрасно понимаете, а в возможности отфильтровать, когда клиент не готов отдавать закрытый SSL/TLS ключ и схема с keyless SSL его не устраивает. В данном случае многие облачные провайдеры (почти все) вынуждены будут развести руками и сказать, что атаку видим, но помочь ничем не можем. И из этой ситуации есть выход, но это всегда «инфраструктурные» истории: отдавать лог; ставить анализатор лога у заказчика; встраивание в приложение и.т.д. Нужно эту тему шире раскрывать…
И да, статья не о том как новичку выбирать сервис, она скорее для тех, кто интересуется технологией.
Но если интересно, то откройте, например, bgp.he.net и посмотрите на граф связности их AS. Затем посмотрите на то, кто для них является апстримом и подумайте, что будет если один из них поймает даже 300Гбит/с. Для того, чтобы было проще рассуждать накину пару вопросов куда смотреть:
1. Сколько у AS апстримов (на удивление некоторые имеют одного, а значит апстриму придется есть в одиночку)?
2. Насколько широкий апстрим?
3. Что сделает апстрим, если флуд начнет аффектить на других не менее важных клиентов, трафик которых начнет дропаться в силу отсутствия полосы по каким-то направлениям?
4. А ловил ли кто-нибудь из них реально даже 200Gbps, чтобы вот так легко заявлять о своих способностях? Маршрутизация она такая, что даже наличие 500Gbps свободной полосы не означает равномерного распределения флуда по всем каналам.
Таки легко? Назовите отечественные специализированные компании, которые это могут сделать легко?
б) предложите банкам или другим финансовым организациям в России использовать keyless-ssl, а потом расскажите нам, что услышите в ответ. А ведь как не странно они основные заказчики на защиту HTTPS.
Разрешите задать пару вопросов:
1. На чей опыт опирались при построении SOC и формировании структуры команды или строили исходя из своего видения и практического понимания, что должно быть именно так?
2. Каков уровень доверия со стороны клиентов аутсорсинговому SOC?
3. Подписываются какие-либо документы сотруднками SOC о не разглашении информации? Возможно, раз в какой-то период проходят проверку на полиграфе? Может отчасти надуманно, основное, что хочется понять, какие еще требования предъявляются к кандидатам, помимо технической компетенции?
4. Кто послужил драйвером появления коммерческого SOC в Jet? «Жирный» клиент, который захотел сервис и готов был платить или все же сначала строили, потом ходили по рынку? Расскажите об этом немного поподробнее.
5. Сталкиваетесь с ситуациями, когда дежурный инженер работает 24x7, а клиент нет, при этом события происходят глубокой ночью? Как в таких случаях происходит реагирование на инциденты?
И в чем заключается качество пакетов?
1. ttl=64 и не изменяется
2. id=0 и не изменяется
3. sport = dport = 0
4. исходя из:
получаем ack != 0, а у SYN сегмента должно быть ack = 0, то на чем палиться старый добрый hping3.
5. win = 512 и не изменяется
6. зачем-то передаете 6 байт в payload?
7. из не существенного, почему-то в pkt-gen.c: ip->ip_tos = IPTOS_LOWDELAY;
ntohl — здесь бессмысленен.
Настолько вольное трактование документации позволило TC ошибиться более чем полностью. Connection Limit работает в противомере под названием «Connection PPS Limit». А от spoofed syn-flood спасает syn-cookie/safe-reset/tcp-reset. Radware сюда еще притянули [http/js]- redirect.
вот тут можно не сомневаться… один из сценариев — ddos-рэкит ваших клиентов, дабы не сомневались в необходимости услуги.
Как связана распреленность сети фильтрации с настройкой фильтров в реальном времени и актуальными техниками атак, которые постоянно видоизменяются? Вам не кажется, что вы путаете причинно-следственные связи?
Ребят, прокомментируйте пож-та каким образом под вашей защитой берется столько «хлама»?
Ума не приложу, как www.reg.ru встал к вам под защиту, похоже бесплатность так манит, что на вашу репутацию можно закрыть глаза.
Ваша логика ясна: решили потихоньку становиться беленькими и пушистыми, поэтому решили взять и без денег, т.к. нужен пиар и поступления с «хлама» пока нормально в карман капают.
Сколько раз слышал: «лучше под ddos сутки пролежать раз месяц, чем весь месяц лежать под защитой ddos-guard и не разу не быть атакованным...»
ATLAS
Я писал, что натятся клиенты, а не сервера.
туннельному интерфейсу клиента либо можно назнчить public ip из того самого пула и затем роутить его пакеты, либо NAT/PAT можно тем же round-robin. Вы хотите сказать, что выделяете адрес под каждого клиента?
Самая младшая линейка коммутаторов cisco доступных на рынке:
Cisco Catalyst 2950-12: 1.8 Mpps wire-speed forwarding rate
• Cisco Catalyst 2950-24: 3.6 Mpps wire-speed forwarding rate
• Cisco Catalyst 2950SX-24: 6.6 Mpps wire-speed forwarding rate
• Cisco Catalyst 2950T-48: 10.1 Mpps wire-speed forwarding rate
• Cisco Catalyst 2950SX-48: 10.1 Mpps wire-speed forwarding rate
Т.е. минимально 1.8 mpps, при том что с виртуалки в лучшем случае выжмите 10-ки kpps.
Признавайтесь, может net/ipv4/tcp_syncookies были выключены?