По следам подкаста telecom №87. FastNetMon. Обнаружение DDoS Павел Одинцов приготовил текстовую версию, которая тянет на отдельную небольшую статью. Публикуем её по согласию с автором.

Всем привет!
Я Павел Одинцов, один из авторов проекта FastNetMon, мы занимаемся разработкой решения для обнаружения DDoS атак.

О чём:

1. Краткое введение про инструмент FastNetMon
2. Алгоритм работы FastNetMon
3. Гибридная модель отражения атак с использованием BGP Unicast и BGP Flow Spec
4. Классификация видов телеметрии и краткий обзор
5. Протокол Netflow, обзор, его особенности и недостатки для целей обнаружения атак
6. Особенности реализации Netflow на крупных сетях, сэмплирование
7. Протокол sFlow v5, обзор, его особенности и преимущества для целей обнаружения атак, проблемы реализации у вендоров.
8. Детальный анализ трафика с port mirror / SPAN порта на Linux
9. Почему AF_PACKET v3 выигрывает у других библиотек для обработки трафика?
10. Обзор возможных способов экспорта телеметрии в публичных облаках, обзор Amazon и Google
11. Подведение итогов

FastNetMon представляет собой DDoS детектор базирующийся на пороговых значениях трафика. Пороговые значения в данном случае — это уровень трафика в пакетах секунду или байтах секунду для заданного типа трафика, который представляют угрозу сети и при превышении которого требуется выполнить какое-либо действие, обычно это отправка BGP Unicast или BGP Flow Spec анонса.
У нашего продукта имеется две версии — community и advanced, community edition распространяется в виде решения с открытым исходным кодом и доступна для установки из стандартных репозиториев таких дистрибутивов Linux как Ubuntu и Debian, для остальных платформ мы предоставляем установочный скрипт. Advanced edition предоставляет расширенные возможности и позиционируется как решение для крупного бизнеса.
Основной платформой для нашего решения является Linux, но обычно конфигурация Linux не вызывает проблем и не занимает много времени, а вот с конфигурацией сетевой телеметрии на стороне сетевого оборудования приходится изрядно повозиться.
С точки зрения вариантов размещения инфраструктуры я бы начал с разделения телеметрии на on-premise и облачную. В первом случае мы имеем полный физический доступ к сетевой инфраструктуре, а во втором мы будем обсуждать реализацию сетевой телеметрии в публичном облаке используя инструменты предоставляемые вендором облака.
Основные варианты доставки трафика для аналитики on premise:

• Netflow и протоколы на его базе (jFlow, cFlow, Netstream), IPFIX
• sFlow
• SPAN / Mirror

Самый популярный и широко распространенный протокол — это, разумеется, Netflow. Безусловно, при разработке этого протокола было учтено множество требований возникающих в процессе аналитики трафика, постаремся остановится на специфике использования протокола Netflow для задачи обнаружения атак.
Протокол Netflow подразумевает, что на стороне сетевого оборудования (обычно роутера) выполняется трекинг потоков и для каждого уникального пакета (обычно с точки зрения 5 tuple: source port, source ip, destination port, destination ip, protocol) попадающего в нашу сеть или покидающего ее в памяти роутера создается элемент.
Как только мы начали говорить о памяти, сразу стоит подчеркнуть, что мы говорим о конечном ресурсе, а сама суть DDoS атак строится на исчерпании какого-либо конечного ресурса (обычно — сетевой ёмкости, но также это могут быть и вычислительные ресурсы роутера). Это один из первых недостатков данного протокола для целей обнаружения атак, так как он сам по себе может служить источником перегрузки сетевого оборудования.
В процессе трекинга потоков внутри роутера возникает еще одна крайне нежелательная для обнаружения атак особенность — задержка между моментом, когда роутер увидел пакет и временем, когда он будет доставлен на коллектор, в данном случае — FastNetMon.
К сожалению, у ряда вендоров стандартная конфигурация таймаута потоков установлена в очень большие значения, нередко достигающие десятков минут. Учитывая что специфика современных атак такова, что атака может разогнаться до сотен гигабит за минуты, это непозволительный риск.
Кроме этого, большинство вендоров может передавать очень ограниченный объем информации о трафике в телеметрии и часто нужная информация, содержащаяся за пределами IP / UDP / TCP заголовка там отсутствует.
Основной способ решения проблем с перегрузкой таблицы потоков — это использование сэмплинга. Например, для 10G порта можно ожидать очень точных результатов при использовании сэмплинга 1 к 1024. Из нашего опыта, бОльшая часть крупных инсталляций использует сэмплирование.
При этом, к сожалению, теряется возможность фиксации низкоскоростных атак, а также нет возможности использования информации о трафике для целей детального аудита.
Сэмплирование — очень мощный инструмент, который почти не имеет недостатков для целей обнаружения атак.
Но, как и всегда, у каждого решения есть определенные проблемы с точки зрения эксплуатации. Из-за довольно высокой сложности таких протоколов как Netflow v9 и IPFIX, с точки зрения зрения коллектора очень сложно автоматически получить информацию о текущей частоте сэмплирования, так как различные вендоры используют различные подходы к вариантам кодирования данной информации и нередко может потребоваться ручная конфигурация частоты сэмплирования на стороне коллектора.
Если в протоколе Netflow сэмплирование является опциональной возможностью, то мой любимый протокол — sFlow изначально строится на нем. Основным преимуществом протокола является почти полное отсутствие информации о состоянии и каких-либо таблиц потоков. Также сам протокол содержит всю необходимую информацию для декодирования прямо в пакете, включая частоту сэмплирования. На этом преимущества не заканчиваются, также в пакете содержатся первые Х байт (от 60 до 140) заголовка пакета, которые очень помогают для целей обнаружения атак.
Все звучит просто прекрасно и именно то, что нужно для целей обнаружения атак. И это полностью соответствует нашему опыту использования данного протокола среди десятков тысяч наших клиентов. При наличии возможности съема телеметрии в формате sFlow мы рекомендуем использовать именно этот режим захвата трафика.
Какие возможны проблемы? Безусловно, не бывает, чтобы все работало так, как ты ожидаешь. Одной из основных проблем sFlow являются реализация sFlow агента на роутере или свитче. Многие вендоры используют крайне жестокие значений лимитов числа пакетов sFlow, которые могут быть отправлены устройством, что ведет к быстрой перегрузке и пропаданию информации о трафике либо к автоматическому увеличению частоты сэмплирования до огромных значений, когда даже гигабитная атака может быть пропущена, а о корректном расчете скоростей трафика для узлов в сети даже не стоит говорить.
Но есть вендоры, которые превзошли все возможные границы дозволенного и просто-напросто не позволяют задать частоту сэмплирования, которая бы обеспечила более-менее корректный расчет скоростей трафика, что сводит на нет возможность использования определенных моделей сетевого оборудования для задачи обнаружения атаки.
Какие есть варианты, если по тем или иным причинам оба описанных варианта нам не подходят?
Итак, мы плавно возвращаемся от сетевого оборудования к Linux, который поможет нам справится с задачей. Почти любой роутер или свитч имеет возможность зеркалирования трафика порта, которая переключает один из портов в режим мониторинга, когда копии трафика со всех заданных портов доставляются в него. Даже если ваше сетевое оборудование этого не умеет, то остается всегда действенный вариант установки оптических делителей, которые осуществят ту же задачу, но уже на уровне среды передачи.
Итак, мы доставили копию трафика нашей сети на машину с Linux. Я уже слышу недовольные вопросы про зеркалирование портов 100G и выше! Да, в этом случае нам понадобится идти на ухищрения и использовать возможности роутеров и свитчей, которые могут позволить нам отбросить часть трафика посредством сэмплирования и доставить лишь его часть в порт.
Итак, мы получили трафик на порту нашей машины с Linux, но как мы его будем анализировать? Во-первых, на данном этапе я рекомендую по возможности использовать самые актуальные стабильные / LTS версии Linux дистрибутивов Ubuntu или Debian, так как сетевой стек ядра Linux находится в состоянии постоянной доделки и, используя более новую версию, вы совершенно бесплатно получаете прирост производительности.
В нашем проекте FastNetMon мы поддерживаем множество режимов захвата трафика из порта, такие как

• PF_RING
• Netmap
• AF_PACKET
• Snabb

Часть из них требует лицензии, часть из них требует сборки драйверов сетевой карты с патчами, которые в свою очередь крайне сложны в поддержке.
Какой же режим захвата трафика наш любимый? Это, безусловно, AF_PACKET! Что же в нем особенного? Основное его преимущество, что он не требует никаких зависимостей и по умолчанию поддерживается в любом современном дистрибутиве Linux. Каких скоростей работы стоит от него ожидать? Согласно нашим тестам, можно ожидать до скоростей довольно близких к line rate 10G порта, из последних тестов нам удалось добиться почти 9 Mpps. Разумеется, всегда сохраняется возможность сегментации и кластеризации, чтобы обработать больше трафика.
Теперь мы плавно переходим от on-premise к публичным облакам. Почти все вендоры большой тройки облаков предоставляют возможность зеркалирования всего трафика заданного VPC в порт мониторинга, на котором может быть запущен совершенно стандартный FastNetMon с тем же AF_PACKET, который мы восхваляли выше. Но как и все в мире облаков, этот полход имеет свои недостатки — цена, которая часто может превышать все преимущества от наличия решения по мониторингу трафика и фиксации атак. В случае портов мониторинга — она может быть очень существенная.
Как более демократичное и масштабируемое решение часто вендоры предлагают VPC Flow Logs, которые в своей сути похожи на телеметрию в формате Netflow. К сожалению, вендоры облаков решили не идти по пути использования таких стандартных сетевых протоколов как IPFIX и изобрели свои собственные, к сожалению, не лишенные недостатков. Как и в случае зеркальных портов недостаток — это увеличение цены, но в данном случае оно косвенное.
Обычно, включить VPC flow logs можно либо очень дёшево либо бесплатно, но вот чтобы их передавать в коллектор, уже потребуется приобретение дополнительного функционала хранения / обработки логов, а также реализация решения передающего телеметрию на коллектор используя lambda / function или же распределенных очередей. Итоговая цена может быть весьма ощутимой, поэтому рекомендую всегда быть очень аккуратным с этим моментом.
Как другие недостатки VPC Flow логов я бы упомянул, что часто они не имеют поддержки протоколов TCP/UDP, что делает обнаружение атак не таким эффективным как в случае on-premise.

Как мы обсудили в статье, телеметрия является неотъемлемым компонентом современных сетей и даже если не требуется решение проблемы с DDoS, она позволяет увидеть множество проблем до того, как они приведут к аварии.