ELK: Анализ почтовых журналов. Подготовка. Logstash.

Некоторое время назад мы начали готовиться к анализу почтовых журналов. Продолжим подготовку.
Используем logstash для парсинга сообщения на поля.
Тут нет ничего интересного и сложного. Вот часть файла конфигурации (/etc/logstash/conf.d/filter.conf), разбирающая сообщения, формируемые в предыдущей заметке:

 ...  
  else if [message] =~ "Secure_Maillog" {  
    mutate { replace => { "type" => "maillog" } }  
    grok {  
     patterns_dir => "/etc/logstash/patterns"  
     match => ["message", "<134>%{SYSLOGTIMESTAMP}\s+%{SYSLOGHOST:sourcehost}  
     \s+%{WORD:syslogprog}:\s+%{NUMBER:timestamp}\t%{EMAIL:source}  
     \t%{EMAIL:destination}\t%{NUMBER:size:int}\t%{GREEDYDATA:subject}"]  
    }  
    date {  
     match => ["timestamp", "UNIX"]  
    }  
  }  
 ....  

В "/etc/logstash/patterns" хранятся файлы с шаблонами. В частности файл "/etc/logstash/patterns/mail" состоит из следующих строк:

 LOGIN [A-Za-z0-9$.+!*'(),~#%&/=:;_-]+  
 EMAIL %{LOGIN}@%{IPORHOST}  
 GREEDYDATA .*  

На сегодня все.

ELK: Ситуационный центр своими руками

Заполним вынужденную паузу про ELK, продолжим развлекаться в канун праздников.
Месяц назад на Хабре проскочила рекламная статья про ситуационные центры, которая вдохновила на создание чего-то похожего своими руками.
Сначала на отдельно стоящий монитор была выведена консоль для мониторинга кластера, который таки был собран (о чем может быть позже, когда рецепт будет вылизан и записан).
Жизнь оказалась слишком прозаична – игры с ELK начали набивать оскомину, поэтому в консоли заглядывали уже не так часто как в начале. В то же время, постоянно включенная консоль мониторинга состояния кластера бросалась в глаза постоянно и, когда кластер желал внимания, привлекала оное своей желтизной или даже краснотой.
Эта особенность отфильтровалась сознанием и было принято решение вывести на нашу «видеостену» диагональю 19”, в том числе информацию с основными индикаторами состояния сети. К сожалению, определить и вывести на один экран правильные индикаторы не получилось, по причине отсутствия последних. Даже придумать их не получилось. Может космический разум предложит что-то? Поэтому было принято решение попеременно выводить на «видеостену» разные dashboards, беглый взгляд на которые поможет понять, что что-то идет не по плану. Опять же мигание и смена видов добавит новогоднего настроения в кабинете.
Сказано, сделано.
Так как свободных компьютеров у нас не оказалось, ситуационный центр был собран на одном из узлов кластера, размещенных под столом. Клавиатуру и мышку можно не подключать, для работы достаточно ssh.
Как поставить пакеты на вашу систему, думаю, разберетесь самостоятельно. Повторюсь, мы работаем с клоном Unix, точнее с Debian.
Из того, что обычно не устанавливается на серверы, нам понадобится:

• Xorg
• firefox (iceweasel)
• xdotool

Как настроить машину для автоматического запуска Xorg, легко найти в сети. Для нормальной работы более чем достаточно прав обычного пользователя.
А теперь, собственно, скрипт, который будет творить магию на мониторе:

  #!/bin/bash   
  #Kibana and Marvel host   
  HOST="ХХХ.ХХХ.ХХХ.ХХХ"            
  #Marvel URL   
  URL="http://$HOST:9200/_plugin/marvel/kibana/index.html#/dashboard/file/marvel.overview.json"   
  #Kill everything   
  killall iceweasel            
  killall Xorg             
  #wait a moment   
  sleep 3               
  #start new Xorg   
  Xorg :1 &   
  #prepare DISPLAY variable for output   
  export DISPLAY=:1   
  #wait Xorg startup   
  sleep 1   
  #disable screensaver   
  xset s off   
  #disable power management for monitor   
  xset -dpms   
  #start browser.   
  iceweasel -width 1920 -height 1080 --display=:1 $URL &   
  sleep 30   
  #if Marvel show agreement - accept   
  xdotool mousemove 1100 250   
  xdotool click 1   
  sleep 5   
  #if Marvel show form for developer - skip   
  xdotool mousemove 1000 450   
  xdotool click 1   
  sleep 5   
  #fullscreen for browser   
  xdotool key F11   
  #get dashboards list from Kibana   
  _URL=$(curl -s -XGET "http://$HOST:9200/kibana-int/dashboard/_search?fields=title" | grep -Po '"title":.*?[^\\\\]"\]\}\},' | sed 's/.*\["//' | sed 's/"\].*//' | sed 's/ /%20/g')   
  #Prepare list of URL   
  for i in $_URL; do   
   URL="http://$HOST/kibana/#/dashboard/elasticsearch/$i $URL";   
  done   
  #forever change dashboards   
  while true; do.   
   for i in $URL; do   
    sleep 60   
    xdotool key "CTRL+l"   
    xdotool type $i   
    xdotool key Return   
    xdotool key F11   
    xdotool key F11   
   done   
  done   

Теоретически, можно было бы вывести на монитор основные графики, которых может хватить для беглого анализа глазами, но пока нет мыслей, как это сделать правильно.
PS. Этот скрипт поступает не очень честно с ребятами из elasticsearch.com, отщелкивая согласие с лицензией. Решайте сами как вам с этим быть.

ELK: Анализ почтовых журналов. Подготовка

Продолжим тематику визуального анализа журналов. С журналов доступа в сеть Интернет переключимся на почтовые.
Начнем с получения журналов с почтового сервера и их подготовку к передаче ELK.
Так получилось, что в моей сети в качестве внутреннего почтового сервера используется Microsoft Exchange 2003. Каким-то неведомым мне образом, раз в сутки в почту падает файл с архивом почтового журнала сервера за предыдущий день. Мы пытались настоять на том, чтобы журналы отправлялись по протоколу syslog c помощью snare, но в этом было отказано под "уважительным" предлогом "высокой чувствительности пользователей к минимальным задержкам в работе сервиса".
Сначала письмо, как и множество других, проходит через procmail. Оно попадает под действие правила:

 :0:  
 * ^Subject(.*Exchange log file*)  
 {  
   :0 Bcw  
   | /home/sa/bin/logs/ExtractAttachment.pl  
   :0 a  
   | /home/sa/bin/logs/ImportMaillog.pl  
   :0  
   inbox/mailstat/.  
 }  

Скрипт "/home/sa/bin/logs/ExtractAttachment.pl" является вариантом этого скрипта.
За скрипт "home/sa/bin/logs/ImportMaillog.pl" не судите строго. Он писался в режиме "быстрее хоть что-нибудь" и сейчас исправлять его не хочется, потому-что "работает!".

 use strict;  
 use Encode qw(decode);  
 use Time::Local;  
 use Sys::Syslog;  
 use open qw(:std :utf8);  
 my $configfile = "/home/sa/bin/logs/rcfile";  
 my $conf = new Config::General("$configfile");  
 my %config = $conf->getall;  
 open (FILE, "<:encoding(utf8)", "/tmp/maillog.tmp") or die "Can't open file /tmp/maillog.tmp!\n";  
 open (OFILE, ">/tmp/maillog") or die "unable to open /tmp/maillog !";  
 openlog("Secure_Maillog", "ndelay", "local0");  
 while (<FILE>) {  
   s/\<\>/postmaster\@udmurtneft.ru/g;  
   my @str = split(/\t/);  
   my $str18 = "";  
   if ( $str[8] =~ /102[80]/ ) {  
      if ( $str[18] =~ /=?/ ) {  
        $str[18] =~ s/UNICODE-1-1-UTF-8/UTF-8/g;  
        $str[18] =~ s/unicode-1-1-utf-7/UTF-8/g;  
        $str[18] =~ s/x-user-defined/UTF-8/g;  
        $str[18] =~ s/gb18030/windows-1251/g;  
        $str[18] =~ s/window-1251/windows-1251/g;  
        $str[18] =~ s/UNKNOWN/windows-1251/g;  
        $str[18] =~ s/134/windows-1251/g;  
        my $flag = utf8::is_utf8($str[18]);  
           $str[18] = Encode::decode('MIME-Header',$str[18]);  
           $str18 = $str[18];  
      }  
      $str[1] =~ s/ GMT//g;  
      my $time = $str[0]." ".$str[1];  
      my @t = ($time =~ /^(\d{4})-(\d{1,2})-(\d{1,2})\s(\d{1,2}):(\d{1,2}):(\d{1,2})/);  
      $t[1]--; $t[3] = $t[3]+4;  
      if ( $t[3] > 23 ) { $t[3] = $t[3] - 24 };  
      my $timestamp = timelocal 0,@t[4,3,2,1,0];  
      print OFILE "\t$timestamp\t$str[19]\t$str[7]\t$str[12]\t$str[18] \n";  
      syslog('mail|info', $timestamp."\t".$str[19]."\t".$str[7]."\t".$str[12]."\t".$str[18]);  
   }  
 }  
 closelog();  
 close(OFILE);  
 system("mysqlimport --local logs /tmp/maillog --user=$config{db}->{user} --password=$config{db}->{password}");  
 unlink("/tmp/maillog.tmp");  
 unlink("/tmp/maillog");  
 unlink("/tmp/report.zip");  

Важные строки выделены жирным. Первая из них передает строку журнала в syslog, а оттуда в logstash. Вторая записывает в олдскульный sql для тяжелого анализа.
В следующий раз, чтобы разбавить тему анализа глазами. рассмотрим что можно достать из SQL.
PS. Если вы захотите отметить, что хранить временные файлы в общей директории /tmp не безопасно, то ответа будет два:
1. На сервере, куда падают журналы, все пользователи имеют доступ к ним.
2.

 $ cat /etc/profile | grep umask  
 umask 077  

Анализ журналов прокси. Продолжение

Почему-то Интернет ломится от статей в стиле "как собрать логи", но статей описывающих, что с этими логами можно сделать практически нет.
Давайте попытаемся заполнить эту нишу и рассмотрим несколько возможных сценариев анализа журналов прокси сервера собранных нами ранее.

Классика:«кто больше съел»
Тут все просто. В панели «Down by user» (это не оскорбление. слово download не влезло в панель) выбираем верхних пользователей, щелкаем на изображении лупы и анализируем

Причем, что удобно, мы на одном экране видим:

1. Человечек смотрел видео с youtube;
2. Человечек начал это делать в обед (12-13);
3. Человечек не смог остановиться, когда обед закончился.

Можно проанализировать, что он смотрел, сопоставить это с журналами работы с информационными ресурсами, но этим сегодня заниматься не будем. Классика!
Классика «слабое звено»

Допустим, мы хотим посмотреть, кто ищет себе работу? Добавляем запрос «urihost: *job* or *rabota* or hh.ru» и наблюдаем кандидатов на анализ. Благодаря панели «Upload max» можно даже отловить момент выкладывания резюме.

В момент написания поста ничего интересного не происходило, поэтому просто посмотрите, что в обед люди не только отдыхают, но и занимаются серфингом по сайтам навевающим грусть на HR.
Стандартный «кто послал»
Вы, наверное, уже обратили внимание на панельку «Upload max» справа от панели запросов. Эта панель показывает размеры индивидуальных отправок данных через прокси-сервер. То есть на ней визуально мы можем выявить нарушения связанные с отправкой наружу информации. Таблично это делать не очень удобно
Смотрим, как у нас дела были в последние 12 часов.

Ага, видим 12 мегабайтную отправку. Уменьшаем время, за которое проводится анализ, так как количество событий в секунду превышает 50.

Уточняем. Фильтруем по пользователю и затем по имени сайта

И вот мы видим, кто отправил информацию и куда. К счастью это штатная отправка на сайт закупок, на анализ которой потребовалось несколько секунд.
Стандартный «масс-контакт»
Случилось некоторое время назад такое, что корпорация добра несколько усовершенствовала свой браузер, в результате чего в нем как-то особенно выделился функционал чата. В результате на прокси обрушился шквал запросов на соединение с IM-сервером, которые отклонялись. Это не есть хорошо.
Чтобы продемонстрировать работу по анализу, пришлось отключить фильтрацию отклоненных запросов (TCP_DENIED). В результате наблюдаем сайт требующий нашего внимания – urs.microsoft.com. Он не связан с IM, описанным в предыдущем абзаце, но для примера пойдет.

Продвинутый «ratio»К сожалению, такой вид анализа на ELK мне пока не удалось реализовать. Его идея в том, чтобы делать расчет соотношения информации отправленной на сайт к принятой. Этот способ анализа позволяет выявлять туннели и сайты-интерфейсы к IM, например. Делается все на сегодня запросом из SQL, где журналы так же хранятся. Нужно сохранить немного брутальности.
Продвинутый «reputation»
Это из раздела помечтать. Идея – дергать из репутационных баз информацию о доверии сайтам и выводить информацию на экран анализа. Идея навеяна плагином WOT для браузеров.

Буду рад, если коллективный разум подскажет, как реализовать продвинутые способы анализа или предложит свои идеи. Что смогу реализую и опишу.

Анализ журналов прокси

Так получилось, что отдел, в котором я работаю, в основном состоит из сотрудников правоохранительных органов, представления о защите информации у которых отличаются от моих. В частности, одним из основных показателей благополучия в информационной системе является «правильное» использование сотрудниками ресурсов сети Интернет. «Правильное» можно расшифровать как мало и редко. И, так как проверки по этим критериям достаточно просто организовать, отчет по результатам мониторинга работы пользователей в сети Интернет становится одним из ключевых в работе отдела.
Как собирать журналы, описано многократно и много где.
Давайте поподробнее рассмотрим, как их анализировать, чтобы покрыть нужды коллег пришедших в коммерческую безопасность из органов и решить свои задачи.
Есть брутальный способ, для настоящих мужиков, через запись журналов в какой-нибудь SQL и запросы к нему из командной строки в стиле:

---

select id, from_unixtime(time), r_host, inet_ntoa(r_ip), r_port, sum(sc_bytes) from proxylog where time > (UNIX_TIMESTAMP() - 86400*2) and cs_username like 'ХХХ' group by r_host order by sum(sc_bytes);

---

Используя его, мы можем быть уверенными, что анализ журналов не сможет сделать никто кроме нас. Это по-своему круто и дает нам определенный авторитет.
Но давайте повернемся лицом к коллегам и используем стандартную на сегодня связку Logstash-Elasticsearch-Kibana (ELK в английском просторечии) для анализа журналов. Вероятно, есть более оптимальные решения, но они потребуют больше времени на настройку и тюнинг. Итак…


ELK мне было удобно поставить на Debian. Правильный "Debian way" описан на этой страничке.

Squid:
Журналы Squid падают в Logstash. Способы выбирайте сами, они описаны во многих местах.
Пара особенностей. По подсказке коллеги из головной конторы, в журнал был добавлен заголовок referrer, а по моей инициативе - количество отправленных байт. В результате директива logformat выглядит так:

---

%ts.%03tu %6tr %>a %Ss/%03>Hs %<st %rm %ru %un %Sh/%<A %mt %>st %{Referer}>h

---

Logstash:
Чтобы падающие сообщения были нормализованы, то есть из потока символов была извлечена информация, используем вот такую конструкцию:

---

…
else if [message] =~ "(squid)" {
mutate { replace => { "type" => "squid-access" } }
grok {
match => ["message", "<14>%{SYSLOGTIMESTAMP}\s+%{SYSLOGHOST:sourcehost}\s+\(%{WORD:syslogprog}\):\s+%{NUMBER:timestamp}\s+%{NUMBER:request_msec}\s+%{IPORHOST:client}\s+%{WORD:cache_result}/%{NUMBER:status}\s+%{NUMBER:size:int}\s+%{WORD:http_type}\s+(%{URIPROTO}://)?(?:%{USER}(?::[^@]*)?@)?(?:%{URIHOST:urihost})?(?:%{URIPATHPARAM})?\s+(%{WORD:username}|-)\s+%{WORD:request_route}/(%{IPORHOST:forwarded_to}|-)\s+%{NOTSPACE:content_type}
\s+%{NUMBER:send_size:int}\s+(%{URI:referer}|-)"]
}
}
…

---

Тут и мне, написавшему этот жуткий regexp, мало что понятно с ходу, но когда будете настраивать logstash разберетесь что к чему - выбора не будет.
ElasticSearch:
Прелесть этой "не базы данных" в том, что все в ней хранится как-то. Поля, индексы, типы - все это появится в момент, когда вы решите заняться оптимизацией или добиться каких-то расширенных возможностей. Что происходит внутри связки ELK нам не важно. На вход мы подаем поток текста, на выходе получаем "кузявые" таблички и графики.
Kibana:
Статей по настройке интерфейса Kibana великое множество. Мне показалось, что эффективнее всего ставить себе какую-то задачу и искать механизм реализации задачи в ограничениях данного нам средства.
В результате для анализа журналов прокси сервера получился такой интерфейс

Панельки пришлось сделать поменьше, чтобы они все помещались на монитор одновременно. Поэтому по всем параметрам показывает TOP5. Чаще всего этого достаточно. Больше чем на 1-2 "нарушителей" в день нет времени.
Схему можно скачать здесь.

Основные способы применения решения рассмотрим в следующий раз.