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

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

К сожалению степень соответствия современной прикладной системы (далее я буду использовать слова "ПО", "продукт", "решение" - это все одно и то же) потребностям реального бизнеса ~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  

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

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

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

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

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

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

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

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

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

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

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