События iLO/iDRAC в SIEM: что собирать и как фильтровать

Зачем тянуть события iLO и iDRAC в SIEM

iLO (HPE) и iDRAC (Dell) - это контроллеры удаленного управления сервером (BMC). Они живут отдельно от операционной системы и часто продолжают работать, даже когда ОС зависла, диск умер или сервер выключен. Их журналы дают слой фактов, которого обычно нет в логах Windows/Linux.

Стандартный мониторинг ОС этого часто не видит по простой причине: ОС пишет только то, что происходит внутри нее. А действия через BMC происходят «снаружи» - удаленная консоль, виртуальные носители, управление питанием, смена настроек BIOS/UEFI, обновления прошивок. Если злоумышленник или администратор перезагрузил сервер через iLO/iDRAC, в логах ОС может остаться только внезапный ребут без причины, а ключевая деталь будет в событиях BMC.

Для расследований это особенно полезно в трех типовых ситуациях:

1. Доступ вне ОС: кто вошел в web-интерфейс BMC, откуда, чем авторизовался, были ли неудачные попытки.

2. Удаленная консоль и виртуальные носители: кто открыл KVM, кто подключил ISO, не запускали ли сервер с «чужого» образа.

3. Питание и аппаратные действия: команды power off/on, принудительный reset, срабатывания датчиков, смена конфигурации.

Есть и обратная сторона: события iLO/iDRAC в SIEM легко превращаются в шум. BMC любят повторять одно и то же (периодические health-статусы, одинаковые предупреждения датчиков, сервисные сообщения), а форматы и поля у разных вендоров отличаются. Поэтому важно собирать эти логи осознанно: оставить события, которые помогают доказать «кто и что сделал», а остальное сразу фильтровать, подавлять или переводить в низкий приоритет.

Какие типы событий нужны в первую очередь

Если вы только начинаете собирать события iLO/iDRAC в SIEM, не пытайтесь забрать все подряд. Для расследований важнее всего действия человека и изменения настроек, которые дают удаленный контроль над сервером или помогают скрыть следы.

В первую очередь полезны пять групп событий:

• Аутентификация и сессии: успешный вход, выход, таймаут, неудачные попытки, блокировки. База для ответа на вопрос: кто и когда получил доступ.
• Учетные записи и права: создание и удаление пользователей, смена пароля, изменение ролей и привилегий, включение локальных аккаунтов. Такие события нередко появляются прямо перед несанкционированными действиями.
• Сетевые настройки BMC: смена IP, DNS, шлюза, маски, включение DHCP, изменения VLAN (если поддерживается), смена настроек времени/NTP. Это помогает заметить попытку увести управление в другую сеть или «починить» доступ после компрометации.
• Удаленная консоль и виртуальные носители: запуск KVM/remote console, подключение Virtual Media, монтирование ISO, загрузка с виртуального устройства. Через BMC можно установить или загрузить что угодно, поэтому это сильный сигнал.
• Питание и перезапуски: power on/off, reset, hard power cycle, сброс через контроллер, изменение политики питания. Важно и для расследований саботажа, и для подтверждения действий админа.

Простой пример: ночью фиксируется hard power cycle, а за 2 минуты до этого - успешный логин и запуск Virtual Media. Даже без ОС-логов видно цепочку действий, а круг пользователей, IP-адресов и времени проверки быстро сужается.

События «железа» и прошивок: что собирать и как трактовать

События BMC часто дают самую раннюю и точную картину проблем с сервером, потому что фиксируют то, что ОС может не успеть записать. В расследованиях они полезны не только при поломках, но и при спорных перезагрузках и «странных» зависаниях.

Что собирать

Начните с категорий, которые влияют на доступность и целостность данных. Обычно достаточно собирать:

• Ошибки и деградацию дисков и RAID-контроллера: rebuild, predictive failure, dropped drive, cache/battery warnings.
• Ошибки памяти, CPU и PCIe: ECC corrected/uncorrected, machine check, device removed/failed.
• Датчики и питание: перегрев, отказ вентилятора, просадки по питанию, потеря/возврат PSU, переход на батарею (если есть).
• Предупреждения перед отказом: рост количества corrected ошибок, «marginal» датчики, нестабильные обороты вентиляторов.
• Операции с прошивками: обновление, откат, неуспешная прошивка, смена версии и компонента.

Как трактовать

Смотрите не только на «Critical», но и на повторяемость. Один краткий скачок температуры может быть следствием нагрузки или сбоем датчика, а серия предупреждений по одному вентилятору часто предшествует аварии.

Для расследования важно различать «исправленные» и «неисправленные» ошибки. Corrected ECC, которые растут день за днем, обычно указывают на деградацию модуля памяти или проблемный слот. Uncorrected ECC или machine check с последующим reset почти всегда требуют реакции как на инцидент доступности.

События прошивок трактуйте как изменения конфигурации: фиксируйте, кто инициировал операцию (если поле есть), какой компонент обновлен и была ли перезагрузка. Например, если после обновления iDRAC или BIOS начались ошибки датчиков, это может быть несовместимость версии или сброс порогов мониторинга.

Если у вас парк серверов, поставляемых и поддерживаемых локально (например, в проектах GSE.kz), такие аппаратные сигналы удобно использовать для раннего выявления отказов и для отделения «железной» причины от действий администраторов.

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

События iLO/iDRAC в SIEM часто становятся недостающим кусочком пазла, когда инцидент выглядит как «сервер сам перезагрузился» или «учетка администратора вдруг перестала работать». Логи BMC показывают действия вне ОС: кто входил в контроллер, что менял, и какие команды на питание выполнялись. Это важно, потому что атака или ошибка могут обойти системные журналы.

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

Саботаж и «тихие» поломки часто выглядят одинаково, пока не посмотришь на события питания и оповещений. Команды Power Off, Reset, Power Cycle, отключение аппаратных алертов, перевод датчиков в «ignored» меняют картину: проблема была не в ОС и не в питании в стойке, а в удаленном управлении.

Отдельная категория - подмена конфигурации BMC. В расследовании полезно быстро ответить на вопросы:

• менялись ли сетевые настройки BMC (IP, шлюз, DNS);
• включался ли удаленный доступ или консоль;
• менялись ли сертификаты/SSH ключи;
• переключались ли источники аутентификации (локальная, LDAP/AD);
• был ли откат или обновление прошивки.

И явный признак сокрытия следов: очистка журналов, отключение отправки syslog, резкое падение количества событий от конкретного iLO/iDRAC. Особенно подозрительно, если это совпало по времени с необычной активностью на хосте (например, запуском новых служб, отключением EDR) и сессией в BMC с того же сегмента сети. Тогда BMC-события помогают связать действия «в железе» и то, что произошло в ОС, в один понятный таймлайн.

Поля, нормализация и привязка к активам

Чтобы события iLO/iDRAC в SIEM были полезны, их нужно не просто принять, а привести к общему виду и связать с конкретным сервером. Иначе расследование упирается в вопрос: «к какому железу относится этот лог, и что именно произошло?»

Минимальный набор полей, которого стоит добиваться при разборе (парсинге) сообщений:

• время события (лучше в UTC) и время получения;
• хост или идентификатор устройства управления (имя iLO/iDRAC, management IP);
• источник (тип BMC: iLO или iDRAC) и продукт/версия прошивки;
• severity (из сообщения и нормализованная шкала SIEM);
• код события и краткое описание (message).

Дальше важнее всего нормализация действий. Разные прошивки пишут по-разному, но в SIEM удобнее иметь единые названия, например: login, logout, auth_failed, config_change, firmware_update, power_cycle, virtual_media_mount. Тогда правила корреляции меньше зависят от формулировок производителя.

Привязка к активу должна опираться не только на hostname. Хорошая практика - тянуть в поля или обогащение серийный номер, модель, площадку/стойку, владельца системы и критичность сервиса. Например, если алерт пришел по BMC для стойки с S200 в проде, дежурный сразу видит, кому звонить и какие изменения допустимы.

Отдельно заведите теги, которые помогают фильтровать без потери смысла:

• environment: production/test
• maintenance_window: yes/no
• asset_criticality: high/medium/low
• system_owner: подразделение или команда
• site: площадка или город

По хранению: для расследований обычно хватает 90-180 дней в горячем доступе, а для аудита и разборов «задним числом» разумно держать 12 месяцев в архиве (с учетом требований вашей отрасли и регулятора).

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

Начните с базы: включите аудит на iLO/iDRAC и отправку syslog на ваш коллектор. Выберите уровни важности так, чтобы точно уходили security-события и изменения конфигурации. «Информационные» сообщения лучше подключать позже, когда вы поймете, что реально нужно, иначе шум быстро забьет очередь.

Дальше проверьте время. Настройте NTP, часовой пояс и убедитесь, что часы BMC совпадают с серверами и SIEM. Даже разница в 2-3 минуты ломает расследование: цепочка «вход - изменение - перезагрузка» начинает выглядеть как разные инциденты.

Транспорт и сеть управления

Определите, как именно передавать события iLO/iDRAC в SIEM: обычный syslog или syslog по TLS (если поддерживается вашей моделью/прошивкой). Важно, чтобы трафик шел из выделенного сегмента сети управления и был ограничен правилами доступа.

Чтобы не упустить критичное, держите под рукой короткий минимум проверок:

• разрешены исходящие подключения BMC к коллектору по нужному порту;
• включены нужные категории логов (security, audit, configuration);
• выставлен адекватный severity (часто достаточно Warning и выше для старта);
• подтверждена доставка: есть счетчики/статусы отправки на стороне BMC.

Проверка парсинга в SIEM

После включения отправки сгенерируйте несколько тестовых действий: неуспешный вход, успешный вход, изменение сетевого параметра, запуск виртуальной консоли. Сравните, что показывает консоль iLO/iDRAC, и что пришло в SIEM: одинаковые ли время, пользователь, IP-адрес, код/тип события.

Если возможно, разделите потоки: безопасность (логины, роли, конфиг) отдельно от health/telemetry (температуры, вентиляторы, деградации). Так проще задавать разные правила хранения и фильтрации: security держите дольше и анализируйте глубже, а «здоровье» обрабатывайте порогами и агрегацией.

Как убрать шум: фильтры, подавление и пороги

Шум от BMC обычно появляется по двум причинам: слишком много «здоровья железа» в informational и повторяющиеся однотипные сообщения. Для событий iLO/iDRAC в SIEM лучше заранее договориться, какие логи важны для расследований, а какие нужны только для эксплуатации.

Практичный базовый подход к фильтрации:

• Оставьте все, что связано с безопасностью и изменениями настроек: входы и ошибки входа, смену паролей, создание сессий, изменения пользователей и ролей, включение удаленной консоли, виртуальных носителей, смену сетевых параметров.
• Для health/telemetry ограничьте informational и «болтливые» статусы (периодические OK, link up/down при нестабильном порту), но сохраните warning/critical по питанию, вентиляторам, температуре, RAID, дискам.
• Отдельно пропускайте события обновлений прошивок и перезагрузок, но помечайте их как потенциально плановые, чтобы дальше работали окна обслуживания.

Дальше включайте подавление повторов (дедупликацию): если за 2-5 минут прилетает один и тот же текст с теми же полями (хост, источник, код), храните один экземпляр и счетчик повторов. Это сильно снижает поток при «сыплющемся» датчике или проблемном питании.

Для алертов почти всегда лучше пороги, а не «каждый лог = инцидент». Например: 10 неудачных входов за 10 минут или 3 попытки входа по заблокированной учетной записи за 5 минут.

Плановые работы тоже должны гасить шум. Заведите окна обслуживания на обновления BIOS/BMC, замену дисков, регламентные перезагрузки (особенно в стойках с серверами уровня S200), чтобы warning не превращались в сотни тикетов.

И разделите каналы по критичности: critical пусть идет в оперативные оповещения, warning - в очередь на разбор, informational - только в хранение и поиск. Белые списки для админских бастионов и разрешенных учетных записей помогают, но не отключайте логирование полностью. Лучше снижать приоритет и повышать пороги.

Идеи корреляций и алертов для расследований

Сами по себе события iLO/iDRAC часто выглядят как отдельный мир. Польза появляется, когда вы связываете их с телеметрией ОС, сетевыми логами и заявками на изменения. Тогда сигналы становятся понятными: кто получил доступ к консоли, что поменял, и что произошло с сервером после этого.

Корреляции, которые реально помогают

Хорошие правила обычно простые. Они опираются на короткие временные окна (5-30 минут) и понятный контекст (критичность сервера, роль, разрешенные сети админов).

• BMC + ОС: успешный вход в iLO/iDRAC, затем на хосте появляются события EDR или ОС (новый админ, включение RDP/SSH, остановка агента, запуск подозрительного процесса). Такой «мостик» показывает, что доступ через BMC мог быть стартовой точкой.
• «Невозможное»: вход в BMC из неожиданной сети, в нерабочее время для этой команды, или из непривычного региона (если есть гео по IP). Полезно добавлять исключения для дежурных.
• Смена конфигурации + тишина: изменение пользователей/ролей, настроек аудита, syslog/SNMP, а затем резкое падение входящих событий от этого BMC.
• Power cycle без заявки: выключение/сброс питания на критичном сервере без связанной заявки или окна работ (особенно для узлов виртуализации и БД).
• Виртуальные носители и загрузка: подключение ISO, включение Virtual Media, смена порядка загрузки. Даже если это делали «для диагностики», событие слишком чувствительное, чтобы его игнорировать.

Как сделать алерты менее шумными

Один и тот же сигнал стоит поднимать до «инцидента» только при дополнительных условиях: критичный актив (например, стойковый сервер S200 в проде), редкий источник IP, несколько ошибок входа перед успехом, повтор события на группе серверов.

Пример: SIEM видит успешный login в iDRAC с нестандартного IP, затем через 10 минут на Windows-сервере появляется создание нового локального администратора и остановка агента EDR. Такая цепочка дает четкую линию: доступ, действие, попытка уменьшить видимость.

Частые ошибки при сборе и фильтрации iLO/iDRAC

Самая частая проблема - собирать только «здоровье» (температуры, вентиляторы, питание) и считать, что этого достаточно. Для расследований важна и безопасность: входы в веб-консоль, смена паролей, создание пользователей, изменения сетевых настроек, включение удаленного носителя, команды на перезагрузку.

Вторая ошибка - время. Если NTP не настроен на BMC и на SIEM-коллекторах, вы получите «кривой» таймлайн: событие входа будет позже команды Power Cycle, а расследование превратится в догадки.

Третья ошибка - смешивать события BMC и ОС без четкой пометки источника. Когда события iLO/iDRAC в SIEM приходят в один поток с syslog Linux или Windows, легко потерять контекст: это была перезагрузка из ОС или из контроллера управления.

Четвертая ошибка - слишком агрессивная фильтрация syslog BMC по тексту. Часто режут «шумные» строки по шаблону и случайно выбрасывают редкие, но критичные сигналы, например неуспешные попытки входа или изменение настроек Remote Media.

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

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

• есть ли отдельный VLAN/подсеть и ACL;
• не торчат ли интерфейсы управления в общую сеть;
• учтены ли подрядчики и сервисные аккаунты;
• контролируется ли доступ через jump host или VPN.

На проектах интеграции (например, при построении серверной инфраструктуры в ЦОД) аудит сети управления нередко дает больше пользы, чем тонкая настройка фильтров.

Короткий чек-лист перед запуском в прод

Перед тем как включать события iLO/iDRAC в SIEM для всех серверов, проверьте базовые вещи. Они не выглядят важными, пока не случится инцидент и не выяснится, что время «плывет», а нужные действия растворились в шуме.

Начните с времени и доставки. На BMC и на коллекторе должны быть одинаковые часовые пояса и стабильная синхронизация, иначе не получится нормальная линия событий. Проверьте это на простом тесте: сделайте вход в интерфейс BMC и убедитесь, что событие появляется в SIEM быстро и с правильным временем.

Дальше - активы и ответственность. Для критичных серверов заранее заполните теги в SIEM (система, среда, владелец, площадка) и держите актуальный список владельцев. Например, если сервер относится к медицинской системе, владельца и приоритет нужно видеть сразу, а не искать в переписке.

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

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

• дедупликация одинаковых сообщений за короткий интервал;
• пороги для повторов (например, серии неудачных логинов);
• исключения на окна обслуживания и плановые работы.

Финальный тест - «сценарий расследования». Возьмите один сервер и разыграйте цепочку: вход в BMC, изменение параметра, перезагрузка. Убедитесь, что по логам можно восстановить кто, откуда и что сделал, и что события связаны с правильным активом в SIEM.

Пример сценария: расследуем перезагрузку через BMC

Ночью в 03:12 сервер неожиданно ушел в перезагрузку. Дежурный видит короткий простой сервиса и подозревает, что кто-то сделал power cycle через BMC (iLO/iDRAC), а не обычный reboot из ОС. Если вы уже собираете события iLO/iDRAC в SIEM, такой кейс разбирается быстро.

Сначала в SIEM ставим временное окно, например 02:45-03:30, и ищем событие типа power_cycle / reset / chassis power. Важно понять, что это было: мягкая перезагрузка, полное отключение питания или сброс контроллера.

Дальше проверяем, был ли вход в BMC перед действием. Обычно это видно по событиям login success/fail, session start, logout, а также по изменениям прав или использованию привилегированных ролей.

Базовая проверка, которая почти всегда дает ответ:

• кто инициировал действие: учетная запись, роль, идентификатор сессии;
• откуда: IP-адрес, подсеть, иногда user-agent или тип клиента;
• что было до перезагрузки: mount virtual media, remote console, смена boot order;
• были ли изменения в настройках BMC: сеть, NTP, DNS, включение новых сервисов;
• совпадает ли время с событиями ОС: shutdown, kernel panic, stop/start служб.

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

В конце сохраните артефакты: сырые syslog-сообщения BMC, учетку и IP инициатора, точное время, ID сессии, а также связанные события на ОС и сетевом оборудовании. И сразу улучшите правила: отдельный алерт на power_cycle без change window, подавление повторяющихся health-уведомлений и порог на multiple login failures с редких подсетей. Для серверов в критичных контурах (например, стойки с S200) такие алерты часто имеет смысл держать с повышенным приоритетом.

Следующие шаги: пилот, правила и поддержка

Начните с короткого пилота, а не со сбора логов со всех серверов сразу. Так быстрее станет ясно, какие события действительно помогают расследованиям, а какие просто забивают SIEM.

Соберите инвентарь: модель сервера, тип BMC (iLO или iDRAC), роль системы (AD, базы, виртуализация), критичность и владелец. Выберите 5-10 приоритетных узлов для пилота: то, что влияет на ключевые сервисы и чаще всего попадает в инциденты.

Дальше зафиксируйте, что считается обязательным: события входа и выхода, смена ролей и прав, изменения настроек, удаленные действия (power on/off, reboot), обновления прошивок, ошибки аутентификации и попытки доступа с неизвестных адресов. Остальное оставьте как диагностическое и включайте точечно, когда есть проблема.

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

Минимальный план пилота

• Утвердить приоритетные серверы и владельцев, подготовить карту активов для SIEM.
• Включить нужные категории логов и единый формат приема (например, syslog), проверить время и NTP.
• Сгенерировать типовые события: вход, неверный пароль, удаленная перезагрузка, изменение параметра, обновление прошивки.
• Прогнать алерты 2-3 дня и настроить подавление шума: пороги, исключения для сервисных аккаунтов, окна обслуживания.
• Описать, кто и как реагирует: SLA, контакты, порядок эскалации.

Если нужна помощь с пилотом и дальнейшей поддержкой серверной инфраструктуры, это можно обсудить с GSE.kz: от настройки источников SIEM и правил до сопровождения, включая серверы серии S200 и 24/7 поддержку.