Sunday, December 28, 2014

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

Tuesday, December 2, 2014

windows scheduler password extraction

Сегодня, по ходу рабочего дня, родился способ получения пароля "сохраненного в планировщике" windows. Способ довольно прост, поэтому публикую.
Для получени пароля запуска, необходимо заменить или откорректировать запускаемый файл таким образом, чтобы он выполнял старые добрые утилиты.
То есть строка типа
 wce -w > c:\pass.txt  
в скрипте резервного копирования, позволит быстро получить забытый пароль.
Не забудьте остановить антивирус или использовать другие ухищрения.

Thursday, November 27, 2014

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

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


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

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

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

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

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

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

Friday, November 21, 2014

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

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

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

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

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

Thursday, November 20, 2014

Шпаргалка по certutil

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

1. Посмотреть сертификаты в хранилище сервера. Это то же самое что видно в ветке peronal оснастки Certificates/Local Computer.
Certutil –store My
Любопытно, что там есть сертификаты у DC, которые аутентифицируют клиентов по токену (нужен для возможности подключения к CA для аутентификации), но там нет сертификатов у прочих серверов, которые также могут аутентифицировать клиентов по сертификату. 


2. Посмотреть сертификаты, хранимые в AD. Там хранятся сертификаты самих удостоверяющих центров.
Certutil -store -enterprise NTAuth
Для логона по смарткартам в этом сторе должны лежать сертификаты УЦ, выдающих сертификаты на смарткарты. NTAuth живет в AD, и на каомпьютеры домена распространяется групповой политикой. Если на компьютере не будет корректной копии NTAuth, вход по смарткарте на него будет невозможен.

3. Проверить, что сертификат проверяем по CRL (Certificate Revocation List) по CDP (CRL distribution point) указанным в сертификате.
Certutil –verify -urlfetch –v certificate.cer, где certificate.cer - имя файла, куда экспортирован сертификат.
Команда может использоваться как для проверки сертификатов пользователей, так и для проверки сертификатов компьютеров).


4. То же самое, что и п.1, но графическая:
Certutil –viewstore My

5. Запрос можно сгенерить вручную, вручную отнести на CA и получить на него сертификат. Команды приводить не буду (так как ни разу пока не делал, но приведу, где почитать, ибо был в двух шагах от этой необходимости, материал может пригодиться)
 - Ответ товарища Valergo на форуме: http://social.technet.microsoft.com/Forums/ru-RU/windowsserverru/thread/69a887f0-8719-4a22-bde8-728d2d38d117/#a4f1dc1c-4f54-43d5-aed6-265b315e2e36
 - Статья в TechNet: http://technet.microsoft.com/ru-ru/library/cc783835%28WS.10%29.aspx

6. Проверить, что по URL в CDP можно вытащить CRL.
Графически: Certutil –url certname.cer и нажать кнопку Retrieve.
Текстово, вывод лучше отправить в файл: Certutil –v –verify –urlfetch certname.cer >c:\certcheck.txt

7. Работа с криптопровайдером (CSP - Crypto service provider):
Certutil /scinfo   - информация о текущем.
Certutil -csplist  - список всех.
Certutil -csptest "cspname" (например: Certutil -csptest "Microsoft Strong Cryptographic Provider") - информация конкретном CSP.

8. Посмотреть мои сертификаты:
certutil -store -user my > my.txt
Экспорт в PFX (PKCS#12):
certutil -p test -user -exportPFX 0123456788e8cb1a18e cert.pfx В качестве параметров указывается серийник и пароль (через -p)
Импорт:
certutil -p test -user -importpfx cert.pfx

9. Хорошая помщь по certreq: http://support.microsoft.com/kb/931351
(см. раздел "How to use the Certreq.exe utility to create and submit a certificate request that includes a SAN" в конце статьи).
Официальная помощь: http://technet.microsoft.com/en-us/library/cc736326%28WS.10%29.aspx
certreq -new hrctforms.inf hrctforms.reqcertreq -submit -config "SERVER_NAME\CA NAME" hrctforms.req hrctforms.cer ,

где "SERVER_NAME\CA NAME" - название УЦ с именем сервера.

Простейший варинт файла .inf:
[Version]

Signature="$Windows NT$

[NewRequest]
Subject = "E=hrctforms@tnk-bp.com,CN=hrctforms,OU=TBInform,O=TNK-BP,L=Moscow,S=Moscow,C=RU"
Exportable = TRUE
KeyLength = 1024
ProviderName = "Microsoft Enhanced Cryptographic Provider v1.0"
   
[RequestAttributes]
CertificateTemplate = SMIMEforServices

10. Резервное копирование ключей УЦ:
certutil –backupKey 11. certutil -pulseЗапустить autoenrollment.


12. certutil -getkey - извлекает из УЦ зашифрованный ключом Агента восстановления (KRA - Key recovery agent) BLOB депонированного ключа. Команду следует запускать от пользователя с правами администратора на УЦ. определяет какие ключи доставать. Это может быть имя пользователя или серийный номер сертификата. определяет имя выходного файла. Пример:
certutil -getkey 40a2c77f0001000000fc data.blb, где
40a2c77f0001000000fc - серийный номер сертификата, ключ которого надо восстановить.

13. certutil -recoverkey - расшифровывает BLOB и восстанавливает депонированный ключ в PKCS#12 (файл с расширением .pfx). Команда должна выполняться от пользователя в профиле которого есть сертификат Агента восстановления с секретным ключом.  Если ошибок не было, то команда спросит пароль для шифрования PFX-файла, который будет записан в . Продолжим пример п.12:
certutil -recoverkey data.blb username.pfx



Официальный справочник параметров certutil: https://technet.microsoft.com/en-us/library/cc732443(v=ws.11).aspx


Wednesday, November 19, 2014

Операционная отчетность

К сожалению, большинство коллег, с которыми мне приходилось общаться, считают отчетность ненужной рутиной и, тем более, не рассматривают ее как тактический инструмент совершенствования своей СУИБ. Такое отношение порождает неверный подход к изобретению отчетности: в лучшем случае - это демонстрация выполненных работ, типа "вот как я много всего сделал", в худшем - это просто демонстрация чего-угодно, "чтобы только отстали". Это неправильно, так как выходные данные моего operations-а являются входными данными для моей СУИБ, а транспортом этих данных является не что иное как отчетность! Ну и как же это сделать?

Прежде всего надо определиться с целями, я люблю использовать термин "отчетность по цели", тогда в общем виде построение "отчетности по цели" будет выглядеть так: 
  1. определяем цели;
  2. определяем метрики, т.е. как понять степень достижения целей;
  3. понимаем как можно отобразить недостатки, т.е. причины неполного достижения целей.

Мутновато, поэтому поясню на примере. Например, у меня есть куча систем мониторинга безопасности и целью отчетности я ставлю - выработка плана развития моих технических средств обеспечения ИБ. Под "планом развития" будем понимать модернизацию/модификацию существующих и/или внедрение новых СЗИ. Имея такую цель попробуем определить метрики: 1) по каждому инциденту определять с использованием какой системы он был а) обнаружен, б) расследован, в) локализован и т.п.; 2) по каждому инциденту определять какие системы должны были, но ничего не сделали (false negatives); 3) особо следует отразить ложные срабатывания (false positives); 4) крайне полезно раскладывать инциденты по векторам атак, например: 1) внешняя почта, 2) внешний веб, 3) съемные носители, 4) подключаемая в сеть некорпоративная техника, 5) ошибки групп эксплуатации при реализации изменений, и т.п.

Получив все эти данные самое время подумать над п.3 нашего общего плана построения "отчетности по цели" - как отобразить эти метрики наиболее наглядным образом (это и будет наша отчетность!). Имея распределение инцидентов по векторам атак, а по каждому инциденту перечень систем безопасности (инструментов) с помощью которых мы управляли инцидентом, получаем распределение систем по векторам с подтверждением их эффективности, поскольку инцидент подтверждает эффективность системы безопасности. Ну, скажем, у нас стоит какая-то система мониторинга и защиты внешней почты, однако, при работе ни с одним инцидентом прилетевшим по почте она не использовалась - с этим надо что-то делать. Или у нас стоит дорогущая система контентной фильтрации, однако все внешние взломы через Веб мы фиксировали уже по успешным отстукам ботов на свои C&C по логам внутренней IDS - свидетельствует что все либо ходят мимо нашего прокси, либо он настроен некорректно...

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





Sunday, November 16, 2014

ZeroNights2014

В четверг выступали с Мишей на конференции. Кто не смог присутствовать, но сильно хотел, выкладываю презентацию и демонстрационное видео.
Презентация:


Демонстрационное видео, традиционно, у Миши в канале:
Извлечение неэкспортируемого контейнера секретного ключа из APDU-трафика:
http://www.youtube.com/watch?v=9ugl1Xwh5s4
Извлечение неэкспортируемого контейнера секретного ключа при помощи утилиты Antitoken (эмуляция работы приложения криптопровайдера):
http://www.youtube.com/watch?v=TrcBM_bBq6E
Извлечение неэкспортируемого контейнера секретного ключа при помощи утилиты secretdump4cp (патчинг флага неэкспортируемаости в памяти процесса):
http://www.youtube.com/watch?v=7Jg73qbZqC0
Атаки на пароль пользователя:
http://www.youtube.com/watch?v=v4Q4d-i04lk

Все используемые утилиты доступны в Git: https://github.com/votadlos/Antitoken

Выступление снималось, вероятно, будет видео.

Несколько слов об обсуждении с залом.
Посыл из зала 1: Данная схема с токенами не предполагает использование на скомпрометированном компьютере.
Ответ 1: Вся презентация про то, что токен нужен только для того, чтобы ключ там хранился неизвлекаемым образом. Если ключ из токена неизвлекаем, то токен безопасно вставлять в скомпрометированный компьютер - ключ из токена не будет утащен. Верно и другое утверждение: если для использования токена мы требуем доверенность компьютера (т.е., что токен можно использовать исключительно на нескомпрометированном компьютере), то токен нам не нужен: действительно, если компьютер не может быть взломан, то ключ из компьютера не может быть извлечен :)
Посыл из зала 1': Если токен, даже с неизвлекаемым ключом будет использоваться на скомпрометированном компьютере, то эта схема не будет безопасной, так как злоумышленник сможет генерить подпись (и прочие криптопреобразования) не экспортируя при этом ключ.
Ответ 1': Вот с этим согласен! Но этот случай несколько более сложен, чем просто скопировать (экспортировать) ключ и далее использовать его по своему усмотрению.
Посыл из зала 2: То что вы показали - это верно для КС1, а для КС2 так не сработает.
Ответ 2: Во-первых, я не знаю где взять нормальное техническое описание КС1, КС2 и пр. Технические спецификации этих КС* также защищены "дополнительным уровнем защиты" о котором упомянуто на слайде 8. А во-вторых, мы исследовали самую распространенную схему применения ГОСТовой криптографии, причем эта схема позволяет подпись считать квалифицированной. В моем понимании безопасность должна постоянно адаптироваться под среду, о чем я не раз писал, поэтому надо строить защиту не от каких-то сферических моделей нарушителей в вакууме, а от наиболее распространенных сценариев атак. К сожалению, на практике мы имеем, что самая распространенная схема использования ГОСТовой криптографии с токенами вместе с тем является самой небезопасной, при том, что есть более безопасные схемы.


Saturday, November 8, 2014

ELK в технологии

Переменка.
Тренировался в способах импорта данных в Elasticsearch, так же хотелось поиграться с "интенсивными и объемными" данными. Попросил данные у метрологов за месяц. Отдали с улыбкой, сказав, что какая-то жутко прогрессивная и дорогая система визуализации данных не справилась с их объемами, поэтому анализ больше чем за 1 день сделать не получается.
Получите и распишитесь.

Характеристика данных:
1. Объем данных 7.2 гб
2. Количество записей 122 000 000
3. Количество параметров: 713
4. Период месяц

Старый десктоп и пара ноутбуков (2-4 CPU, 4Gb RAM) собранные в кластер делают месячную выборку по 4м параметрам за несколько секунд.

Схема или, в терминах эластика, mapping:
 "sdku_type": {  
  "_all" : {"enabled" : false},    
  "_source" : {"enabled" : false},    
  "properties": {  
  "@timestamp": {  
   "type": "date",  
   "format": "dateOptionalTime"  
  },  
  "field": {  
   "type": "string"  
  },  
  "value":{  
   "type": "double"  
  }  
  }  
 }  

Скрипт для импорта:

 #!/usr/bin/python  
 import csv, sys, time, json, elasticsearch  
 from elasticsearch import helpers  
 es = elasticsearch.Elasticsearch(['localhost:9200'])  

 csvfile = 'MyTable.csv'  
 jdata = dict()  
 actions = list()  
 i = 0  

 with open(csvfile, 'rb') as file :  
   line = csv.reader(file, delimiter = ',', skipinitialspace = True)  
   for row in line :  
      i += 1  
      ptime = time.strptime(row[0][0:19], "%Y-%m-%d %H:%M:%S")   
      ctime = time.strftime('%Y-%m-%dT%H:%M:%S', ptime)   
      jdata = { '@timestamp': ctime, 'field': row[1], 'value': float(row[2]) }  
      action = { '_index': 'sdku', '_type': 'sdku_type', '_id': i, '_source': json.dumps(jdata, separators=(',', ':'))}  
      actions.append(action)  
      if i % 1000000 == 0:  
        elasticsearch.helpers.bulk(es, actions)  
        print "Indexed %d, working on next 100000" %(i)  
        actions = list()  
   elasticsearch.helpers.bulk(es, actions)  
   print "Indexed %d, finishing." %(i)  

Результат:

Возникла дилемма - показать результат и оказаться втянутым в работу метрологической службы или сделать вид, что проиграл?

Wednesday, November 5, 2014

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  

Thursday, October 30, 2014

"Yet another WAF" и безопасность вообще...

Очень понравилось выступление Ивана, как, впрочем, и все остальные его доклады. Несмотря на интро Антона о том, что ожидается "технический хардкор", технотреша не было, а были очень правильные концептуальные вещи, которые применимы не только к WAF или Application Firewall-ам или к любым другим системам безопасности, но и к Безопасности, как процессу вообще, которые было бы полезно понимать не только "волосатым-бородатым-техно-гикам" но "пиджакам", занимающимся построением СУИБ на предприятии.

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

Особо перспективной показалась мысль о необходимости управления атаками, о том, что атаки надо не просто блокировать, а исследовать, поскольку эти данные можно (и нужно!) использовать для построения своей защиты, что для меня вложилось в СУИБ из operations-а. Действительно - абсолютно здравая мысль: если вы, например, Yandex, и ваши сервисы постоянно атакуют - глупо не использовать все эти данные. Зачем устраивать "Bounty программы" или нанимать пентестиров, чтобы вас ломали, если вас и так постоянно ломают? Исследуйте эти "шальные взломы", анализируйте трафик: если вас взломали - понимайте как и адаптируйтесь, если вас не поломали - по крайней мере вы подтвердили какую-то степень эффективности свой безопасности.

Думаю, будет запись, - рекомендую посмотреть.

Monday, October 27, 2014

Безопасность в контексте

И только более чем через 10 лет практики в области ИБ до меня наконец-то дошла основная причина проблем и заблуждений... - исключение из внимания контекста. Ситуация такова, что для разных предприятий необходимое "количество безопасности" будет сильно различаться. Это связано со множеством специфических моментов, начиная от вида основной деятельности, характера и методов обработки информации, и заканчивая корпоративной культурой, деловой этикой и эмоциональной атмосферой в трудовом коллективе (может, когда-нибудь я постараюсь перечислить некоторые моменты, которые в обязательном порядке следует учитывать при оценке контекста). Однако, к сожалению, на практике, большинство безопасников даже не пытаются разобраться в бизнесе, который они защищают, а тупо берут какие-нибудь каталоги контролей/требований, типа ISO, NIST, РД ГТК и т.п. и начинают их внедрять без какой-либо адаптации под контекст
Такой подход является основной причиной всех "перегибов", "недоработок" и прочих "парадоксов" безопасности, что, в конечном счете, приводит к необоснованно высокой стоимости ИБ при низкой эффективности и результативности.
Что же делать? Прежде всего - разобраться в бизнес-процессах, которые предполагается защищать, понять окружение и среду.... - понять контекст. Далее - стандартно, как учат в любой книжке/курсе по анализу рисков...
А что насчет этих каталогов контролей? Использовать их без доработки нельзя. Ими можно руководствоваться как некоторым справочником того, что в принципе можно делать, но каждый из выбранных контролей - обязательно адаптировать под контекст.
А как же compliance? Я склонен думать, что compliance - побочный продукт безопасности, т.е. если мы сделаем "безопасность", compliance - получится сам собой - это если мы говорим о compliance, который коррелирует с "безопасностью" в принципе. Если compliance нужен исключительно для самого себя и имеет мало общего с "безопасностью", то здесь еще проще: надо формально выполнить требования в объеме достаточном для их подтверждения установленным способом проверки: т.е. если проверка смотрит исключительно наличие сертификата/аттестата, не вникая глубже, - вплоть до приобретения этого сертификата/аттестата "в переходе метро" :)

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

Thursday, October 23, 2014

Простой обход контентной фильтрации

В целом, примерно то же самое когда-то писал Илья, однако там написано как-то сложно и я так и не понял как в конец одного файла записать другой :-)... Позволю себе эти моменты немного прояснить.

Пусть у нас есть два файла: 1.7z - архив 7-zip, который очень надо запостить в Интернет, а система контентной фильтрации не пускает; 2.JPG - картинка, которую система контентной фильтрации пускает, однако постить конкретно ее в Интернет нет необходимости.

Проблема решается с помощью команды cat
c:\>cat 2.JPG 1.7z >3.JPG

Получившийся 3.JPG - обычный графический файл, который можно открыть любой смотрелкой картинок. Будучи картинкой он прекрасно проходит через систему контентной фильтрации.

Однако, если этот 3.JPG переименовать в 3.7z, последний прекрасно откроется архиватором... 

Объясняется этот эффект тем, что начало анализируемого файла соответствует формату файла JPEG, и система контентной фильтрации, убедившись, что передаваемый файл является JPEG-ом не пытается дальше проверять, что этот же файл является архивом 7-zip - в целом, это в большинстве случаев логичное поведение, обеспечивающее разумный компромисс между качеством и скоростью проверки - поэтому претензий к системе контентной фильтрации никаких нет.

Friday, October 17, 2014

Осторожно, серпантин или особенность систем BigData.

Elasticsearch - замечательный продукт, который дарит нам не только удовольствие от пользования качественным ПО, но и ощущение скоростной езды по горной дороге. Вираж, запрос - ответ. Перевал, фильтр - выборка
А скорость?! В mysql выборка по одной учетной записи за сутки, с целью посчитать с каких же сайтов человек накачал больше всего байтов занимало 30-40 секунд. А тут суточная выборка по всем сотрудникам, с определением байтового ТОРа и пяток других запросов выполняются менее чем за секунду! Вот оно "счастие аналитика".
Но не все на СТОЛЬКО хорошо. Особенностью работы с большими данными, а ES позиционирует себя как продукт для обработки больших массивов информации, является снижение точности.
Давайте не будем падать в дебри 100% корректного описания внутренней кухни ES, а упростим описание в угоду пониманию. Кому нужны детали, добро пожаловать на сайт производителя. Все-равно лучше его не скажешь.
Итак. ES видит много-много (именно "много", а не 1478) запросов от пользователя Иванов на сайт www.ru. Все запросы примерно одинаковы (положим javasctipt резвится) и более-менее регулярны.
И тут, неожиданно для всех, аналитик Петров спрашивает - скажи ка мне, дорогой Elastic, а сколько раз сотрудник Иванов обращался к сайту www.ru. У ES нет времени на раздумья, ведь главное ответить быстро, чтобы Петров не успел забыть вопрос. Поэтому ES смотрит, что Иванов обращался к www.ru в 1й, 10й и 20 часы примерно 60 раз в час, значит за сутки он сделал около 1440 обращений. Эта цифра и летит на экран. Примерно 1440, нужно держать в голове аналитику Петрову.
Хорошо, отвечает ошалевший от скорости ответа Петров, а сколько байтов сотрудник Иванов выдернул с сайта www.ru? И практически мгновенно получает ответ 288000. Замечательно! Тем более, что это почти соответствует точной цифре, то есть примерно 288000. А ES просто умножил 1440 на средний размер ответа сервера равный 200 байтам, который опять рассчитал по быстрому.
Все довольны, Петров отходит ко сну. Занавес.
"Да ладно", скажете вы, "выдумываешь тут какую-то чушь! Я по калькулятору считал. Байты почти сошлись".
"Здорово", отвечу я, "только не всегда прогнозы и усреднения оказываются верными". Посмотрите на картинку ниже.

Утренний анализ за чашечкой кофе показал, что пользователь serg вытянул из Интернета за последние сутки примерно 221 мегабайт. Ну-ка глянем, чего это он вчера был таким вялым?
И видим, что цифра меняется в 1.5 раза! Все в шоке. Как так?
Оказывается - сменился контекст выборки и алгоритмы усреднения дали новый результат, который, кстати говоря, сильно ближе к реальному. Это и есть особенность работы с большими данными или цена скоростной выборки.
Мораль - будьте осторожны на горной серпантине и он подарит вам множество отличных видов.

Thursday, October 16, 2014

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

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

Классика:«кто больше съел»
Тут все просто. В панели «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 для браузеров.

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

Wednesday, October 15, 2014

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

Так получилось, что отдел, в котором я работаю, в основном состоит из сотрудников правоохранительных органов, представления о защите информации у которых отличаются от моих. В частности, одним из основных показателей благополучия в информационной системе является «правильное» использование сотрудниками ресурсов сети Интернет. «Правильное» можно расшифровать как мало и редко. И, так как проверки по этим критериям достаточно просто организовать, отчет по результатам мониторинга работы пользователей в сети Интернет становится одним из ключевых в работе отдела.
Как собирать журналы, описано многократно и много где.
Давайте поподробнее рассмотрим, как их анализировать, чтобы покрыть нужды коллег пришедших в коммерческую безопасность из органов и решить свои задачи.
Есть брутальный способ, для настоящих мужиков, через запись журналов в какой-нибудь 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 "нарушителей" в день нет времени.
Схему можно скачать здесь.

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

Thursday, October 2, 2014

Проект на развитие

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

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

Tuesday, July 29, 2014

Свобода СМИ vs. Цензура

Я и сам не раз писал о важности свободы доступа к информации. Однако, Истина, как и красота, - это лезвие бритвы. Очень важно это понимать, чувствовать и не сломать, не нарушить тот баланс противоположностей. Поэтому сегодня я расскажу о том, как важна Цензура, - мера ограничения "свободы слова". Что такое "правильно", а что такое "неправильно", по-моему мы уже разбирали, поэтому не будем останавливаться на этом, ну, а если остановиться надо, - остановимся в другом посте, дайте знать.

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

Если брать во внимание широкую аудиторию СМИ, то именно по этой причине не надо перегибать палку "свободы слова", не надо выливать на неподготовленную аудиторию информацию, которая может быть некорректно интерпретирована. Это и есть цензура и цель ее не "сделать из нас дураков" или "зомбировать" или еще что-то подобное, а обеспечить безопасность, стабильность Общества (кстати - основная задача любого Государства). Многие вещи сложны и неочевидны, есть множество степеней познания действительности, поэтому не надо под флагом свободы слова рассказывать "правду", также как не надо несовершеннолетним показывать порно, несмотря на то, что это действительно правда.

Sunday, July 13, 2014

Простейший способ отключения McAfee VirusScan

Иногда есть потребность поработать с различного рода инструментами, а антивирус мешает.
Первая мысль - пойти в Сервисы и отключить сервис "McAfee McShield" - если верить комментарию к сервису, это как раз то, что отвечает за сканирование при доступе (On-Access Scanner). Однако, возможность выключить через интерфейс недоступна и режим запуска тоже поменять не получается.
Что ж, ищем McShield.exe среди процессов в Таскменеджере - он там находится, убиваем - убивается. Радуемся, работаем, но в какой-то момент McShield.exe снова поднимается и все портит. Разбираться кто его поднимает - лень, но надо все-таки как-то сделать, чтобы не поднялся.
Решение до безобразия просто - переименовать файлик McShield.exe так, чтобы пытающийся поднять его не нашел. 
Итак, файлик "C:\Program Files (x86)\McAfee\VirusScan Enterprise\x64\McShield.exe" (путь можно посмотреть в свойствах сервиса "McAfee McShield") переименовываем в то, что нравится, - я добавил единичку в конце. Больше McAfee меня не беспокоил.

Важно: Когда закончили свои занимательные упражнения - обязательно переименуйте файлик обратно, - крайне не рекомендую отключать антивирус навсегда!

Thursday, July 10, 2014

Измена или глупость?

Не перестаю удивляться странностям государственных подходов к ИБ. То мы всей страной покупаем и внедряем Apple с iOS, а после появления Сноудена, переходим на Samsung с Android... хотя ежу понятно, беря во внимание что Samsung - южнокорейская фирма, а Android - производства Google, вероятность существования там закладок ни чуть не меньше, чем в iOS. Полагаю, была команда что-то сделать - что-то сделали (стандартный министерский подход: ориентация не на результат (как видно, - он тот же: закладки американской фирмы Apple заменили на закладки американской фирмы Google), а на процесс: по проблеме что-то сделали).

И вот новый перл: товарищи сделали отечественный планшет на отечественной ОС. В заметке есть фрагмент, который только сейчас открыл мне глаза. Основное выделено жирным:
"....Причем на фоне череды скандалов, которые сотрясают Европу (прослушивание телефона Меркель, как вариант), понятно, что закладки в подобной технике есть по умолчанию. Выбор поставщика, который имеет давние и тесные отношения с Министерством обороны США, выглядит, как минимум, странно, хотя тут самое время вспомнить о вредителях и осознанных шагах, направленных на подрыв обороноспособности страны. Хотя это может быть и просто обыкновенное отсутствие профессионализма в своей области, что еще страшнее."
В данном случае страшнее как раз не отсутствие профессионализма (или откровенная глупость), а напротив - умышленное вредительство.
Когда я только начинал взаимодействовать с гос* я не раз удивлялся тому насколько непрофессиональны используемые подходы, насколько неэффективные решения принимаются. Я удивлялся тому, почему из множества различных вариантов решения проблемы, в госкомпании выбирают наихудший сценарий, и как все эти люди, которые эти решения принимают, смогли так сконцентрироваться: все вокруг государства и ключевых государственных предприятий. Да и не могут быть люди настолько непрофессиональны... И только теперь до меня дошло: действительно, люди не могут быть настолько непрофессиональны, напротив, они профессионалы, но у них другая цель - вредить Стране. Это заслацы-вредители, которых внедрили во все сферы наших высоких технологий, поставили у руля подразделений ИБ крупнейших госкомпаний, внедрили в Регуляторов. Тогда все сходится: глупые, неэффективные решения имеют цель разрушить ИТ и ИБ Страны (по крайней мере не развиваться в ногу со временем) и маскируются под непрофессионализм, что создает почву для бесконечного троллинга в Сети (ситуация чем-то напоминает многочисленные высказывания Дженифер Саки об Украине, России, Белоруссии и мире вообще: как бы не комичны были эти заявления, США продолжают творить что хотят. Иногда я думаю, что США специально провели конкурс по всей Америке, чтобы найти госпожу Саки и выставить ее на всеобщее обозрение, и тем самым продемонстрировать всему миру, что им абсолютно фиолетово что о них думают в мире и ничто их не остановит (как не остановит американский флот отсутствие морских границ у Белоруссии). Теперь все сходится: решения, которые порою идут в разрез с общей логикой (тут даже не до профессионализма) также легко объясняются злым умыслом.
Остается ждать и надеяться, что когда-нибудь на место этих вредителей, маскирующихся под непрофессионалов придут профессионалы-патриоты, и все будет по-другому, лучше, и нам не придется краснеть за супер-пупер защищенный планшет, с которого даже не потрудились оттереть надпись "Motorola".

Monday, July 7, 2014

Перлюстрация почты. Заметка 2.

Итак, вся почта, отправляемая сотрудниками, складывается в каталог /var/mail/mailarchive, о чем мы написали в файле /etc/exim4/systemfilter.txt.
Почта раскладывается по каталогам, имена которых равны электронному адресу. 
Чтобы прочесть накопленное можно переименовать собранные файлы в файлы с расширением eml и скормить их ОС Windows.
Но мне больше нравится следующий способ:
Нужные файлы я копирую в специально выделенную папочку, при этом переименовывая их в файлы с цифровым названием:
let j=1; for i in `ls | grep -v make`; do mv $i $j; let j=$j+1; done; chmod a+r *
Затем либо на сервере либо удаленно запускаем почтовый клиент claws-mail который настраиваем таким образом, чтобы "специально выделенная папочка" являлась одним из каталогов, где хранится почта. У меня это сделано с сервера сбора почты на локальную машину через sshfs. Наслаждаемся интерфейсом.
А есть еще способ, который позволяет вам не прикасаться к собранным данным.
В /etc/crontab добавляем строку:
50 23   * * *   root    /mailmonitor_copy
Сам скрипт mailmonitor_copy наполняем следующими строчками:
#!/bin/bash
UserName="VICTIM_WITHOUT_DOMAIN"
Recipient="READER_WITHOUT_DOMAIN"

let j=1;

for i in `find  /var/mail/mailarchive/$UserName@DOMAIN/new -name *.`hostname`* -mtime -1`; do
    cp $i /tmp/$j.eml;

    PATH/mail -f $Recipient@DOMAIN -t $Recipient@DOMAIN -s "message $j of user $UserName" -a /tmp/$j.eml
    rm /tmp/$j.eml;
    let j=$j+1;
done

if [[ $j == 1 ]]; then
   
/mail -f  $Recipient@DOMAIN -t $Recipient@DOMAIN -s "No mail from $UserName at `date +%F`"
fi


И под завязку скрипт, который отправляет почту (он в предыдущем скрипте отмечен как PATH/mail и взят откуда-то с просторов интернета и доработан много лет назад. Силен он тем, что позволяет отправлять почту с приложениями.

#!/usr/bin/perl

use Net::SMTP;
use Getopt::Std;

$boundary="Message-Boundary-20030214";

getopt('ftsba', \%args);

if (!($args{f} and $args{t} and $args{s} )) {
    usage();
    exit;
}

if ($args{f}) {
    $from = $args{f};
}
if ($args{t}) {
    $to = $args{t};
}
if ($args{s}) {
    $subject = $args{s};
}
if ($args{b}) {
    $plain_text_message = $args{b};
}
if ($args{a}) {
    $attachment = $args{a};
    @_array = split("/", $attachment);
    $attachment_name = $_array[scalar(@_array)-1];
}

# Constructors
$smtp = Net::SMTP->new('localhost');

$smtp->mail($from);
$smtp->to($to);

push(@message, "Date: ".`date --rfc-822`);
push(@message, "To: $to\n");
push(@message, "From: $from\n");
push(@message, "Subject: $subject\n");
push(@message, "MIME-Version: 1.0\n");

#push(@message, "Content-Type: text/plain;");
#push(@message, "        charset=\"koi8-r\"");
#push(@message, "Content-Transfer-Encoding: 8bit");

push(@message, "Content-type: Multipart/mixed;\n");
push(@message, "\tboundary=\"$boundary\"\n");
push(@message, "\n");
push(@message, "This is a multi-part message in MIME format.\n");
push(@message, "\n");
push(@message, "--$boundary\n");

##  Print out any text message sent with the email
if ($plain_text_message){
    push(@message,"Content-type: text/plain; charset=koi8-r\n");
    push(@message,"Content-transfer-encoding: 7bit\n");
    push(@message,"\n");
    push(@message,$plain_text_message);
    push(@message, "\n");
}


if ($attachment) {
    push(@message,"--$boundary\n");
    ##  Print the header for that attachment.
    push(@message, "Content-type: application/octet-stream;\n name=\"$attachment_name\"\n");
    push(@message, "Content-Disposition: attachment;\n filename=\"$attachment_name\"\n");
    push(@message,"Content-transfer-encoding: BASE64\n");
    push(@message,"\n");

    ##  Send out the contents!!
    ## Store the new line character
    $_nl=$/;
    undef $/;
    open(FL,$attachment) || die $!;
    binmode (FL);
    $some_text=; ## Read the entire file contents into the variable

    close(FL);
    $/=$_nl; ## Restore the new line character.

    $some_text=encode_base64($some_text);
    push(@message,$some_text);
}

push(@message,"\n");
push(@message,"--$boundary--\n");

##     Indicte Start of the DATA header & send the message
$smtp->data(@message);


##     Close the connection
$smtp->quit;



sub encode_base64 ($;$){
 my $res = "";
 my $eol = $_[1];
 $eol = "\n" unless defined $eol;
 pos($_[0]) = 0;                          # ensure start at the beginning
 while ($_[0] =~ /(.{1,45})/gs) {
   $res .= substr(pack('u', $1), 1);
   chop($res);
 }
 $res =~ tr|` -_|AA-Za-z0-9+/|;               # `# help emacs
 # fix padding at the end
 my $padding = (3 - length($_[0]) % 3) % 3;
 $res =~ s/.{$padding}$/'=' x $padding/e if $padding;
 # break encoded string into lines of no more than 76 characters each
 if (length $eol) {
   $res =~ s/(.{1,76})/$1$eol/g;
 }
 $res;
}

sub usage () {
    print "Usage: mail [-f from] [-t to] [-s subject] <-b body=""> <-a attachment_file="">\n";
}

Tuesday, June 10, 2014

Opensource vs. Non-opensource

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

Tuesday, June 3, 2014

Перлюстрация почты. Заметка 1.

Продолжим попирать свободы разных типов и видов, в условиях недостаточного финансирования.

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

Разворачиваем циновки, достаем бубны и призываем на помощь уже не раз выручившую нас юникс-подобную операционную систему. На нее устанавливаем любой почтовый сервер. На подвернувшемся мне под руку Debian оказался Exim, который переводим в режим satellite. Что же, пусть он немного послужит силам, которые сложно однозначно идентифицировать.

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

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

Для работы с «улетающей» почтой используем механизм «system-wide message filtering» характерный тем, что правило срабатывает 1 раз для сообщения независимо от количества адресатов и работает оно до роутинга.

Начнем с файла /etc/exim4/conf.d/main/ 01_exim4-config_listmacrosdefs, вставив в него пару строк (на самом деле их вставить можно куда угодно, но тут мне кажется, их легче найти через пару лет):

system_filter = /etc/exim4/systemfilter.txt
system_filter_directory_transport = local_copy_outgoing


Тут мы определили, где будет прописано наше правило и транспорт для сохранения писем.

Теперь создадим файл /etc/exim4/systemfilter.txt и запишем в нем следующее:

if $sender_address_domain is and not $sender_address is
then
    save /var/mail/mailarchive/$sender_address/
elif $sender_address is
then
    finish
else
    seen finish
endif


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

Как, сохраняя свою совесть чистой, отправлять собираемую информацию руководству, в следующей серии.

PS. Не считаю зазорным постоянно напоминать сотрудникам о том, что их почта собирается и может быть прочитана сотрудниками службы безопасности или их руководством. Рекомендую делать это регулярно, даже если почта не собирается - береженого бог бережет.

Monday, May 26, 2014

PHDaysIV

В прошлый четверг выступали на конференции.

В двух словах доклад был посвящен  взлому генераторов java.util.Random и java.security.SecureRandom . Первый из них является криптографически нестойким, второй - криптографически стойким, внутри у него нормальная хеш-функция, типа SHA-1. Помимо рассказа о том, как можно атаковать генераторы, были продемонстрированы атаки на реальные приложения их использующие.

В случае Random атаковывалось внутреннее состояние генератора - по выходной последовательности оно восстанавливалось, что позволяло в последствии генерить такой же выход, что и в случае атакуемого приложения. Были предложены методы, позволяющее атаковать внутреннее состояние более эффективно, чем полным перебором. Важно отметить, что атака на выход метода .nextInt(limit) для четного limit не разработана нами и была известно ранее, однако, для нечетного limit и для limit, представляющего собой степень 2 - наше изобретение. Выходы методов .nextLong() и .nextInt() так реализованы, что они в "в лоб" перебираются мгновенно.

Для случая SecureRandom атаковывалось первоначальное состояние генератора, seed, то, чем он был инициализирован. Исследовать безопасность SHA-1 мы посчитали бесперспективным. Здесь проблема в том, что есть немало приложений в которых инициализация производится коротким seed который либо просто известен, либо эффективно перебирается - такие приложения были найдены, а их взлом продемонстрирован в демонстрациях.

Все коды, которые мы написали в рамках этого небольшого исследования доступны в GitHib - https://github.com/votadlos/JavaCG.

Презентация:



Демонстрации, доступны в Мишином канале YouTube:
http://www.youtube.com/watch?v=mdOfZMsj4hA 
http://www.youtube.com/watch?v=BwXhpjiCTyA 
http://www.youtube.com/watch?v=B3EkrmNWeJs 
http://www.youtube.com/watch?v=--ZuBUc2F2Y 

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