Что вас ждёт в статье:
Введение
1. Подготовка стенда и установка инструментов на macOS
2. Создание файла кастомных правил и сигнатур
3. Запуск Suricata и проверка детекта TCP SYN-флуда
4. Настройка кастомного правила против ICMP-флуда
5. Запуск Suricata и проверка детекта ICMP-флуда
Заключение
Введение
Первая часть здесьИтак, друзья, раз вы дочитали первую часть и разобрались с тем, как работают DDoS-атаки на сетевых уровнях, — пора переходить к практике. Пора перейти от схем TCP/IP и устроить DDoS своими руками и посмотреть, как выглядит защита.
Самое крутое, что для проведения полноценного исследования сетевой безопасности вам не понадобятся дата-центры, дорогие корпоративные роутеры, аппаратные коммутаторы или облако арендованных серверов. Весь необходимый лабораторный стенд мы развернем прямо на вашем рабочем персональном компьютере. Мы будем выступать и в роли атакующих, и в роли защитников: самостоятельно спроектируем сигнатуры безопасности, запустим контролируемую лавину пакетов и сами же её поймаем. Для разворачивания программного обеспечения мы будем использовать менеджер пакетов Homebrew.
Поехали!
1. Подготовка стенда и установка инструментов на macOS
Чтобы провести сетевую атаку «сами на себя» без риска нарушить работу сторонних ресурсов в интернете или вызвать подозрения у вашего интернет-провайдера, мы задействуем локальный сетевой интерфейс петли (lo или localhost). Его уникальность заключается в том, что весь трафик, отправленный на адрес 127.0.0.1, не покидает пределы вашего процессора и сетевого стека операционной системы. Пакеты мгновенно разворачиваются на уровне ядра и возвращаются обратно, что делает локальную петлю идеальным, абсолютно безопасным и при этом невероятно высокоскоростным полигоном для тестирования систем обнаружения вторжений под высокими пакетными нагрузками.Для управления программным обеспечением откройте терминал и установите актуальную систему обнаружения вторжений Suricata версии 8.x. Установку мы производим через экосистему Homebrew, что позволит развернуть свежий бинарный файл изолированно от основных системных директорий ОС. Выполните одну простую команду: brew install suricata
После того как Homebrew загрузит все необходимые зависимости, скомпилирует исполняемые файлы и завершит установку в свое выделенное дерево каталогов, нам необходимо верифицировать результат. Для этого проверим успешность инсталляции и текущую мажорную версию движка в системе с помощью команды: suricata -V
В ответ терминал должен выдать официальную строчку с подтверждением, например: This is Suricata version 8.0.5 RELEASE. Это означает, что исполняемый файл успешно прописался в системных путях окружения и ядро системы безопасности готово к обработке низкоуровневых сигнатур.
2. Создание файла кастомных правил и сигнатур
Движок Suricata представляет собой мощный аналитический процессор, но сам по себе он не знает, какой трафик является легитимным, а какой — враждебным. Ему необходимы наборы правил (сигнатур), по которым он будет производить побитовую сверку проходящих пакетов. Чтобы не ковырять вручную огромный дефолтный файл конфигурации suricata.yaml, который содержит тысячи строк параметров и легко ломается из-за одного неверного пробела в разметке YAML, мы применим профессиональный подход. Мы создадим свой собственный, изолированный и чистый файл правил local.rules и скормим его движку напрямую через аргументы командной строки при запуске.Поскольку утилита ставилась через Homebrew, все конфигурационные директории изолированы внутри рабочей папки менеджера пакетов по пути /opt/homebrew/etc/ (или /usr/local/etc/ в зависимости от архитектуры вашего процессора). Откроем текстовый редактор Nano для создания и редактирования нашего файла правил: nano /opt/homebrew/etc/suricata/local.rules
Перед вами откроется пустой экран текстового редактора. Вставьте в файл следующую сигнатуру, строго контролируя, чтобы вся запись легла в одну строку без принудительных переносов и разрывов: alert tcp any any -> any any (msg:"DDoS ATTACK: SYN-Flood Detected!"; flags:S; threshold:type threshold, track by_dst, count 100, seconds 1; sid:1000001; rev:1; )
Давайте подробно разберем внутреннюю архитектуру этого правила, чтобы понимать, как работает система:
alert tcp — Если критерии совпадают (в нашем случае tcp), движок обязан немедленно сгенерировать алерт и записать событие в лог-файл.
any any -> any any — Обозначает сетевые адреса и порты источника и назначения. Конструкция any any означает, что мы перехватываем пакеты с абсолютно любого IP-адреса и любого порта, направляющиеся на любой локальный хост и порт. Это избавляет нас от ручной привязки к конкретным домашним подсетям.
msg:"DDoS ATTACK: SYN-Flood Detected!" — Текстовое сообщение, которое отобразится в логах и на дашборде администратора безопасности, мгновенно объясняя природу инцидента.
flags:S; — Проверяет только пакеты с флагом SYN (запросы на подключение).
threshold:... count 100, seconds 1 — Реагирует только в том случае, если на один и тот же адрес назначения прилетело больше 100 таких пакетов за 1 секунду.
sid:1000001; — уникальный номер нашего правила.
3. Запуск Suricata и проверка детекта TCP SYN-флуда
Переходим к этапу инициализации защиты. Мы будем запускать Suricata вручную через терминал, передавая ей параметры напрямую. Флаг -c указывает путь к основному конфигурационному файлу, развернутому через Homebrew, флаг -S принудительно заставляет движок использовать наше свежее кастомное правило в обход остальных баз, а флаг -i намертво привязывает сетевой анализатор к локальной петле интерфейса (в зависимости от вашей системы пишем lo или lo0).В первом окне терминала введите следующую команду для старта: sudo suricata -c /opt/homebrew/etc/suricata/suricata.yaml -S /opt/homebrew/etc/suricata/local.rules -i lo0
При старте Suricata подгружает конфигурацию, инициализирует наше кастомное правило против SYN-флуда и переходит в режим мониторинга трафика.
Утилита потребует права суперпользователя, поэтому введите ваш пароль и нажмите Enter. На экране побегут служебные строчки инициализации модулей. Дождитесь, пока в самом низу не загорится зеленая строка: i: threads: ... Engine started.. Это наш главный маркер — ядро запущено, анализатор работает на всю мощность вашего процессора и пассивно слушает локальный трафик. Оставьте это окно открытым, ни в коем случае не закрывайте его.
Чтобы наблюдать за результатами работы детектора, откройте второе окно терминала. Нам нужно запустить непрерывное чтение файла алертов. Для этого используем стандартную утилиту tail с флагом -f, указывая путь к логам внутри изолированной директории Homebrew:
tail -f /opt/homebrew/var/log/suricata/fast.log
На экране будет пусто, ибо это обычно состояние системы, в которой отсутствует аномальный сетевой шум. Теперь пришло время сымитировать атаку, откройте третье окно терминала, там сгенерируем SYN-флуд без использования стороннего софта. Мы напишем многопоточный скрипт генерации TCP-соединений на python. Скопируйте и запустите команду:
python3 -c "import socket; [socket.socket(socket.AF_INET, socket.SOCK_STREAM).connect_ex(('127.0.0.1', 80)) for _ in range(100000)]"
Этот скрипт мгновенно порождает 50 независимых вычислительных потоков, каждый из которых в бесконечном цикле на максимальной скорости процессора пытается открыть TCP-сессию на локальный порт 80. терминал со скриптом визуально замрет. Мгновенно переключитесь во второе окно, где у нас запущен мониторинг логов. Вы увидите, как экран с большой скоростью заполняется строками: [] [1:1000001:1] DDoS ATTACK: SYN-Flood Detected! [].
Наше первое кастомное правило успешно справилось со своей задачей на транспортном уровне (L4). Чтобы остановить эту лавину и разгрузить систему, перейдите в третье окно с Python-скриптом и нажмите комбинацию клавиш «ctrl + C». Затем перейдите в первое окно с запущенной Suricata и также остановите её через «ctrl + C».
4. Настройка кастомного правила против ICMP-флуда
Теперь переходим ко второму вектору — атаке сетевыми пингами на уровне L3. Снова откроем наш файл правил, чтобы добавить туда вторую независимую сигнатуру: nano /opt/homebrew/etc/suricata/local.rulesСпуститесь на вторую строчку и допишите туда второе правило в один ряд, без переносов (строго под нашим первым правилом для TCP): alert icmp any any -> any any (msg:"DDoS ATTACK: ICMP-Flood Detected!"; itype:8; threshold:type threshold, track by_dst, count 50, seconds 1; sid:1000002; rev:1; )
Давайте подробно разберем специфику этой новой сигнатуры и поймем, чем она отличается от первой:
alert icmp — Переключает аналитический движок на работу с сетевым уровнем и протоколом межсетевых управляющих сообщений ICMP.
itype:8; — Фильтрует только пакеты Echo Request (тот самый входящий пинг).
threshold:type threshold, track by_dst, count 50, seconds 1 — Счетчик интенсивности. Мы разрешаем единичные диагностические проверки нашей сети, но, если на адрес назначения прилетает более 50 пинг-запросов за одну секунду, это классифицируется как аномальный шквал трафика и, соответственно, срабатывает алерт.
sid:1000002; — Уникальный номер нашего второго правила.
5. Запуск Suricata и проверка детекта ICMP-флуда
Перед тем как начать тестирование нового вектора атаки, нам необходимо навести порядок в нашей рабочей среде. Лог-файл fast.log является обычным текстовым файлом, в который Suricata последовательно дописывает данные, поэтому там всё еще хранятся тысячи строк от нашего предыдущего теста с Python-скриптом. Чтобы старые записи не мешали анализировать текущие результаты, обнулим лог алертов.Во втором окне терминала, где запущен мониторинг, нажмите комбинацию клавиш «ctrl + C» для остановки старого вывода. Вывод прекратится, и строка ввода станет активной. Выполните команду очистки размера файла до нуля, используя системные пути Homebrew:
sudo truncate -s 0 /opt/homebrew/var/log/suricata/fast.log
Теперь снова запустите непрерывное чтение файла с чистого листа, чтобы видеть поступающие данные в реальном времени:
tail -f /opt/homebrew/var/log/suricata/fast.log
Переходим в первое окно терминала и заново активируем наш многопоточный поисковый движок Suricata, чтобы он подгрузил обновленный файл local.rules с двумя правилами:
sudo suricata -c /opt/homebrew/etc/suricata/suricata.yaml -S /opt/homebrew/etc/suricata/local.rules -i lo0
Дождитесь зеленой надписи Engine started.. Теперь переходим в третье окно терминала для запуска атаки уровня L3. В операционную систему изначально встроен мощный диагностический инструмент ping, у которого есть скрытый экстремальный режим работы. Если запустить его с флагом -f , утилита перестанет ждать ответы от удаленного узла и начнет отправлять пакеты Echo Request непрерывно, один за другим, на максимальной физической скорости, которую способна выдать ваша система. Запустите локальный флуд пингами следующей командой: sudo ping -f 127.0.0.1
В левом окне мониторинга моментально просыпается наша вторая сигнатура, забивая лог предупреждениями DDoS ATTACK: ICMP-Flood Detected!. Атака успешно зафиксирована. Нажмите ctrl + C в окне пинга и в окне Suricata, чтобы завершить тест и вернуть процессор в состояние покоя.
Заключение
Мы это сделали! Экран терминала, забитый бегущими алертами о флуде — это лучший практический показатель того, что наши кастомные правила сработали. Мы развернули движок Suricata, развернутый через пакетный менеджер Homebrew, написали свою логику детекта, запустили многопоточный генератор трафика на Python, активировали флуд пингами и в реальном времени увидели, как автоматика вычисляет атакиКонечно, в условиях реального промышленного продакшена дежурные инженеры по безопасности не сидят перед мониторами и не смотрят на сырые логи глазами через консольную команду tail -f. Алерты скармливают продвинутым системам сбора событий и визуализации трафика, таким как ELK или Grafana, чтобы строить красивые графики плотности pps в реальном времени.
Самый главный, базовый шаг — вовремя и безошибочно обнаружить инфраструктурную угрозу на уровнях L2–L4 — вы теперь умеете делать самостоятельно.
Поздравляю с успешным завершением лабораторной работой, и пусть ваши каналы связи всегда остаются свободными от мусорного трафика!
Последнее редактирование:
