A Microsoft Network Policy Server elég jól logol alapesetben az Event Viewerben:
Előfordult azonban, hogy bár a kliensek használták az NPS-t, logok nem kerültek be az eventviewerben. Első körben ellenőriztem az NPS propertiesben, hogy be van-e kapcsolva a logolás:
Végül admin paranccsorból kierőltetve, megjelentek a logok:
Egyre több helyen alkalmazzák, hogy a Wifi/VPN hitelesítés nem név/jelszó párossal (esetleg valamilyen MFA megoldással kombinálva) történik, hanem felhasználói tanúsítványokkal. Nagyon üdvözlendő! 🙂
Sok esetben viszont a “lifecycle” kezelése nincs átgondolva és megoldva. Azaz: a tanúsítványkiadás megy GPO-ból/Intune-ból, mint a karikacsapás, de hogyan kezeljük a visszavonást? Security szempontból mindenképpen érdemes a távozó dolgozó kiállított tanúsítványait visszavonni, nem csak az Active Directory accountját letiltani stb.
Az alábbi példában bemutatom, hogyan lehet a Certificate Authority felületéről és Powershellből célzottan tanúsítványt visszavonni. Fontos hangsúlyozni, hogy ez egy user decomission process része kell legyen!
Tanúsítvány visszavonása CA konzolból:
Jelentkezzünk be a CA szerverre és indítsuk el a Certificate Authority konzolt. Az Issued Certificate résznél találjuk az összes kiállított tanúsítványt (akár több ezer is lehet)
Az egyes felhasználó számára kiállított tanúsítványokat a View/Filter opcióval tudjuk leszűrni.
Állítsuk össze a szűrési feltételt:
Field: Issued Common Name
Operation: =
Value: a kívánt felhasználó AD-ben szereplő neve (pl. Kovács László)
Megkapjuk az összes, számára kiállított tanúsítványt:
Ezután a tanúsítványon jobb klikkel kiválaszthatjuk a Revoke Certificate opciót:
Megadhatjuk a Reason Code-ot:
Az egyes kódok jelentése:
KeyCompromise. The private key that is associated with the certificate is compromised and is in the possession of an unauthorized individual—for example, if a portable computer is stolen or a smart card is lost.
■ CACompromise. The smart card or disk on which the CA’s private key is stored is compromised and is in the possession of an unauthorized individual. When a certificate manager revokes a CA’s certificate, all certificates issued by that CA are considered revoked.
■ AffiliationChanged. An individual is terminated or has resigned from an organization. It is not necessary to revoke a certificate when an individual changes departments unless your security policy requires that each departmental CA should issue certificates to the individuals in that department.
■ Superseded. A new certificate must be issued if a smart card fails or the legal name of a user has changed. The new certificate supersedes the previous certificate, which must be revoked.
■ CessationOfOperation. If your organization decommissions a CA, use this revocation code to revoke the CA’s certificate. Do not revoke the certificate if the CA publishes CRLs for the currently issued certificates but does not issue new certificates.
■ CertificateHold. A temporary revocation that indicates that a CA will not vouch for a certificate at a specific time. After a certificate is revoked by using CertificateHold, you can later unrevoke the certificate.
Tanúsítvány visszavonása Powershell segítségével
Ha egy felhasználónak több kiállított tanúsítványa van, a fenti konzolos megoldás fárasztó lehet. Itt tudjuk segítségül hívni a Powershellt.
A tanúsítványok visszavonása után ne felejtsünk el új CRL-t publikálni:
(Megjegyzés: sok visszavont tanúsítvány esetén a CRL mérete túl nagy lehet, ami egyes szolgáltatásoknál gondot okoz (pl. időtúllépés a CRL letöltése során). Ezért érdemes figyelni rá, hogy időnként a már nem szükséges visszavont elemeket töröljük a Certificate Authority adatbázisából)
Utána szükséges a Remote Access service-t újraindítani:
Restart-Service RemoteAccess -PassThru
Ezzel a szerveroldali beállítások elkészültek. Szükséges viszont hogy a kliens oldalon is megegyezzenek az IPSec konfigurációk, itt is segítségül hívhatjuk a powershellt:
Hogy néz ki mindez, ha Intune-ból akarjuk kiküldeni az IPSec policyt? Nos, elsőre nem feltétlenül egyértelmű, hogy a fenti parancsban definiált értékek hol vannak az Intune policyban:
Hogy ne kelljen sokat keresgélni, tesztelgetni, itt egy működő beállítás:
Az IT-securityben nagy hangsúlyt fektetünk rá, hogy az operációs rendszerek/alkalmazások naprakészek legyenek. Ugyanez vonatkozik a böngészőkre is, elemi érdek, hogy mindig a biztonsági frissítésekkel ellátott verziót használjuk, a céges erőforrások eléréséhez (OWA, Sharepoint Online stb).
Lásd CIS Control 9.1 “Ensure only fully supported browsers and email clients are allowed to execute in the enterprise, only using the latest version of browsers and email clients provided through the vendor.”
Eddig az elmélet, de a gyakorlatban hogyan tudjuk kikényszeríteni, hogy valóban csak “friss” böngészővel lehessen az erőforrásokat elérni?
Ebben segit az Azure AD Conditional Acces és Defender for Cloud Apps szolgáltatás. Lássuk, hogyan lehet letiltani az “outdated” browser használatát.
Megjegyzés: outdated browsernek számít az aktuális főverzió -2. Tehát ha pl. az Edge a 109-es verziónál jár, akkor támogatott a 109, 108 és 107 főverzió.
Először is, szükség lesz a kívánt erőforrás (OWA, Sharepoint stb) továbbirányítására a Defender for Cloud Apps-ba.
Conditonal Access
Készítsünk egy Conditional Access policy-t, az alábbi beállításokkal:
Defender for Cloud Apps Access Policy
A Cloud Apps-ban hozzunk létre egy Access Policyt:
Az User agent tag értéke legyen egyenlő az Outdated browser kategóriával illetve az Action legyen Block értéken. Természeseten más filtereket is hozzáadhatunk (user group stb.)
Tesztelés
Tesztelésként telepítettem egy Firefox 98-at és megpróbálkoztam egy böngészős Teams bejelentkezéssel. A Defender for Cloud Apps blokkolta is az elérést, ahogy vártuk:
A fenti tiltást nemcsak böngészőre, de akár operációs rendszerre is alkalmazható:
Összefoglalás
Ahogy a fentiekből látható, könnyen biztosíthatjuk, hogy naprakész böngészőkből legyen elérhető az erőforrás (ne feledjük, hogy nemcsak beépített MS szolgáltatásokat tudunk így védeni, az Azure AD Application Proxy segítségével akár 3rd party vagy on-prem alkalmazásokat is).
Fontos szerepe van a break-glass accountoknak, hogy legyen “visszaállási” lehetőségünk hibás konfiguráció (pl. kizártuk magunkat a tenantból Conditional Access policyval) vagy szolgáltatás kiesés esetén. Személyes élmény 2018-ból, mikor nagyjából napig nem működött az Azure MFA, így bejelentkezni sem tudtam az admin accounttal 🙂
Erre a veszélyre reflektálva sok szervezet használ már break-glass accountot. Mielőtt rátérnénk a security vonatkozásokra, nézzük át gyorsan az ajánlásokat az accounttal kapcsolatban:
a break-glass account az Azure AD-ban létrehozott entitás legyen; ne használjuk syncelt vagy federált accountot.
ne legyen személyhez kapcsolva
Ha használunk a breakglasshoz MFA-t, ne legyen valaki személy telefonja, emailcíme stb; a legjobb egy dedikált FIDO2 security key, biztos helyre elzárva
az accountra ne vonatkozzon semmilyen Conditional Access policy, illetve egyéb más security policy
Azure AD Identity Protectionban állítsuk permanent Global Administratorra, ne csak Eligible-re
Monitorozás
Security szempontból elengedhetetlen, hogy monitorozzuk ennek az accountnak a használatát. Hiszen nincs személyhez kötve, nincs MFA sem hozzá, így kritikus hogy lássuk az aktivitását. Ebben tud segiteni a Microsoft Sentinel.
A monitorozáshoz szükséges előfeltételek:
Microsoft Sentinel és Log Analytics Workspace
Azure AD P1 vagy P2 licensz a sign-in logok exportálásához
Break-glass account
Break-glass account Object ID
Feltételezzük, hogy a Sentinel már be van állítva, rátérhetünk a konnektor konfigurálásra.
Sentinel konnektor konfigurálása
Navigáljunk el a Sentinel portálra, majd a Data Connectors közül válasszuk ki az Azure Active Directory konnektort:
Az Audit és Sign-in logokat válasszuk ki:
A konnektor státuszát és a loggyűjtést tudjuk ellenőrzni a tulajdonságlapon:
Analytic rule elkészítése
Készítünk egy rule-t, ami incidenst generál ha a break-glass accounttal aktivitás történne.
Navigáljunk el a Sentinel portálon az Analytics részre és válasszuk a Create scheduled query rule opciót.
Adjunk nevet és leírást a szabálynak, a Tactics résznél válasszuk ki az Initial Access és Credential Access lehetőségeket, a Severity legyen High értéken.
A Set rule logic résznél egy Kusto lekérdézést kell definiálnunk:
Az UserID-hoz tartoztó object-id-t megtaláljuk az Azure Active Directoryban a break-glass account tulajdonságlapján.
A lekérdést állítsuk be 5 percenkéntire.
Az Incident setting résznél állitsuk be hogy generálódjon incidens
Ellenőrzés
A beállítások után érdemes leellenőrizni, hogy valóban működik-e az incidensgenerálás. Ehhez jelentkezzünk be a break-glass accounttal és nézzük, megjelenik-e a Sentinel alert.
Összefoglalás
Az break-glass account megléte nagyon fontos, de ugyanúgy kiemelt szerepet kap a monitorozása is. A fentiek alapján ez könnyen beállítható.
Amikor az IT-securityben gondolkodunk, nem szabad elfelejteni a külső támadási felületet (external attack surface), ahonnan a szervezet támadható. A támadási felületbe tartozhat egy internetre publikált weboldal, egy nem támogatott és esetleg sérülékenységet tartalmazó PHP-kód.
A külső támadási felület felmérését általában erre szakosodott cégekkel szokták megvizsgáltatni a vállalatok. Ez egyrész drága is lehet, illetve sokszor csak egy pillanatképet kapunk az aktuális problémákról.
Defender EASM
Az EASM folyamatosan felfedezi és feltérképezi digitális támadási felületet, hogy külső nézőpontot adjon az online infrastruktúráról. Ez a vizibilitás segithet az IT szakembereknek hogy azonositsák és elháritsák a kockázatokat.
A Defender EASM a Microsoft-infrastruktúra feltérképezési technológiai részét használja az online infrastruktúrához kapcsolódó eszközök felfedezésére, a technológia aktívan szkennel, hogy további betekintést nyerjen és felderítse a gyenge pontokat.
Az alábbi erőforrásokat képes felhasználni a felderitéshez:
Domains
Hostnames
Web Pages
IP Blocks
IP Addresses
ASNs
SSL Certificates
WHOIS Contacts
Licenszelés: az első 30 napig ingyenes, utána 0,011 USD/asset/nap. Assesnek számit a domain/host/IP cimek stb
EASM beállitása
A használatához szükségünk lesz egy Azure előfizetésre és egy resouce group-ra. Fontos tudni, hogy jelenleg EASM-instancet csak az alábbi régiókban tudunk létrehozni:
A deployment végeztével az Overview fülön kezdhetjük el a beállitást. Rákereshetünk egy létező vállalatra vagy a “Create custom attack surface” gombbal definiálhatunk egyedi beállitásokat. A példa kedvéért mi egy custom konfigurációt készitünk.
Itt meg kell adnunk a Seed-eket, azaz információkat, amikre a discovery process lefuthat. Ezek lehetnek domainek, IP-tartományok, email kontaktok (pl. office@cegnev.hu) stb. Válasszuk a domaint és irjuk be a kivánt értéket.
Végül mentsük el a konfigot. A leltározási folyamat 24-48 órát vehet igénybe
A discover folyamat igy néz ki:
EASM használata
A leltár felépülte után az Overview oldalon egy áttekintést kapunk
Az Attack Surface Priorities szekció összefoglalja a különböző megfigyelt problémákat. A képen látható 2 medium és 5 low severity találat.
Az egyes találatokra kattintva láthatjuk az érintett IP-ket/hostokat. Jelen esetben egy Django projectnél azonositott egy SQL-injection sebezhetőséget, a hozzátartozó CVE advisory-val és a remediation lépésekkel (Django frissités ajánlott)
Inventory
Az inventoryban láthatjuk a felderitett elemeket. Az asseteket törölhetjük, módosithatjuk
Security Posturedashboard
A security posture mutat különböző értékeket, pl CVE exposure, domainek adminiszrációjával (hol vannak a domainek regisztrálva), az internet felől elérhető nyitott portokat
GDPR Compliance dashboard
A felderitett asseteket megvizsgálja GDPR megfelelőség szempontjából. A dashboard részei a következők:
Website by status
SSL Certificate Posture
SSL Certificate Expiration
Sites with SHA 1 / SHA256
P11 Posture
Login posture
Cookie posture
OWASP Top 10 dashboard
Ezen a dashboardon láthatjuk az OWASP által definiált legkritikusabb security ajánlásokat.
Broken access control
Cryptographic failure
Injection
Insecure design
Security misconfiguration
Vulnerable and outdated components
Identification and authentication failures
Software and data integrity failures
Security logging and monitoring
Server-side request forgery
Összefoglalás
A Defender EASM egy nagyon hasznos eszköz arra, hogy security szemszögből “kintről”, az internetről is felfedezzük a security hiányosságokat, problémákat. Az assetek számára érdemes odafigyelni, mert bár darabonként nem drága, de többezer tételnél már növelheti az Azure költséget.
Egyre közeleg a dátum, mikor a Microsoft végleg kivezeti a basic authenticationt az Exchange Online elérésében (2023.március 31.)
Az M365 adminok ezt többé-kevésbé tudják, és meg is teszik a szükséges lépéseket. Viszont sokszor jön a kérdés, mik is ezek a legacy protokollok és mi használja őket?
Az Azure Active Directoryban sign-in logban leszűrve ezeket látjuk, mint legacy protocols:
Legacy protocols:
Authenticated SMTP – POP és IMAP kliensek használják levélküldésre
Autodiscover – Outlook és Exhange Active Sync kliensek használják a mailboxok megkeresésére az Exchange Online-ban, pl Windows Mail és egyéb mobilalkalmazások
Ügyfelekkel való konzultáció során szinte mindig elhangzik a kérdés: melyek az ingyenes Sentinel-konnektorok? Tudjuk őket definiálni, de vannak olyan ingyenes konnektorok, amik tartalmaznak fizetős elemeket is.
Ingyenes adatforrások:
Azure AD Identity Protection
Azure Activity Logs
Office 365
Microsoft Defender for Cloud
Microsoft Defender for IoT
Microsoft 365 Defender
Microsoft Defender for Endpoint
Microsoft Defender for Identity
Microsoft Defender for Cloud Apps
Fontos tisztázni: a data connector bekötése mindig ingyenes. A logfileok esetén csak az Azure Acive Directory és O365 audit logok ingyenesek. A többi logforrásnál csak az alert és incidens generálás és néhány aktivitás ingyenes.
Nézzük egyenként a data connectorokat:
Azure AD Identity Protection:
Előfeltétel: Azure AD Premium 2 licensz
Ingyenes adattipus: Security Alert (IPC)
Azure Activity:
Ingyenes adattipus: minden tipus
Office 365
Ingyenes adattipus: Sharepoint, Exchange és Teams activity
Defender for Cloud:
Ingyenes adattipusok: Security Alert
Defender for IoT:
Ingyenes adattipus: Security Alert
Microsoft M365 Defender:
Ingyenes adattipus: Security Alert és Security Incident
Figyelem: a többi adatbetöltés már számolódik a Sentinel költségbe!
Defender for Endpoint:
Ingyenes adattipus: Security Alert (MDATP)
Defender for Identity:
Ingyenes adattipus: Security Alert (AATP)
Defender for Cloud Apps:
Ingyenes adattipus: Security Alert (Defender for Cloud App)
A Cloud Discovery logok bekapcsolása szintén számolódik a Sentinelben
Összefoglalva:
Mint látjuk, a Microsoft Sentinelt költséghatékony módon tudjuk használni arra hogy az O365 és Azure Activity logokat gyűjtsük és a különböző Microsoft termékekből érkező alerteket is fogadjuk.
2022 novemberében a Microsoft az Ignite konferencián bejelentette az Azure AD CBA szolgáltatás végleges (General Available) állapotba kerülését. Lássuk, mi ez és hogyan tudjuk beállitani.
Mi az Azure AD CBA?
A CBA lehetővé teszi, hogy különböző Microsoft alkalmazásokba és webes felületekre tanúsitvánnyal jelentkezzünk be. A tanúsitványt a saját PKI (public key infrastructure) környezetünkből kapjuk és az Azure AD ezt használja fel a hitelesitéshez. Ezzel egy úgynevezett phishing-resistent megoldást kapunk.
Hogyan működik a CBA?
A következő ábra bemutatja a bejelentkezési folyamatot:
Az Azure AD ellenőrzni, hogy a tenantban be van-e állitva a CBA authentication. Ha igen, akkor megjelenik egy link “Use a certificate or smartcard” néven
7. Az Azure AD ellenőrzni a tanúsitvány visszavonási listát (CRL), hogy nincs-e visszavonva
8. Ha van Conditional Access policy, ami megköveteli az MFA-t, és ha az úgynevezett certificate authentication binding rule megfelel, akkor a belépés megtörténik.
9. Az Azure AD elküldi a primary refresh tokent és a belépési process lezárul
Hogyan állitsuk be a CBA-t?
Előfeltételek:
Működő PKI rendszer (legalább egy root CA plusz egy intermediate CA)
Kiadott tanúsitvány a felhasználóknak (client authentication SKU)
A CA-nak legyen elérhető a CRL listája az internet felől (ennek hiányában az Azure AD nem fogja leellenőrizni a tanúsitvány érvényességét és nem blokkolja a belépést)
Ügyfeles konzultáció során merült fel az alábbi scenárió:
“Exchange 2016 hybrid környezetünk van, sok postafiókot már migráltunk az O365-be, de sok még a földi Exchange-en van. Az Exchange Online elérésére van több Conditional Access lehetőségünk (MFA, Intune compliant device stb) is, lehetne ezt a földi fiókokra is alkalmazni?”
Jó hír, hogy lehetséges, a Hybrid Modern Authentication révén (minimum követelmény az Exchange 2013 és Outlook 2013)
Hogyan néz ki a Hybrid Modern Authentication (HMA) folyamat?
A felhasználó elindítja az Outlookot ami az autodiscover segítségével csatlakozik a földi Exchange–hez. Innen a kapcsolat továbbmegy az evoSTS URL-hez, amit az HMA kialakítása során beállítottunk.
Az Outlook az AzureAD-hoz fordul, végrehajtja a modern auth folyamatot, alkalmazódnak rá az esetlegesen beállított Conditional Access szabályok.
A sikeres auth után a felhaszáló megkapja az Access Tokent és Refresh Tokent.
Az Access Tokent átadva a földi Exchange szervernek, a mailbox elérhetővé válik.
Kinek ajánlott a HMA?
Olyan szervezeteknek, ahol hosszú távú hybrid kialakítását tervezik, és biztosítani kívánják, hogy a földi postafiókok elérése is ugyanolyan szabályozottan történjen, mint a felhős esetén.
Zoltan Istvanffy's IT Blog 