devinblack001/ddos-reduction-systemАдаптивный двухэтапный шлюз для защиты от DDoS-атак на уровне L4, использующий поведенческий анализ трафика, классификацию методом случайного леса и принудительное применение правил на уровне ядра через ipset/iptables.
Первая линия обороны
Адаптивный двухступенчатый шлюз для смягчения объёмных DDoS-атак на уровне 4.
Автор: Abdullah Armiyao
Проект: Adaptive Two Stage Framework for Near Real Time Layer 4 Volumetric DDoS Mitigation Using Behavioral Traffic Analysis
Большинство систем защиты от DDoS используют фиксированные пороги: блокируют всё, что отправляет больше некоторого жёстко заданного числа пакетов в секунду. Это не работает в обоих направлениях. Легитимный всплеск трафика в часы пик приводит к блокировке реальных пользователей, либо атакующий остаётся чуть ниже порога и проходит.
FLOD изучает, как выглядит ваш обычный трафик, и сдвигает собственные границы обнаружения в соответствии с ним. Он отличает DDoS-флуд от всплеска легитимных запросов (flash crowd) — законного роста нагрузки — без ручной настройки порогов.
Он работает в разрыве на шлюзе между источником трафика и защищаемыми хостами и сбрасывает или ограничивает нежелательные источники на уровне ядра.
Панель управления указывает адреса, заблокированные как атакующие, чтобы человек, не знакомый с топологией сети, мог определить, какие отправители были враждебными. Адреса с ограничением скорости перечислены отдельно, поскольку ограничение скорости также используется как предупредительная мера и применяется сразу к целым группам.
Ступень 1 — это сенсор на Rust на пути прохождения пакетов. Он захватывает каждый пакет, направленный к защищаемому хосту, вычисляет скорость и разнообразие источников на коротких окнах и сравнивает их с базовой линией, которую поддерживает самостоятельно. Он выполняет только арифметические операции, поэтому не мешает трафику.
Ступень 2 — это сервис на Python. Он получает сводку от Ступени 1 раз за окно, классифицирует её с помощью Random Forest и применяет меры на уровне ядра через ipset и iptables. Параллельно на каждом окне работает Isolation Forest, помечающий трафик, не похожий ни на что, что изучила любая из моделей, и отображаемый как отдельное состояние Anomalous, а не влияющий на применение мер. Ступень 2 также обслуживает веб-панель управления.
Они соединены через Unix domain socket.
FLOD работает с объёмными флудами уровня 4, видимыми только по заголовкам пакетов: скорость, энтропия исходных IP, сочетание протоколов и то, насколько трафик сконцентрирован на самом нагруженном источнике. На практике это означает флуды, которые одновременно являются высокообъёмными и сконцентрированными, поступающими от ограниченного набора реальных адресов.
Одна вещь явно вне области применения, и одна решается частично:
Атаки на уровне приложений. Содержимое запросов не анализируется, поэтому низкоскоростные и медленные флуды запросов и исчерпание соединений находятся за пределами того, что может наблюдать набор признаков, основанный только на заголовках.
Рандомизированная подмена источника. Подделка нового исходного адреса для каждого пакета повышает энтропию, а не понижает её, инвертируя сигнал, который ищут признаки на основе адресов. Энтропия исходных портов, дисперсия TTL и разнообразие отпечатков TCP SYN инвариантны относительно подмены адресов и закрывают это слепое пятно обнаружения, но обнаружение поддельного флуда — более узкая задача, чем его остановка: блокировка поддельного адреса всё равно наказывает того, кто на самом деле им владеет, поэтому безопасное применение мер против этого класса остаётся открытым вопросом. См. Detection и Explainer.
git clone https://github.com/DevInBlack001/ddos-reduction-system.git
cd ddos-reduction-system
sudo bash scripts/install.sh --interface <IFACE> --victim-ips <IP1>,<IP2>
sudo systemctl enable --now ddos-stage2
sudo systemctl enable --now ddos-stage1
Установщик собирает Ступень 1, затем копирует код Ступени 2 и виртуальное окружение в /opt/flod/stage2 (принадлежащий root) и настраивает там административную учётную запись, поскольку Ступень 2 работает от root и не должна исполнять что-либо из рабочей копии, в которую непривилегированная учётная запись всё ещё может писать. Изменяемое состояние — база данных, конфигурация JSON, обученные модели — находится в /var/lib/flod. Сама рабочая копия с этого момента является лишь источником; повторный запуск scripts/install.sh или scripts/update.sh обновляет установленную копию из неё. Причины описаны в Security.
Панель управления доступна на порту 8000 по HTTPS после установки самоподписанного сертификата установщиком. Полные инструкции, включая сетевую топологию, от которой это зависит, находятся в wiki.
Установщик также настраивает инструментарий сборки eBPF, когда это возможно, под ту версию LLVM, которую поставляет ваш дистрибутив. Эта часть необязательна: без неё сенсор всё равно собирается и работает на libpcap.
У сенсора два бэкенда захвата. libpcap используется по умолчанию и работает везде. При наличии инструментария --capture-mode kernel подсчитывает пакеты в пути драйвера через XDP и TC, пробуждая пользовательское пространство раз за окно, а не раз за пакет. Обнаружение в обоих случаях идентично.
Настройка обнаружения измеряется, а не угадывается. scripts/calibrate.py читает собственный лог сенсора, выбирает образцы обычного трафика и определяет, где должны находиться границы аномалий в вашей сети.
Чтобы попробовать без установки, запустите из рабочей копии:
sudo bash scripts/run.sh
Он запрашивает каждое необходимое значение, предлагает значение по умолчанию для каждого и спрашивает, запускать ли также Ступень 2. Добавьте --defaults, чтобы принять всё без запросов.
Чтобы запустить наборы тестов:
scripts/test.sh
Wiki — для запуска системы:
| Страница | Содержание |
|---|---|
| Installation | Требования, размещение в сети, первый вход |
| Configuration | Флаги сенсора, настройка применения мер, оповещения |
| Dashboard Guide | Каждая страница консоли |
| Troubleshooting | Когда что-то не работает |
docs/ — для понимания или изменения системы:
| Документ | Содержание |
|---|---|
| Architecture | Конвейер, многопоточность, настройка захвата, измерение исходящего трафика |
| Detection | Welford, EWMA, энтропия, границы аномалий, сохранение базовой линии |
| Explainer | Каждый термин и каждое поле формата передачи, объяснённые для нетехнического читателя |
| IPC | Формат передачи вектора признаков |
| Enforcement | Классификация, четыре уровня смягчения, обработка NAT |
| Training | Захват размеченных данных и обучение модели |
| Testing | Запуск обоих наборов тестов |
| Security | Этап усиления защиты и модель угроз |
| Roadmap | Завершённые и запланированные версии |
| Benchmark Results | FLOD против фиксированного порога: оборудование, методология, полный вывод |
| Lessons Learned | Реальные баги, найденные в ходе разработки, сохранённые ради того, что они обобщают |
CONTRIBUTING.md описывает настройку разработки и соглашения. SECURITY.md описывает порядок сообщения об уязвимостях.
Этот проект — мой собственный. Концепция, архитектура, двухступенчатый дизайн, подход к обнаружению, политика применения мер, набор признаков и каждое функциональное решение во всех версиях принадлежат мне. Я создал его как учебное упражнение по сетевой безопасности, статистическому обнаружению и системному программированию и руководил его проектированием и развитием на протяжении всего процесса.
Я использовал ИИ в качестве помощника по программированию во время реализации: он писал и рефакторил код по моим спецификациям и служил собеседником, пока я прорабатывал компромиссы в дизайне. Решения о том, что строить, зачем и как система должна себя вести, были моими.
Личный проект с открытым исходным кодом и работающая система, но не прошедшая состязательное тестирование, необходимое для production-продукта безопасности. Разворачивайте её в лабораторной сети или там, где можете позволить себе, чтобы она ошибалась.
См. LICENSE.