Комментарии 4
Какой-то жиденький пост, на статью не тянет…
На вступление только.
Из личного опыта: Как система для хранения и поиска по логам, ELK — хорошее решение.
Но вот сколько я видел дэшбордов — народ изголяется, но толку от них мало. Вот у вас в статье 2 примера: симпатичные картинки, но польза от таких дэшбордов близка к нулю.
На вступление только.
Из личного опыта: Как система для хранения и поиска по логам, ELK — хорошее решение.
Но вот сколько я видел дэшбордов — народ изголяется, но толку от них мало. Вот у вас в статье 2 примера: симпатичные картинки, но польза от таких дэшбордов близка к нулю.
Это вступление к циклу статей, далее все будет более подробно описано. С моей точки зрения, вполне неплохо настроить дашбоарды с auto_refresh, которые будут показывать события по инцидентам ИБ для оперативного реагирования. Например, заблокировать определенный IP адрес на firewall или поставить сигнатуру IPS в Prevent.
Позвольте несколько вопросов:
1. Изучали ли возможность замены Logstash на Fluent или Vector? Последний декларирует большую производительность и меньшее потребление памяти vector.dev/#performance
2. Если вы строите графики по определенным полям структурированного лога, то зачем хранить все поля этого лога?
3. Как следствие из п.2, изучали ли возможность хранение логов не в Elasticsearch, а например в Clickhouse?
1. Изучали ли возможность замены Logstash на Fluent или Vector? Последний декларирует большую производительность и меньшее потребление памяти vector.dev/#performance
2. Если вы строите графики по определенным полям структурированного лога, то зачем хранить все поля этого лога?
3. Как следствие из п.2, изучали ли возможность хранение логов не в Elasticsearch, а например в Clickhouse?
Заканчивался 2019 год, на хабре узнали про ЕЛК
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
1.Elastic stack: анализ security логов. Введение