Stfw.RuПочему «маленьким» тоже нужен SOC – и почему им не нужен SIEM
У небольших проектов безопасность обычно выглядит так: хост упал, сайт начал рассылать спам, в логах внезапно появились странные запросы, а в панели провайдера – резкий рост нагрузки. Дальше начинается угадайка: «это DDoS или кто-то залез», «почему RDP логинится ночью», «кто создал нового пользователя», «почему антивирус ничего не сказал». И почти всегда выясняется одно: событий много, но они размазаны по разным машинам и быстро исчезают из-за ротации. Вы видите симптомы, а цепочку действий – нет.
В корпоративном мире это решают SOC и SIEM. Но малому проекту чаще всего не нужна тяжелая платформа, нужен понятный контроль: централизовать логи, добавить телеметрию процессов и сети, и настроить несколько «железобетонных» алертов, которые реально сигналят о компрометации или опасной ошибке.
Самый практичный способ – выделить виртуальный сервер VPS под роль «коллектора безопасности» и собрать на нем персональный мини-SOC. Сервер можно взять у любого провайдера. Например, на VPS.house удобно поднять VPS в Москве со статическим IP и быстрыми дисками, а затем по мере роста логов увеличить конфигурацию без миграций. Дальше в статье: какие события собирать, как их фильтровать, как хранить и как реагировать.
Личный SOC на VPS – что это такое в реальности
Личный SOC для малого проекта – это не «пульт охраны» и не обещание абсолютной защиты. Это три вещи:
- централизованные события с нескольких узлов в одном месте (чтобы расследовать не по памяти)
- детальные события процесса (что запускалось, чем, откуда, с какими аргументами)
- алерты по понятным правилам (не тысячи «слабых сигналов», а десяток сильных)
Для Windows-среды идеальная связка под эти задачи – WEF/WEC + Sysmon.
WEF/WEC простыми словами – почему это лучше «агента логов» для старта
WEF (Windows Event Forwarding) – механизм пересылки событий Windows. WEC (Windows Event Collector) – роль коллектора, куда события собираются. По сути, это штатный способ собрать Security/System/Application (и не только) со всех машин на один сервер, без установки сторонних агентов.
Почему это удобно малому проекту:
- меньше зоопарка – не нужно выбирать и поддерживать отдельный агент логирования на каждом хосте
- понятная модель – у вас появляется один журнал «Forwarded Events», а на источниках остаются свои локальные журналы
- нормально масштабируется – добавлять источники можно постепенно и без переделок архитектуры
- правила фильтрации можно держать в подписках и централизованно ими управлять
Важный момент: WEF/WEC не делает «магической защиты». Он делает то, чего обычно не хватает – сохраняет факты.
Sysmon – что он добавляет и почему без него расследование часто упирается в «а дальше неизвестно»
Security-журналы Windows полезны, но часто дают «сигнал» без деталей. Sysmon (Sysinternals) закрывает этот разрыв: он пишет расширенную телеметрию по процессам, сетевым соединениям, драйверам, загрузкам, изменениям в реестре и другим действиям, которые обычно важны при атаках.
С практической точки зрения Sysmon отвечает на вопросы, на которые стандартные журналы отвечают хуже:
- какой именно процесс запустился и с какими аргументами
- какой родительский процесс его породил
- откуда взялся бинарник, что он записал на диск
- куда процесс ходил по сети
- какие «точки закрепления» менялись (автозагрузка, службы, задачи)
Но Sysmon надо настраивать аккуратно – иначе он превращается в шум и «забивает» полезные сигналы объемом.
Базовая архитектура: один VPS-коллектор и несколько источников
Минимальная схема для малого проекта выглядит так:
- VPS-коллектор (Windows Server) – принимает события по WEC, хранит их, строит представления, запускает алерты по расписанию
- Источники – Windows-серверы (включая Windows VPS), рабочие машины админов, иногда jump/bastion-хост
- Канал уведомлений – почта, Telegram/Slack/Teams через webhook, или хотя бы отдельная почта для алертов
Если у вас смешанная среда (Linux + Windows), логично начать с Windows-событий как самого уязвимого участка для удаленного доступа (RDP, службы, планировщик), а Linux закрыть отдельным легким сбором (journald/ssh/auth) позже. Личный SOC можно растить по мере зрелости, а не пытаться «обнять всё» в первую неделю.
Как выбрать конфигурацию VPS под роль коллектора
Коллектор логов – это не «тяжелая аналитика», ему важны диск и предсказуемая производительность. CPU обычно нужен умеренный, RAM – с запасом под кэш журналов и запросы, диск – быстрый и достаточного объема под ретеншн.
Типичная ошибка – взять маленький диск «на попробовать», а потом потерять историю как раз перед инцидентом. Лучше сразу решить два вопроса:
- сколько дней логов вы хотите хранить (для малого проекта разумно думать хотя бы о неделях, а не о днях)
- какие события вы реально собираете (Sysmon и Security при «шумной» конфигурации растут очень быстро)
Плюс: удобно, когда конфигурацию VPS можно менять без долгого переезда и с перерасчетом по факту использования. Это позволяет начать с разумного минимума и масштабировать объем диска, когда станет понятно, сколько логов вы генерируете на самом деле.
Шаг 1. Поднимаем WEC на сервере-коллекторе
На Windows Server роль коллектора включается штатными средствами. На практике вам нужно:
- включить и настроить службу Windows Event Collector
- подготовить WinRM (это транспорт для подписок)
- определить модель подписок: «collector initiated» или «source initiated»
Для малой инфраструктуры чаще удобнее «source initiated»: источники знают адрес коллектора и сами публикуют события. Это проще масштабировать, когда машины появляются и исчезают.
Дальше на коллекторе создаются подписки (Subscriptions) – это фильтры по журналам и типам событий. Ключевая мысль: подписка должна тащить только то, что вам реально нужно, иначе вы утонете.
Шаг 2. Включаем аудит Windows так, чтобы события были полезными
Многие включают сбор событий, но забывают включить нормальный аудит. Итог – на коллекторе красиво, а внутри пусто. На старте важно не «включить всё подряд», а выбрать базовые категории, которые дают сильные сигналы:
- входы и выходы (успешные и неуспешные, особенно по удаленным протоколам)
- изменения учетных записей и групп (создание пользователя, добавление в админы)
- изменения политик (аудит-политик, прав, иногда – UAC)
- создание служб и задач (закрепление и исполнение)
- изменения в критичных настройках (RDP, firewall, WinRM, удаленное управление)
Если у вас домен – это одна история. Если у вас рабочая группа – другая. Но принцип одинаков: вы должны видеть «кто вошел», «что создал» и «что изменил».
Шаг 3. Ставим Sysmon на источники, но не превращаем его в генератор мусора
Sysmon ставится на источники (серверы, админские машины, bastion). Важно не просто установить, а правильно выбрать конфигурацию.
Принцип настройки Sysmon для малого проекта:
- сначала собираем минимум, который даёт цепочки атаки
- потом добавляем точечно то, чего не хватает в расследованиях
- исключения делаем осознанно, а не «чтобы стало тихо»
На старте обычно достаточно концентрироваться на событиях процессов и сети, плюс точках закрепления. А вот сбор каждого чтения реестра или каждого обращения к файлам в системных директориях чаще не нужен и быстро раздувает объем.
Как правильно доставлять события Sysmon на коллектор
Sysmon пишет в свой журнал (Microsoft-Windows-Sysmon/Operational). Его удобно пересылать тем же WEF. Тогда на коллекторе у вас будут и Security-события, и Sysmon в «Forwarded Events».
Фишка WEF в том, что можно сделать отдельные подписки под Sysmon и под Security, с разной «срочностью» (Normal или Minimize Latency). Для алертов по компрометации чаще подходит быстрая доставка, а для «фоновых» событий – нормальная.
Самое важное: модель детектов без SIEM – выбираем «сильные сигналы»
Без SIEM вы не будете строить сложные корреляции «как у взрослых SOC». И это нормально. Задача малого проекта – иметь десяток надежных сигналов, которые:
- редко срабатывают «просто так»
- быстро проверяются человеком
- закрывают самые частые сценарии компрометации
Ниже – набор правил, который дает хороший эффект без перегруза. Это не «универсальная истина», а рабочая стартовая база.
Сигнал 1. Подбор паролей и «шумные» входы
Смысл – видеть не один неудачный логин, а серию. Брутфорс по RDP, WinRM, SMB или web-панели обычно выглядит как десятки и сотни попыток за короткий промежуток.
Что делаем без SIEM: раз в 5 минут скрипт (PowerShell) считает количество неуспешных входов по источнику/IP и, если превышен порог, отправляет алерт. В алерте обязательно должны быть: хост, учетная запись, источник, число попыток, окно времени.
Сигнал 2. Успешный вход «не в то время» или «не с того места»
Это не про «в 3 ночи всегда зло». Это про базовый профиль. Если ваш админ обычно заходит из одного диапазона и в рабочее время, внезапный вход из другого региона или ночью – повод посмотреть. Даже в малом проекте это часто ловит компрометации раньше, чем начнутся разрушения.
Сигнал 3. Новый локальный администратор или изменение привилегий
Создание учетной записи и добавление в админские группы – один из самых сильных индикаторов. В идеале это должно быть редким и осознанным событием, а значит – алерт почти всегда полезен.
Сигнал 4. Создание службы, драйвера или плановой задачи
Закрепление в системе через службы и задачи – классика. В нормальной эксплуатации это происходит редко и обычно связано с конкретным обновлением или внедрением. Если вы видите создание новой службы с непонятным бинарником из временной директории – это почти всегда расследование.
Сигнал 5. Подозрительные цепочки процессов (Sysmon)
Здесь важна не «черная магия», а здравый смысл. Несколько примеров «сильных» комбинаций:
- офисный документ или браузер породил PowerShell/cmd/wscript
- PowerShell запускается с кодированными командами или скачивает содержимое из сети
- rundll32/regsvr32 запускаются с нетипичными аргументами
- процесс стартует из пользовательских временных папок и тут же выходит в сеть
Эти признаки не доказывают взлом, но хорошо выделяют «необычное» в потоке событий.
Сигнал 6. Массовые изменения файлов в короткое время
Шифровальщики и «плохие скрипты» часто оставляют след в виде лавины операций: массовые переименования и записи. В Windows это можно ловить разными способами. Без SIEM достаточно примитивного, но полезного контроля: рост событий по изменениям в критичных каталогах плюс мониторинг расширений, которые характерны именно для вашего проекта (например, конфиги, базы, документы).
Важно: это работает лучше, если у вас есть понятная структура «где хранятся важные данные», а не «везде по чуть-чуть».
Сигнал 7. Изменения сетевой экспозиции: firewall, RDP, удаленное управление
Одна из самых неприятных историй – когда после компрометации злоумышленник «подстраивает инфраструктуру» под себя: открывает порты, включает RDP наружу, ослабляет firewall. Поэтому изменения правил файрвола и параметров удаленного доступа – это хороший кандидат на немедленный алерт.
Где хранить правила и как сделать алерты без SIEM, но по-взрослому
Есть три простых механизма, которые дают результат без тяжелой платформы:
1. Custom Views в Event Viewer – быстро и понятно
На коллекторе можно собрать «представления» по нужным фильтрам: входы, админские изменения, службы, Sysmon-события процессов и сети. Это удобно для ручного разбора и обучения команды – вы видите данные как «панель приборов».
2. Планировщик заданий + PowerShell – для алертов
Сценарий простой: скрипт раз в N минут делает запрос в Forwarded Events (или в нужные журналы), ищет совпадения, агрегирует и отправляет уведомление. Это не SIEM, но для малого проекта часто достаточно.
Ключевые правила качества алертов:
- алерт должен содержать контекст (кто, где, когда, сколько, чем подтверждается)
- алерт должен быть «проверяемым» за 2-5 минут
- алерт должен иметь действие: что сделать прямо сейчас
3. Разделение «шумных» и «критичных» подписок WEF
Для критичных сигналов полезно доставлять события быстрее, а для «фоновых» – обычным режимом. Это снижает задержки там, где они важны, и не перегружает систему лишним трафиком.
Ретеншн и место на диске – как не потерять историю из-за банальной нехватки объема
Логи имеют неприятное свойство кончать диск незаметно. Чтобы не «вылететь» в момент инцидента, нужна простая политика:
- отдельный диск или отдельный том под логи (так проще контролировать и расширять)
- лимиты журналов и осознанная ротация
- мониторинг свободного места и алерт при достижении порога
- архивация самых важных журналов по расписанию, если вам нужна длинная история
Дисковая часть особенно важна для Sysmon. Его можно сделать полезным, но компактным – если не пытаться логировать всё подряд.
Безопасность самого коллектора – иначе SOC станет «призом» для атакующего
Коллектор – концентратор фактов, а значит его нужно защищать лучше, чем обычный сервер.
- минимум сервисов – на коллекторе не должно быть «лишних» приложений
- доступ только по VPN или по списку IP для администрирования
- раздельные учетные записи – обычная и админская, без привычки работать «всё время админом»
- обновления по графику – коллектор не должен превращаться в «никто не трогает, чтобы не сломать»
- бэкап конфигурации – подписки WEF, скрипты алертов, шаблоны представлений, список источников
Если коллектор упадет или будет скомпрометирован, вы потеряете не только удобство, но и доказательства.
Практический план внедрения на 1-2 дня: чтобы заработало, а не осталось «идеей»
- Поднимите VPS под коллектор и выделите диск под логи с запасом
- Настройте WEC и одну тестовую подписку на Security-события входов
- Подключите 1-2 ключевых хоста (например, Windows VPS с RDP и рабочую машину админа)
- Поставьте Sysmon на эти хосты с умеренной конфигурацией, подключите пересылку его журнала
- Соберите 3-5 Custom Views под самые важные сценарии
- Сделайте 5 алертов: брутфорс, новый админ, новая служба/задача, подозрительный PowerShell, изменения firewall/RDP
- Проверьте реакцию: сгенерируйте тестовые события и убедитесь, что алерты доходят и содержат контекст
Если после этого у вас появляется привычка «заглядывать в события» и вы хотя бы раз быстро расследовали странность по логам – значит мини-SOC уже приносит пользу.
Где здесь виртуальный сервер и почему это удобно именно на VPS
Суть подхода в том, что вы отделяете функции безопасности от боевых сервисов. Даже если ваш основной сервер занят приложениями, у SOC-узла другая роль: хранить факты, обрабатывать события, слать алерты. VPS под такую роль удобен тем, что:
- его можно быстро поднять и так же быстро пересоздать по шаблону, если нужно
- можно масштабировать диск и ресурсы по мере роста логов
- статический IPv4 упрощает настройку источников и ограничений доступа
- при грамотной архитектуре он не зависит от «рабочего ПК админа»
Если нужен практичный вариант «взял и сделал», можно , например, на VPS.house и использовать его как централизованный коллектор WEC с быстрым диском под события и ретеншн. Важно, что это не «реклама SOC», а инженерный способ перестать терять следы.
Финал: видеть атаки по фактам – это навык, который начинается с одного правильного сервера
Личный SOC на VPS не обещает, что вас «никогда не взломают». Он делает другое – сокращает время между «что-то странное» и «понятно, что произошло». WEF/WEC дает централизованные события, Sysmon дает детали, а простые алерты без SIEM учат реагировать на сильные сигналы, а не на шум.
И, пожалуй, самое ценное: когда у вас появляется история событий за недели и месяцы, безопасность перестает быть гаданием. Она становится инженерией.
