Microsoft Sentinel a gyakorlatban
Az előző cikkben a Microsoft Sentinel komponenseit és működését egy gyakorlati laborkörnyezeten keresztül ismertettem elméleti alapokra helyezve a SIEM/SOAR megoldás szerepét. Most azonban szintet lépünk: éles környezetben vizsgáljuk meg, hogyan használhatjuk a Sentinelt valós biztonsági események észlelésére és elemzésére.
Ebben a részben FortiGate tűzfal VPN naplói, valamint egyéb kritikus rendszerlogok segítségével mutatom be, hogyan lehet fenyegetéseket és gyanús aktivitásokat azonosítani. Végigmegyek a Sentinel adatforrások integrációján, az elemzési folyamatokon, és bemutatok konkrét vizsgálati eseteket – hogyan észlelhetünk például egy gyanús bejelentkezést, vagy hogyan lehet egy anomáliát mélyebben elemezni KQL lekérdezések segítségével.
Célom, hogy a Sentinel gyakorlati alkalmazását lépésről lépésre bemutatva segítséget nyújtsak azoknak, akik a saját környezetükben szeretnék kiaknázni a Sentinel képességeit a proaktív fenyegetésfelderítés és incidenskezelés terén.
🎬Forgatókönyv:
🛠Nézzük meg részletesen, milyen feladatokat végzünk el, miről lesz szó, és hogyan segíthet mindez a gyakorlatban.
📡A VPN logok példáján keresztül szemléltetjük a Microsoft Sentinel működését, mert egy konkrét, gyakorlati eset segít könnyebben átlátni ezt a komplex rendszert.
🛡 Fortigate tűzfal logjainak bekötése
🔹 A Fortigate tűzfal naplóit integráljuk a Sentinelbe, hogy valós idejű VPN eseményeket észlelhessünk.
🔍 Elemzés
🔹 KQL lekérdezések VPN eseményekre – Egyéni KQL lekérdezésekkel elemezheted a VPN csatlakozásokat és a felhasználói aktivitást.
🔹 VPN használati minták vizsgálata – Azonosíthatod a tipikus és szokatlan VPN-használati szokásokat a vállalatodban.
🚨 Detektálás
🔹 Gyanús VPN bejelentkezések riasztása – Automatikus értesítések a nem megszokott vagy kockázatos VPN bejelentkezések esetén.
🔹 Sikertelen VPN bejelentkezések figyelése – A többszöri sikertelen bejelentkezési kísérletek monitorozása a lehetséges támadások észlelésére.
🤖 Automatizáció
🔹 Playbook az ismeretlen IP-ről érkező bejelentkezések tiltására – Automatizált válasz az új vagy gyanús IP-címekről érkező bejelentkezések blokkolására.
📊 Vizualizáció
🔹 VPN Dashboard készítése Sentinelben – Grafikonokkal és térképekkel vizualizálhatod a VPN-használatot és a csatlakozási mintákat.
🔥 Fusion tesztelése
🔹 VPN bejelentkezések és admin jogok kombinált elemzése – Azonosíthatod, ha egy felhasználó röviddel a VPN-bejelentkezés után adminisztrátori jogosultságokat kap, ami gyanús lehet.
🛡 Fortigate tűzfal logjainak bekötése
A következő konfiguráció célja, hogy egy FortiGate tűzfalról érkező VPN kapcsolati naplókat (syslog) bekössük Microsoft Sentinel-be az egyszerűbb és átláthatóbb elemzés érdekében. Mivel csak a VPN-re vonatkozó logokat fogjuk továbbítani, a folyamat érthetőbb és kezelhetőbb lesz, mintha az összes tűzfalnapló között kellene keresgélnünk.
A naplók UDP Syslog protokollon keresztül érkeznek, és az adatokat egy Azure Arc-on keresztül kapcsolt Windows szerver fogja fogadni, amely továbbítja azokat a Sentinel Workspace-be. Ennek megvalósításához szükség lesz egy Data Collection Rule (DCR) létrehozására, amely szabályozza, hogy a beérkező logok milyen formában és milyen célhelyre kerüljenek.
A folyamat során:
- A FortiGate tűzfal beállításra kerül, hogy csak a VPN eseményekről küldjön syslogokat.
- Az Azure Arc által felügyelt szerver fogadja és előkészíti a naplókat.
- Egy Data Collection Rule (DCR) biztosítja, hogy a megfelelő adatok a Sentinel-be kerüljenek.
Ez a megoldás segít abban, hogy hatékonyan elemezzük a VPN kapcsolatokkal kapcsolatos eseményeket, anélkül hogy más tűzfalnaplók között kellene keresgélnünk.
Windows szerverünkön az alábbi logfájlba érkeznek be a Fortigate VPN rendszerlogok:
Ismerjük meg a VPN Syslogot, egy logbejegyzés – logsor (JSON formátumban jön be a tűzfalról UDP modulon keresztül):
{ „EventSourceAddress”: „192.168.1.100”, „MessageSourceAddress”: „192.168.1.100”, „AgentLess”: true, „EventReceivedTime”: „2025-02-10 14:30:00”, „AgentModuleName”: „UDP-In Syslog”, „SourceModuleName”: „UDP-In Syslog”, „AgentModuleType”: „im_udp”, „SourceModuleType”: „im_udp”, „AgentName”: „logsystem”, „PatternPath”: „Agentless;FortiOS;Event;VPN;39425 – SSL_VPN_SESSION_TUNNEL_DOWN”, „SyslogSeverity”: „INFO”, „Severity”: „informational”, „EventTime”: „2025-02-10 14:29:59”, „Hostname”: „192.168.1.100”, „Message”: „SSL tunnel shutdown”, „TaxonomyOS”: „FortiOS”, „TaxonomyProducer”: „NetworkVPNGateway”, „devname”: „FW-Gateway01”, „devid”: „FG1234567890”, „tz”: „+0100”, „logid”: „0101039425”, „subtype”: „vpn”, „level”: „information”, „logdesc”: „SSL VPN tunnel down”, „action”: „tunnel-down”, „tunneltype”: „ssl-web”, „tunnelid”: „987654321”, „remip”: „203.0.113.55”, „srccountry”: „Germany”, „user”: „johndoe@example.com”, „group”: „VPN_Users”, „reason”: „User disconnected manually”, „duration”: 4321, „sentbyte”: „10240”, „rcvdbyte”: „20480”, „msg”: „SSL tunnel shutdown”, „EventCategory”: „event/vpn”, „SourceCountry”: „Germany”, „ReceivedBytes”: „20480”, „SentBytes”: „10240”, „TransferredBytes”: 30720, „TargetAccountName”: „johndoe”, „TargetGroupName”: „vpn_users_group”, „TaxonomyAction”: „Disconnect”, „TaxonomyObject”: „Session”, „TaxonomyObjectSubType”: „Session_VPN”, „TaxonomyStatus”: „Success”, „TargetDomainName”: „example.com”, „TargetAccount”: „example.com\\johndoe”, „Facility”: „local7”, „EventSourceHostname”: „log-server01”, „TimeGenerated”: „2025-02-10 14:29:59” }
Azure Arc-ba bevont földi (on-premise) szerveren van a fenti Syslog fájl – A Monitoring Extension modulnak telepítve kell lennie:
Az alábbi on-premise szerveren a Microsoft Monitoring Agentet megfelelően kell konfigurálni, hogy a megfelelő Sentinel Log Analytics workspace-hez csatlakozzon.
Vezérlőpult:
Kell a megfelelő workspace ID (ez a Sentinel Log Analytics Workspace alatt az Overview alatt található):
A Sentinel Log Analytics Workspace-nél, az Agent rész alatt látszik, hogy szerverünk megfelelően csatlakoztatva lett.
Data Collection Rule beállítása a Log begyűjtéséhez:
Új Data Collection Rule, neve: FortiDCR
Itt kijelöljük a szervert amiről a logokat akarjuk gyűjteni. (A szerver nevét kitakartam, mert valódi környezetben csináltam a tesztet.)
Custom Text logot hozunk létre:
Custom JSON tipusú adatforrást készítünk:
Beadjuk a forrást ahonnan jön a log:
1 – Megdjuk hol található a log fájl a szerveren
2 – Megadjuk az adattábla nevét a Sentinel workspace-n ahová kerül a log
3 – Fel kell venni a JSON schema-t a megfelelő adattípusokkal string, datetime, stb.
Kiválasztjuk magát a Sentinel Workspace-t:
A FortigateSyslog_CL nevű adattábla ahová kerül a Syslog:
Így tudunk KQL lekérdezéseket indítani:
KQL tipusú query-vel le lehet kérdezni a Sentinelbe felkerült VPN logokat:
🔍 Elemzés
• KQL lekérdezések VPN eseményekre:
Futtathatsz egy alap KQL lekérdezést, hogy ellenőrizd a logokat (utolsó 24 óra):
Pédáult mit vizsgálhatsz?
✅ VPN csatlakozások és bontások (action: tunnel-up, tunnel-down)
✅ Felhasználók IP-címei és országai (remip, srccountry)
✅ Miért bontotta a kapcsolatot? (reason: auth timeout, user disconnect)
✅ Mennyi ideig tartott a munkamenet? (duration)
• VPN használati minták vizsgálata
Ha riasztásokat szeretnél generálni bizonyos gyanús VPN eseményekre, hozz létre egy Custom Analytic Rule-t Sentinelben.
📌 Példa: Ismeretlen országból VPN bejelentkezés
Ha egy felhasználó nem megszokott országból csatlakozik VPN-re, az kompromittált fiók jele lehet.
📌 KQL lekérdezés a szabályhoz:
📌 Mit csinál ez a szabály?
✔ Ha egy felhasználó például Kínából vagy Oroszországból jelentkezik be VPN-re, riasztást generál. (Vagy Magyarországon, Németországon, és Franciaországon kívűl bárhonnan.)
✔ Beállíthatod, hogy automatikusan küldjön e-mailt vagy Teams értesítést. Lentebb kibontom, hogyan lehet Custom Analytic Rule-t készíteni.
🚨 Detektálás
🔐 Gyanús VPN bejelentkezések riasztása
Ha egy felhasználó többször próbálkozik sikertelenül bejelentkezni VPN-re, akkor felmerülhet a gyanú, hogy brute force támadás vagy ellopott jelszó tesztelése zajlik.
📌 KQL Lekérdezés a Szabályhoz
⚡ Mit Csinál Ez a Szabály?
✔ Ha egy felhasználó 30 percen belül 3-nál többször próbál belépni, azonnal riaszt.
✔ Hatékonyan alkalmazható Brute Force támadások felismerésére.
(Talán a 3 próbálkozás még kevés, hiszen előfordulhat, hogy a felhasználó egyszerűen elfelejtette a jelszavát. Az 5 sikertelen kísérlet viszont már valószínűsíti a támadás gyanúját. A tesztemben 3 próbálkozással demonstrálom a működést.)
🔐 Sikertelen VPN bejelntkezési kísérletek figyelése (Itt jön képe a Custom Analytic Rule)
Az előző szekcióban tesztelt lekérdezést, amely sikeresen visszaadta az eredményeket, most bemásoljuk, és ezzel „Rule Query” formátumban alkalmazzuk.
Ebben a szakaszban lehetőség van automatikusan incidens generálására, valamint egy Playbook futtatására, például az Entra-felhasználó letiltására. Jelenleg még nincs előre definiált válaszreakció, de a későbbi tesztesetek során ezt is bemutatom.
🤖Automatizáció: Playbookok a VPN Események Kezelésére
Ha egy gyanús VPN esemény történik, azonnal automatizálhatod a válaszreakciót Sentinel Playbookok segítségével, amelyek az Azure Logic Apps platformon futnak.
📌 Példa: Gyanús VPN Bejelentkezés Automatikus Zárolása
Ha egy felhasználó fél órán belül 5x sikertelenül próbál bejelentkezni, a rendszer azonnal felfüggesztheti a fiókját az alábbi lépések szerint:
📌 Mit Csinál a Playbook?
1️⃣ Microsoft Sentinel riasztást küld (Incidenst generál) ha túl sok sikertelen bejelentkezés van fél órán belül
2️⃣ A Playbook csatlakozik az Azure AD-hez, és ideiglenesen zárolja a felhasználót.
3️⃣ Egy Teams értesítést küld a SOC csapatnak, hogy az esemény gyorsan kivizsgálható legyen.
📌 Hogyan Hozd Létre?
✅ Navigálj ide: Microsoft Sentinel → Automation → Playbooks
✅ Hozz létre egy új Playbook-ot, és szerkezd alatta a Logic App-et
✅ Válassz egy triggert: „When an alert is triggered in Sentinel”
✅ Adj hozzá egy műveletet: „Entra User Block” (Ez egy összetett folyamat, amelyhez előre definiált műveletek állnak rendelkezésre, de manuálisan is testreszabható, szinte bármit meg lehet vele csinálni.)
🔹 Logic App és az Automatikus Válaszreakciók
Ebben a pontban lép be a Logic App, amely lehetővé teszi az automatikus válaszreakciók kezelését. Itt beállítható például:
✔ Entra felhasználó letiltása gyanús tevékenység esetén
✔ Teams értesítés küldése a SOC csapatnak
Mivel a beállítások viszonylag összetettek, ebben a bemutatóban nem fogom teljesen végigvezetni ezt a konfigurációt.
ℹ Fontos Tudnivaló a Logic App Számlázásáról
💰 A díjazás a végrehajtások (runs) alapján történik, nem a triggerek száma számít!
🔄 Ha egy trigger többször lefut és elindítja a munkafolyamatot, minden egyes végrehajtás után külön díjazás történik. Ez azt jelenti, hogy nem a trigger aktiválásának száma, hanem a tényleges folyamatfutások számítanak a költségek szempontjából.
💡 Tipp: Ha szeretnéd minimalizálni a költségeket, érdemes beépíteni feltételeket és szűrőket, amelyek csak releváns események esetén indítják el a munkafolyamatot.
Például:
✔ Csak akkor fusson le, ha a bejelentkezési próbálkozás egy gyanús országban történt.
✔ Csak akkor tiltsa le a felhasználót, ha több sikertelen kísérlet történt rövid időn belül.
✔ Csak kritikus események esetén küldjön értesítést a SOC csapatnak.
Logic App Designer:
A Logic App tervezőben lehetőség van a teljes folyamat logikájának vizuális felépítésére. Ennek részletes bemutatása önmagában is megérne egy külön blogposztot, így ebben a cikkben csak a legfontosabb lépéseket érintem.
Tehát létrejön a Custom Analytic rule alapján az incidens (VPN Suspicious Logins – VPN failed logins – tesztemben ezt véletlenül több néven is létrehoztam de ugyan arra az eseményre jön létre):
Ha a „VPN failed Logins” – rule alapján automatikusan létrejön egy incidens akkor válaszként a Playbook-ot a rendszer le fogja futtatni = ha fél órán belül 5 sikeretelen VPN bejelentkezés volt akkor a kompromittált Entra user letiltódik, SOC csapatnak Teams értesítés megy ki.
📊 VPN Használat Vizualizálása – Dashboard Készítése
Vizuálisan informatív módon követheted nyomon a céges VPN használatot az alábbi módon. A Sentinel Workbookokkal könnyedén létrehozhatsz egy átlátható és részletes dashboardot.
📌 Mit jeleníthetsz meg a VPN dashboardon?
✅ Élő VPN munkamenetek száma – valós idejű követés
✅ Top 10 leggyakoribb VPN felhasználó – ki csatlakozik a legtöbbször? (Jelen esetben ezt mutatom be.)
✅ VPN csatlakozások földrajzi térképen – hol történnek a kapcsolódások?
✅ VPN kapcsolatok időbeli eloszlása – csúcsidők vizsgálata az irodában
📌 KQL lekérdezés a leggyakoribb VPN felhasználókhoz
Az alábbi KQL lekérdezéssel könnyedén listázhatod a legaktívabb VPN-felhasználókat:
1️⃣ Navigálj a Microsoft Sentinel → Workbooks menüponthoz
2️⃣ Hozz létre egy új dashboardot
3️⃣ Adj hozzá diagramokat és térképeket a KQL lekérdezések alapján
Új Sentinel Workbook létrehozása:
Hozzáadjuk a query-t (a lekérdezést):
Itt a lekérdezés:
El kell mentenünk:
Mostmár megjelent a workbook, a mentettek között:
Valós időben látszódik a Top 10 VPN felhasználó:
🔥 Fusion Rule Tesztelése Gyanús VPN Eseményekre
A Fusion Rule képes különböző eseményeket összekapcsolni, így segít azonosítani azokat a szokatlan mintázatokat, amelyek biztonsági kockázatot jelenthetnek. Ha ilyen eseményt érzékel, automatikusan riasztást generál.
📌 Gyanús helyzet: VPN bejelentkezés + Admin jogosultság szerzése
Képzeld el a következő forgatókönyvet:
🔹 Egy felhasználó VPN-en keresztül bejelentkezik
🔹 Rövid időn belül adminisztrátori jogosultságot kap az Active Directory-ban
Ez a viselkedés szokatlan lehet, különösen, ha az adott felhasználó korábban nem kapott adminisztrátori jogokat, vagy ha a rendszerben ritkán történik ilyen változás. Ez akár belső fenyegetést, kompromittált fiókot vagy jogosulatlan hozzáférési kísérletet is jelezhet.
📌Itt már nemcsak a FortiGate VPN Syslogokat, hanem az on-premise Windows Server tartományvezérlők Event logjait is felhasználjuk. A két adatforrást összevetjük és korreláljuk, hogy átfogóbb képet kapjunk az eseményekről.
Az alábbi DCR (Data Collection Rule gyűjti be a Windows Event logokat a földi „on-premise” szerverről):
Ez pedig maga az eseménynapló bejegyzés:
Az Event ID 4728 a Windows Security Log egyik eseménye, amely azt jelzi, hogy egy felhasználót hozzáadtak egy biztonsági csoporthoz.
📌 Részletek az Event ID 4728-ról:
✔ Esemény típusa: Windows Security Log
✔ Esemény leírása: „A member was added to a security-enabled global group.”
✔ Mit jelent? Ez az esemény azt rögzíti, amikor egy felhasználó bekerül egy globális biztonsági csoportba, például az Administrators, Domain Admins vagy más privilegizált csoportokba.
A tesztem során manuálisan rögzítettem az eseményt a naplóba azon a tesztszerveren, amelyre az Azure Monitoring Agent már telepítve volt. Ugyanakkor ez akár egy valós eseményként is megjelenhetne, ha az Azure Monitoring Agentet a tartományvezérlőkre is telepítenénk. (Mivel éles környezetben „teszteltem”, így nem akartam a logokat „meghamisítani”.)
🔍 VPN Bejelentkezés és Admin Jog Kiosztás Felderítése
Az alábbi KQL lekérdezés segít azonosítani azokat az eseteket, amikor egy felhasználó VPN-en bejelentkezik, majd 3 órán belül admin jogot kap egy Windows gépen. Ez a viselkedés gyanús lehet, és segíthet kiszűrni potenciális támadásokat vagy jogosulatlan hozzáféréseket.
📌 KQL Lekérdezés
🔎 KQL Lekérdezés Működése
1️⃣ VPN események keresése (FortiGate logok)
✔ A FortiSyslog_CL táblából szűri a VPN eseményeket (subtype == "vpn").
✔ Csak a sikeres VPN csatlakozásokat (action == "tunnel-up") tartja meg.
✔ A felhasználónevet kisbetűs formára alakítja (tolower()), hogy illeszkedjen a Windows eseménylogokhoz.
✔ Kiválasztott mezők:
🔹 VPN_TimeGenerated – VPN bejelentkezés időpontja
🔹 User – A VPN-en bejelentkezett felhasználó
2️⃣ Windows események keresése (Admin jog kiadás)
✔ A Windows Event logokból csak azokat az eseményeket keresi, ahol az Event ID = 4728 (admin jog kiosztás).
✔ A RenderedDescription mezőből az admin jogot kapó felhasználót kisbetűsítve dolgozza fel.
✔ Kiválasztott mezők:
🔹 Event_TimeGenerated – Admin jog kiosztás időpontja
🔹 ExtractedUser – Az admin jogot kapó felhasználó
🔹 EventMessage – Az esemény részletes leírása
🔹 Computer – Az érintett számítógép
3️⃣ VPN és Windows események összekapcsolása
✔ A join kind=inner operátor segítségével összekapcsolja a két eseményt felhasználónév alapján (User == ExtractedUser).
✔ Csak az azonos felhasználókhoz kapcsolódó események maradnak meg.
4️⃣ Időbeli szűrés: csak 3 órán belüli események
✔ Az admin jog kiosztásának 3 órán belül kell történnie a VPN bejelentkezés után.
✔ Ha ez a feltétel nem teljesül, az esemény nem jelenik meg az eredményben.
5️⃣ Kimeneti adatok kiválasztása
🔹 ExtractedUser – Az érintett felhasználó neve
🔹 VPN_TimeGenerated – VPN belépés időpontja
🔹 Event_TimeGenerated – Admin jog kiosztás időpontja
🔹 Computer – Az érintett számítógép
🔹 EventMessage – Az esemény részletes leírása
🔹 EventType – Egyedi jelölés: "VPN Login & Admin Rights Escalation"
❓ Miért Fontos Ez a Szabály?
✅ Automatikusan felismeri, ha egy felhasználó VPN-en bejelentkezik, majd rövid időn belül admin jogot kap.
✅ Segít kiszűrni a gyanús tevékenységeket, például támadásokat vagy insider threat-eket.
✅ Microsoft Sentinelben riasztásra és incident generálásra használható.
A Fusion Rule elkészítése:
Bemásoljuk a lekérdezést, az Entity mapping, és scheduling megadása:
Mikor van találat, és a két eseményt összekapcsolja a Sentinel megjelenik az incidens:
📝Összegzés
A Sentinel a gyakorlatban nem csupán egy elméleti biztonsági megoldás, hanem egy valós helyzetekben tesztelt és bizonyítottan hatékony eszköz, amely segít az IT-környezetek átláthatóságának növelésében és a fenyegetések gyors kezelésében. A cikk során számos gyakorlati példát és valós forgatókönyvet vizsgáltunk meg, amelyek rámutattak a Sentinel erősségeire, kihívásaira és az optimalizálás lehetőségeire.
A tapasztalatok azt mutatják, hogy a megfelelő konfiguráció, folyamatos finomhangolás és automatizáció révén a Sentinel valóban hatékony védelmi vonalat képezhet. Nem csupán a riasztások észlelésében, hanem azok kontekstuális elemzésében és kezelésében is kulcsszerepet játszik.
Végső soron a Sentinel nem csupán egy eszköz, hanem egy proaktív biztonsági stratégia része, amely segíthet a cégeknek a modern fenyegetésekkel szembeni védekezésben. Az igazi kihívás nem csupán az implementáció, hanem a folyamatos optimalizálás és a biztonsági csapatok megfelelő felkészítése annak érdekében, hogy a Sentinel teljes potenciálját ki lehessen aknázni.