Центральные логи безопасности: видеть картину целиком, а не по кускам

Инцидент начался буднично: в пятницу вечером кто-то зашёл в учётку финансового директора с офисного компьютера бухгалтерии. Сам финдиректор в этот момент был на встрече. Учётку заметили случайно - сисадмин клиента увидел активную сессию в Task Manager на рабочей станции, куда зашёл по другой причине.

Начали разбираться. И тут выяснилось главное: логи входов на рабочих станциях лежат локально, в Windows Event Log, с ротацией по размеру. К моменту расследования на половине машин нужные события уже затёрлись. Где-то журнал был выставлен на 512 КБ и перезаписывался раз в несколько дней. На сервере картина была чуть лучше, но только чуть.

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

Что пошло не так с логами

Проблема не в том, что логи не писались. Они писались - Windows по умолчанию аудит входов включает. Проблема в том, что логи жили там же, где работала атакуемая система. Это структурно неверно по двум причинам.

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

Вторая - доступность. Если злоумышленник получил привилегированный доступ, он может почистить журнал. Это не фантастика - через Event Viewer или WMI-скрипт это делается в несколько кликов. На взломанной машине журналу доверять нельзя.

Логи нужно собирать туда, куда у скомпрометированной системы записи нет.

Что собрали

Решение для данного клиента получилось относительно простым, потому что в инфраструктуре уже стоял Linux-сервер - мы его использовали ещё для других задач. Развернули на нём syslog-ng, настроили Windows-машины на отправку Security Event Log через evtsys - небольшой агент, который пишет Windows-события в syslog-формате на удалённый приёмник.

Схема выглядела так:

Рабочие станции / серверы Windows
         |
      evtsys (агент, UDP 514)
         |
    syslog-ng (Linux)
         |
   /var/log/adg-events/
         |
      logcheck (фильтры + email)

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

Не SIEM, конечно. Но работающее решение, которое можно было поднять за день.

Что поменялось сразу

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

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

Что осталось не решённым

Честно говоря, это только первый шаг. Несколько проблем никуда не делись.

evtsys через UDP - это «fire and forget». Пакет потерялся - событие пропало. Для критичных систем это не очень хорошо, но TCP-вариант сложнее в настройке, и мы его пока не тронули.

Фильтры logcheck написаны вручную и покрывают только то, что мы явно предусмотрели. Новый тип атаки пройдёт мимо, пока кто-то не добавит правило. Это не система обнаружения - это система оповещения о заранее известных паттернах.

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

Linux-журналы и сетевое оборудование пишут в тот же syslog, но без единой схемы. Роутер пишет в одном формате, коммутатор - в другом, sshd - в третьем. Коррелировать события вручную - занятие для очень терпеливых людей.

Зачем это важно сейчас

После того как мы занимались разграничением прав в домене, стало понятно, что минимальные привилегии - это полдела. Вторая половина - знать, что происходит с теми привилегиями, которые всё же выданы. Кто, когда, с какого места.

Локальные логи для этого не годятся. Хранятся там же где и то, что защищают, перезаписываются через несколько дней и доступны тому, кого мы, возможно, расследуем.

Центральный сбор - это не про безопасность «по-настоящему». Это про минимальный уровень видимости, без которого любое расследование начинается с фразы «данных нет». Такой разговор с клиентом - не самый приятный, особенно в пятницу вечером.

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