Ваша главная ошибка и сайт и сервис находятся на одном сервере
ваш тест не релевантен в отношении того на одной машине крутится сайт и сервис или на разных. даже если бы на разных, ничего не мешает подключится по VPN, узнать внешний IP, в который натит всех клиентов и таргетом указать его.
иначе любой скрипткиди положит ваш сервис с домашней машины
вы пробовали с домашней машины с данным параметром --rand-source?
Если я не ошибаюсь, то Share band приложение поднимает два туннеля поверх разнородных каналов передачи даных (GPRS, EDGE, Wi-Fi, etc) с серверами расположенными в ДЦ Share band. Устройству назначается IP-адрес из пула Share band. Затем исходящий трафик от устройства балансируется в туннели и передается серверам, через них же принимается обратный трафик. Судя по white paper ДЦ находятся в us, nl и uk, так что российским пользователям серфить с такой задержкой удовольствие не великое.
Продолжительность атаки примерно 30 минут, с 16:20 до 16:50. Не расскажите почему у вас в этот период времени вырос passed трафик, а также упало кол-во запросов по сравнению с моментом до и после атаки? Также было бы интересно услышать ваше мнение о причинах появления ICMP трафика.
Потоком считается набор пакетов, проходящих в одном направлении. Когда сенсор определяет, что поток закончился (по изменению параметров пакетов, либо по сбросу TCP — сессии), он отправляет информацию в коллектор. В зависимости от настроек он также может периодически отправлять в коллектор информацию о все еще идущих потоках [2].
Осмелюсь переписать этот абзац, потому как многие фразы звучат очень неоднозначно: «в одном направлении», «по сбросу TCP-сесии». Также надеюсь, что после моего комментария выполнение некоторых команд в CLI станет немного понятнее.
Все пакеты у которых совпадают source/destination IP адреса, source/destination порты, номер протокола, интерфейс и класс сервиса — группируются в поток (flow) и затем эти пакеты и байты начинают подсчитываться, а информация о них записываться в NetFlow database, называемой NetFlow cache.
Процесс в маршрутизаторе, коммутаторе, etc., ответственный за NetFlow осуществляет поиск по записям кэша, с целью найти такие потоки:
— были бы затерменированы
— время жизни которых истекло(простаивает в течении заданного времени — inactive flow timer)
— долгоживущие(продолжающиеся дольше заданного порога — active flow timer).
Затерминированными считаются те потоки, семантика транспортного протокола которых свидетельствует о завершении сессии, например для TCP сесии был получен пакет с TCP флагами FIN или RST. После того как поток по заданным выше условиям был найден, данные о нем экспортируется на коллектор.
В случае с долгоживущими потоками, информация о них может разбиваться на несколько записей, которые объединяются уже коллектором в общий поток трафика.
Т.к. в коментариях встретил обсуждения вопроса влияния на производительность, скину полезную ссылку на первоисточник: NetFlow Performance Analysis
«ip route-cache flow» может использоваться только для основного интерфейса, а «ip flow ingress» — это расширение для использования для сабинтерфесов.
ip route-cache flow — устаревшая команда, которая осталась для совместимости. Была заменена на ip flow ingress
Опередили. Ссылка на RFC2671. Это был ответ на вопрос откуда получаем плечо. Что касается поиска зоны для которой ответ может превышать 512байт, можно долго искать длинный ответ, но пацаны обычно рисуют TXT запись 4кбайт для фейкового домена.
А вот меня на самом деле пугает совсем другая вещь. DNS reflection/amplification атака с точки зрения реализации элементарна, в связи с чем не нужно ванговать, чтобы утверждать, что чем больше людей о них узнает, тем больше атак мы будем наблюдать и этот год будет не простым. Инструментария по поиску открытых резолверов предостаточно, генераторов dns запросов тоже. А удивляет тот факт, что интернет сообщество в лице операторов связи по всему миру очень аморфно и не спешит выполнять требования BCP38, который появился в далеком 2000 году. Пока у атакующих будет возможность арендовать/брутить сервера с возможностью спуфа, либо создавать ботнеты из пользовательских ПК, которые также могут спуфить, мы будем наблюдать различиные вариации amplification атак (DNS, NTP, SNMP, etc). И 300Гбит/с не предел, это лишь к вопросу ресурсов у атакующих. С плечом 1:70, достаточно и 10 серверов подключенных гигабитом.
А вы не пробовали то же самое сделать на сервере, например с CPU Intel Xeon E5 серии и сетевыми адаптерами Intel I350 или Х520 серий? При этом «прибив» жестко очеди сетевой карты к нужному ядру и посмотреть на результат.
Radware — это все же Enterprise и DC решение, несмотря на то, что и SP его можно назвать, но с ОЧЕНЬ большой натяжкой, т.к. inline решения уж слишком ограничены при внедрении в топологию сети оператора, а заявленый Out-of-Path лишает части функционала и требует опять же извращений с маршрутизацией, либо редиректом трафика. Все потому что изначально архитектура решения была заточена под корпоратов, отсюда и ограниченное число серверных и сетевых политик.
Замечание по поводу сервера HP вообще не имеют место, похоже вы не разобрались в сути. Если говорить об «Анализаторе», то это вполне нормально, что он является обычным промышленным сервером и то что там стоят оптероны тоже вполне нормально, т.к. он решается задачи по сбору информации по Flow,SNMP, BGP и для этого не требуются специализированные процессоры. Собственно CP/FS/BI/PI у арбора это такие же обычные сервера, но покрашенные дорогой краской и стоит там либо Linux, либо в версиях постарее OpenBSD, на Intel CPU. Если говорить о топовых устройства фильтрации, то и Arbor и у МФИ это специализированные сетевые процессоры, у МФИ — Tilera (NSFOCUS тоже их использует), а сервер HP служит лишь базой для его установки. Про ваши объемы flow преувеличиваете, либо озвучьте цифру.
Вообще, мне ваш выбор импонирует, просто суть статьи совсем не понятна, т.к. ожидал увидеть сравнение в разрезе основного функционала, а пишите о том, что не смогли устройство настроить, либо как в случае с Radware — не понравился интерфейс, но ни слова о том, как же он фильтровал вредоносный трафик, тем более интересно, что трафик не синтетический.
Кстати, CloudSignaling собираетесь задействовать?
P.S. Не пытаюсь принизить или возвысить кого-либо из вендоров, каждый из них в чем-то хорош и имеет сви killer фичи, но в тоже время каждый из них не является серебряной пулей. Желаю успехов при дальнейшей эксплуатации. И будет очень интересно почитать, какие у вас ощущения от работы с железом спустя несколько месяцев.
Результат ожидаемый. Вы пытались сравнивать оборудование класса Enterprise (Arbor Pravail, Radware DefensePro) и Service Provider(МФИ Софт «Периметр», NSFOCUS). Например, настройки того же Arbor Peakflow SP ничем не отличаются от МФИ Софт «Периметр» и что же взглянув на интерфейс вы бы сделали такие же выводы? После инсталляции железа, в дальнейшем Вам бы пришлось крутить только контрмеры во время DDoS, а о других настройках можно было бы забыть. По удобству интерфейса Radware полностью согласен. Ну а Pravail подкупает конечно же красотой интерфейса, на что многие заказчики и ведутся, не особо вдаваясь в функционал и возможности, тестирую железо на сетевом флуде или на тупых High Rate http флудах.
Либо вы сами запутались, либо пытаетесь запутать других, третьему не бывать:).
Пример: на роутере с поднятым процессом BGP имеется слушающий сокет на 179 TCP. Если вы зарядите SYN флуд на 179 порт лупбэк интерфейса и при этом CoPP будет не настроен, то получите профит и не только потому что SYN пакеты будут Process Switching. Тут несколько вариантов развития событий: переполненный backlog, умирание процессора супервизора от интераптов на высоком pps. И если backlog не дает устанавливать новые сессии от BGP пиров, то высокий pps (больше 100kpps не нужно) к процессору уложит все шасси.
Решить данную проблему как раз и призван CoPP, фильтруя пакеты на ASIC в forwarding plane, не давая умереть какому-нибудь слабенькому CPU 700MHZ у того же SUP720.
Adam J. O’Donnell в исследовании Games, Metrics, and Emergent Threats описал причины переключения внимания злоумышленников с цели X на цель Y, на примере Win и Mac, выдвигая различные гипотезы. Вывод был следующим: концентрация внимания злоумышленников к продукту резко возрастает, как только доля его рынка переваливает за 12-16%. Наличие/отсутствие публикаций об уязвимостях скорее всего также коррелирует с долей рынка/популярностью.
Атаки большой магнитуды (в 99% случаев — «тупой» UDP,ICMP флуд) в сети оператора связи срезаются BGP FlowSpec'ом на границе сети и незачем его гнать по backbone до ЦОТ. L7 атаки еще не достингли >10G размеров, за исключением DNS. В любом случае, согласен, 10-ка не подстать МегаФону(Synterra), с таким запасом прочности будет больно приземляться.
ваш тест не релевантен в отношении того на одной машине крутится сайт и сервис или на разных. даже если бы на разных, ничего не мешает подключится по VPN, узнать внешний IP, в который натит всех клиентов и таргетом указать его.
вы пробовали с домашней машины с данным параметром --rand-source?
Осмелюсь переписать этот абзац, потому как многие фразы звучат очень неоднозначно: «в одном направлении», «по сбросу TCP-сесии». Также надеюсь, что после моего комментария выполнение некоторых команд в CLI станет немного понятнее.
Все пакеты у которых совпадают source/destination IP адреса, source/destination порты, номер протокола, интерфейс и класс сервиса — группируются в поток (flow) и затем эти пакеты и байты начинают подсчитываться, а информация о них записываться в NetFlow database, называемой NetFlow cache.
Процесс в маршрутизаторе, коммутаторе, etc., ответственный за NetFlow осуществляет поиск по записям кэша, с целью найти такие потоки:
— были бы затерменированы
— время жизни которых истекло(простаивает в течении заданного времени — inactive flow timer)
— долгоживущие(продолжающиеся дольше заданного порога — active flow timer).
Затерминированными считаются те потоки, семантика транспортного протокола которых свидетельствует о завершении сессии, например для TCP сесии был получен пакет с TCP флагами FIN или RST. После того как поток по заданным выше условиям был найден, данные о нем экспортируется на коллектор.
В случае с долгоживущими потоками, информация о них может разбиваться на несколько записей, которые объединяются уже коллектором в общий поток трафика.
Т.к. в коментариях встретил обсуждения вопроса влияния на производительность, скину полезную ссылку на первоисточник: NetFlow Performance Analysis
ip route-cache flow — устаревшая команда, которая осталась для совместимости. Была заменена на ip flow ingress
Замечание по поводу сервера HP вообще не имеют место, похоже вы не разобрались в сути. Если говорить об «Анализаторе», то это вполне нормально, что он является обычным промышленным сервером и то что там стоят оптероны тоже вполне нормально, т.к. он решается задачи по сбору информации по Flow,SNMP, BGP и для этого не требуются специализированные процессоры. Собственно CP/FS/BI/PI у арбора это такие же обычные сервера, но покрашенные дорогой краской и стоит там либо Linux, либо в версиях постарее OpenBSD, на Intel CPU. Если говорить о топовых устройства фильтрации, то и Arbor и у МФИ это специализированные сетевые процессоры, у МФИ — Tilera (NSFOCUS тоже их использует), а сервер HP служит лишь базой для его установки. Про ваши объемы flow преувеличиваете, либо озвучьте цифру.
Вообще, мне ваш выбор импонирует, просто суть статьи совсем не понятна, т.к. ожидал увидеть сравнение в разрезе основного функционала, а пишите о том, что не смогли устройство настроить, либо как в случае с Radware — не понравился интерфейс, но ни слова о том, как же он фильтровал вредоносный трафик, тем более интересно, что трафик не синтетический.
Кстати, CloudSignaling собираетесь задействовать?
P.S. Не пытаюсь принизить или возвысить кого-либо из вендоров, каждый из них в чем-то хорош и имеет сви killer фичи, но в тоже время каждый из них не является серебряной пулей. Желаю успехов при дальнейшей эксплуатации. И будет очень интересно почитать, какие у вас ощущения от работы с железом спустя несколько месяцев.
Пример: на роутере с поднятым процессом BGP имеется слушающий сокет на 179 TCP. Если вы зарядите SYN флуд на 179 порт лупбэк интерфейса и при этом CoPP будет не настроен, то получите профит и не только потому что SYN пакеты будут Process Switching. Тут несколько вариантов развития событий: переполненный backlog, умирание процессора супервизора от интераптов на высоком pps. И если backlog не дает устанавливать новые сессии от BGP пиров, то высокий pps (больше 100kpps не нужно) к процессору уложит все шасси.
Решить данную проблему как раз и призван CoPP, фильтруя пакеты на ASIC в forwarding plane, не давая умереть какому-нибудь слабенькому CPU 700MHZ у того же SUP720.
Советую ознакомится с RFC 6192, довольно свежий и очень полезный документ, тем более для SP.