Always-on VPN IPSec policy Intune-ból

Aki már konfigurált AOVPN-t, az tudja, hogy illik az IPsec beállításokat az alapértelmezettnél erősebbé tenni.

Az alapértelmezett IPSec értékek a következők:

  • Encryption: 3DES
  • Authentication/Integrity: SHA-1
  • Key Size: DH Group 2 (1024 bit)

A javasolt beállítások:

  • Encryption: AES128
  • Authentication/Integrity: SHA-256
  • Key Size: DH Group 14 (2048 bit)

A VPN szerver oldalon ezt powershell paranccsal tudjuk módosítani:

Set-VpnServerConfiguration -CustomPolicy -AuthenticationTransformConstants SHA256128 -CipherTransformConstants AES128 -DHGroup Group14 -EncryptionMethod AES128 -IntegrityCheckMethod SHA256 -PFSgroup PFS2048 -SALifeTimeSeconds 28800 -MMSALifeTimeSeconds 86400 -SADataSizeForRenegotiationKilobytes 1024000

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:

$connection = “[connection name]”
Set-VpnConnectionIPsecConfiguration -ConnectionName $connection -AuthenticationTransformConstants SHA256128 -CipherTransformConstants AES128 -DHGroup Group14 -EncryptionMethod AES128 -IntegrityCheckMethod SHA256 -PFSgroup PFS2048 -Force

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:

IKE Security Association Parameters

  • Encryption algorithm: AES-128
  • Integrity check algorithm: SHA2-256
  • Diffie-Hellman group: 14

Child Security Association Parameters

  • Cipher transform algorithm: CBC-AES-128
  • Authentication transform alorithm: HMAC-SHA256-128
  • Perfect forward secrecy (PFS) group: Use parent Diffie-Hellman group

Elavult böngészők szűrése

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).

Break-glass account monitorozása

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:

SigninLogs
| project UserId,UserPrincipalName, Location, SourceSystem, TimeGenerated, IPAddress
| where UserId == 'object-id'
| extend AccountCustomEntity = UserPrincipalName
| extend IPCustomEntity = IPAddress
| extend HostCustomEntity = SourceSystem

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ó.