iLO/iDRAC оқиғалары SIEM-де: нені жинау және қалай сүзгілеу

Неліктен iLO және iDRAC оқиғаларын SIEM-ге жіберу қажет

iLO (HPE) және iDRAC (Dell) — сервердің қашықтан басқару контроллері (BMC). Олар операциялық жүйеден бөлек жұмыс істейді және көбіне ОЖ ілініп қалғанда, диск істен шыққанда немесе сервер өшірілгенде де әрекет жасай береді. Олардың журналдары Windows/Linux логтарында болмайтын факттердің қабатын береді.

Қарапайым себеп: ОЖ тек өз ішінде болып жатқан нәрсені жазады. Ал BMC арқылы жасалатын әрекеттер «сырттан» болады — қашықтан консоль, виртуалды носительдер, қуатты басқару, BIOS/UEFI параметрлерін өзгерту, прошивка жаңартулары. Егер шабуылдаушы немесе әкімші iLO/iDRAC арқылы серверді қайта жүктеген болса, ОЖ логында тек кенеттен қайта жүктелгені қалуы мүмкін, ал маңызды деталь BMC оқиғаларында болады.

Тергеулер үшін бұл үш типтік жағдайда әсіресе пайдалы:

1. ОЖ-ден тыс қолжетімділік: кім BMC веб-интерфейсіне кірген, қайдан, қандай тәсілмен аутентификация жасаған, сәтсіз талпыныстар болды ма.

2. Қашықтан консоль және виртуалды носительдер: кім KVM ашты, кім ISO қосқан, сервер «басқа» образдан жүктелді ме.

3. Қуат пен аппараттық әрекеттер: power off/on командалары, принудительный reset, датчиктердің сигналдары, конфигурация өзгерістері.

Бірақ кері жағы бар: iLO/iDRAC оқиғалары SIEM-да оңай шуды тудырады. BMC жиі бірдей нәрсені қайталайды (периодтық health-статустар, ұқсас датчик ескертулері, сервис хабарлары), ал өндірушілердегі форматтар мен өрістер әртүрлі болады. Сондықтан логтарды саналы жинау маңызды: «кім және не істеді» дәлелдейтін оқиғаларды қалдырып, қалғанын сүзгілеңіз, басыңыз немесе төмен приоритетке ауыстырыңыз.

Бірінші кезекте қандай типтегі оқиғалар қажет

Егер сіз әлі жұмыс бастаған болсаңыз, бәрін бірден алуға тырыспаңыз. Тергеулер үшін ең маңыздысы — адамның әрекеттері мен қашықтан басқаруға мүмкіндік беретін параметрлер өзгерістері, сондай-ақ із жасыртатын әрекеттер.

Бірінші кезекте бес топ оқиғалар пайдалы:

• Аутентификация және сессиялар: сәтті кіру, шығу, таймаут, сәтсіз талпыныстар, блоктаулар. Бұл — кім қашан кіргенін анықтауға база.
• Учёттік жазбалар мен құқықтар: пайдаланушыларды құру/жою, пароль өзгерту, рөлдер мен привилегияларды өзгерту, локалдық аккаунттарды қосу. Мұндай оқиғалар жиі рұқсатсыз әрекеттерден бұрын шығады.
• 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 жіберуді өшіру, нақты құрылғыдан оқиғалар санының күрт азаюы — ізді жапқыш әрекет белгісі. Егер бұл ОЖ-дағы күмәнді әрекеттермен бір уақытта болса (мысалы, жаңа қызметтердің іске қосылуы, 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-пен шектелмеуі керек. Жақсы тәжірибе — сериялық нөмір, модель, площадка/стойка, жүйе иесі және сервис критикалдылығын тартыңыз. Мысалы, егер алерт продтағы S200 тұратын стойкадан келсе, дежурный дереу кімге хабарласу керектігін біледі.

Тегтер де пайдалы:

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

Сақтау саясаты: тергеулер үшін әдетте 90–180 күн «ыстық» қолжетімділік жеткілікті, ал аудит пен кері тергеулер үшін 12 ай архив ұстау ақылға қонымды (саланың және реттеушінің талаптарын ескеріңіз).

Қадамдық баптау: логтарды қосуынан SIEM-ге қабылдауға дейін

Бастапқы базадан бастаңыз: iLO/iDRAC-та аудитті қосып, syslog-ты коллекторға жіберуді баптаңыз. Қауіпсіздік оқиғалары мен конфигурация өзгерістерінің деңгейлерін таңдаңыз. «Информациондық» хабарларды кейінірек ғана қосқан жөн, әйтпесе шудан негізгі оқиғалар байқалмай қалады.

Содан кейін уақытты тексеріңіз. NTP, уақыт белдеуі бапталғанын және BMC сағаттары серверлер мен SIEM-пен сәйкес келетінін тексеріңіз. Тіпті 2–3 минут айырмашылық та тергеу таймлайнын бұзады.

Транспорт және басқару желісі

iLO/iDRAC оқиғаларын қалай жіберетіндігіңізді шешіңіз: қарапайым syslog немесе syslog по TLS (модель/прошивка қолдайтын болса). Трафик басқару сегментінен шығып, қолжетімділік ережелерімен шектелгені маңызды.

Қысқа тексерістер тізімі:

• BMC-тан коллекторға жіберуге рұқсат берілген порттар ашық;
• қажетті лог категориялары қосылған (security, audit, configuration);
• бастапқы severity адекватты (әдетте Warning және одан жоғары жеткілікті);
• жеткізу расталған: BMC жағында жіберу статустары бар.

SIEM-да парсингті тексеру

Жіберуді қосқаннан кейін бірнеше тесттік әрекет жасаңыз: сәтсіз кіру, сәтті кіру, желі параметрін өзгерту, виртуал консоль іске қосу. iLO/iDRAC консольдегі жазбалар мен SIEM-ге келген жазбаларды салыстырып, уақыт, пайдаланушы, IP және оқиға коды бірдей ме екенін тексеріңіз.

Мүмкін болса ағындарды бөліңіз: қауіпсіздік (кіру, рөлдер, конфиг) және health/telemetry (температура, желдеткіштер, деградация). Осылайша сақтау және сүзгілеу ережелерін бөлек қою оңай: security жазбаларын ұзақ сақтау және терең талдау, ал health-ті пра thresholds және агрегация арқылы өңдеу.

Шуды қалай азайту: фильтрлер, подавление және порогтар

BMC шудың екі себебі: тым көп «жабдық денсаулығы» informational деңгейінде және қайталанатын біртипті хабарлар. iLO/iDRAC оқиғаларын жинағанда қай логтардың тергеулер үшін маңызды екенін алдын ала келісу керек.

Нақты практикалық тәсіл:

• Қауіпсіздік пен конфигурация өзгерістеріне байланысты барлық оқиғаларды қалдырыңыз: кірістер мен қателіктер, пароль өзгерістері, сессиялар, пайдаланушылар мен рөлдерді өзгерту, қашықтан консоль және виртуалды носительдер, желі параметрлерін өзгерту.
• Health/telemetry үшін informational және «шулы» статустарды (периодтық OK, link up/down тұрақсыз порты барда) шектеу, бірақ қуат, вентиляторлар, температура, RAID, дискілер бойынша warning/critical сақтау.
• Прошивка жаңартулары мен перезагрузкаларды бөлек өткізіп, оларды жоспарлы жұмыстар ретінде белгілеңіз.

Қайталауларды (дедупликация) қосыңыз: 2–5 минут ішінде бірдей мәтінмен (хост, қайнар, код) келсе, бір жазбаны сақтап, қайталану санын есептеңіз. Бұл «сыпылып жатқан» датчик кезінде ағынды айтарлықтай азайтады.

Алерттерде әрқашан порогтар пайдалану жақсы: мысалы, 10 сәтсіз кіріс 10 минут ішінде немесе 3 талпыныс бұғатталған есептік жазбаға 5 минут ішінде.

Жоспарлы жұмыстардың өтпелігі де шуды басады. BIOS/BMC жаңартуларына, диск ауыстыруға, регламенттік перезагрузкаларға қызмет көрсету терезелері ашып қойыңыз — әйтпесе warning-тар мыңдаған тикетке айналуы мүмкін.

Каналдар мен приоритетті бөлу: critical — оперативті хабарландыру, warning — қарауға, informational — тек сақтау және іздеу. Админдік бастиондар мен рұқсат етілген аккаунттар үшін ақ тізімдер пайдалы, бірақ логтауды мүлде өшірудың қажеті жоқ — приоритетті төмендету жеткілікті.

Корреляциялар мен алертер үшін идеялар

Бұлар өздері жалғыз тұрған кезде көп мағына бермейді. Пайдасы — оларды ОЖ, желі және өзгерістер журналдарымен байланыстыруда: кім консольге кірді, не өзгертті және серверден кейін не болған.

Пайдалы корреляциялар

Жақсы ережелер қарапайым және қысқа уақыт терезелеріне сүйенеді (5–30 минут) және контекстке (сервер критикалығы, рөлі, админдердің рұқсат етілген желілері).

• BMC + ОЖ: iLO/iDRAC-та сәтті кіру, одан кейін хостта EDR немесе ОЖ оқиғалары (жаңа админ, RDP/SSH қосу, агентті тоқтату, күдікті процесс іске қосу). Бұл BMC арқылы кіру бастаушы нүкте болды деген күдікті байланыс.
• «Мүмкін емес»: BMC-қа таңдамайтын желіден немесе жұмыс уақытынан тыс кіру. Гео бойынша IP-пен бақылау пайдалы; дежуршылар үшін ерекшеліктер қосыңыз.
• Конфигурация өзгерісі + тишина: пайдаланушылар/рөлдер өзгертілді, аудит немесе syslog бапталды, содан кейін бұл BMC-тан оқиғалар күрт азайды.
• Power cycle без заявка: критичті серверде қуатты өшіру/қайта қосу өзгеріс терезесісіз болғанда.
• Виртуалды носительдер және жүктеу: ISO қосу, Virtual Media қосу, жүктеу тәртібін өзгерту — диагностика үшін жасалса да, өте сезімтал оқиға.

Алерттерді аз шуды ету

Бір сигналды «инцидент» деңгейіне тек қосымша шарттармен көтеріңіз: критикалық актив, белгісіз IP, бірнеше сәтсіз кіріс алдында сәтті кіріс, бірнеше серверде қайталану.

Мысалы: SIEM бірде iDRAC-та сәтті кірісті көріп, 10 минуттан кейін Windows-серверде жаңа локалдық админ жасалып, EDR агенті тоқтатылды. Мұндай тізбек: қолжетімділік, әрекет, көрінуді азайту — анық сызық береді.

Жиі жіберілетін қателіктер

Ең жиі қателік — тек «денсаулық» логтарын жинап, бұл жеткілікті деп ойлау. Тергеулер үшін қауіпсіздік оқиғалары да маңызды: веб-консольге кіру, пароль өзгерту, пайдаланушылар құру, желі параметрлерін өзгерту, remote media және перезагрузка командалары.

Екінші қателік — уақыт. Егер NTP BMC-те және SIEM-коллекторларда бапталмаса, таймлайн «қисық» болады: кіру оқиғасы перезагрузкадан кейін көрінетін болады.

Үшінші — BMC және ОЖ оқиғаларын бөлек белгілемеу. Егер бәрі бір ағынға түссе, контекст жоғалады: бұл перезагрузка ОЖ-дан болған ба, әлде контроллерден бе.

Төртінші — syslog-ты мәтін бойынша тым қатал үзу. Шу сөздерді қиып тастағанда сирек, бірақ маңызды хабарлар (мысалы, сәтсіз кірулер немесе Remote Media өзгерістері) де жоғалып кетуі мүмкін.

Бесінші — тест пен продты араластыру. Бірдей алерт стендте және өндірісте әртүрлі мағына береді; сондықтан орта белгілеулері мен порогтар керек.

Көп жағдайда басқару желісіне кімнің қолжетімдігін тексеруді ұмытады:

• жеке VLAN/подсеть пен ACL бар ма;
• басқару интерфейстері жалпы желіге шықпай ма;
• мердігерлер мен сервис аккаунттары есепке алынған ба;
• jump host немесе VPN арқылы қолжетімділік бақылана ма.

Интеграция жобаларында басқару желісінің аудиты көп жағдайда сүзгілерді баптаудан да тиімді нәтиже береді.

Өндіріске қосар алдында қысқа чек-лист

iLO/iDRAC оқиғаларын барлық серверге қосар алдында мына негізгі нәрселерді тексеріңіз. Олар маңызды көрінбеуі мүмкін, бірақ инцидент болып, уақыт «ағып» кеткенше бәрі анықталады.

Уақыт пен жеткізуді тексеруден бастаңыз. BMC және коллекторда бірдей уақыт белдеуі мен тұрақты синхронизация болуы тиіс. Тест ретінде BMC-ға кіріп, оқиға SIEM-ге дұрыс уақытпен және жылдам келетінін тексеріңіз.

Активтер мен жауапкершілікті тексеріңіз. Критикалық серверлер үшін тегтерді (система, орта, иесі, площадка) алдын ала толтырып қойыңыз. Мысалы, медициналық жүйеге қатысты сервердің иесін және приоритетін бірден көру керек.

Кілт оқиғаларды жинап жатқаныңызға көз жеткізіңіз: кіру талпыныстары, аутентификация қателері, баптаулардың өзгеруі, қуатты басқару, прошивка жаңарту, консоль мен виртуалды носительге қолжетімділік.

Шуды басу ережелерін орнатыңыз:

• қысқа интервалда бірдей хабарларды дедупликациялау;
• қайталануларға порогтар (мысалы, сериялы сәтсіз кірістер);
• қызмет көрсету терезелері мен жоспарлы жұмыстарға ерекшеліктер.

Финалдық тест — «тергеу сценарийі». Бір серверде сессия жасап: BMC-ға кіріп, параметрді өзгертіп, қайта жүктеңіз. SIEM арқылы «кім, қайдан және не істеді» анық көрінетінін және оқиғалардың дұрыс активке байланғанын тексеріңіз.

Мысал сценарий: BMC арқылы перезагрузканы тергеу

Түнде 03:12-де сервер күтпеген жерден қайта жүктелді. Дежурный қысқа сервис үзілуін көріп, бұл power cycle BMC арқылы жасалған ба, әлде ОЖ-дағы reboot па деп күдіктенеді. Егер iLO/iDRAC оқиғаларын жинасаңыз, мұндай жағдай тез шешіледі.

Алдымен 02:45–03:30 уақыт аралығын алып, power_cycle / reset / chassis power типті оқиғаларды іздеңіз. Бұл қай түрдегі қайта жүктеу екенін анықтаңыз: жұмсақ reboot, толық қуат өшіру немесе контроллер ресеті ме.

Келесі — әрекетті бастады ма әлде әлдеқайда бұрын кірген бе: login success/fail, session start, logout оқиғалары және рөлдердің қолданылуы, privileges.

Негізгі сұрақтар:

• әрекетті кім бастаған: аккаунт, рөл, сессия идентификаторы;
• қайдан: IP, подсеть, кейде user-agent;
• перезагрузка алдындағы әрекеттер: virtual media монтажы, remote console, boot order өзгерту;
• BMC баптаулары өзгерді ме: желі, NTP, DNS, жаңа сервис қосу;
• ОЖ оқиғалары уақытына сай па: shutdown, kernel panic, қызметтердің тоқтауы/жүктелуі.

Егер power_cycle-дан 10 минут бұрын Virtual Media қосылып, жүктеу тәртібі өзгертілген болса, бұл дайындық белгісі. Егер сол уақытта таңдамайтын IP-ден сәтсіз кірулер болса, пароль подборы болуы мүмкін.

Соңында артефакттарды сақтаңыз: шикі syslog-месседждер, инициатор аккаунты мен IP, нақты уақыт, сессия ID, ОЖ және желі оқиғалары. Және ережелерді жақсартыңыз: change window-сыз power_cycle үшін жеке алерт, health-хаустың дедупликациясы және сирек подсеттерден бірнеше сәтсіз кірістерге порог.

Келесі қадамдар: пилот, ережелер және қолдау

Бәрін бірден жинамай, қысқаша пилоттан бастаңыз. Солай нақты қандай оқиғалар тергеуге көмектесетінін және қандайлар шум тудыратынын тез анықтайсыз.

Инвентарь жасап алыңыз: сервер моделі, BMC түрі (iLO немесе iDRAC), жүйе рөлі (AD, БД, виртуализация), критичность және иесі. Пилот үшін 5–10 приоритетті узел таңдаңыз: негізгі сервистерге әсер ететін және жиі инцидентке ұшырайтындар.

Обязательные оқиғаларды анықтаңыз: кіру/шығу, рөл/құқық өзгерістері, қашықтан әрекеттер (power on/off, reboot), прошивка жаңартулары, аутентификация қатесі және белгісіз IP-ден кіру талпыныстары. Қалғанын диагностикалық ретінде қалдырыңыз.

Пилот тиімді болуы үшін желі басқаруын ұйымдастырыңыз: бөлек басқару желісі, минималды рұқсаттар, әкімші әрекеттерінің журналын сақтау.

Минималды пилот жоспары

• Приоритетті серверлер мен иелерді бекітіңіз, актив картасын дайындаңыз.
• Қажетті лог категорияларын қосып, қабылдау форматын (мысалы, syslog) біріздендіріңіз, уақыт пен NTP-ны тексеріңіз.
• Тесті оқиғаларды жасаңыз: сәтсіз кіріс, сәтті кіріс, параметр өзгерту, консоль іске қосу, перезагрузка.
• 2–3 күн алерттерді өткізіп, шуды басу: порогтар, сервис аккаунттарға исключения, қызмет көрсету терезелері.
• Реакция схемасын және эскалация тәртібін жасаңыз (SLA, контакты).

Егер көмек қажет болса пилот пен қолдауға — GSE.kz-пен талқылауға болады: SIEM көздерін баптаудан ережелерге және 24/7 қолдауға дейін.