Рассмотрим пример реализации защиты сетевого периметра с использованием Opensource-решений на базе:
— Snort — система обнаружения\предотвращения вторжения (в контексте данной статьи будет рассматриваться как IDS);
— OSSEC — хостовая IDS (Host-based intrusion detection system);
— Prelude\Prewikka — SIEM-система для обработки и управления событиями (Security information and event management).

В предыдущих статьях, посвященных обеспечению безопасности веб-сайта и сетевого периметра были рассмотрены инструменты nginx-naxsi (web application firewall), fail2ban (сервис блокировки доступа) и snort (IDS). Давайте попробуем соединить все подсистемы воедино, снарядив в довесок SIEM, позволяющей просматривать и анализировать события в удобном виде. Кроме этого, использование подобной системы позволит подготовиться к соответствию со стандартом PCI DSS.

Далее в примерах будут использоваться 3 сервера:
Сервер R — сетевой шлюз;
Сервер WAF — веб-сервер с установленным Nginx-Naxsi и Fail2ban;
Сервер SIEM — сервер просмотра и обработки событий.

Итак, приступим!

Установка и настройка Snort

Сервер R

В репозиториях Debian есть уже готовые сборки Snort и Snort-mysql, простые в установке и уже содержащие стандартный набор правил. Минус заключается в том, что правил довольно мало. Расширенный набор правил можно скачать с официального сайта (рекомендуется использовать правила, предоставляемые по платной подписке, содержащие наиболее актуальные сигнатуры атак). Устаревшие версии Snort, находящиеся в репозитории Debian, нам не подойдут, поэтому произведем установку из исходников:

# mkdir -p /opt/src
# cd /opt/src

Установим зависимости. Библиотеку libdnet, необходимую для работы Snort, придется также установить из исходников.


# apt-get install libdaq-dev libpcap-dev libssl-dev libpcre3-dev checkinstall
# wget http://sourceforge.net/projects/libdnet/files/libdnet/libdnet-1.11/libdnet-1.11.tar.gz/download -qO- | tar xvzpf - -C /opt/src
# cd libdnet-1.11 && ./configure && make && checkinstall

Установим Snort:


# wget https://www.snort.org/downloads/snort/snort-2.9.7.3.tar.gz -qO- | tar xvzpf - -C /opt/src
# cd /opt/src/snort-2.9.7.3 && ./configure --enable-sourcefire
# make && checkinstall

Отлично. Теперь необходимо скачать и подключить расширенный набор правил с сайта, предварительно зарегистрировавшись на Snort.org и получив oinkode:


# mkdir -p /etc/snort
# wget https://www.snort.org/rules/snortrules-snapshot-2962.tar.gz?oinkcode=038c3ee32c10a975b466522d823d9e9fa3ffbd2f -qO- | tar xvzpf - -C /etc/snort
# mv /etc/snort/etc/* /etc/snort/ && rm -rf /etc/snort/etc
# cat /etc/passwd | grep snort || useradd snort
# mkdir /var/log/snort && chown -hR snort /var/log/snort

Готово. Переходим к настройке. Укажем диапазон нашей внутренней подсети, пути доступа к правилам и т.д.:

# nano /usr/local/snort/etc/snort.conf

Подготовим все необходимо для запуска Snort:


# touch /etc/snort/rules/white_list.rules
# touch /etc/snort/rules/black_list.rules
# chown snort:snort /etc/snort/rules/*.rules
# mkdir -p /var/log/snort
# chown snort:snort /var/log/snort

Проверим конфигурацию:

# snort -T -c /etc/snort/snort.conf

В случае появления ошибки:

сделаем симлинк библиотеки:

# cd /usr/lib/ && ln -s /usr/local/lib/libdnet.1.0.1 libdnet.1

Запускаем Snort:

# snort -c /etc/snort/snort.conf -D -i eth1 -u snort -g snort

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

Установка и настройка SIEM

Сервер SIEM

Произведем настройку Prelude SIEM:


# apt-get install apache2 libmysqlclient-dev make gcc libssl-dev
# apt-get install prelude-manager libprelude-dev

Произведем настройку автозапуска при старте системы:

# nano /etc/default/prelude-manager

# update-rc.d prelude-manager defaults

И установим Prewikka — веб-интерфейс для удобства просмотра и анализа событий:

# apt-get install prewikka

Теперь нам необходимо настроить vhost на веб-сервере:


# cd /etc/apache2/sites-enabled/
# mv 000-default prewikka

а также установить права доступа для www-data:

# chown -hR www-data:www-data /etc/prewikka

Перезапускаем веб-сервер:

# /etc/init.d/apache2 restart

По-умолчанию Prewikka производит резолвинг хостов, что не всегда бывает полезным (особенно, если речь идет о секции SRC IP). Чтобы отключить резолв, необходимо выставить параметр -1 в секции dns_max_delay в файле /etc/prewikka/prewikka.conf.

Проверяем работу веб-интерфейса, открыв в браузере http://web_server_ip. Логин\пароль: admin\admin.

Установка и настройка OSSEC HIDS

Сервер SIEM

OSSEC HIDS является хостовой системой обнаружения вторжений, позволяя выявлять и пресекать подозрительную активность на хосте. Скачаем последнюю версию с официального сайта и произведем установку:


# apt-get install make gcc libssl-dev -y
# wget http://www.ossec.net/files/ossec-hids-2.8.2.tar.gz --user-agent=Mozilla -qO- | tar xvzpf - /tmp
# cd /tmp/ossec-hids-2.8.2/src && make setprelude && ../install.sh

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

Интегрируем OSSEC с Prelude:

# nano /var/ossec/etc/ossec.conf

Теперь нужно подключить OSSEC к Prelude. Для этого нам потребуется одновременный доступ к двум консолям. Это можно сделать утилитой screen (запустите screen, CTRL+A CTRL+C создасть новое окно, переключение между окнами осуществляется комбинацией CTRL+A).

Запустим в первой консоли:


# prelude-admin registration-server prelude-manager
а во второй:
# prelude-admin register OSSEC "idmef:w" 127.0.0.1 --uid ossec --gid ossec

Введя одноразовый пароль, получим сообщение об успешной интеграции OSSEC:

Запустим сервисы:


# /etc/init.d/prelude-manager start
# /etc/init.d/ossec start

Добавление OSSEC-агентов

Существует, как минимум, два способа добавить агента OSSEC — сгенеровать ключ авторизации на сервере или же активировать агента удаленно. Рассмотрим оба варианта.

Вариант 1. Генерация ключа на сервере
На сервере SIEM выполним:

# /var/ossec/bin/manage_agents

Если процедура производится в первый раз, необходимо перезапустить OSSEC-сервер, чтобы он начал слушать UDP-port 1514:
# /etc/init.d/ossec restart

Извлечем сгенерированный ключ для клиента с помощью опции «E»:
# /var/ossec/bin/manage_agents

укажем ID агента (в данном случае 001) и получим ключ:
Agent key information for ‘001’ is:

Сервер R
Установим и настроим OSSEC-агент:


# wget http://www.ossec.net/files/ossec-hids-2.8.2.tar.gz --user-agent=Mozilla -qO- | tar xvzpf - -C /tmp
# /tmp/ossec-hids-2.8.2/install.sh

# /var/ossec/bin/manage_agents

Добавим ключ через опцию «I» и перезапустим OSSEC:

# /etc/init.d/ossec restart

Перейдем на сервер SIEM и убедимся, что агент подключился:

# /var/ossec/bin/agent_control -l

Вариант 2. Удаленное подключение агента

Установим на сервере R OSSEC-агент, как это было описано в первом варианте. На сервере SIEM запустим сервис аутентификации агентов с опцией -i (опция при регистрации агента сохраняет его IP-адрес, не допуская подключения с других IP адресов для данного агента):

/var/ossec/bin/ossec-authd -i

Вернемся на сервер R и запустим клиент аутентификации с указанием IP-адреса сервера OSSEC:

/var/ossec/bin/agent-auth -m OSSEC_SERVER_IP

Агент должен успешно пройти аутентификацию на сервере. Обратите внимание, что для приема событий OSSEC слушает подключения на 1514 UDP порту, в то время как модуль авторизации на сервере (при аутентификации вторым методом используется порт 1515 TCP.

Настройка профилей OSSEC

Гибкость OSSEC обеспечивается, в том числе, за счет использования профилей — набора правил для хоста или группы хостов, объединенных по определенным критериям, таких как операционная система, роль и т.д. Рассмотрим пример создания профиля для серверов, использующих Snort в качестве IDS. Для этого создадим на OSSEC-сервере файл, описывающий политику мониторинга логов для подобных серверов.

Сервер SIEM

# nano /var/ossec/etc/shared/agent.conf

Мы указали, что для профиля snort необходимо анализировать файл /var/log/snort/alert, имеющий формат snort-fast. Подключим профиль клиенту:
Сервер R

# nano /var/ossec/etc/ossec.conf

# /etc/init.d/ossec restart

Отлично, теперь события Snort будут поступать на сервер SIEM.

По умолчанию, при установке OSSEC-агента, конфиг ossec.conf уже содержит список файлов для мониторинга. Для OSSEC версии 8.1 доступны различные форматы журналов событий, имеющих интуитивно понятное название. С полным списком форматов можно ознакомиться здесь. Помимо стандартных файлов журналов Linux-систем и приложений, доступны такие форматы, как:
snort-full, snort-fast — формат журнала Snort;
eventlog — стандартный формат журнала Windows;
eventchannel — формат журнала Windows, позволяющий обрабатывать не только классические Windows-логи, но и данные из Application and Services (для Windows Vista и старше);
command, full_command — выполнение команды в системе. Выполняется только при указании в ossec.conf на каждом агенте, нельзя передать через agent.conf;
multi-line — позволяет работать с журналами приложений, использующие несколько строг для генерации событий.

Кроме этого, по умолчанию ossec.conf содержит секции по анализу контроля целостности файлов.

События, поступающие от OSSEC-агентов на сервер, сначала проходят обработку пре-декодером, декодером, а после к ним применяется набор правил. Правила расположены в каталоге /var/ossec/rules и должны быть подключены в конфигурационном файле ossec.conf. Все конфигурационные файлы OSSEC имеют формат XML. На этапе пре-декодинга извлекается такая информация, как имя хоста, приложения, сгенерировавшего событие, источник события и т.д.

Декодер событий

Обработка события декодером (/var/ossec/etc/decoder.xml) производится на основе паттернов. Давайте попробуем создать декодер для событий fail2ban.

Оригинальное событие имеет следующий вид:

Чтобы убедиться, что декодера для данного события не существует, обработаем его утилитой ossec-logtest:

# echo '2015-06-19 00:39:35,920 fail2ban.actions: WARNING [some_waf_rule] Ban 94.ХХ.8.ХХ' | /var/ossec/bin/ossec-logtest -a

и получим пустой результат:

Опция -a для ossec-logtest выводит только алерт (если паттерн будет найдет в декодере и в правиле), в то время как опция -v/-d предоставит больше информации об обработке.

Создадим декодер, извлекающий из правила Source IP, название правила и действия утилиты fail2ban (Ban\Unban):
# nano /var/ossec/etc/decoder.xml

и повторим обработку:

# echo '2015-06-19 00:39:35,920 fail2ban.actions: WARNING [some_waf_rule] Ban 94.XX.8.XX' | /var/ossec/bin/ossec-logtest -v

Отлично. Перейдем к созданию правил.

Итак, мы уже создали декодер для событий fail2ban, давайте попробуем разобраться с правилами OSSEC.

Каждое правило OSSEC имеет свой уникальный идентификатор, правила сгруппированы по их назначению. Более подробную информацию о правилах и о назначении идентифкаторов можно прочитать здесь. Таким образом мы можем использовать идентификаторы в диапазоне от 100000 до 109999 для собственных правил. Кроме этого, правила содержат уровень критичности (level) от 0 до 15. Значение 0 игнорируются, а 15 означает максимальный уровень критичности.

Давайте попробуем создать правило для событий fail2ban:

# nano /var/ossec/rules/local_rules.xml

Первое правило будет сообщать о блокировки, поэтому мы назначили ему максимальный уровень критичности (в Prewikka будет отображаться красным), второе (о разблокировки) с уровнем 3 (синий цвет).

Давайте попробуем создать правило для обработки событий Naxsi, который мы рассматривали в статье, посвященной обеспечению безопасности сайта. Событие имеет следующий вид:

Проверим работу правила утилитой ossec-logtest:

# echo '2015/06/19 00:14:11 [error] 1569#0: *8948 NAXSI_FMT: ip=94.ХХ.8.ХХ&server=ХХХ.ru&uri=/wp-admin/admin-ajax.php&learning=1&vers=0.54&total_processed=158&total_blocked=30&block=1&cscore0=$XSS&score0=20&zone0=BODY|NAME&id0=1311&var_name0=data[clef]&zone1=BODY|NAME&id1=1311&var_name1=data[wp-refresh-post-lock][post_id]&zone2=BODY|NAME&id2=1311&var_name2=data[wp-refresh-post-lock][lock], client: 94.ХХ.8.ХХ, server: ХХХ.ru, request: "POST /wp-admin/admin-ajax.php HTTP/1.1", host: "ХХХ.ru", referrer: "https://ХХХ.ru/wp-admin/post.php?post=484&action=edit"' | /var/ossec/bin/ossec-logtest -a

и убедимся, что событие обрабатывается верно:

Вывод сообщает нам, что событие после обработки декодером в конечном итоге попадает под правило с идентификатором 31301. Рассмотрим его:

# nano /var/ossec/rules/nginx_rules.xml

и дополним новым правилом:

# nano /var/ossec/rules/local_rules.xml

Перезапустим OSSEC:

# /etc/init.d/ossec restart

Проверим:


# echo '2015/06/19 00:14:11 [error] 1569#0: *8948 NAXSI_FMT: ip=94.XX.8.XX&server=XXX.ru&uri=/wp-admin/admin-ajax.php&learning=1&vers=0.54&total_processed=158&total_blocked=30&block=1&cscore0=$XSS&score0=20&zone0=BODY|NAME&id0=1311&var_name0=data[clef]&zone1=BODY|NAME&id1=1311&var_name1=data[wp-refresh-post-lock][post_id]&zone2=BODY|NAME&id2=1311&var_name2=data[wp-refresh-post-lock][lock], client: 94.XX.8.XX, server: XXX.ru, request: "POST /wp-admin/admin-ajax.php HTTP/1.1", host: "XXX.ru", referrer: "https://XXX.ru/wp-admin/post.php?post=484&action=edit"' | /var/ossec/bin/ossec-logtest -a

Отлично. Теперь события Naxsi будут иметь идентификатор 100001 с уровнем критичности 5.

Предположим, что наш веб-сервер обслуживает несколько виртуальных хостов и мы хотим игнорировать все сообщения Naxsi для виртуального хоста ХХХ1.ru. Такую задачу можно реализовать с помощью правила c уровнем критичности 0:

# nano /var/ossec/rules/local_rules.xml

Заключение

Snort не умеет работать с SSL трафиком в нативном режиме. Для контроля SSL-соединений можно использовать дополнение к Snort в виде viewssld.

OSSEC достаточно гибкий инструмент, позволяющий обрабатывать события из различных источников и различного содержания, а также реализовать гибкую политику парсинга событий. К OSSEC-серверу можно подключать как управляемые агенты, так и agentless-устройства, такие как коммутаторы и прочие сетевые устройства, не поддерживающие OSSEC-агенты. Кроме этого, сервер OSSEC можно использовать для удаленного хранения log-файлов. Помимо анализа и обработки событий, OSSEC умеет работать в режиме IPS (используя «active response»): блокировать доступ или же выполнять иные действия.

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

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