Comments 8
А почему выбрали способ с чтением лог файла, а не перенаправлением лога в пайп?
Дает этот способ какие-то преимущества?
А то я тут на работе как раз недавно подобную вещь реализовывал, только через Kafka + Kafka Streams.
Дает этот способ какие-то преимущества?
А то я тут на работе как раз недавно подобную вещь реализовывал, только через Kafka + Kafka Streams.
Соглашаемся с тем, что вариантов передачи исходных событий от источника (в примере — веб-сервер Apache) к обработчику (ядру корреляции) известно множество. В самом начале даже предпринимались попытки использовать связку Filebeat > Logstash > RabbitMQ для этих целей (отказались по причине нетривиальности настроек). Детальное сравнение различных реализаций в рамках проекта не проводилось.
В наших условиях использование связки «простой пример приложения, отслеживающего изменения лог-файла источника данных» > RabbitMQ обусловлено в большей степени образовательными целями: познакомить слушателей с брокерами сообщений (как классом программных решений) и показать простоту реализации интерфейса в исходном коде коннектора.
В наших условиях использование связки «простой пример приложения, отслеживающего изменения лог-файла источника данных» > RabbitMQ обусловлено в большей степени образовательными целями: познакомить слушателей с брокерами сообщений (как классом программных решений) и показать простоту реализации интерфейса в исходном коде коннектора.
Я имел в виду почему аксесс лог апача читали так хитро, а не не напрямую в апачконнектор, без записи в файл httpd.apache.org/docs/2.4/logs.html#piped
Задача принимается к проработке в последующих релизах, спасибо!
Интересная статья, спасибо!
1. Можете рассказать, почему выбрали именно такой стенд с веб-сервером, не, например, авторизацией в Windows?
2. Почему именно такие продукты для разработки выбраны?
3. Почему архитектура SIEM получилась именно такая, а не какая-то другая?
4. Почему не взяли сразу готовый стек продуктов ELK (там меньше разработки, имхо, надо сложить конструктор в единое целое)?
1. Можете рассказать, почему выбрали именно такой стенд с веб-сервером, не, например, авторизацией в Windows?
2. Почему именно такие продукты для разработки выбраны?
3. Почему архитектура SIEM получилась именно такая, а не какая-то другая?
4. Почему не взяли сразу готовый стек продуктов ELK (там меньше разработки, имхо, надо сложить конструктор в единое целое)?
Пробуем коротко и по порядку:
1. Среди десятка разных источников событий и коннекторов предложенный в примере вариант c веб-сервером показался нам наиболее удачным. В итоговом сценарии открываем одновременно 4 окна: 1 — окно браузера с тестовым веб-приложением, 2 — окно коннектора, 3 — окно ядра корреляции, 4 — окно с консолью администратора. И слушатели, самостоятельно моделируя перебор пароля, наблюдают взаимосвязь разработанных компонентов и «превращение» отдельных событий безопасности в инцидент. Возможно субъективно, но пример с авторизацией в Windows кажется менее наглядным. Хотя, когда остается время и аудитория подготовленная, после предложенного ApacheConnector довольно быстро появляются и WMIConnector, и MysqlConnector, и SSHConnector, и другие.
2. XAMPP — быстро. MongoDB — чтобы познакомить с NoSQL/NewSQL. RabbitMQ — чтобы познакомить с брокерами сообщений на примере одного из самых популярных. PHP и C# — личные предпочтения.
3. Архитектура заимствована из известных источников (см. по тексту публикации). Наша задача состояла в том, чтобы с минимальными расхождениями продемонстировать рабочий пример, поясняющий суть процесса обработки событий безопасности. Эксперты, конечно же, заметят отличия (например, нормализация у нас реализована рядом с ядром корреляции, а по-хорошему нужно сдвигать ближе к коннектору), но спишем это на допустимую погрешность в целях повышения наглядности и простоты.
4. Уверены, предложенный пример поясняет функциональную модель SIEM системы лучше, чем в примере со стеком ELK. Разработки во втором случае меньше, но правильно ли это? Когда «своими руками» прочитал событие безопасности из файла, передал в канал, нормализовал, обработал, сформировал инцидент, отправил в хранилище и на экран консоли, то сразу разобрался.
1. Среди десятка разных источников событий и коннекторов предложенный в примере вариант c веб-сервером показался нам наиболее удачным. В итоговом сценарии открываем одновременно 4 окна: 1 — окно браузера с тестовым веб-приложением, 2 — окно коннектора, 3 — окно ядра корреляции, 4 — окно с консолью администратора. И слушатели, самостоятельно моделируя перебор пароля, наблюдают взаимосвязь разработанных компонентов и «превращение» отдельных событий безопасности в инцидент. Возможно субъективно, но пример с авторизацией в Windows кажется менее наглядным. Хотя, когда остается время и аудитория подготовленная, после предложенного ApacheConnector довольно быстро появляются и WMIConnector, и MysqlConnector, и SSHConnector, и другие.
2. XAMPP — быстро. MongoDB — чтобы познакомить с NoSQL/NewSQL. RabbitMQ — чтобы познакомить с брокерами сообщений на примере одного из самых популярных. PHP и C# — личные предпочтения.
3. Архитектура заимствована из известных источников (см. по тексту публикации). Наша задача состояла в том, чтобы с минимальными расхождениями продемонстировать рабочий пример, поясняющий суть процесса обработки событий безопасности. Эксперты, конечно же, заметят отличия (например, нормализация у нас реализована рядом с ядром корреляции, а по-хорошему нужно сдвигать ближе к коннектору), но спишем это на допустимую погрешность в целях повышения наглядности и простоты.
4. Уверены, предложенный пример поясняет функциональную модель SIEM системы лучше, чем в примере со стеком ELK. Разработки во втором случае меньше, но правильно ли это? Когда «своими руками» прочитал событие безопасности из файла, передал в канал, нормализовал, обработал, сформировал инцидент, отправил в хранилище и на экран консоли, то сразу разобрался.
Спасибо за комментарии, в целом со всем согласен кроме четвертого. Но тут скорее уже дело вкуса и предпочитаемого способа восприятия информации (например, кто-то лучше воспринимает информацию визуально, кто-то лучше на слух). Видимо, у Вас бэкграунд разработчика, у меня больше аналитическо-математический, мне не обязательно программировать, чтобы понять логику работы.
Благодарю премного, ждем продолжения!
Sign up to leave a comment.
Как за один день разработать SIEM (систему управления инцидентами информационной безопасности)