Suricata

Введение

Suricata — это сетевой движок IDS, IPS и NSM, разработанный OISF и сообществом Suricata.

Ресурсы

• Главная страница
• Трекер ошибок
• Руководство пользователя
• Руководство разработчика
• Руководство по установке
• Форум поддержки пользователей

Участие в разработке

Мы рады принимать патчи и другие вклады. Ознакомьтесь с нашим Процессом участия, чтобы узнать, как начать.

Suricata — это сложное программное обеспечение, работающее в основном с недоверенным входным воздействием. Неправильная обработка этого воздействия повлечет серьезные последствия:

• в режиме IPS сбой может вывести сеть из строя
• в пассивном режиме компрометация IDS может привести к утечке важных и конфиденциальных данных
• пропущенное обнаружение может привести к недетектируемой компрометации сети

Другими словами, мы считаем, что ставки довольно высоки, особенно поскольку во многих распространенных случаях IDS/IPS будет напрямую доступен злоумышленнику.

По этой причине мы разработали процесс контроля качества (QA), который является весьма обширным. Следствием этого является то, что вклад в Suricata может быть somewhat длительным процессом.

В общих чертах шаги следующие:

1. Проверки на основе GitHub-CI. Они выполняются автоматически при создании запроса на слияние.
2. Обзор со стороны разработчиков из команды и сообщества.
3. Запуск тестов QA на частных стендах. Они являются частными из-за характера тестового трафика.

Обзор шагов QA Suricata

Участники команды OISF могут отправлять сборки в нашу частную систему QA. Она выполнит серию тестов сборки и набор регрессионных тестов, чтобы убедиться, что существующие функции не нарушены.

Финальные тесты QA занимают минимум несколько часов и обычно выполняются в ночное время. В настоящее время в них входят:

• обширные тесты сборки на различных ОС, компиляторах, уровнях оптимизации, конфигурациях функций
• статический анализ кода с помощью cppcheck, scan-build
• анализ кода во время выполнения с помощью valgrind, AddressSanitizer, LeakSanitizer
• регрессионные тесты для обнаруженных ранее ошибок
• проверка корректности логирования
• тестирование unix-сокетов
• тестирование на fuzzing на основе pcap с использованием ASAN и LSAN
• тестирование IDS и IPS на основе воспроизведения трафика

Помимо этих тестов, в зависимости от типа изменения кода, могут быть запущены дополнительные ручные тесты:

• тестирование воспроизведения трафика (несколько гигабит)
• обработка больших коллекций pcap (несколько терабайт)
• тестирование на fuzzing (может занять несколько дней или даже недель)
• тестирование производительности на основе pcap
• тестирование производительности в реальных условиях
• различные другие ручные тесты на основе оценки предложенных изменений

Важно понимать, что почти все вышеуказанные тесты используются как приемочные тесты. Если что-то не проходит, исправление этого лежит на вас.

Один из этапов QA в настоящее время выполняется после слияния. Мы отправляем сборки в программу Coverity Scan. Из-за ограничений этой (бесплатной) службы мы можем отправлять сборки не более одного раза в день. Конечно, после слияния сообщество может обнаружить проблемы. В обоих случаях мы просим вас помочь в решении проблем, которые могут возникнуть.

Часто задаваемые вопросы

В: Примете ли вы мой запрос на слияние (PR)?

О: Это зависит от ряда факторов, включая качество кода. В случае новых функций также зависит от того, считают ли команда и/или сообщество функцию полезной, насколько она влияет на другой код и функции, риски регрессий производительности и т.д.

В: Когда мой PR будет слит?

О: Это зависит. Если это основная функция или изменение с высоким риском, оно, вероятно, попадет в следующую мажорную версию.

В: Почему мой PR был закрыт?

О: Как описано в рабочем процессе Suricata на GitHub, мы ожидаем новый pull request для каждого изменения.

Обычно команда (или сообщество) дает обратную связь по pull request, после чего ожидается, что он будет заменен улучшенным PR. Поэтому смотрите комментарии. Если вы не согласны с комментариями, мы все еще можем обсудить их в закрытом PR.

Если PR был закрыт без комментариев, это, скорее всего, связано с ошибкой QA. Если проверки GitHub-CI завершились неудачно, PR следует исправить сразу. Нет необходимости обсуждать это, если вы не считаете, что ошибка QA неверна.

В: Компилятор/средство анализа кода/инструмент неправ, что делать?

О: Для содействия автоматизации QA мы не принимаем сохранение предупреждений или ошибок. В некоторых случаях это может означать, что мы добавим подавление, если инструмент это поддерживает (например, valgrind, DrMemory). Некоторые предупреждения можно отключить. В исключительных случаях единственным "решением" является рефакторинг кода для обхода ложного срабатывания ограничения статического анализатора. Хотя это и расстраивает, мы предпочитаем это наличию предупреждений в выводе. Предупреждения имеют тенденцию игнорироваться, а затем увеличивать риск скрытия других предупреждений.

В: Я думаю, что ваш тест QA неправилен

О: Если вы действительно так считаете, мы можем обсудить, как его улучшить. Но не делайте этот вывод слишком поспешно, чаще всего неправ оказывается код.

В: Требуется ли подписание соглашения о лицензии участника?

О: Да, мы делаем это, чтобы сохранить владение Suricata в одном лице: Open Information Security Foundation. Смотрите http://suricata.io/about/open-source/ и http://suricata.io/about/contribution-agreement/