Комплексная услуга

Читая книжку Practical malware analysis (кстати, обалденная книжка) пытаюсь найти применение этим знаниям для CISO и прихожу к выводу, что держать в штате заказчика таких ребят не надо, - разумнее это аутсорсить. Очевидно, что аутсорсить надо у того, кто это здорово делает и у кого объемы этой работы таковы, что ее себестоимость низкая. Кто же это такие :) ? Антивирусные вендоры!
Может, я, конечно, отстал от жизни и на рынке есть подобные предложения, но я не могу понять почему антивирусные вендоры не продают вместе со своими продуктами сервис по анализу и противодействию таргетированным атакам, против которых их продукты, очевидно, бессильны. Это позволило бы представить на рынке комплексную услугу.

Заказчику такая услуга интересна в том плане, что она комплексная и, очевидно, более эффективная чем всякие лозунги про эффективность автоматов и типовых подходов против APT. Автомат не способен адаптироваться, поступать нестандартно, здесь нужна работа человека... Да и вообще, пускай с профессионалами сражаются профессионалы!
Мое мнение, что в перспективе нас ожидают исключительно таргетированные атаки, поскольку мы почти все электрифицировали и разместили в Интернете, что позволят получать не виданный ранее профит, измеряемый миллионами рублей, а, вместе с тем, заказная разработка софта - 100 т.р. + способность поставить правильно задачу (написать техтребования).
Я это все говорю к тому, что автоматическая борьба с зловредами уже неэффективна и в недалеком будущем вообще превратится в профанацию, поэтому антивирусным вендорам надо задуматься об адаптации к ситуации и выводить на рынок более эффективные продукты\сервисы...

Прежде, чем описывать почему этот сервис будет выгоде антивирусному вендору. Попробую пофантазировать как этот сервис мог бы выглядеть.
1. Заказчик как-то узнал, что его поимели, да хоть даже из новостей... ну если не узнал никак, то он вряд ли будет заказчиком этого сервиса :) - вообще, сейчас мир таков, что есть только два типа заказчиков: которых имеют и они об этом знают и которых имеют и они об этом не знают, поэтому, если вы ничего не видите - это очень плохой знак!. Обращается на сервисную линию, ему выделяется телефонный эксперт, который помогает ему собрать необходимый эвиденс. Тут вендор может вложиться в курсы для своих заказчиков по компьютерной криминалистике, и этот шаг в большинстве случае будет пропущен - заказчик будет в состоянии собрать все что нужно, и как это нужно. Ну, или можно предоставлять автоматизированные инструменты для сбора.
2. Вендор, получив все это анализирует:
- выпускает экстру которая сразу позволит как-то "вылечить" проблему,
- помогает найти ответы на вопросы "что за негодяй", "какой мотив" и т.п. с чем можно пойти в милицию,
- помогает с "Lessons learned": что за уязвимость, как ее закрыть\снизить риск и т.п.
3. Все

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

По-моему обалденная перспектива для всех. Надо брать и внедрять!

Сотрудничество в условиях импортозамещения

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

К сожалению степень соответствия современной прикладной системы (далее я буду использовать слова "ПО", "продукт", "решение" - это все одно и то же) потребностям реального бизнеса ~40% (я умышленно не называю о каком ПО идет речь и предполагаю упреки читателя, что без определения предметной области рассуждения ни на чем не базируются, однако, пост не претендует на конкретную инструкцию к исполнению, его цель, как и большинства остальных, - заставить подумать о проблеме, возможно, подумать иначе, чем раньше). 

Из этих 40% надо сделать следующие выводы:
1. ПО еще дорабатывать и дорабатывать до получения желаемого результата, т.е. еще требуется немало инвестиций в это ПО.
2. Теме не менее элементарные потребности (наиболее значимые, определяющие соответствие этого ПО назначению и, собственно, своему названию :) ) ПО закрывает и, поставив его "из коробки", уже будет несколько лучше, чем вовсе без него.

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

С моей точки зрения, варианты №1 и №2 - приемлемы, вариант №3 - откровенно проигрышный для заказчика, поскольку мы получаем нерыночный, эксклюзивный продукт, следствием чего является - нерыночная эксклюзивная цена дальнейшей поддержки и развития. Поэтому, выбирая решение, в обязательном порядке следует внимательно обдумывать выбор продукта, не удовлетворяющего потребности в полном объеме и развитие которого возможно только на условиях единственного поставщика.

Лично мне нравится вариант №2, когда мы покупаем исключительно лицензии доступного на рынке продукта. Риск того, что разработчик не будет дорабатывать свой продукт в соответствии с нашими потребностями компенсируется тем, что, если продукт будет развиваться в принципе, он будет дорабатываться в соответствии с потребностями рынка и в этих условиях лучше мне подстроиться под рынок, чем требовать "эксклюзива" за нерыночную стоимость.

Ну а если есть риск, что продукт не будет развиваться вообще (== рынка для него не будет), то лучше идти про сценарию №1 и самому обрасти зрелой функцией разработки и сопровождения ПО.

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  

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