SIEM: первые шаги и корреляция логов

Логи у нас есть. Давно есть. Центральный syslog-сервер, на который льётся всё подряд: firewall, коммутаторы, Linux-хосты, IDS Snort. Суммарно - несколько десятков тысяч строк в сутки. Хранятся, ротируются, пакуются. Красота.

Только читать их некому. Не потому что лень - просто физически невозможно. Grep по ключевым словам после инцидента работает, но превентивно ничего не даёт. К тому времени, как утром кто-то садится разбираться, атака уже или удалась, или сдохла сама по себе.

Мы начали думать об этом всерьёз после того, как Gartner стал активно писать про SIEM - Security Information and Event Management. Концепция простая: собрать события из разных источников, нормализовать форматы и применить правила корреляции. Одиночный failed login - шум. Пятьдесят failed login с одного IP за две минуты, а следом успешный - это уже история.

Что смотрели

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

Нашли OSSIM - Open Source Security Information Management. Испанский проект, развивается с 2003-го, GPLv2. Собирает события, нормализует, коррелирует по pads и собственному движку. Из коробки поддерживает Snort, Iptables, OpenSSH, Samba, Postfix, DHCP и ещё десяток источников. Не ArcSight, но что-то реальное.

Поставили в тестовую среду на отдельную машину с Debian. Настройка заняла два вечера - в основном уходило время на подгонку форматов syslog-сообщений под то, что OSSIM умеет парсить.

Что подключили

Три источника для начала:

• Firewall (iptables). Логи пакетов, которые дропаются или проходят по явному правилу. Форматируются через ulogd, идут в syslog.
• Snort IDS. Уже стоял в режиме пассивного зеркала на порту коммутатора. Алёрты шли в файл и частично в syslog - пришлось поправить конфиг под barnyard для нормального вывода.
• SSH-аутентификация. /var/log/auth.log с нескольких серверов, пробрасываем через rsyslog на центральный коллектор.

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

Первая корреляция

Через два дня после запуска OSSIM выстрелил первый алёрт коррелятора.

Правило, которое сработало - стандартное, из поставки: SSH brute-force. Порог: больше двадцати неудачных попыток аутентификации с одного IP за пять минут.

На одном из серверов, смотрящих наружу по нестандартному порту, кто-то методично перебирал пароли. Начал в 02:14, к 02:17 OSSIM уже показывал алёрт с деталями: источник, количество попыток, список опробованных логинов. Имя root встречалось чаще всего, дальше - admin, test, oracle. Классика.

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

Три минуты от начала атаки до алёрта - не потому что мы такие быстрые, а потому что машина смотрела на поток и считала.

Что пока не работает

OSSIM не идеален, и честность требует это признать.

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

Нормализация форматов - самая трудоёмкая часть. У каждого устройства свой формат syslog, и там, где OSSIM не знает парсера, события идут как «unknown» и в корреляцию не попадают. Для iptables пришлось писать простое правило парсинга вручную.

Хранение. OSSIM держит события в MySQL. При нашем объёме база начинает расти заметно, и надо думать про ротацию и архивирование на уровне СУБД.

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

Сейчас у нас три источника и десяток активных правил. Планируем добавить Windows Event Log через snare-агент и аутентификацию на VPN. Посмотрим, что из этого получится в боевых условиях - пока рано делать выводы.