Итак, на сегодня у нас готовы:
1. Сбор журналов почтового сервера;
2. Их парсинг для упрощения анализа.
Займемся тем, ради чего все затеяно – собственно анализом.
Автоматизированный анализ, освобождающий наше время для чтения Интернета, пока отложим и займемся первичным визуальным анализом (Exploratory Data Analysis).
Для начала, нам нужно нечто, красиво формующее получаемые журналы.
Сделаем это посредством Kibana. Для этого был сделан небольшой dashboard выложенный на github.com . Забирайте. Прежде чем загрузить dashboard в Kibana, в любом текстовом редакторе сделайте замену “dom1.int” и “dom2.int” на свои собственные домены.
Пара слов о dashborde. Он состоит из 5ти блоков.
1. “ALLMAIL” - Cодержит общий график отражающий количество отправленных и принятых сообщений по типу: внутренние, пришедшие извне, ушедшие вовне.
2. “INTERNAL” - график и таблицы для сообщений пересылаемых внутри периметра
таблица “Source count (all)” - количество отправленных сообщений в штуках
таблица “Destination count (all)” - количество полученных сообщений в штуках
таблица “Summ by src (all)” - объем отправленных сообщений в байтах
таблица “Summ by dst (all)” - объем полученных сообщений в байтах
3. “INSIDE” - график и таблицы для сообщений входящих в периметр
набор таблиц аналогичен блоку “INTERNAL”
4. “OUTSIDE” - график и таблицы для сообщений выходящих за периметр
набор таблиц аналогичен блоку “INTERNAL”
5. “ALL EVENTS” - таблица сообщений с полями, разобранными на предудущем этапе:
@timestamp – примерное время отправки\приема сообщения
source – источник (электронный адрес)
destination – получатель (электронный адрес)
subject - тема
size – размер в байтах
Давайте скорее займемся самым интересным – анализом. Рассмотрим не очень сложный сценарий, который не просто выполнить сортировками почтовых журналов – будем искать сотрудников, пересылающих свою почту на внешний почтовый ящик.
Итак открываем dashboard “Maillog analysis” (пример сделан на данных последней недели января). Выберем четрверг с полуночи до полуночи. На периоде в сутки, как будет видно дальше, анализ проще.
Сразу замечаем человечка, который, вероятно, настроил пересылку. Делаем фильтр по его внутреннему адресу, щелкнув на значке лупы в любой из таблиц.
Видим, что в рамках рабочего дня (выделено красным), графики коррелируют довольно сильно, а за пределами – графики абсолютно идентичны. Разница вида графиков в рабочее время обусловлена тем, что сотрудник отправляет почту не только на внешний почтовый ящик, но и внутри периметра.
Для более точного анализа, отфильтруем сообщения, которые адресованы только на внутренний адрес сотрудника либо на его внешний адрес.
Фильтр, содержащий логику в kibana, формируется с особенностью – логический оператор пишется с использованием прописных букв:
К счастью мы видим, что пересылка осуществляется не полностью. Сотрудник настроил пересылку только с определенных адресов для получения диспетчерских сводок. Дальнейшая проверка подтвердила это. Но сейчас мы об этом не знаем. Если закрыть глаза на разницу графиков в рабочее время, то по ночным журналам можно заряжать зондер-команду и отправлять ее вязать нарушителя. Подтверждение - пересылки почты вне рабочего дня - приведено на рисунке.
Ограничения метода:
1. Высокая трудоемкость, как следствие нерегулярность.
2. Не полное покрытие – отсеиваем сотрудников с большим трафиком и не замечаем слабонагруженные адреса, которые никогда не окажутся в топах.
Вообще, созданный dashboard, позволяет увидеть много интересного:
1. Сбои в работе почтовой системы – не фатальные, которые все замечают без специальных средств, а те в которых появляются задержки в пересылке, например. На первом рисунке видно, что почтовую систему лихорадило в пятницу, хотя на сбои в пересылке почты никто не жаловался.
2. Массовые рассылки, в том числе произведенные вредоносным ПО.
Выведя его на экран ситуационного центра, проходя мимо, можно зацепиться за что-нибудь глазами и выполнить детальный анализ уже на рабочем месте.
Буду рад, если сообщество предложит свои сценарии или направления анализа, с тем чтобы модифицировать dashboard и выложить его для использования.
1. Сбор журналов почтового сервера;
2. Их парсинг для упрощения анализа.
Займемся тем, ради чего все затеяно – собственно анализом.
Автоматизированный анализ, освобождающий наше время для чтения Интернета, пока отложим и займемся первичным визуальным анализом (Exploratory Data Analysis).
Для начала, нам нужно нечто, красиво формующее получаемые журналы.
Сделаем это посредством Kibana. Для этого был сделан небольшой dashboard выложенный на github.com . Забирайте. Прежде чем загрузить dashboard в Kibana, в любом текстовом редакторе сделайте замену “dom1.int” и “dom2.int” на свои собственные домены.
Пара слов о dashborde. Он состоит из 5ти блоков.
1. “ALLMAIL” - Cодержит общий график отражающий количество отправленных и принятых сообщений по типу: внутренние, пришедшие извне, ушедшие вовне.
2. “INTERNAL” - график и таблицы для сообщений пересылаемых внутри периметра
таблица “Source count (all)” - количество отправленных сообщений в штуках
таблица “Destination count (all)” - количество полученных сообщений в штуках
таблица “Summ by src (all)” - объем отправленных сообщений в байтах
таблица “Summ by dst (all)” - объем полученных сообщений в байтах
3. “INSIDE” - график и таблицы для сообщений входящих в периметр
набор таблиц аналогичен блоку “INTERNAL”
4. “OUTSIDE” - график и таблицы для сообщений выходящих за периметр
набор таблиц аналогичен блоку “INTERNAL”
5. “ALL EVENTS” - таблица сообщений с полями, разобранными на предудущем этапе:
@timestamp – примерное время отправки\приема сообщения
source – источник (электронный адрес)
destination – получатель (электронный адрес)
subject - тема
size – размер в байтах
Давайте скорее займемся самым интересным – анализом. Рассмотрим не очень сложный сценарий, который не просто выполнить сортировками почтовых журналов – будем искать сотрудников, пересылающих свою почту на внешний почтовый ящик.
Итак открываем dashboard “Maillog analysis” (пример сделан на данных последней недели января). Выберем четрверг с полуночи до полуночи. На периоде в сутки, как будет видно дальше, анализ проще.
Сразу замечаем человечка, который, вероятно, настроил пересылку. Делаем фильтр по его внутреннему адресу, щелкнув на значке лупы в любой из таблиц.
Видим, что в рамках рабочего дня (выделено красным), графики коррелируют довольно сильно, а за пределами – графики абсолютно идентичны. Разница вида графиков в рабочее время обусловлена тем, что сотрудник отправляет почту не только на внешний почтовый ящик, но и внутри периметра.
Для более точного анализа, отфильтруем сообщения, которые адресованы только на внутренний адрес сотрудника либо на его внешний адрес.
Фильтр, содержащий логику в kibana, формируется с особенностью – логический оператор пишется с использованием прописных букв:
destination: “username@ dom1.int” OR “external@email.box”
К счастью мы видим, что пересылка осуществляется не полностью. Сотрудник настроил пересылку только с определенных адресов для получения диспетчерских сводок. Дальнейшая проверка подтвердила это. Но сейчас мы об этом не знаем. Если закрыть глаза на разницу графиков в рабочее время, то по ночным журналам можно заряжать зондер-команду и отправлять ее вязать нарушителя. Подтверждение - пересылки почты вне рабочего дня - приведено на рисунке.
Ограничения метода:
1. Высокая трудоемкость, как следствие нерегулярность.
2. Не полное покрытие – отсеиваем сотрудников с большим трафиком и не замечаем слабонагруженные адреса, которые никогда не окажутся в топах.
Вообще, созданный dashboard, позволяет увидеть много интересного:
1. Сбои в работе почтовой системы – не фатальные, которые все замечают без специальных средств, а те в которых появляются задержки в пересылке, например. На первом рисунке видно, что почтовую систему лихорадило в пятницу, хотя на сбои в пересылке почты никто не жаловался.
2. Массовые рассылки, в том числе произведенные вредоносным ПО.
Выведя его на экран ситуационного центра, проходя мимо, можно зацепиться за что-нибудь глазами и выполнить детальный анализ уже на рабочем месте.
Буду рад, если сообщество предложит свои сценарии или направления анализа, с тем чтобы модифицировать dashboard и выложить его для использования.
