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

Итак, на сегодня у нас готовы:
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 и выложить его для использования.

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 .*  

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

Киберчувство прекрасного

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

В старшем школьном возрасте я с удовольствие изучал произведения Ивана Ефремова вообще и Лезвие бритвы в частности, где автор достаточно убедительно формализовал понятие "красоты". Однако внутри у меня оставалось несогласие с автором в том, что все не так просто и что красота не может быть разложена на совокупность формальных признаков (применительно к человеку - размер, форма и взаимные пропорции определенных частей тела и т.п.), что мы, высокоразвитые мыслящие существа, все-таки ощущаем красоту какими-то дополнительными "рецепторами", работа коих не поддается 100%-ной формализации и объяснению.

Я и сейчас склонен думать, что произведение искусства мне "просто нравится", и мне не важно понимать что в этом произведении "правильно", а что - "неправильно", да и что вообще такое "правильно", и искать ответ на вопрос почему мне это нравится.

Но, пройдя курс я получил очередной удар по своему ощущению прекрасного :( Рассматривались рекомендательные системы на примере оценки рейтинга художественных фильмов. На примере было продемонстрировано как ловко можно разложить "вкус", т.е. понимание "мне нравится" на банальные метрические составляющие, как то: "% продолжительности погони на автомобилях с перестрелками к общему времени", "% мелодрамы", "характер музыки саундреков" и т.п. Проанкетировав огромное количество респондентов можно получить вполне достоверную картину "вкуса" людей с разбиением по географическому местоположению, по возрасту, по социальному положению и т.п., и будущие свои произведения адаптировать с учетом этих знаний о "вкусе" потенциальной аудитории. Поскольку налицо некая формальная логика вполне возможно это запрограммировать..... и мы получаем компьютер-композитор, компьютер-писатель, компьютер-художник..... Причем все эти "кибер-ребята" оснащены способностью адаптации своего понимания "вкуса" на основании анализа рейтингов, т.е. они обладают "киберчувствами".

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

Но, несмотря на все эти удары по мироощущению, я склонен оставаться при своем мнении, вынесенном еще со времен школы, что искусство - это в любом случае нечто уникальное/выдающееся, что не может быть банально разложено на метрические составляющие рекомендательной системы, что люди воспринимают искусство не мозгом, а сердцем, что все эти попытки раскалывания "красоты" на элементарные составляющие объясняются лишь постоянным желанием Человека "понять себя", объяснить "почему так" (или, банально, монетизировать свои умения, угадав спрос), что истинное искусство не делается за деньги и на заказ, что произведения искусства никогда не будут создаваться машинами и мы никогда не получим поколение биологических автоматов!

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, отщелкивая согласие с лицензией. Решайте сами как вам с этим быть.

windows scheduler password extraction

Сегодня, по ходу рабочего дня, родился способ получения пароля "сохраненного в планировщике" windows. Способ довольно прост, поэтому публикую.
Для получени пароля запуска, необходимо заменить или откорректировать запускаемый файл таким образом, чтобы он выполнял старые добрые утилиты.
То есть строка типа

 wce -w > c:\pass.txt  

в скрипте резервного копирования, позволит быстро получить забытый пароль.
Не забудьте остановить антивирус или использовать другие ухищрения.

Признавать свои ошибки

."На чужих ошибках учится только мудрый гений, на своих - умный, дурак - не учится вовсе"

Из личного опыта

Вопреки расхожему мнению о правильности стратегии "молчания в тряпочку", я склонен считать, что способность находить, признавать и, самое главное, - эффективно исправлять свои ошибки - это более чем позитивная характеристика, которая, при несложных умозаключениях, будет способствовать не понижению, какого-нибудь, там, рейтинга, а к его повышению; из чего следует, что грамотный подход к PR-у своих уязвимостей и работы над ними, можно использовать как маркетинговый/рекламный инструмент.

Вот действительно, разве можно объяснить идиоту, что он идиот? Сам факт понимания субъектом, что он идиот уже означает, что он не идиот, и, поскольку быть идиотом, очевидно, сопряжено, с разного рода неудобствами, в перспективе он будет продумывать план своей модернизации (изменения взглядов, изменения поведения, внешнего вида, интересов, увлечений, ... - да чего угодно! - зависит от области, в которой он ощутил себя идиотом и о степени понимания собственного идиотизма). В общем, логика понятна: понимание своих проблем свидетельствует о переходе на новый уровень зрелости. Т.е. это развитие, а развитие - ну разве это плохо?!

Если Web-компания, постоянно пентестит свои внешние сервисы, находит в них уязвимости и патчит их - круто, что они вообще этим занимаются, понимают, что это надо делать, делают это и исправляются (== становятся лучше!). Если они при этом еще публикуют технические описания этих уязвимостей - совсем хорошо, так как это дает возможность продвинутому читателю понимать уровень сложности и качество проводимых ими аудитов, что характеризует, опять же, уровень технологической зрелости. 

Аналогично, если компания пишет софт, и ресурсами своей продуктовой безопасности (если есть профессиональная продуктовая безопасность, которая ломает по-всякому только-то вышедший из-под программиста код - это уже прорыв!) или внешнего аудитора (но, конкретно в данном случае, мне кажется, свои - лучше, так как они "больше в теме", а "замыливания глаза" у них нет, так как все-таки код они не пишут, а только исследуют его) находит баги, исправляет их, и публично пишет об этом - это неплохо.

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

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

1. это опыт, которым стоит делиться;
2. это демонстрирует вашу модель зрелости во всех перспективах: технологической, организационной, процессной, пр.;
3. это позволяет сделать мир лучше.

Качество/Цена

Не раз я порочил и поносил критерий "минимальной цены" при выборе победителя в конкурсе на услуги безопасности, вот еще пост в копилку ЗА более интеллектуальный подход к выбору поставщика услуг, чем сравнение стоимости предложений.

Один мой приятель, генеральный директор и основатель успешной компании, оказывающей услуги в области ИБ, во время проведения с ним "эффективных переговоров" о необходимости снижения цены сказал: "Я могу выполнить любые работы за любые деньги, вопрос только в качестве". Те переговоры были действительно "нереально эффективными" - была получена большая скидка от первоначального предложения, но об успешности результата этих работ я так позитивно отозваться не могу :(. Теперь тот случай я рассказываю как притчу для тех, кто испытывает позывы выбрать на выполнение консалтинговых услуг явно демпингующего поставщика.

Бла-бла-бла - это, конечно, хорошо, но давайте попробуем придумать, что с этим делать, как обосновывать правильный выбор, не попадаться на разгильдяев и не перестараться.

1. В тендерной документации требуйте предоставление плана работ с указанием трудоемкости по каждому пункту, исполнителей, полный состав проектной команды с подтверждением их квалификации. Если есть возможность можно еще тупо спросить ставки.
2. В конкурсной комиссии должны быть эксперты по предметной области, способные: оценить адекватность плана, указанной трудоемкости работ, требуемого состава исполнителей и их квалификации. Эксперт должен знать рынок, должен иметь представление о стоимости на рынке специалистов указанной квалификации, что крайне полезно, если ставки остались не известны (на практике это не большая проблема, так как вполне нормально требовать стоимость по каждому пункту плана, а имея стоимость и трудоемкость пункта плана работ - предположение о ставке исполнителей делается очевидным образом).
3. Все радикальные расхождения в представленных на конкурс планах должны в обязательном порядке анализироваться и, в конечном счете, этому должно быть найдено объяснение. Если причиной расхождений является неоднозначность задания, надо переигрывать конкурс.
4. Все радикальные расхождения в стоимости предложений разных конкурсантов должны также обязательно анализироваться, и этому также должно быть найдено адекватное объяснение.
5. Не надо выбирать предложение, заявленная стоимость которого ниже рассчитанной экспертом (с учетом пунктов плана, их трудоемкости, состава исполнителей и их квалификации).
6. Не надо вестись на эксклюзивные предложения со стоимостью явно ниже рассчитанной экспертом себестоимости работ. Все эти "скидки" в конечном счете будут вашими издержками: либо вы будете работать больше, либо дальнейшая перспектива взаимоотношений с этим поставщиком для вас явно не будет характеризоваться адекватностью стоимости работ.

Рынок, если он конкурентен, - нормальный способ регулирования соотношения Качество/Цена, пытайтесь прогнозировать последствия ваших решений - увидев сыр, попытайтесь увидеть и мышеловку и, уверен, все получится, как планировали, хотя бы на треть :).