FastFlowIPs
Как всё началось
Открытый исходный код или не открытый - вот в чём вопрос.
Вечная дилемма между взять готовое с полки и написать своё в эпоху бесконечных инструментов AI только обострилась. Но стоит ли действительно писать что-то самому. Универсального ответа нет. Впрочем, если сбросить свои страхи в /dev/null, идея уже не кажется такой безумной.
Наша история началась с обновления VyOS на продакшен-маршрутизаторах до 1.5.x (circinus).
После этого и без того нервного процесса мы обнаружили, что часть правил межсетевого экрана тихо самоудалилась. И самое весёлое - на каждом маршрутизаторе это была одна и та же конкретная часть.
Так что мы нехотя открыли VyOS Project Updates, где наткнулись вот на это: FastNetMon-based service ids ddos-protection is removed from rolling and deprecated in LTS releases (T7241):
Довольно долго у нас был CLI для настройки FastNetMon - демона обнаружения DDoS. Однако эта интеграция никогда не была особенно глубокой, и путей к её существенному улучшению мы не видим.
Долгосрочный план - перевести FastNetMon в дополнение, как только мы доведём механизм, позволяющий дополнениям расширять системный CLI. Что касается встроенных компонентов, подход будет "качество вместо количества": лучше иметь меньше интеграций, которые обслуживают много пользователей и хорошо сочетаются друг с другом, но дать всем возможность установить или разработать интеграции под собственные нужды.
Проблема не была ни сверхсрочной, ни критической, но как брокеру IPv4 и хостинг-провайдеру такой мониторинг нам был нужен. Поэтому мы решили действовать немедленно.
Пройдя типичный цикл - отрицание, гнев, торг, - мы наконец приняли утрату service ids ddos-protection и попробовали воскресить FastNetMon Community вручную. Вот тут подступила депрессия. Версия Community отказалась устанавливаться по причинам, которые, будем честны, все и так подозревали. А покупать коммерческую версию никто не спешил.
Проблема не была катастрофической, но для нас как брокера IPv4 и хостинг-провайдера такой мониторинг был необходим. Так что решение было очевидным: действовать немедленно.
FastNetMon: мы тебя любим, но...
Наши отношения с FastNetMon начались не так давно, но инструмент быстро покорил наши сердца и приносил реальную пользу - даже при том, что стабильно съедал около 30% процессора.
Видимость трафика была идеальной, Grafana светилась метриками, и жизнь казалась чуть спокойнее.
А теперь? Теперь мы смотрим на пустые панели трафика и почему-то добровольно выбираем путь "усложни себе жизнь". Ну... не добровольно. Скорее по принуждению. И, как обычно, все недостатки начинаешь припоминать только когда что-то теряешь.
В целом FastNetMon оправдал наши ожидания и даже превзошёл их.
Но при всех плюсах он собирал огромную гору совершенно ненужных данных, превращая панели в шумный карнавал цифр и графиков. Плюс та самая нагрузка на процессор: не катастрофическая, но достаточно раздражающая. Так что твёрдого "да" или "нет" у нас так и не сложилось. Душа просила простоты и легкости, а не очередной подписки и тонкой настройки каждый раз, когда инструмент чихнёт.
Идея написать своё пришла не сразу. Битва за FastNetMon продолжалась - мы даже пытались оживить его, вытащив старый двоичный файл с другого сервера. Да, подход был сомнительный, но он сработал: FastNetMon вернулся к жизни. Только... радости в этом не было.
Ощущение было такое, будто мы сшили набитое чучело давно ушедшего питомца: технически стоит, смутно узнаваемо, но жить с этим было... неуютно.
Так что мы дружно решили: так продолжаться не может. И тогда мы начали строить собственный защитник от DDoS на своём мониторинге, с блэкджеком и минимальной нагрузкой на процессор.
А дальше всё завертелось
Итак, началась разработка собственного инструмента. Лучшие умы команды плюс, конечно, пара моделей AI подключились к брейнштормингу, и так появился FastFlowIPs. FastFlowIPs - высокопроизводительный инструмент сетевого мониторинга на eBPF, который в реальном времени отслеживает статистику трафика по каждому IP. Он спроектирован для продакшен-сред с минимальными накладными расходами.
Основная идея проста: он снимает сетевой трафик через eBPF, считает статистику по каждому IP (PPS, Мбит/с) и умеет автоматически блокировать адреса, которые превышают настраиваемые пороги. Метрики выгружаются по протоколу Graphite и прекрасно совпадают с тем, чего ждёт Grafana. Панели получаются чистыми, легкими и быстро собираются.
FastFlowIPs запускается одной строкой, где вы задаёте -min-ips-pps и -min-flow-pps, чтобы выгружать только самые осмысленные метрики, плюс сеть и интерфейс для наблюдения. Единственное обязательное требование - явно указать -graphite-host и -graphite-port, если вы хотите отправлять метрики.
Вдобавок FastFlowIPs оптимизирован под нагруженные сети:
на 75% меньше операций с мьютексами, на 60% быстрее работа со строками по сравнению с типичными реализациями.
Пример конфигурации ниже:
# Интерфейс и основное
-interface eth0 # Сетевой интерфейс (по умолчанию: eth0)
-interval 5s # Интервал сбора
-show-stats # Показывать периодические таблицы
-verbose # Подробное журналирование
# Фильтрация по сети
-networks "192.168.1.0/24" # Наблюдать только за указанными сетями
# Пороги блокировки адресов
-ban-pps-rx 1000 # Блокировать при приёме > 1000 PPS
-ban-pps-tx 500 # Блокировать при отправке > 500 PPS
-ban-mbps-rx 100 # Блокировать при приёме > 100 Мбит/с
-ban-mbps-tx 50 # Блокировать при отправке > 50 Мбит/с
-ban-time 5m # На сколько блокировать
-ban-script /path/script.sh # Скрипт, выполняемый при блокировке и разблокировке
# Выгрузка в Graphite
-graphite-host localhost # Сервер Graphite
-graphite-port 32003 # Порт Graphite
-min-flow-pps 10 # Выгружать только потоки > 10 PPS
-min-ips-pps 5 # Выгружать только адреса > 5 PPS
Никак нельзя было обойти режимы наблюдения - они позволяют настроить этот скромный инструмент под свой личный вкус:
- Тихий режим (по умолчанию): показывает только события блокировки и сообщения при запуске. Идеально для продакшена.
- Режим статистики (-show-stats): печатает периодические таблицы трафика, отсортированные по объёму.
- Подробный режим (-verbose): детальное журналирование, включая статистику выгрузки в Graphite.
И вишенка на торте - скрипт блокировки, который безжалостно блокирует любую подозрительную активность, перешедшую заданные пороги:
/path/to/script.sh ban 192.168.1.100 # IP превысил порог
/path/to/script.sh unban 192.168.1.100 # Блокировка истекла
Простой пример на iptables:
#!/bin/bash
case $1 in
ban) iptables -I INPUT -s $2 -j DROP ;;
unban) iptables -D INPUT -s $2 -j DROP 2>/dev/null ;;
esac
Но в любом случае скрипт всегда можно поправить и сделать его более или менее агрессивным - как требует ваша инфраструктура.
И пара слов о Graphite и метриках. Панель в Grafana собирается за считанные минуты на двух основных типах метрик:
Метрики потоков: **network.flows.{SRC_IP}*to*{DST_IP}.{pps,mbps}.{rx,tx}**
Метрики адресов: **network.ips.{IP_ADDRESS}.{pps,mbps}.{rx,tx}**
Больше подробностей о FastFlowIPs есть в самом репозитории: https://github.com/denisix/fastflowips, и вы всегда можете поддержать автора или поучаствовать в развитии этого небольшого, но уже могучего инструмента.
Архитектура в 3 абзацах (без страданий)
Если описать инструмент человеческим языком, внутри это аккуратный небольшой сервис на Go, который слушает пакеты NetFlow, разбирает их на составляющие и строит простую статистику по каждому адресу: pps, mbps, входящий и исходящий - то есть кто шумит в сети и почему. Вся математика делается на ходу: Go идеально подходит для таких лёгких, но высокопроизводительных операций.
Данные собираются в небольшие структуры в памяти, сортируются и периодически отправляются наружу: либо в Graphite и Grafana, либо в любой другой приёмник, который вы укажете. Блокировка адресов внешним скриптом реализована через пороги PPS и Мбит/с и вызов BanScript - на случай, если кто-то внезапно решит устроить небольшой локальный праздник DDoS.
Самое приятное: это один чистый двоичный файл без горы зависимостей и без обычного "ада мелкого открытого проекта". Настройки передаются флагами, статистика собирается напрямую, логика прозрачная. В итоге у нас получился легкий и честный инструмент, который делает ровно то, что нам нужно - без излишней магии и без тяжёлых демонов в комплекте.
Результаты через пару дней
Отладка оказалась куда длиннее и сложнее, чем написание самого инструмента. Сначала мы вообще не собирались задавать FastFlowIPs пороговые значения, поэтому несколько раз (много) Grafana нервно затаивала дыхание под объёмом метрик и вовсе отказывалась их нам показывать. В легенде панели было столько адресов, что её можно было прокручивать часами и, скорее всего, так и не добраться до конца. Мы просчитались - но где?
Отладка то ломала всё, то стабилизировала, то снова ломала нашего измученного FastFlowIPs, пока он не начал тихо плакать на краевых случаях. Метрик было либо слишком много, либо слишком мало, либо не было совсем. Видимо, от эмоциональной перегрузки. Вдобавок самой большой загадкой для нас оказались метрики Flows RX/TX, которые слегка перепутались местами, что прекрасно было видно в реальном времени на маршрутизаторах VyOS. С этим боролись лучшие умы нашей команды, и в итоге цель была достигнута: метрики стабилизировались, а Grafana излечилась от астмы.
Сегодня у нас аккуратные, чистые и информативные метрики, которые показывают ровно тот сетевой трафик, который нам нужен:
Когда пора собирать собственный мини-FastNetMon
Изобретать свои велосипеды - плохо. До того момента, когда без велосипеда просто не сдвинуться с места.
Писать свой инструмент имеет полный смысл, когда готовые решения либо слишком тяжёлые, либо слишком умные для вашей конкретной задачи. Когда вам не нужны 100500 функций, интеграции с космической станцией и панели на 19 мониторов - когда вам нужны просто цифры, быстро и без мигрени.
Своё решение стоит рассмотреть и тогда, когда ситуация требует гибкости: нужно добавить метрику на ходу, встроить собственную логику против DDoS, заставить мониторинг дружить с вашим причудливым оборудованием или просто обойти ограничения, которые внезапно убрали из любимой прошивки (тёплый привет VyOS 1.5).
Коротко говоря, писать своё - это про контроль, скорость, минимализм и независимость от компонентов, которые внезапно исчезают из репозиториев. Главное - помнить золотое правило: если можно сделать проще, делайте проще.
И ещё одно правило: если работает - не трогайте.
Большой финал
В конце концов вся эта история не про трафик, не про DDoS и даже не про FastNetMon.
Она про то, что иногда команда просто хочет инструмент, который работает, не ломается после обновления и не превращает жизнь в повтор "Побега из Шоушенка".
Мы не переизобретали велосипед - мы собрали собственный маленький самокат, который идеально подходит под нашу дорогу. И в этом нет ничего плохого. В мире, где огромные открытые проекты живут своей непредсказуемой жизнью, приятно иметь что-то своё - знакомое, стабильное и восхитительно скучное.
Так что если вы когда-нибудь смотрели на очередной "идеальный, но чуть слишком идеальный" инструмент и думали: "честно, проще написать самому" - возможно, вы и правда на верном пути.
Только делайте это умно, с тестами... и будьте готовы немного пострадать.
