книги хакеры / журнал хакер / 184_Optimized

Kiev n Doolyle @Flkic r.com

Взлом

За высоким забором OSSEC

ШВЕЙЦАРСКИЙ НОЖ ДЛЯ ОБНАРУЖЕНИЯ ВЗЛОМОВ

Даниил Светлов svetlov.pro

ЗНАКОМСТВО

Ну что ж, давай знакомиться, OSSEC — это бесплатная hostbased система обнаружения вторжений, распространяющаяся под лицензией GNU GPLv2. Исходный код проекта можно найти на GitHub’е, а основным спонсором разработки выступает компания Trend Micro.

OSSEC подразумевает несколько вариантов установки. Основные:

•server — возможность анализа локальных логов и приема подключений от агентов и syslog-серверов;

•agent — подключение к серверу и пересылка туда логов для анализа.

Еще есть типы local и hybrid. Local фактически представляет собой сервер без возможности принимать внешние

подключения syslog или агентов, а hybrid — одновременную инсталляцию типов local и agent. Самый часто используемый метод деплоя — клиент-серверный. На отдельную машину устанавливается сервер, на все остальные — агенты. После этого между ними устанавливается защищенное соединение. Агент пересылает на сервер логи для анализа, следит за целостностью файлов, выполняет другие проверки. Сервер, в свою очередь, генерирует сигналы тревоги, записывает эту информацию в лог-файл, базу данных, отправляет на syslogсервер или на почту. Имеется возможность централизовано загружать файл конфигурации агента с сервера.

Что же может предложить этот open source проект? Прежде всего анализ логов, которые генерируются на серверах и сетевом оборудовании. Помимо самого обычного одностроч-

ного syslog, поддерживаются логи Snort (full и fast), Squid, IIS,

Взлом

ТЕСТОВЫЙПОЛИГОН

Развернем OSSEC в небольшой сети, которая позволит использовать максимальное количество функций. Роль межсетевого экрана у нас будет выполнять Cisco ASA, на отдельный сервер, где установлен Snort, зеркалируется весь трафик, проходящий через файрвол. Лог Snort на этом сервере мы будем анализировать с помощью OSSEC. На веб-сервере будем анализировать все логи, проверять сервер на наличие руткитов и целостность файлов. Для отслеживания изменений в конфигурации файрвола используем функцию OSSEC agentless check, а для анализа логов будем отсылать все логи с ASA прямо на сервер OSSEC. Не будем обделять вниманием и Windows-сегмент нашей сети. Установим на Windowsсерверы агент OSSEC и подключим необходимые каналы

Eventlog. Поехали!

УСТАНОВКАСЕРВЕРА

До последнего времени OSSEC распространялась в виде архива с исходниками и скриптом инсталляции. При этом во время установки происходила компиляция всех файлов. Это, конечно же, подразумевает установку компилятора на сервер, куда мы устанавливаем OSSEC. Около года назад пакеты для RHEL, CentOS и Fedora появились в репозитории компании Atomicorp, которая занимается разработкой защищенного дистрибутива для хостинг-компаний. Так что теперь установить можно и из исходников, и из пакетов. Но при установке из пакетов необходимо учитывать несколько моментов. Первый: многие глобальные параметры OSSEC задаются на этапе компиляции. Естественно, при установке из пакета ты не сможешь их изменить. К таким параметрам относится, например, поддержка сохранения информации о сигналах тревоги

вбазы данных MySQL и PostgreSQL. Второй момент заключается в ванильности сборки. Разработчики из Atomicorp накладывают на оригинальные исходники свои патчи. Чаще всего этот функционал нужен только при использовании OSSEC

вдистрибутиве Atomicorp. В любом случае он меняет поведение OSSEC. Если функционал этих патчей тебе не нужен, а устанавливать все-таки хочется из пакетов, ты можешь скачать Source RPM, отредактировать spec-файл и удалить оттуда применение всех ненужных патчей. Третий момент: пакеты есть только для RPM-based дистрибутивов. Если у тебя Debian, Ubuntu или, например, FreeBSD, ставить придется из исходников.

Итак, поскольку с настройкой стороннего репозитория и установкой оттуда пары пакетов каждый справится, я предлагаю рассмотреть установку из исходников. Качай с официального сайта (www.ossec.net) архив. На данный момент последняя версия 2.7.1. Распаковывай его и запускай install.sh.

Убедись, что install.sh, а также файлы src/InstallServer. sh и src/InstallAgent.sh имеют права на исполнение. Сначала нам необходимо установить серверную часть. Она также будет выполнять функции агента на той системе, куда установлена. Так что устанавливать на сервер OSSEC еще и агент не придется. Для начала установим сервер.

Скрипт инсталляции задаст несколько вопросов. Первый из них — выбор языка, второй — тип инсталляции. Нам нужен тип Server. Далее пойдут вопросы о том, какие использовать функции. Рекомендую ставить все опции по умолчанию за ис-

ключением active responce. Это связано прежде всего с тем, что active responce содержит в себе несколько готовых скриптов, которые она может выполнить при ложном срабатывании правила. Поэтому, пока ты не будешь досконально понимать, как работает данная функция, какие команды выполняет и при каких условиях, не советую ее активировать. После этого инсталлятор совершит первичный поиск логов на твоем сервере. Ему известно расположение всех стандартных логов, поддерживаемых ОС и программ. Если же скрипт не найдет какой-то важный лог, то мы его сможем добавить после инсталляции. После того как вся необходимая информация собрана, начнется компиляция и установка OSSEC.

СКАРМЛИВАЕМЛОГИ

По умолчанию OSSEC устанавливается в папку /var/ossec. Основной конфиг, будь то сервер или агент, находится по пути

/var/ossec/etc/ossec.conf. Посмотри на него внимательно.

Он сгенерирован на основе твоих ответов инсталлятору и найденных логов.

<localfile>

<log_format>syslog</log_format>

<location>/var/log/messages</location>

</localfile>

Разделы localfile указывают тип и расположение логов. Проверь, что для всех системных лог-файлов есть соответствующие записи в конфиге. Если твой сервер работает под управлением CentOS или Debian, то, скорее всего, все логи будут найдены автоматически. Но сейчас, как я говорил, можно добавить недостающие. В путях к файлам логов на *nixсистемах также можно использовать символ * и форматы даты функции языка С strftime. Использование пути /var/log/%Y- %m-%d/*.log будет корректным. Это очень удобно в тех случаях, когда на сервере запущены контейнеры lxc или openvz. Достаточно поставить OSSEC на хостовую машину и указать ей с помощью маски на расположение логов всех контейнеров.

Например, так: /var/lxc/*/rootfs/var/log/*.log. Ставить

OSSEC на каждую виртуальную машину в таком случае не нужно.

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

цию с active responce. Команды active responce срабатывают при каких-то условиях, сигналах тревоги, а команды из localfile выполняются с определенным интервалом. В стандартном конфиге, который генерируется при установке, есть парочка таких команд. Например, очень полезная проверка открытых портов:

Взлом

Настройка агента на Windows

Теперь можно запускать агент. Сразу проверь лог /var/ ossec/log/ossec.log. Там должно быть сообщение об успешном подключении к серверу. Теперь можешь проверить, что алерты генерируются, — зайди по SSH на сервер. На сер-

вере OSSEC в файле /var/ossec/log/alerts/alert.log

должно появиться соответствующее сообщение.

НАСТРОЙКАOSSECДЛЯСЕТЕВЫХУСТРОЙСТВ

С настройкой OSSEC на серверах закончили. Теперь давай настроим работу с сетевыми устройствами. Наша цель — анализ логов, поступающих с файрвола, и контроль изменений конфигурации. Для приема логов на центральном OSSEС-сервере в файл конфигурации необходимо добавить следующие строки:

<remote>

<connection>syslog</connection>

<port>514</port>

<allowed-ips>192.168.1.1</allowed-ips>

</remote>

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

Теперь используем agentless проверку конфигурации. Прежде всего необходимо включить в OSSEС эту опцию. Для это-

го выполни команду /var/ossec/bin/ossec-control enable agentless. Затем необходимо добавить данные аутентификации для нашего устройства. Выполняется это командой /var/

ossec/agentless/register_host.sh add ossec@192.168.1.1 ossec_pass enable_pass. Как ты видишь, необходимо указать два пароля — для пользователя и для enable, если это Ciscoдевайс. Остается добавить в файл конфигурации следующие строки:

<agentless>

<type>ssh_asa-fwsmconfig_diff</type>

<frequency>3600</frequency>

<host>ossec@192.168.8.252</host>

<state>periodic_diff</state>

</agentless>

Обрати внимание, что строка в разделе <host> должна быть такой же, какую ты использовал в последней команде при регистрации хоста. Естественно, пользователь на устройстве должен быть создан, пароль для него установлен такой, как ты указал при регистрации хоста, а с IP-адреса OSSECсервера должен быть разрешен вход по SSH. Теперь можно перезапустить OSSEC и проверить логи.

ИНТЕГРАЦИЯСДРУГИМИСИСТЕМАМИ

Взаимодействие OSSEC с другими системами организуется в основном с помощью анализа лог-файлов или отправки сигналов тревоги по протоколу syslog. Так, чтобы получать уведомления от Snort, необходимо указать агенту OSSEC расположение лог-файла Snort:

<localfile>

<log_format>snort-fast</log_format>

<location>/var/log/snort/alert</location>

</localfile>

Обрати внимание, что Snort может писать логи в разных форматах — full и fast. В OSSEC для них есть разные опции log_format — snort-full и snort-fast соответственно.

В случае c аппаратными IPS необходимо также пересылать их логи с помощью syslog на центральный сервер OSSEC.

OSSEC можно настроить на отправку сигналов тревоги c центрального сервера в SIEM-системы или просто на другой сервер для хранения по протоколу syslog:

<syslog_output>

<server>192.168.1.3</server>

<port>514</port>

<format>default</format>

</syslog_output>

УСТАНОВКААГЕНТАДЛЯWINDOWS

Установка агента на Windows почти ничем не отличается, он уже скомпилирован и распространяется с инсталлятором. После установки агента его необходимо настроить. Для этого

запусти C:\Program Files (x86)\ossec-agent\win32ui.exe

от имени администратора. В открывшееся окно введи адрес сервера и ключ, который сгенерировал на сервере. После этого зайди в меню Manage и выбери Start OSSEC.

Входящий лог

<decoder name="sshd">

<program_name>^sshd</ program_name>

<decoder name="sshd-success">

<prematch>^Accepted</

prematch>

<regex offset="after_prematch">^\S+for(\S+)from(\S+)port</regex> <order>user, srcip</order>

User=Root

Srcip=127.0.0.1

За высоким забором OSSEC

Взлом

РЕШАЕМ ПРОБЛЕМУ ОТСУТСТВИЯ ИНФОРМАЦИИ О SECURITY-АПДЕЙТАХ

Многие любят использовать CentOS в качестве серверной платформы. В какой-то момент встает вопрос о контроле безопасности, в том числе контроле апдейтов безопасности, появляются проблемы мелкого технического характера. В частности, нельзя просто так взять и внедрить Spacewalk/Satellite, или просто запустить yum --security, или тупо получить список пропущенных секурити-патчей. Впрочем, и эта проблема решается просто...

Алексей Синцов

Известный white hat, докладчик на security-конференциях, соорганизатор ZeroNights и просто отличный парень. В данный момент занимает должность Principal Security Engineer

в компании Nokia, где отвечает за безопасность сервисов платформы HERE.

ИСТОЧНИКПРОБЛЕМЫ

Как мы знаем, CentOS — это дистрибутив всеми любимого Linux, который основан на RHEL, но отличается от него бесплатностью. Таким образом, все те, кто хотел бы иметь Red Hat, но не хочет платить «за поддержку» и прочие вещи, могут легко поставить CentOS и наслаждаться тем же результатом за меньшие деньги. Это все здорово, но все же мелкие обломы приключаются, и один из таких сюрпризов связан как раз с безопасностью.

Покажу живой пример. Итак, мы хотим проверить неустановленные Security Updates в свежеустановленном Red Hat. Что мы делаем? Правильно:

yum --security check-update

1.Если у нас есть доступ/подписка Red Hat Network, то мы можем сгенерировать этот файл на основе файла из репо Red Hat.

2.Мы можем генерировать updateinfo.xml самостоятельно, а информацию о метаданных взять из листа рассылки CentOS.

3.Мы можем создать локальный скрипт, не использующий yum, но обращаться к нему для получения установленных пакетов, а затем сравнивать версии с тем, что есть в листе рассылки CentOS. То есть Spacewalk/ Red Hat Satellite в пролете по умолчанию.

Решения 1 и 2 подразумевают, что у нас должен быть свой собственный репозиторий — для больших и средних компаний нормальное и частое решение. Только с вариантом 1 мы тратим деньги, поскольку нам нужна подписка, — а тогда почему мы не используем RHEL? Вариант 3 годится, если у нас нет своего репо и мы хотим чекать пропущенные секурити-

В результате мы увидим список неустановленных security-патчей.

Но вот незадача, то же самое действие на таком же «устарелом» CentOS дает другую картину:

[root@ip-10-37-162-20 msp]# yum --security check-update

Loaded plugins: fastestmirror, nokia-s3yum, security

Determining fastest mirrors

Limiting package lists to security relevant ones

No packages needed for security; 6 packages available

То есть нам говорят, что пропущенных патчей безопасности нет, но это не так. Ну и вот как тут внедрять систему патч-менеджмента? Получается, даже стандартный Red Hat Spacewalk (система для инвентаризации и мониторинга, в том числе и патчей безопасности) бесполезен. Это обидно и неприятно. Эта же тема поднималась не раз в комьюнити CentOS, и каждый раз ответ один: не поддерживается такая фича, и все тут.

РЕШАЕМПРОБЛЕМЫСАМИ

Причина проблемы в том, что в отличие от RHEL в репозиториях CentOS нет метаданных о патчах, о том, является ли данный патч Security, BugFix, ну и так далее. В итоге мы имеем просто набор патчей и никак не можем их характеризовать с точки зрения безопасности. Если зайти на репо CentOS, то можно заметить, что файла updateinfo.xml там вообще нет. Именно этот ресурс и необходим, ведь в нем содержатся нужные метаданные. Таким образом, решений может быть несколько:

Security Errata per month

Red Hat Enterprise Linux 5 Server Default Install

Патч-менеджмент в CentOS

ПАРСИМ,ПАРСИМ,ГЕНЕРИМ

Сами мейл-листы можно найти тут: bit.

ly/1sRqTod. Как видно, их можно удобно скачать в виде заархивированных почтовых сообщений за каждый месяц (bit.ly/1eysKVD). Реализация этого кода, например на Python, не должна составить труда. Что ж, часть дела, можно сказать, сделана. Теперь можно и парсить скачанные файлы (после распаковки, конечно). Чтобы не перегружать код, все отдельные сообщения, включая темы писем, можно распарсить, используя модуль mailbox, а в третьем питоне можно сразу парсить через модуль email:

regex_CESA=re.compile("CESA-\S+")

regex_rpm = re.compile("([a-zA-Z0-9\-\._]+\.(\w+)\.rpm)")

messagesForMonth = mailbox.mbox(pathToFile)

for msg in messagesForMonth:

if(regex_CESA.search(msg['Subject'])):

# ǮȕȤȔȕȔȦȯȖȔșȠ security-ȣȔȦȫ

issue_id=regex_CESA.search(msg['Subject']).group(0)

# ǤȢȥȦȔșȠ RPM, ȡȔȣȤȜȠșȤ:

rpm_list={}

results=regex_rpm.findall(msg.get_body())

for name in results:

if name[1] in rpm_list:

rpm_list[name[1]].append(name[2])

else:

rpm_list[name[1]]=[]

rpm_list[name[1]].append(name[2])

Логика в том, что мы обрабатываем только те сообщения, где в теме указано непосредственно CESA, так как именно этой аббревиатурой характеризуются все сообщения, связанные с безопасностью. Там же в теме передается и уровень риска, и общее название пакета. Все это так же легко достается из почтового сообщения. Теперь, когда понятен подход к парсингу, нужно понять, как формировать updateinfo.xml.

Собственно формат файла довольно банален:

<updates>

<update from="%ǯǮǫǥ_FROM" status="stable"

type="security" version="1.4">

<id>%ISSUE_ID</id>

<title>%ǧǠǣǮǫǮǢǮǪ</title>

<release>CentOS %ǢǥǰDZǨǿ</release>

<issued date="%ǤǠDzǠ" />

<references>

<reference title="upstream" type="self"

href="%DZDZǻǫǪǠ"/>

</references>\n")

<description>N/A</description>

<severity>%ǪǰǨDzǨǷǭǮDZDzǼ</severity>

<pkglist>

<collection short="EL-%ǢǥǰDZǨǿ">

<name>CentOS %ǢǥǰDZǨǿ</name>

<package arch="%ARCH" epoch="0" name="%ǨǬǿ"

release="%ǰǥǫǨǧ" src="" version="%ǢǥǰDZǨǿ_ǯǠǪǥDzǠ">

<filename>%RPM</filename>

<sum type="%DzǨǯ_ǷșȞ_DZdzǬǬǻ">%DZdzǬǬǠ</sum>

</package>

</collection>

</pkglist>

</update>

...

</updates>