SIEM без бюджета корпорации: как собрать логи с серверов и компьютеров в одном месте и увидеть атаку раньше

Я двадцать лет чиню чужую IT-инфраструктуру и раз в пару месяцев слышу одну и ту же фразу: «у нас же антивирус стоит, как нас взломали». Стоит. И даже что-то ловит. Но антивирус видит один компьютер, а атака обычно ходит по сети неделями, прежде чем добраться до шифровальщика. Расскажу, как я собираю логи с 10-50 машин в одну кучу без Splunk за миллион в год и без выделенного безопасника в штате.

Почему антивирус и EDR — это не защита, а только один из слоёв

Смотрите, как выглядит типичная атака на бухгалтерию или юрфирму. Сначала фишинговое письмо, кто-то из бухгалтеров открывает вложение. Потом злоумышленник неделю тихо сидит в сети, смотрит расшаренные папки, собирает пароли из браузера, пробует RDP на соседние машины. И только в конце — шифрование всего, до чего дотянулся. Антивирус на этом пути сработает в лучшем случае в момент фишинга, да и то не всегда: современные загрузчики умеют обходить сигнатурный анализ, я сам видел, как Windows Defender молча пропускал PowerShell-скрипт, который качал полезную нагрузку прямо в память.

У одного клиента, торговая компания на 35 рабочих мест, ровно так и было. Заразился один ноутбук менеджера по продажам через письмо от «поставщика». EDR на его машине честно среагировал через три дня — заблокировал подозрительный процесс. А то, что за эти три дня с его учётки кто-то раз пять пытался подключиться по RDP к серверу 1С и один раз таки зашёл — этого никто не увидел, потому что смотреть было некуда. Логи RDP-сервера лежали в своём Event Viewer, логи ноутбука — в своём, и никто их не сопоставлял.

Вот в этом вся суть: EDR и антивирус — это глаза на каждом отдельном устройстве. А атака видна только когда сводишь события с разных устройств вместе и смотришь на них по времени. Это и есть SIEM в своей базовой идее — Security Information and Event Management, если по-русски: сбор и сопоставление логов безопасности. Слово страшное, корпоративное, стоит как крыло самолёта. Но суть можно реализовать за вменяемые деньги и на коленке, если знать, что собирать.

Что на самом деле нужно собирать в офисе до 50 машин

Забудьте про идею тащить в одно место абсолютно все логи — это утонет в шуме и вы сами перестанете туда заглядывать через неделю. Я обычно собираю пять типов событий, этого хватает для 90% реальных инцидентов.

Первое — успешные и неуспешные входы в Windows (Event ID 4624, 4625) на всех серверах и, если есть возможность, на ключевых рабочих станциях: бухгалтерия, директор, сервер 1С. Пять неудачных попыток входа подряд ночью с одной машины — это не человек забыл пароль, это перебор. Второе — создание новых учётных записей и добавление в группу администраторов (4720, 4728, 4732). Если у вас в компании 20 человек и вдруг ночью появился новый админ — это на 99% не сисадмин трудится в три часа ночи.

Третье — запуск PowerShell с необычными параметрами и создание запланированных задач, это классический способ закрепиться в системе. Четвёртое — исходящие RDP-подключения между рабочими станциями, у обычного бухгалтера таких быть не должно вообще. И пятое, для тех у кого есть сервер — логи Veeam и других бэкапов: если задание бэкапа вдруг стало падать без причины или бэкапы стали резко расти в размере, часто это первый признак, что кто-то уже шифрует файлы медленно, по чуть-чуть, чтобы не спалиться.

Инструмент: Wazuh, а не Splunk за миллион рублей

Когда я говорю клиентам про централизованный сбор логов, все сразу вспоминают Splunk и пугаются ценника — там лицензирование по объёму данных, и для конторы на 40 машин легко вылезает на несколько сотен тысяч рублей в год. Забудьте про Splunk для такого масштаба, он не для вас, он для банков.

Я использую Wazuh — это опенсорсный форк OSSEC, бесплатный, с готовым агентом под Windows, Linux и Mac. Ставится сервер на одну виртуалку с 4 ГБ памяти, этого за глаза хватит на 50 источников. На каждый компьютер и сервер накатывается лёгкий агент, который весит меньше 30 МБ и не грузит проц. Агент шлёт события на сервер, там они парсятся, коррелируются между собой по готовым правилам, и если что-то подозрительное — вылезает алерт в веб-панели, можно ещё и в Telegram прикрутить, я обычно так и делаю для клиентов.

Разворачивал у клиента-медцентра на 22 рабочих места вместе с сервером 1С и терминалом. Ушло у меня на всё про всё полтора дня: установка сервера, накат агентов через групповую политику AD, настройка правил под их специфику — там важно было отслеживать доступ к базе с персональными данными пациентов, это уже требование 152-ФЗ. С тех пор система живёт полтора года, стоит им это в районе 15 тысяч рублей в месяц за виртуалку в облаке, плюс моё время на настройку алертов раз в квартал.

Как это выглядит на практике: живая история с перебором пароля

Расскажу конкретный случай, чтобы было понятно, ради чего всё это городится. Клиент — юридическая фирма, 18 юристов, терминальный сервер на RDS, наружу открыт порт для удалённой работы с домашних компов. Классика жанра, я таких серверов повидал десятки.

В три часа ночи Wazuh поймал 47 неудачных попыток входа за 12 минут с одного внешнего IP, все под разными логинами — явно перебор по словарю имён сотрудников. Правило корреляции сработало, ушло уведомление в Telegram-чат, я увидел его утром в восемь. Ничего критичного не случилось — пароли у всех были достаточно сложные, брутфорс не прошёл. Но я сразу заблокировал IP на файрволе и добавил геоблокировку по стране, потому что запрос шёл из Вьетнама, а у клиента ни одного удалённого сотрудника оттуда нет.

Без централизованного лога эта попытка осталась бы в Event Viewer терминального сервера, куда никто не заходит месяцами. А через неделю, две, три — рано или поздно перебор бы кто-то довёл до конца, или подобрали бы пароль через утечку с другого сайта, люди же переиспользуют пароли. И тогда бы это была уже не строчка в логе, а шифровальщик на всех файлах фирмы и разговор со мной на повышенных тонах.

Подводные камни: чего не стоит ждать от такой системы

Скажу честно, чтобы не создавать иллюзий. Wazuh и подобные ему решения — это не искусственный интеллект, который сам поймёт, что у вас происходит атака. Правила корреляции нужно настраивать под конкретный бизнес, и в первые недели система будет заваливать вас ложными срабатываниями. У одного клиента-производства система полторы недели ругалась на «подозрительный PowerShell», а это просто их 1С-программист гонял скрипты обновления конфигурации каждый вечер. Пришлось добавить исключение.

Второй момент — систему кто-то должен смотреть. Я видел компании, которые поставили себе SIEM, обрадовались, а потом полгода не заглядывали в панель, потому что «работает же само». Не работает само. Алерты нужно разбирать хотя бы раз в неделю, а критичные — сразу, в моменте. Если у вас в штате нет человека, готового этим заниматься, отдавайте это на аутсорс, иначе деньги на инфраструктуру потрачены зря.

И третье — это дополнение к антивирусу и бэкапам, а не замена. У меня был клиент, который решил, что раз поставил SIEM, можно сэкономить на регулярном тестировании бэкапов. Дурная логика: SIEM видит атаку раньше, но не гарантирует, что вы её остановите до того, как что-то пострадает. Бэкапы, сегментация сети, минимальные права у пользователей — всё это никуда не девается, SIEM просто добавляет вам глаза там, где их раньше не было.

С чего начать, если решили попробовать

Не пытайтесь сразу подключить все 50 машин и все возможные источники логов — утонете в настройке и в алертах. Я всегда начинаю с трёх точек: сервер с базой 1С или другой критичной системой, терминальный сервер с внешним доступом, и рабочая станция директора или главбуха — обычно самая привлекательная цель для фишинга. Это уже закрывает процентов семьдесят реальных рисков для маленькой компании.

Дальше подключайте остальные машины постепенно, партиями по 5-10 штук, и каждый раз давайте системе неделю поработать, прежде чем добавлять следующую партию — так проще разобраться, откуда идёт очередной ложный алерт. Через месяц-два у вас будет рабочий набор правил под конкретно вашу компанию, и дальше уже дело техники — добавлять новые устройства по мере роста парка.

Если своей IT-службы нет или она занята текучкой типа принтеров и Windows-обновлений, разумнее отдать настройку и сопровождение подрядчику, который такое уже делал не первый раз. Стоимость первичной настройки для офиса на 30-40 машин у нас обычно укладывается в 60-90 тысяч рублей разово плюс ежемесячное сопровождение, и это на порядок дешевле, чем один инцидент с шифровальщиком и простоем в неделю.

Частые вопросы

Сколько реально стоит содержать такую систему в месяц?
Для офиса на 30-40 рабочих мест виртуалка под сервер Wazuh обходится в 3-7 тысяч рублей в месяц в зависимости от облака, плюс время на сопровождение и разбор алертов. Если отдаёте на аутсорс, ежемесячное сопровождение обычно укладывается в 15-25 тысяч рублей. Это в разы дешевле, чем один час простоя после атаки шифровальщика.

Можно ли обойтись без отдельного сервера и собирать логи в облаке?
Да, есть облачные версии на манер Wazuh Cloud или аналогичные SaaS-решения, но для конторы до 50 машин я обычно рекомендую свою виртуалку — дешевле и данные остаются у вас, что важно, если работаете с персональными данными по 152-ФЗ.

Заменяет ли такая система полноценный SOC с дежурной сменой?
Нет. Это инструмент, который видит и сопоставляет события, но реагировать на алерты всё равно должен человек. Для малого бизнеса круглосуточный SOC экономически бессмысленен, достаточно разбирать критичные алерты в течение рабочего дня и настроить уведомления в Telegram для ночных событий.

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