Эта статья написана под впечатлением от статьи "OSSIM — разворачиваем комплексную open source систему управления безопасностью". Я не буду повторяться и описывать сам процесс установки системы. Я хочу только внести некоторые уточнения и пояснения связанные с практическим опытом применения OSSIM.
В любой инструкции вы прочитаете, что «однозначно на виртуалку». Мой ответ: «однозначно на железо». Оба ответа верны. Почему?
Первый ответ верен, поскольку OSSIM устанавливается «в комплекте» с операционной системой и диск с образом может не содержать драйверов, необходимых для вашего железа. Если вы с этим столкнетесь, то это будет ваша проблема, которую вам придется решать самостоятельно. Установка на виртуальную машину обеспечивает некоторую универсальность и отсутствие проблем. Кроме того, нет никакой гарантии, что после апдейта проблемы не придется решать заново. Существуют официальные коммерческие «железные реализации», которые продаются в виде appliance и, соответственно, поддерживаются, но мы смотрим на Open Source OSSIM и здесь все проблемы железа — это ваши проблемы.
Второй ответ верен, поскольку любой гипервизор — это тормоза. Поборники всеобщей виртуализации могут сколько угодно трубить в трубы, бить в барабаны, размахивать флагами, но гипервизоры резко снижают производительность гостевой системы. Как правило, этим можно пренебречь, но OSSIM любит скорость. В результате самосборный на баребоне мини-компьютер с 4-ядерным атомом, 16ГБ DDR3 и SSD 128GB SATA3 уделает виртуалку на HP dl380 легко. Виртуальной машине вы должны будете дать гораздо больше ресурсов, чем потребуется физической. И это обойдется дороже. А что касается драйверов, при установке вам будет предложено вставить флешку с драйверами, если это потребуется.
Важно. На железной машине установщик запустится только с загрузочного CD. Если вы зальете образ на флэшку, установка OSSIM не произойдет, но вы сможете поставить Debian.
Очень важно. Никогда не пытайтесь поставить OSSIM «второй системой» на рабочий компьютер. Установщик считает, что его ставят на голую машину и не задает идиотских вопросов «как разбить диск на разделы?». Первым делом он без спросу перезапишет таблицу разделов и отформатирует диск.
Установка OSSIM вовсе не занимает «15 минут». Гораздо дольше. На последнем этапе вам даже покажется, что установщик завис и всё пропало. Подождите. Он работает.
Скорость дисковой подсистемы. Правильно использовать SSD. Объемы не важны. 100GB хватит. А вот скорость очень важна. На то есть две причины. Во-первых, текстовые логи, которые поступают на syslog и затем читаются плагинами OSSIM. Во-вторых, база данных, которая крутится на той же машине. SSD радикально повышает производительность системы.
Количество ядер процессора. Не так важна производительность каждого ядра, как важно их количество. OSSIM выполняет очень простые операции, но их сразу много и они могут выполняться параллельно. Это также важно для его Network IDS (Suricata), как известно, она многопоточная.
Объем оперативной памяти. Менее критично, но лучше, чтобы в файл подкачки ничего не выталкивалось.
Подходящая конфигурация для виртуальной машины в расчете на суточный поток в 2 миллиона событий в логах и 10 терабайт трафика на «неразборчивом» интерфейсе: 8 ядер, 16GB. Но это впритык. Ресурсы будут съедены под завязку.
И да, разумеется, неразборчивый интерфейс, на который вы намерены кинуть со спан-порта вашего коммутатора трафик, собранный для анализа сурикатой со всех виланов вашей сети, должен быть 10Gbs. Иначе он просто захлебнется.
Если вы собираетесь управлять сервером OSSIM с машины Windows, вам понадобятся putty и WinSCP. Ну, или FAR, если вы его любите. Приятнее управлять с машины с Ubuntu. По крайней мере не надо каждый раз проверяться не записал ли случайно в какой-нибудь скрипт окончания строк в виде CRLF.
После установки вы не сможете подключиться к серверу по SSH с удаленной машины. В Debian 8 по умолчанию в конфигурации sshd стоит параметр `PermitRootLogin without-password`, его надо поменять в `/etc/ssh/ssh_config` на `PermitRootLogin yes`.
Еще одной важной штукой является правильная конфигурация часового пояса плагинов. Дело в том, что даже когда все источники логов находятся в одном часовом поясе, не обязательно они используют одинаковое локальное время. Например System Center Configuration Manager считает, что время разумно хранить в базе в UTC. И если у вас есть плагин, который читает из его базы новые события (а у меня есть), то вам нужно учитывать, что они записаны не в локальном времени.
Часовой пояс для плагинов устанавливается в двух местах: во-первых, в `/etc/ossim/agent/config.cfg` устанавливается часовой пояс по умолчанию для всех плагинов, во-вторых, его можно переопределить в конфиг-файле каждого отдельного плагина. Определение часового пояса означает инструкцию для генератора плагинов «считать что данные поступают из такого-то часового пояса и конвертировать время в наше». В данном случае «наше» — это локальное время сервера. На самом деле в базу данных время будет записано в UTC, но там есть отдельное поле, в котором будет записано смещение «локальной системы».
Интересные вещи начинаются когда у вас два однотипных источника в разных часовых поясах. Например, вы берете логи маршрутизаторов cisco-asa из разных филиалов. В этом случае вам понадобится обрабатывать их разными плагинами, в конфиг-файлах которых вы укажете разный параметр `tzone=`. Этот параметр задается в секции `[default]`. Я об этом пишу, потому что в документации вы этого не найдете, не знаю почему. Формат POSIX: `tzone=Europe/Moscow`.
Мой ответ: «родным» средством AlienVault HIDS, он же OSSEC. Конечно я это коротко поясню.
Теоретически вы можете использовать любой из многочисленных агентов для отправки журнала событий Windows на syslog или воспользоваться WMI. На OSSIM есть клиент WMI и есть стандартный плагин для чтения логов Windows. Так же есть стандартный плагин для агента SNARE, но если вы имеете дело с русской Windows, то он вам не пригодится. Все дело в том, что SNARE шлет данные с русской Windows в кодировке cp1251, а стандартный парсер для SNARE написан под cp1252. Придется править регулярки.
Но самое интересное начнется когда вы будете собирать логи с «разноязычных» систем. Например, у вас на рабочих станциях русская Windows, а на серверах английская. И как теперь это анализировать? На самом деле это общая проблема для всех SIEM. Решают они ее разными способами. Например, ArcSight применяет довольно замысловатую систему сбора логов Windows, которая позволяет собирать логи только на английском языке не зависимо от локализации системы. OSSEC использует совсем простой прием. При установке агента на Windows в его рабочую директорию записывается csv файл с таблицей строковых сообщений журнала Windows на английском языке. Поэтому «сущностная часть» сообщения, которая нужна для анализа, всегда приходит на одном языке, независимо от локализации системы. А вот «данные» приходят «на языке оригинала». Это довольно удобно.
Кроме того, стандартный плагин для агента OSSEC очень хорошо прописан. Он тщательно разбирает события по типам. Если вы воспользуетесь другим способом сбора логов, вам придется здорово попотеть над раскладыванием событий по полочкам. Ну, и наконец, OSSEC — это не просто «пересылка логов» — это действительно Host IDS и очень даже не плохая. Не даром TrendMicro решила использовать этот движок в своем «продвинутом» антивирусе. И да, OSSEC надежен, как контрольный выстрел. Вы можете спокойно устанавливать агента на любую критичную систему.
И еще. Кролики — это не только ценный мех, но и 3-4 килограмма диетического мяса. OSSEC — это не сборщик логов, он сам по себе SIEM. В OSSIM он передает вовсе не лог Windows, а собственный alert.log, который формируется на основе предварительной обработки событий полученных от агентов. Здесь окажутся, например: события изменения контролируемых файлов, или такие агрегированные события, как «многократная ошибка» или «многократное изменение контрольной суммы ключа в реестре». Он полезнее, чем просто сборщик. OSSEC очень широко распространен по Интернету, его очень часто применяют для защиты веб-серверов, поэтому сообщество большое и активное.
Разумеется вы можете поиграться с другими способами сбора логов Windows. Это интересно.
На Windows машины агент устанавливается с неким файлом конфигурации по умолчанию. Этот файл лежит здесь: `/usr/share/ossec-generator/installer/ossec.conf`. OSSEC поддерживает загрузку конфигураций с сервера. Для этой цели служит файл `/var/ossec/etc/shared/agent.conf`. По умолчанию он отсутствует. Этот файл можно создать из веб-интерфейса консоли OSSIM (Environment — Detection — Agents — agent.conf). Или просто написать в текстовом редакторе.
Здесь должны содержаться в формате XML директивы конфигурации, которые будут «слиты» с локальным файлом конфигурации агента. Блоки директив для разных агентов могут быть помечены, чтобы применяться только к нужным агентам. Допускается пометка по типу ОС, имени агента, имени профиля (в локальном конфиге агента в этом случае должно быть указано имя его профиля).
Таким образом можно изменять конфигурации агентов централизовано и точечно. Термин «слиты» требует уточнения. Что будет, если локальная секция файла конфигурации будет переопределена? Теория гласит, что сначала читается локальный файл, затем серверный, правило считанное последним переопределяет все предыдущие. На практике я никогда не пробовал такое пересечение параметров конфигурации. Просто не было необходимости. Надеюсь, когда понадобится, будет работать так, как я думаю.
Еще один важный момент. В шаблоне для локального конфига агентов указан способ соединения с сервером:
Как видите здесь ip адрес. Я не знаю почему авторы предпочли такой шаблон. Можно указывать FQDN тогда эта секция должна выглядеть иначе:
Однако так не сделано. Это значит, что при смене ip адреса сервера, все агенты отвалятся. Не очень хорошая идея. Конечно, SIEM это не такое устройство, на котором меняют ip адрес, но как-то неприятно. Конечно, можно изменить эту секцию в шаблоне, но, скорее всего, при очередном апдейте шаблон будет сгенерирован заново. Нужно будет постоянно это отслеживать. Меня эта проблема не волнует, поскольку я не имею привычки менять адреса.
На Windows агента удобнее всего ставить с веб-консоли OSSIM, пользуясь кнопкой Automatic deployment. Но при этом вам понадобятся учетные данные локального администратора целевого хоста (или домена). Установка из групповых политик или средствами SCCM весьма затруднительна. Дело в том, что каждый файл установки индивидуален для конкретного хоста, поскольку содержит уникальный ключ для шифрования обмена с сервером. Такая вот секретность на уровне PCI DSS. Печалька.
Для Linux есть возможность работы agentless, но это требует настройки соединений с хостами по SSH. На мой взгляд, это плохая идея. Я предпочитаю ставить агентов. В этом случае совсем ручная установка с компиляцией агента на целевой машине из «сырцов». Официально поддерживается версия 2.8.2, но версия 2.8.3 также работает без проблем. На самом деле есть пакеты для разных систем, например, для Debian. Подробнее смотрите здесь
Нажмите в меню веб-консоли кнопку support и получите ссылки. Обязательно для чтения:
USM 5.x Plugins Management Guide
Customizing Correlation Directives or Cross Correlation Rules
Intrusion Detection in AlienVault
Policy Management Fundamentals
Using USM and OSSIM 5.1 with OTX — AlienVault
Assets, Groups & Networks
System Errors, Warnings and Suggestions
Вроде всем понятно, но, как доходит до дела, оказывается, что люди, по большей части, не верно представляют себе предназначение SIEM. Прежде всего, это не средство защиты. И даже не «система управления безопасностью», уж извините мне заголовок статьи, но не я первый начал. На самом деле, это средство обнаружение удавшихся нарушений защиты. Стандартная схема построения защиты начинается с определения возможных атак (актуальных угроз) и способов их совершения. Затем придумываются и внедряются технические и организационные меры защиты, которые расставляются на возможных «векторах атаки». А после всего этого ставятся «контроли», назначение которых в том, чтобы увидеть, что все ваши меры защиты не работают. Вот к этому классу и относится SIEM.
Вот это и нужно понимать. SIEM предназначен для обнаружения уже случившихся нарушений или обходов защитных мер, как технических, так и организационных. Это что-то вроде системы видеонаблюдения. Прежде всего, вы должны определить по каким признакам вы будете обнаруживать эти нарушения, как SIEM будет выявлять эти признаки, откуда он будет брать необходимую информацию. Нет ли у вас «мертвых зон», которые SIEM не видит. Ситуации могут быть самые неожиданные.
OSSIM сохраняет подозрительный пакет в формате pcap для анализа. Вот он:
А что это было?
А было так. В одной конторе айтишники тестировали какую-то штуковину, которая крутилась в среде сервера приложений tomcat. Они установили эту штуку на первый попавшийся сервер, ясное дело оставив вход на консоль с пустым паролем. По тестировали и забыли. Первым попавшимся оказался сервер служб терминалов. И, как понятно, tomcat работал под учетной записью system. Злой хакер фишингом подсунул трояна на компьютер одного из сотрудников и посмотрел, что полезного есть в сети. Нашел этот забытый веб-сервер и обрадовался. Залил на него библиотеку для поддержки консольных команд. Именно момент тестирования этой библиотеки показан на картинке. Была запущена команда net user, а suricata засвистела увидев в http-responce содержимое вывода этой команды. Пока разбирались, что за фигня, злой хакер уже примостил туда мимикацу и начал собирать пароли пользователей, благо на сервер терминалов они все заходят.
Ситуация очень жизненная. Люди всегда допускают ошибки. Не только айтишники, но и хакеры.
Или вот более простая история. Вот страничка алармов совсем свежая.
Это так называемый OTX Pulse. Вот его детали:
А что это было?
А это браузер одного из сотрудников, когда он просматривал одну из веток форума на сайте bankir.ru, ломанулся на URL owqkq.ne1t3v8.top, а это одна из парковочных страниц, пользующих Angler Exploit Toolkit. Тоже интересная история.
Чтобы не было «мертвых зон», необходимо в первую очередь расставить агентов HIDS (OSSEC) на ВСЕ хосты в сети. Затем, настроить передачу на «неразборчивый» интерфейс OSSIM ВСЕГО трафика вашей внутренней сети, чтобы он обрабатывался NIDS (Suricata). Обязательно настроить и запустить периодическое сканирование уязвимостей сканером OpenVAS по крайней мере всех узлов DMZ. Это важно. Наблюдения показывают, что даже по совсем маленькой компании каждые сутки проходятся 20-50 вражеских сканеров. Будет лучше, если вы обнаружите уязвимость раньше, чем они. Я не преувеличиваю, только преуменьшаю. Вот реальный фрагмент суточного отчета:
И это только та часть, которая относится к известным сообществу злодеям, а есть еще часть отчета со списком неизвестных злодеев. Конечно, большинство из них наседает не сильно. Например: вот так (это вырезка из того же отчета):
Но встречаются и весьма навязчивые личности.
Еще вам понадобятся логи файрволов. Это тот минимум, который есть в любой конторе. А дальше уже внутренние штуки: логи доступа к СУБД и отдельным бизнес-приложениям, логи веб-серверов и т.д. и т.п. Собрать можно всё, что угодно. Если нет стандартного плагина для парсинга логов, очень легко написать свой. Правда легко. Разработка вашего первого плагина не займет у вас больше пары дней. А разработка второго, займет пару часов.
Что касается контроля нарушения организационных мер защиты, вот, например, у вас в конторе запрещено вносить изменения в конфигурацию production среды без согласования службы информационной безопасности. OSSEC просвистит вам о любом изменении конфигурации и вы сможете проверить было оно согласовано или нет. Самое интересное начинается, когда выясняется, что никто это изменение не вносил.
Давать советы о том, какие именно правила контроля надо применять, я не буду. В каждой деревне свои традиции. Если есть вопросы, спрашивайте.
Важно. AlienVault OSSIM — это не только SIEM в классическом понимании. Это целая этажерка, в которую входят: Host IDS, Network IDS, Wireless IDS, Volnurability Scaner, NetFlow Collector. То есть, это полный классический набор «контролей» для организации видеонаблюдения за сетью компании.
Если вам кажется, что-то работает не так, надо начинать смотреть логи. Где?
Логи OSSEC и ошибки:
`/var/ossec/logs/ossec.log`- здесь вы увидите ошибки OSSEC. Самая распространенная ошибка — это потеря связи с агентом, бывает при каких-нибудь фатальных сбоях коммуникации по сети, или после переустановки агента. Редкая, но при большом количестве агентов может быть не такой уж редкой. Если на консоли вы видите, что какой-либо агент не активен, а вы знаете, что компьютер включен, значит вам сюда. В логе ошибка выглядит как `ERROR: Duplicated counter for 'agent-name'`. Устраняется просто. На веб-консоли (environment — detection — agents) или в файле `/var/ossec/etc/client.keys` ищем агента с этим именем и смотрим его номер (число в самой левой колонке). Затем лезем в каталог `/var/ossec/queue/rids` и удаляем в нем файл с именем — номером агента. Заходим SSH на консоль сервера, выходим в командную строку и делаем `/etc/init.d/ossec restart`. Все дела. Честно говоря, других ошибок с OSSEC я и не видел.
`/var/ossec/logs/alerts/alerts.log`- это лог в который OSSEC складывает разжеванные события от агентов, именно отсюда OSSIM читает события и обрабатывает их плагином для OSSEC. Здесь вы можете посмотреть, что туда валится и как это выглядит.
Остальные логи в традиционной `/var/log` из них полезные `/var/log/alienvault/agent/agent.log` и там же `agent_error.log`. Они могут пригодиться при отладке собственных плагинов. Учтите, что на рабочей системе размер `agent.log` исчисляется гигабайтами.
Каких-то серьезных ошибок в работе OSSIM я никогда не наблюдал. Один раз после очередного апдейта системы перестал работать регулярный бэкап. Оказалось они неверно назначили права на один из файлов. Это исправили буквально на следующие сутки. Информация о таких проблемах проходит на форуме сообщества. Еще один раз, после очередного апдейта, перестали работать следующие апдейты. В этот раз пришло оповещение, что апдейт, который выложили четыре часа назад содержит баг и вот его надо устранить таким-то образом, а вот исправленный апдейт был выложен в такое-то время. Кстати, если апдейт стандартными средствами (из веб или ssh консоли) валится и не работает, его можно выполнить командами
с консоли сервера.
Пожалуй, это всё, что я хотел сказать. И главное. Это Open Source. Чего бы вам не захотелось — Python с вами. А если вы не хотите, чтобы он был с вами, смотрите на коммерческую версию — Python с ними. И здесь мы подходим к последнему вопросу.
Мой ответ: если вам нужен SIEM для нужд компании, то Enterprise. У вас никогда не хватит человеческих и технических ресурсов, чтобы довести Open Source версию до уровня Enterprise, конечно, если ваша компания не ставит целью разработку собственного SIEM. Но, если это не ваш бизнес, займитесь своим. К сожалению, любой Enterprise SIEM стоит очень дорого. Но они стоят так дорого не потому, что у них какие-то необыкновенные движки сервера корреляции, а потому что в них вложены огромные затраты на создание библиотек правил корреляции событий, анализ «сигнатур» сложных атак и способов их обнаружения, отладку этих способов. Это та работа, которую вы не сможете выполнить самостоятельно. Я не хочу здесь распространяться о преимуществах коммерческих продуктов, мне эти преимущества кажутся очевидными и не стоящими обсуждения.
Так почему я трачу время на этот Open Source? Во-первых, он мне нравится. Из всех подобных Open Source проектов, этот удачный. Во-вторых, на сайте компании AlienVault написано что-то вроде «мы хотим сделать безопасность доступной для всех». Неплохая идея. Поддерживаю. Очень многие компании просто никак не могут себе позволить купить коммерческий продукт этого класса. Я знаю, что есть целая армия сисадминов-фрилансеров, назовем их так, обслуживающих небольшие компании. Им есть смысл посмотреть в эту сторону. Я ведь не зря в самом начале упомянул мини-компьютер. Маленький SIEM — это вполне реальная штука.
Этерпрайзу — энтерпрайзово, а комьюнити — комьюнитево. Землю — крестьянам, фабрики — рабочим, деньги — банковским служащим. «Счастья всем, и чтобы на всех хватило» (А. и Б. Стругацкие. «Пикник на обочине»).
Использованные источники:
https://www.alienvault.com/documentation
https://alienvault.ru/open-threat-exchange/
http://ossec.github.io/docs/
http://suricata-ids.org/docs/
На что ставить? Железо или виртуалка?
В любой инструкции вы прочитаете, что «однозначно на виртуалку». Мой ответ: «однозначно на железо». Оба ответа верны. Почему?
Первый ответ верен, поскольку OSSIM устанавливается «в комплекте» с операционной системой и диск с образом может не содержать драйверов, необходимых для вашего железа. Если вы с этим столкнетесь, то это будет ваша проблема, которую вам придется решать самостоятельно. Установка на виртуальную машину обеспечивает некоторую универсальность и отсутствие проблем. Кроме того, нет никакой гарантии, что после апдейта проблемы не придется решать заново. Существуют официальные коммерческие «железные реализации», которые продаются в виде appliance и, соответственно, поддерживаются, но мы смотрим на Open Source OSSIM и здесь все проблемы железа — это ваши проблемы.
Второй ответ верен, поскольку любой гипервизор — это тормоза. Поборники всеобщей виртуализации могут сколько угодно трубить в трубы, бить в барабаны, размахивать флагами, но гипервизоры резко снижают производительность гостевой системы. Как правило, этим можно пренебречь, но OSSIM любит скорость. В результате самосборный на баребоне мини-компьютер с 4-ядерным атомом, 16ГБ DDR3 и SSD 128GB SATA3 уделает виртуалку на HP dl380 легко. Виртуальной машине вы должны будете дать гораздо больше ресурсов, чем потребуется физической. И это обойдется дороже. А что касается драйверов, при установке вам будет предложено вставить флешку с драйверами, если это потребуется.
Важно. На железной машине установщик запустится только с загрузочного CD. Если вы зальете образ на флэшку, установка OSSIM не произойдет, но вы сможете поставить Debian.
Очень важно. Никогда не пытайтесь поставить OSSIM «второй системой» на рабочий компьютер. Установщик считает, что его ставят на голую машину и не задает идиотских вопросов «как разбить диск на разделы?». Первым делом он без спросу перезапишет таблицу разделов и отформатирует диск.
Установка OSSIM вовсе не занимает «15 минут». Гораздо дольше. На последнем этапе вам даже покажется, что установщик завис и всё пропало. Подождите. Он работает.
Самые важные ресурсы для OSSIM в порядке убывания значимости
Скорость дисковой подсистемы. Правильно использовать SSD. Объемы не важны. 100GB хватит. А вот скорость очень важна. На то есть две причины. Во-первых, текстовые логи, которые поступают на syslog и затем читаются плагинами OSSIM. Во-вторых, база данных, которая крутится на той же машине. SSD радикально повышает производительность системы.
Количество ядер процессора. Не так важна производительность каждого ядра, как важно их количество. OSSIM выполняет очень простые операции, но их сразу много и они могут выполняться параллельно. Это также важно для его Network IDS (Suricata), как известно, она многопоточная.
Объем оперативной памяти. Менее критично, но лучше, чтобы в файл подкачки ничего не выталкивалось.
Подходящая конфигурация для виртуальной машины в расчете на суточный поток в 2 миллиона событий в логах и 10 терабайт трафика на «неразборчивом» интерфейсе: 8 ядер, 16GB. Но это впритык. Ресурсы будут съедены под завязку.
И да, разумеется, неразборчивый интерфейс, на который вы намерены кинуть со спан-порта вашего коммутатора трафик, собранный для анализа сурикатой со всех виланов вашей сети, должен быть 10Gbs. Иначе он просто захлебнется.
Если вы собираетесь управлять сервером OSSIM с машины Windows, вам понадобятся putty и WinSCP. Ну, или FAR, если вы его любите. Приятнее управлять с машины с Ubuntu. По крайней мере не надо каждый раз проверяться не записал ли случайно в какой-нибудь скрипт окончания строк в виде CRLF.
После установки вы не сможете подключиться к серверу по SSH с удаленной машины. В Debian 8 по умолчанию в конфигурации sshd стоит параметр `PermitRootLogin without-password`, его надо поменять в `/etc/ssh/ssh_config` на `PermitRootLogin yes`.
Time Zone
Еще одной важной штукой является правильная конфигурация часового пояса плагинов. Дело в том, что даже когда все источники логов находятся в одном часовом поясе, не обязательно они используют одинаковое локальное время. Например System Center Configuration Manager считает, что время разумно хранить в базе в UTC. И если у вас есть плагин, который читает из его базы новые события (а у меня есть), то вам нужно учитывать, что они записаны не в локальном времени.
Часовой пояс для плагинов устанавливается в двух местах: во-первых, в `/etc/ossim/agent/config.cfg` устанавливается часовой пояс по умолчанию для всех плагинов, во-вторых, его можно переопределить в конфиг-файле каждого отдельного плагина. Определение часового пояса означает инструкцию для генератора плагинов «считать что данные поступают из такого-то часового пояса и конвертировать время в наше». В данном случае «наше» — это локальное время сервера. На самом деле в базу данных время будет записано в UTC, но там есть отдельное поле, в котором будет записано смещение «локальной системы».
Интересные вещи начинаются когда у вас два однотипных источника в разных часовых поясах. Например, вы берете логи маршрутизаторов cisco-asa из разных филиалов. В этом случае вам понадобится обрабатывать их разными плагинами, в конфиг-файлах которых вы укажете разный параметр `tzone=`. Этот параметр задается в секции `[default]`. Я об этом пишу, потому что в документации вы этого не найдете, не знаю почему. Формат POSIX: `tzone=Europe/Moscow`.
Чем лучше собирать логи Windows?
Мой ответ: «родным» средством AlienVault HIDS, он же OSSEC. Конечно я это коротко поясню.
Теоретически вы можете использовать любой из многочисленных агентов для отправки журнала событий Windows на syslog или воспользоваться WMI. На OSSIM есть клиент WMI и есть стандартный плагин для чтения логов Windows. Так же есть стандартный плагин для агента SNARE, но если вы имеете дело с русской Windows, то он вам не пригодится. Все дело в том, что SNARE шлет данные с русской Windows в кодировке cp1251, а стандартный парсер для SNARE написан под cp1252. Придется править регулярки.
Но самое интересное начнется когда вы будете собирать логи с «разноязычных» систем. Например, у вас на рабочих станциях русская Windows, а на серверах английская. И как теперь это анализировать? На самом деле это общая проблема для всех SIEM. Решают они ее разными способами. Например, ArcSight применяет довольно замысловатую систему сбора логов Windows, которая позволяет собирать логи только на английском языке не зависимо от локализации системы. OSSEC использует совсем простой прием. При установке агента на Windows в его рабочую директорию записывается csv файл с таблицей строковых сообщений журнала Windows на английском языке. Поэтому «сущностная часть» сообщения, которая нужна для анализа, всегда приходит на одном языке, независимо от локализации системы. А вот «данные» приходят «на языке оригинала». Это довольно удобно.
Кроме того, стандартный плагин для агента OSSEC очень хорошо прописан. Он тщательно разбирает события по типам. Если вы воспользуетесь другим способом сбора логов, вам придется здорово попотеть над раскладыванием событий по полочкам. Ну, и наконец, OSSEC — это не просто «пересылка логов» — это действительно Host IDS и очень даже не плохая. Не даром TrendMicro решила использовать этот движок в своем «продвинутом» антивирусе. И да, OSSEC надежен, как контрольный выстрел. Вы можете спокойно устанавливать агента на любую критичную систему.
И еще. Кролики — это не только ценный мех, но и 3-4 килограмма диетического мяса. OSSEC — это не сборщик логов, он сам по себе SIEM. В OSSIM он передает вовсе не лог Windows, а собственный alert.log, который формируется на основе предварительной обработки событий полученных от агентов. Здесь окажутся, например: события изменения контролируемых файлов, или такие агрегированные события, как «многократная ошибка» или «многократное изменение контрольной суммы ключа в реестре». Он полезнее, чем просто сборщик. OSSEC очень широко распространен по Интернету, его очень часто применяют для защиты веб-серверов, поэтому сообщество большое и активное.
Разумеется вы можете поиграться с другими способами сбора логов Windows. Это интересно.
Кое-что о конфигурации агентов OSSEC
На Windows машины агент устанавливается с неким файлом конфигурации по умолчанию. Этот файл лежит здесь: `/usr/share/ossec-generator/installer/ossec.conf`. OSSEC поддерживает загрузку конфигураций с сервера. Для этой цели служит файл `/var/ossec/etc/shared/agent.conf`. По умолчанию он отсутствует. Этот файл можно создать из веб-интерфейса консоли OSSIM (Environment — Detection — Agents — agent.conf). Или просто написать в текстовом редакторе.
Здесь должны содержаться в формате XML директивы конфигурации, которые будут «слиты» с локальным файлом конфигурации агента. Блоки директив для разных агентов могут быть помечены, чтобы применяться только к нужным агентам. Допускается пометка по типу ОС, имени агента, имени профиля (в локальном конфиге агента в этом случае должно быть указано имя его профиля).
<agent_config name="agent001|agent002|agent018">
настройки
</agent_config>
<agent_config os="Linux|FreeBSD">
настройки
</agent_config>
<agent_config os="Windows">
настройки
</agent_config>
<agent_config profile="web-server">
настройки
</agent_config>
Таким образом можно изменять конфигурации агентов централизовано и точечно. Термин «слиты» требует уточнения. Что будет, если локальная секция файла конфигурации будет переопределена? Теория гласит, что сначала читается локальный файл, затем серверный, правило считанное последним переопределяет все предыдущие. На практике я никогда не пробовал такое пересечение параметров конфигурации. Просто не было необходимости. Надеюсь, когда понадобится, будет работать так, как я думаю.
Еще один важный момент. В шаблоне для локального конфига агентов указан способ соединения с сервером:
<server-ip>172.17.2.10</server-ip>
<notify_time>120</notify_time>
<time-reconnect>240</time-reconnect>
Как видите здесь ip адрес. Я не знаю почему авторы предпочли такой шаблон. Можно указывать FQDN тогда эта секция должна выглядеть иначе:
<server-hostname>fqdn</server-hostname>
...
Однако так не сделано. Это значит, что при смене ip адреса сервера, все агенты отвалятся. Не очень хорошая идея. Конечно, SIEM это не такое устройство, на котором меняют ip адрес, но как-то неприятно. Конечно, можно изменить эту секцию в шаблоне, но, скорее всего, при очередном апдейте шаблон будет сгенерирован заново. Нужно будет постоянно это отслеживать. Меня эта проблема не волнует, поскольку я не имею привычки менять адреса.
Замечания об установке агентов на хосты
На Windows агента удобнее всего ставить с веб-консоли OSSIM, пользуясь кнопкой Automatic deployment. Но при этом вам понадобятся учетные данные локального администратора целевого хоста (или домена). Установка из групповых политик или средствами SCCM весьма затруднительна. Дело в том, что каждый файл установки индивидуален для конкретного хоста, поскольку содержит уникальный ключ для шифрования обмена с сервером. Такая вот секретность на уровне PCI DSS. Печалька.
Для Linux есть возможность работы agentless, но это требует настройки соединений с хостами по SSH. На мой взгляд, это плохая идея. Я предпочитаю ставить агентов. В этом случае совсем ручная установка с компиляцией агента на целевой машине из «сырцов». Официально поддерживается версия 2.8.2, но версия 2.8.3 также работает без проблем. На самом деле есть пакеты для разных систем, например, для Debian. Подробнее смотрите здесь
Где искать документацию и что лучше почитать
Нажмите в меню веб-консоли кнопку support и получите ссылки. Обязательно для чтения:
USM 5.x Plugins Management Guide
Customizing Correlation Directives or Cross Correlation Rules
Intrusion Detection in AlienVault
Policy Management Fundamentals
Using USM and OSSIM 5.1 with OTX — AlienVault
Assets, Groups & Networks
System Errors, Warnings and Suggestions
Зачем нужен SIEM?
Вроде всем понятно, но, как доходит до дела, оказывается, что люди, по большей части, не верно представляют себе предназначение SIEM. Прежде всего, это не средство защиты. И даже не «система управления безопасностью», уж извините мне заголовок статьи, но не я первый начал. На самом деле, это средство обнаружение удавшихся нарушений защиты. Стандартная схема построения защиты начинается с определения возможных атак (актуальных угроз) и способов их совершения. Затем придумываются и внедряются технические и организационные меры защиты, которые расставляются на возможных «векторах атаки». А после всего этого ставятся «контроли», назначение которых в том, чтобы увидеть, что все ваши меры защиты не работают. Вот к этому классу и относится SIEM.
Вот это и нужно понимать. SIEM предназначен для обнаружения уже случившихся нарушений или обходов защитных мер, как технических, так и организационных. Это что-то вроде системы видеонаблюдения. Прежде всего, вы должны определить по каким признакам вы будете обнаруживать эти нарушения, как SIEM будет выявлять эти признаки, откуда он будет брать необходимую информацию. Нет ли у вас «мертвых зон», которые SIEM не видит. Ситуации могут быть самые неожиданные.
OSSIM сохраняет подозрительный пакет в формате pcap для анализа. Вот он:
А что это было?
А было так. В одной конторе айтишники тестировали какую-то штуковину, которая крутилась в среде сервера приложений tomcat. Они установили эту штуку на первый попавшийся сервер, ясное дело оставив вход на консоль с пустым паролем. По тестировали и забыли. Первым попавшимся оказался сервер служб терминалов. И, как понятно, tomcat работал под учетной записью system. Злой хакер фишингом подсунул трояна на компьютер одного из сотрудников и посмотрел, что полезного есть в сети. Нашел этот забытый веб-сервер и обрадовался. Залил на него библиотеку для поддержки консольных команд. Именно момент тестирования этой библиотеки показан на картинке. Была запущена команда net user, а suricata засвистела увидев в http-responce содержимое вывода этой команды. Пока разбирались, что за фигня, злой хакер уже примостил туда мимикацу и начал собирать пароли пользователей, благо на сервер терминалов они все заходят.
Ситуация очень жизненная. Люди всегда допускают ошибки. Не только айтишники, но и хакеры.
Или вот более простая история. Вот страничка алармов совсем свежая.
Это так называемый OTX Pulse. Вот его детали:
А что это было?
А это браузер одного из сотрудников, когда он просматривал одну из веток форума на сайте bankir.ru, ломанулся на URL owqkq.ne1t3v8.top, а это одна из парковочных страниц, пользующих Angler Exploit Toolkit. Тоже интересная история.
Чтобы не было «мертвых зон», необходимо в первую очередь расставить агентов HIDS (OSSEC) на ВСЕ хосты в сети. Затем, настроить передачу на «неразборчивый» интерфейс OSSIM ВСЕГО трафика вашей внутренней сети, чтобы он обрабатывался NIDS (Suricata). Обязательно настроить и запустить периодическое сканирование уязвимостей сканером OpenVAS по крайней мере всех узлов DMZ. Это важно. Наблюдения показывают, что даже по совсем маленькой компании каждые сутки проходятся 20-50 вражеских сканеров. Будет лучше, если вы обнаружите уязвимость раньше, чем они. Я не преувеличиваю, только преуменьшаю. Вот реальный фрагмент суточного отчета:
Коммуникации с известными вредоносными хостами за период 2016:02:18 - 2016:02:19
Время Внешний IP Место Репутация хоста
2016-02-18 09:22:46 180.97.106.37 Nanjing Malicious Host
2016-02-18 09:38:37 216.218.206.123 Fremont Malicious Host
2016-02-18 09:52:57 85.25.214.226 Germany Scanning Host
2016-02-18 10:08:11 146.185.250.105 Saint Petersburg Malicious Host
2016-02-18 10:22:54 178.62.14.193 London Malicious Host
2016-02-18 10:23:24 94.102.49.79 Netherlands Malicious Host
2016-02-18 10:47:52 195.88.209.6 Moscow Malicious Host
2016-02-18 10:53:29 222.186.34.177 Nanjing Malicious Host
2016-02-18 11:07:48 71.6.135.131 San Diego Malicious Host
2016-02-18 11:58:17 193.105.134.220 Sweden Malicious Host
2016-02-18 11:58:51 62.210.206.219 France Malicious Host
2016-02-18 12:28:13 193.109.69.150 Russia Malicious Host
2016-02-18 12:43:40 216.218.206.96 Fremont Malicious Host
2016-02-18 13:08:50 209.126.124.67 St Louis Malicious Host
2016-02-18 13:53:19 178.33.17.241 France Malicious Host
2016-02-18 14:23:52 198.20.70.114 Chicago Malicious Host
2016-02-18 14:32:49 104.219.238.10 Rye Malicious Host Scanning Host
2016-02-18 14:38:38 198.23.112.119 Dallas Scanning Host
2016-02-18 15:02:58 198.20.69.98 Chicago Malicious Host
2016-02-18 15:03:29 64.125.239.136 United States Malicious Host
2016-02-18 15:28:35 162.248.74.2 Clarks Summit Malicious Host
2016-02-18 15:43:36 222.174.5.28 Jinan Malicious Host
2016-02-18 15:57:42 66.240.236.119 San Diego Malicious Host
2016-02-18 16:13:09 74.82.47.45 Fremont Malicious Host
2016-02-18 16:13:44 64.125.239.92 United States Malicious Host
2016-02-18 17:07:57 142.54.162.74 Kansas City Malicious Host
2016-02-18 17:22:41 64.125.239.107 United States Malicious Host
2016-02-18 17:58:54 23.239.66.99 United States Malicious Host
2016-02-18 18:07:50 61.216.2.14 Taiwan Malicious Host
2016-02-18 18:08:03 198.20.69.74 Chicago Malicious Host
2016-02-18 18:08:18 141.212.122.84 Ann Arbor Malicious Host
2016-02-18 18:08:18 141.212.122.81 Ann Arbor Malicious Host
2016-02-18 19:52:53 185.94.111.1 Russia Malicious Host
2016-02-18 19:58:27 162.244.35.24 United States Malicious Host
2016-02-18 20:23:00 162.244.35.22 United States Malicious Host
2016-02-18 20:23:37 89.248.160.192 Netherlands Malicious Host
2016-02-18 20:43:55 222.174.5.17 Jinan Malicious Host
2016-02-18 21:23:55 185.130.5.201 Republic of Lithuania Malicious Host
2016-02-18 21:47:39 92.60.184.34 Ukraine Scanning Host
2016-02-18 22:33:48 209.126.102.181 St Louis Malicious Host
2016-02-18 22:57:37 71.6.167.142 San Diego Malicious Host
2016-02-18 23:13:37 212.83.148.78 France Malicious Host
2016-02-19 00:07:54 185.130.5.240 Republic of Lithuania Scanning Host
2016-02-19 00:48:22 64.125.239.224 United States Malicious Host
2016-02-19 01:13:11 66.240.192.138 San Diego Malicious Host Scanning Host
2016-02-19 02:33:05 198.204.234.74 Kansas City Scanning Host Malicious Host
2016-02-19 02:57:03 104.243.223.8 Tampa Malicious Host
2016-02-19 02:58:02 198.20.99.130 Netherlands Malicious Host
2016-02-19 03:27:43 162.244.35.25 United States Malicious Host
2016-02-19 03:28:13 89.163.251.200 Germany Malicious Host
2016-02-19 04:28:25 71.6.165.200 San Diego Malicious Host
2016-02-19 04:52:08 93.174.93.181 Netherlands Malicious Host
2016-02-19 04:58:24 184.105.247.238 Fremont Malicious Host
2016-02-19 05:23:07 192.162.101.79 Russia Malicious Host
2016-02-19 05:23:20 64.125.239.112 United States Malicious Host
2016-02-19 06:12:43 188.138.1.218 Germany Malicious Host Scanning Host
2016-02-19 06:12:44 74.82.47.55 Fremont Malicious Host
2016-02-19 06:43:55 209.239.123.106 St Louis Malicious Host
2016-02-19 07:13:45 185.56.28.67 Netherlands Malicious Host
2016-02-19 08:13:09 184.105.247.228 Fremont Malicious Host
2016-02-19 08:28:51 184.105.139.72 Fremont Malicious Host
И это только та часть, которая относится к известным сообществу злодеям, а есть еще часть отчета со списком неизвестных злодеев. Конечно, большинство из них наседает не сильно. Например: вот так (это вырезка из того же отчета):
Информация Netflow для 180.97.106.37 : Nanjing : Malicious Host
Время Период Протокол Источник Получатель Пакетов Байт Потоков
2016-02-18 09:22:46.585 0.000 ICMP 91.111.111.9:0 180.97.106.37:3.0 1 56 1
2016-02-18 09:22:46.586 0.000 TCP 180.97.106.37:46024 91.111.111.9:3128 1 40 1
2016-02-18 20:32:23.247 0.000 TCP 180.97.106.37:37254 91.111.111.101:22 1 40 1
2016-02-18 20:43:38.783 0.000 TCP 180.97.106.37:45840 91.111.111.25:22 1 40 1
2016-02-18 20:43:38.783 0.000 ICMP 91.111.111.25:0 180.97.106.37:3.0 3 204 1
2016-02-18 22:07:25.502 0.000 TCP 180.97.106.37:54895 91.111.111.36:22 2 80 1
2016-02-18 22:41:06.739 0.000 TCP 91.111.111.13:22 180.97.106.37:48365 1 40 1
2016-02-18 23:16:01.974 0.996 TCP 180.97.106.37:13302 91.111.111.32:80 10 539 1
2016-02-18 23:16:01.975 0.679 TCP 91.111.111.32:80 180.97.106.37:13302 7 3048 1
2016-02-18 23:20:07.473 0.000 TCP 180.97.106.37:43667 91.111.111.9:22 2 80 1
2016-02-18 23:20:07.473 0.000 ICMP 91.111.111.9:0 180.97.106.37:3.0 1 56 1
2016-02-19 05:50:52.757 12.217 TCP 91.111.111.44:80 180.97.106.37:53461 5 260 1
Но встречаются и весьма навязчивые личности.
Еще вам понадобятся логи файрволов. Это тот минимум, который есть в любой конторе. А дальше уже внутренние штуки: логи доступа к СУБД и отдельным бизнес-приложениям, логи веб-серверов и т.д. и т.п. Собрать можно всё, что угодно. Если нет стандартного плагина для парсинга логов, очень легко написать свой. Правда легко. Разработка вашего первого плагина не займет у вас больше пары дней. А разработка второго, займет пару часов.
Что касается контроля нарушения организационных мер защиты, вот, например, у вас в конторе запрещено вносить изменения в конфигурацию production среды без согласования службы информационной безопасности. OSSEC просвистит вам о любом изменении конфигурации и вы сможете проверить было оно согласовано или нет. Самое интересное начинается, когда выясняется, что никто это изменение не вносил.
Давать советы о том, какие именно правила контроля надо применять, я не буду. В каждой деревне свои традиции. Если есть вопросы, спрашивайте.
Важно. AlienVault OSSIM — это не только SIEM в классическом понимании. Это целая этажерка, в которую входят: Host IDS, Network IDS, Wireless IDS, Volnurability Scaner, NetFlow Collector. То есть, это полный классический набор «контролей» для организации видеонаблюдения за сетью компании.
Траблы и шутинг
Если вам кажется, что-то работает не так, надо начинать смотреть логи. Где?
Логи OSSEC и ошибки:
`/var/ossec/logs/ossec.log`- здесь вы увидите ошибки OSSEC. Самая распространенная ошибка — это потеря связи с агентом, бывает при каких-нибудь фатальных сбоях коммуникации по сети, или после переустановки агента. Редкая, но при большом количестве агентов может быть не такой уж редкой. Если на консоли вы видите, что какой-либо агент не активен, а вы знаете, что компьютер включен, значит вам сюда. В логе ошибка выглядит как `ERROR: Duplicated counter for 'agent-name'`. Устраняется просто. На веб-консоли (environment — detection — agents) или в файле `/var/ossec/etc/client.keys` ищем агента с этим именем и смотрим его номер (число в самой левой колонке). Затем лезем в каталог `/var/ossec/queue/rids` и удаляем в нем файл с именем — номером агента. Заходим SSH на консоль сервера, выходим в командную строку и делаем `/etc/init.d/ossec restart`. Все дела. Честно говоря, других ошибок с OSSEC я и не видел.
`/var/ossec/logs/alerts/alerts.log`- это лог в который OSSEC складывает разжеванные события от агентов, именно отсюда OSSIM читает события и обрабатывает их плагином для OSSEC. Здесь вы можете посмотреть, что туда валится и как это выглядит.
Остальные логи в традиционной `/var/log` из них полезные `/var/log/alienvault/agent/agent.log` и там же `agent_error.log`. Они могут пригодиться при отладке собственных плагинов. Учтите, что на рабочей системе размер `agent.log` исчисляется гигабайтами.
Каких-то серьезных ошибок в работе OSSIM я никогда не наблюдал. Один раз после очередного апдейта системы перестал работать регулярный бэкап. Оказалось они неверно назначили права на один из файлов. Это исправили буквально на следующие сутки. Информация о таких проблемах проходит на форуме сообщества. Еще один раз, после очередного апдейта, перестали работать следующие апдейты. В этот раз пришло оповещение, что апдейт, который выложили четыре часа назад содержит баг и вот его надо устранить таким-то образом, а вот исправленный апдейт был выложен в такое-то время. Кстати, если апдейт стандартными средствами (из веб или ssh консоли) валится и не работает, его можно выполнить командами
apt-get update
apt-get upgrade
с консоли сервера.
Пожалуй, это всё, что я хотел сказать. И главное. Это Open Source. Чего бы вам не захотелось — Python с вами. А если вы не хотите, чтобы он был с вами, смотрите на коммерческую версию — Python с ними. И здесь мы подходим к последнему вопросу.
Open Source или Enterprise?
Мой ответ: если вам нужен SIEM для нужд компании, то Enterprise. У вас никогда не хватит человеческих и технических ресурсов, чтобы довести Open Source версию до уровня Enterprise, конечно, если ваша компания не ставит целью разработку собственного SIEM. Но, если это не ваш бизнес, займитесь своим. К сожалению, любой Enterprise SIEM стоит очень дорого. Но они стоят так дорого не потому, что у них какие-то необыкновенные движки сервера корреляции, а потому что в них вложены огромные затраты на создание библиотек правил корреляции событий, анализ «сигнатур» сложных атак и способов их обнаружения, отладку этих способов. Это та работа, которую вы не сможете выполнить самостоятельно. Я не хочу здесь распространяться о преимуществах коммерческих продуктов, мне эти преимущества кажутся очевидными и не стоящими обсуждения.
Так почему я трачу время на этот Open Source? Во-первых, он мне нравится. Из всех подобных Open Source проектов, этот удачный. Во-вторых, на сайте компании AlienVault написано что-то вроде «мы хотим сделать безопасность доступной для всех». Неплохая идея. Поддерживаю. Очень многие компании просто никак не могут себе позволить купить коммерческий продукт этого класса. Я знаю, что есть целая армия сисадминов-фрилансеров, назовем их так, обслуживающих небольшие компании. Им есть смысл посмотреть в эту сторону. Я ведь не зря в самом начале упомянул мини-компьютер. Маленький SIEM — это вполне реальная штука.
Этерпрайзу — энтерпрайзово, а комьюнити — комьюнитево. Землю — крестьянам, фабрики — рабочим, деньги — банковским служащим. «Счастья всем, и чтобы на всех хватило» (А. и Б. Стругацкие. «Пикник на обочине»).
Использованные источники:
https://www.alienvault.com/documentation
https://alienvault.ru/open-threat-exchange/
http://ossec.github.io/docs/
http://suricata-ids.org/docs/
