Лично сам в речи использую «скорость», либо сразу указываю единицу измерения. «Максимальная атака со скоростью 100 Mpps», «Сейчас идет атака на 500 Gbps».
Какие аргументы были против этого термина?
pps, bps, rps, cps, tps - это метрики атаки, которые
выглядят как скорость
packet per seconds, bit per second, requests per second;
можно посчитать взятием производной с инкрементального счетчика количества пакетов, бит, запросов;
плавают как скорость
утилизируют ресурсы, которые принято называть, либо измерять скоростью;
крякают как скорость
в русском языке под термином «скорость» понимают быстроту изменения какой-либо величины, в данном случае количества полученных пакетов, бит, запросов.
Спасибо за отчет. Много информации и интересно было читать. Отдельный плюс за терминологию в фразах «битовой и пакетной интенсивности», «пропускная способность TCP-флуда», «нейтрализованных DDoS-атак» вместо популярных у журналистов «мощностью» и «отражение атаки»
В процессе интерпретации значений появились вопросы.
1. Первый IP-фрагмент с UDP заголовками учитывается как udp_flood или как ip_flood? Если как udp_flood, тогда не могу понять низкую долю комбинации upd_flood, ip_flood. Если как ip_flood, тогда получается некоторые UDP амплификации считаются как ip_flood, а не udp_flood.
2. Атака с флагами SYN-ACK учитывалась в tcp_flood?
Основные типы DDoS-атак — Layer 3 и Layer 7. Они названы так в соответствии с уровнями сетевой модели OSI, на которых выполняются.
Layer 3 DDoS нацелен на сетевое оборудование и соединения. В ходе атаки создаётся огромный паразитный трафик, например, с помощью SYN-пакетов (syn-flood).
Какая-то уж совсем грубая классификация.
Если взять из вашего примера SYN Flood, то SYN-флаг это атрибут TCP, протокола транспортного уровня (L4). Или NTP Amplification Attack тоже использует транспортный протокол, но уже UDP, и не дотягивает на L7-атаку. А вот IP Fragmentation Attack явно уже использует свойства IP, протокола сетевого уровня (L3). Противодействие этим атакам разное исходя из свойств их протоколов.
Поэтому если и классифицировать DDoS-атаки в Интернете по уровням сетевой модели OSI, то L3, L4, L7.
При этом нужно понимать, что атака уровнем выше может быть успешна, как атака нижестоящего уровня. Например, L7-атака HTTP Flood c миллиона хостов забьет входящим трафиком 100 Mbps порт, т.е. израсходует ресурсы на L1.
В цитируемом предложении не идет речь про максимальную наблюдаемую SYN-ACK атаку на сеть qrator. А пишут о том, что при подготовке отчета на сайт qrator.net впервые прилетела эта атака, до этого они наблюдали только в сторону клиентов.
Нет, не решит.
Для фильтрации DDoS-атак между провайдерами в текущей реализации BGP Flowspec есть ряд ограничений.
1. Доверие
Оператор не может просто так позволить кому-то извне определять какой трафик должен сбрасываться на его сети, а какой проходить. А если пришло «ошибочное» правило и пострадал клиент оператора, то кто будет отвечать? Есть несколько вариантов проверки и фильтрации приходящих правил, но они для ограниченных сценариев использования. Также на доверие влияют пункты 2 и 3.
2. Оборудование
Большинство современных маршрутизаторов с BGP Flowspec ограничены несколькими тысячами «элементарных» правил. Если взаимодействие по BGP Flowspec ставить на поток, то TCAM быстро закончится.
3. Баги
Поддержка BGP Flowspec у разных вендоров и моделях различается и неполноная. Есть серьезные ошибки в реализации. Например, CVE-2019-0003, CVE-2014-6386.
4. Деньги
Транзитный оператор зарабатывает на пересылке трафика. Если трафик атаки не нагружает его сеть, то фильтрация получается себе в минус.
5. Частичная защита
Используя правила BGP Flowspec можно срезать только часть объемных атак и не для всех видов защищаемых сервисов. При этом остаются атаки другого типа и объемные атаки трафик, которых не получается описать через текущий набор.
Среди игровых серверов чаще всего первые три пункта.
2. Стоимость услуги DDoS-атаки начинается от несколько десятков долларов, и зависит от атакуемого сервиса, наличия защиты, требования к времени простоя. Видов DDoS-атак много и большинство из них просты в организации.
В статье не упомянул два случая, когда графики по-настоящему врут.
1. Для подсчета количества обработанных байт используется 32-х битный счетчик.
На больших скоростях счетчик переполняется между замерами, и на график ставится точка сильно ниже реальной.
2. Для телеметрии использую *flow протоколы со семплированием. Т.е. в подсчет попадают не все пакеты, а один из n.
Собранные данные изначально уже являются неточными.
Может быть расхождение в коэффициентах семплирования на сенсоре и коллекторе.
При DDoS-атаке количество flow возрастает. Вследствие этого в сети управления увеличивается количество UDP трафика с телеметрией. Дальше для спасения сети управления часть UDP срезается, либо теряется на забитом линке. В итоге на коллекторе неполная информация, а графики не отображают действительность.
Коммутаторы и маршрутизаторы не считают по L2 Data.
Такой подсчет встречается у более специализированных устройств. Когда в pipeline обрабатывается уже содержимое на следующем уровне стека.
Например, summary график mitigation из Arbor TMS при TCP SYN Flood
Если смотреть на графики, то метрики атаки ~105 Kpps ~33,7 Mbps
Обычно при SYN Flood размеры IP Headres = 20Bytes и TCP Headers = 20 Bytes, в сумме 40 Bytes.
Расчеты на калькуляторe (линк с установленными значениями) показывают, что подсчет идет на L3 уровне. На физическом уровне использование линка 70,56 Mbps.
По-видимому, в этом случае можно будет наблюдать ситуацию, когда 10 GbE линк забит, а на графике всего 4,76 Gbps (сейчас не проверял).
Поддерживаю термин "скорость" :-)
Лично сам в речи использую «скорость», либо сразу указываю единицу измерения. «Максимальная атака со скоростью 100 Mpps», «Сейчас идет атака на 500 Gbps».
Какие аргументы были против этого термина?
pps, bps, rps, cps, tps - это метрики атаки, которые
выглядят как скорость
packet per seconds, bit per second, requests per second;
можно посчитать взятием производной с инкрементального счетчика количества пакетов, бит, запросов;
плавают как скорость
утилизируют ресурсы, которые принято называть, либо измерять скоростью;
крякают как скорость
в русском языке под термином «скорость» понимают быстроту изменения какой-либо величины, в данном случае количества полученных пакетов, бит, запросов.
Спасибо за отчет. Много информации и интересно было читать. Отдельный плюс за терминологию в фразах «битовой и пакетной интенсивности», «пропускная способность TCP-флуда», «нейтрализованных DDoS-атак» вместо популярных у журналистов «мощностью» и «отражение атаки»
В процессе интерпретации значений появились вопросы.
1. Первый IP-фрагмент с UDP заголовками учитывается как udp_flood или как ip_flood?
Если как udp_flood, тогда не могу понять низкую долю комбинации upd_flood, ip_flood.
Если как ip_flood, тогда получается некоторые UDP амплификации считаются как ip_flood, а не udp_flood.
2. Атака с флагами SYN-ACK учитывалась в tcp_flood?
3. Является ли SYN Flood L4-атакой?
Какая-то уж совсем грубая классификация.
Если взять из вашего примера SYN Flood, то SYN-флаг это атрибут TCP, протокола транспортного уровня (L4). Или NTP Amplification Attack тоже использует транспортный протокол, но уже UDP, и не дотягивает на L7-атаку. А вот IP Fragmentation Attack явно уже использует свойства IP, протокола сетевого уровня (L3). Противодействие этим атакам разное исходя из свойств их протоколов.
Поэтому если и классифицировать DDoS-атаки в Интернете по уровням сетевой модели OSI, то L3, L4, L7.
При этом нужно понимать, что атака уровнем выше может быть успешна, как атака нижестоящего уровня. Например, L7-атака HTTP Flood c миллиона хостов забьет входящим трафиком 100 Mbps порт, т.е. израсходует ресурсы на L1.
Если уж меряться графиками, то в контексте TCP SYN-ACK график в Mpps показательней. И не для всего IP, а только TCP.
В цитируемом предложении не идет речь про максимальную наблюдаемую SYN-ACK атаку на сеть qrator. А пишут о том, что при подготовке отчета на сайт qrator.net впервые прилетела эта атака, до этого они наблюдали только в сторону клиентов.
Для фильтрации DDoS-атак между провайдерами в текущей реализации BGP Flowspec есть ряд ограничений.
1. Доверие
Оператор не может просто так позволить кому-то извне определять какой трафик должен сбрасываться на его сети, а какой проходить. А если пришло «ошибочное» правило и пострадал клиент оператора, то кто будет отвечать? Есть несколько вариантов проверки и фильтрации приходящих правил, но они для ограниченных сценариев использования. Также на доверие влияют пункты 2 и 3.
2. Оборудование
Большинство современных маршрутизаторов с BGP Flowspec ограничены несколькими тысячами «элементарных» правил. Если взаимодействие по BGP Flowspec ставить на поток, то TCAM быстро закончится.
3. Баги
Поддержка BGP Flowspec у разных вендоров и моделях различается и неполноная. Есть серьезные ошибки в реализации. Например, CVE-2019-0003, CVE-2014-6386.
4. Деньги
Транзитный оператор зарабатывает на пересылке трафика. Если трафик атаки не нагружает его сеть, то фильтрация получается себе в минус.
5. Частичная защита
Используя правила BGP Flowspec можно срезать только часть объемных атак и не для всех видов защищаемых сервисов. При этом остаются атаки другого типа и объемные атаки трафик, которых не получается описать через текущий набор.
Среди игровых серверов чаще всего первые три пункта.
2. Стоимость услуги DDoS-атаки начинается от несколько десятков долларов, и зависит от атакуемого сервиса, наличия защиты, требования к времени простоя. Видов DDoS-атак много и большинство из них просты в организации.
Как (инструмент) и с чего (счетчик) снимаются показатели скорости на A и Б?
Укажите поточней значения в момент времени на балансировщике и на А, Б.
1. Для подсчета количества обработанных байт используется 32-х битный счетчик.
На больших скоростях счетчик переполняется между замерами, и на график ставится точка сильно ниже реальной.
2. Для телеметрии использую *flow протоколы со семплированием. Т.е. в подсчет попадают не все пакеты, а один из n.
Такой подсчет встречается у более специализированных устройств. Когда в pipeline обрабатывается уже содержимое на следующем уровне стека.
Например, summary график mitigation из Arbor TMS при TCP SYN Flood
Если смотреть на графики, то метрики атаки ~105 Kpps ~33,7 Mbps
Обычно при SYN Flood размеры IP Headres = 20Bytes и TCP Headers = 20 Bytes, в сумме 40 Bytes.
Расчеты на калькуляторe (линк с установленными значениями) показывают, что подсчет идет на L3 уровне. На физическом уровне использование линка 70,56 Mbps.
По-видимому, в этом случае можно будет наблюдать ситуацию, когда 10 GbE линк забит, а на графике всего 4,76 Gbps (сейчас не проверял).