Password spraying'u ja credential stuffing'u tuvastamine logidest

Password spraying ja credential stuffing paistavad mõlemad logides ebaõnnestunud sisselogimiste hunnikuna, kuid hunniku kuju on erinev, nagu ka lahendus. Kui Teie ainus häire on "viis ebaõnnestumist ühel kontol", jäävad mõlemad rünnakud märkamata.

Kolm rünnakut, kolm mustrit

OWASP-i Credential Stuffing Prevention Cheat Sheet eristab neid järgmiselt:

OWASP-i sõnul on kaitsemeetmed paljudel juhtudel samad ja need toimivad ka brute force'i vastu.

Mida logidest otsida

MITRE-i tuvastusstrateegia password sprayingu puhul on suur hulk autentimisvigu, kus ühte parooli või väikest paroolide kogumit proovitakse paljudel kasutajakontodel kindla ajaakna jooksul. Credential stuffing'u puhul on tunnuseks mitu ebaõnnestunud katset erinevate kasutajanime ja parooli paaridega ühelt IP-aadressilt või ühest sessioonist lühikese aja jooksul.

Ründajad kohanduvad ilmsete vastumeetmetega:

• Aeglustatud spraying. MITRE kirjeldab APT28 tööriistu, mis tegid päevade või nädalate vältel umbes neli katset tunnis sihtmärgiks oleva konto kohta. Quad7 tegevuses tehti 24 tunni jooksul üks sisselogimiskatse, mis jäi brute force'i tuvastuslävedest allapoole. Kontopõhised loendurid seda ei püüa.
• Hajutatud spraying. MITRE märgib ka, et APT28 kasutas hajutatud suuremahulisteks sprayridadeks Kubernetes'i klastrit. Ainult allika-IP-põhine loendus jätab sellise rünnaku märkamata, sest ükski üksik aadress ei ebaõnnestu sageli. Lugege seetõttu ka ajaakna kohta kokku ebaõnnestunud erinevad kontod kõigist allikatest ning jaotage samad andmed lisaks ASN-i ja user agent'i järgi.
• Vaiksemad protokollid. Ründajad võivad kasutada LDAP- ja Kerberos-katseid, mis käivitavad vähem tõenäoliselt väga nähtavaid sündmusi, näiteks Windowsi "logon failure" sündmust ID 4625, mille tavaliselt põhjustavad ebaõnnestunud SMB-ühendused. Koguge lisaks 4625-le ka LDAP- ja Kerberos-vigu.

Ründajad sihivad tavaliselt haldusteenuseid levinud portidel: SSH (22/TCP), RDP (3389/TCP), SMB (445/TCP), LDAP (389/TCP), Kerberos (88/TCP) ning veebipõhised haldusliidesed portidel 80 ja 443. Sihtmärgiks on ka SSO, föderatiivset autentimist kasutavad pilverakendused ja väljastpoolt ligipääsetav e-post, näiteks Office 365 ja OWA.

Microsoft 365: kasutage smart lockout'i õigesti

Microsoft Entra smart lockout on alati sisse lülitatud. Vaikimisi lukustab see konto pärast 10 ebaõnnestunud katset Azure Public tenantides või pärast kolme katset Azure US Government tenantides. Esimene lukustus kestab ühe minuti ja pikeneb järgmiste ebaõnnestumiste korral. Microsoft ei avalda, kui kiiresti kestus kasvab.

• See jätab meelde kolm viimast vale parooli räsi, nii et sama vale parooli kordamine ei suurenda loendurit. See hoiab ära kasutaja korduva trükivea tõttu lukustumise. Spray vastu aitab see vähe, sest seal näeb iga konto parooli ainult üks kord.
• Tuttavatel ja võõratel asukohtadel on eraldi lukustusloendurid, nii et uuest asukohast ründav ründaja saab lukustuse, samal ajal kui tegelik kasutaja jätkab tööd.
• Kohandatud väärtused nõuavad Microsoft Entra ID P1 või kõrgemat litsentsi. Logige Microsoft Entra admin center'isse vähemalt Authentication Policy Administrator'i rollis ja minge Entra ID > Authentication methods > Password protection. Seal saate määrata Lockout threshold'i ja Lockout duration'i sekundites (vaikeväärtus 60).
• Entra blokeerib vaikimisi mõned sisselogimised ka IP-liikluse ja käitumissignaalide põhjal ning tagastab AADSTS50053 - IdsLocked, olenemata sellest, kas parool oli õige. Käsitlege kontosid, mille puhul see kood ilmub, sihitud kontodena, kuid ärge pidage seda tõendiks, et parool oli vale või õige.

Smart lockout ei garanteeri, et tõeline kasutaja ei jää kunagi lukku. MITRE lisab teise külje: liiga range poliitika võib põhjustada teenusetõkestuse, kui kõik rünnaku all olevad kontod lukustuvad.

Hübriidlahendused

Pass-through authentication'i puhul peab Entra lävi olema madalam kui kohaliku AD DS-i lävi ning AD DS-i lävi peaks olema vähemalt kaks kuni kolm korda kõrgem. Entra lukustuse kestus peab olema pikem kui AD DS-i oma. Microsofti näites on lävi 10 versus 20 ja kestus 120 sekundit versus 60. Entra kestus määratakse sekundites ja AD DS-is minutites, seega kontrollige ühikuid.

Räsi jälgimine ei ole pass-through authentication'iga saadaval. AD DS-i väärtuste vaatamiseks avage Group Policy Management, muutke poliitikat, mis sisaldab Teie lukustusseadeid, ja liikuge asukohta Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Account Lockout Policy.

Teie enda sisselogimisleht ja avalikud teenused

Lukustus on kontopõhine kontroll. Meie hinnangul ei jõua stuffing'u jooks, mis proovib iga kontot ühe või kaks korda, sageli kunagi lävendini, seega ärge tehke sellest põhikaitset. MITRE hoiatab, et stuffing võib põhjustada arvukalt ebaõnnestumisi ja lukustusi, kuid see sõltub Teie poliitikast. Mõlema tehnika leevendusmeetmete hulka kuuluvad lisaks:

• Mitmefaktoriline autentimine (MFA), kus võimalik lülitatud sisse kõigil väljastpoolt ligipääsetavatel teenustel.
• Conditional access poliitikad, mis blokeerivad sisselogimised mittevastavatest seadmetest või väljastpoolt organisatsiooni määratletud IP-vahemikke.
• Riskantsete päringute blokeerimine, näiteks anonümiseerivatest teenustest või proxy'dest tulevad päringud.
• NIST-i juhistel põhinevad paroolipoliitikad.
• Stuffing'u puhul andmeleketes teadaolevate kontode ennetav lähtestamine kas kohe või pärast brute force'i katsete tuvastamist.

Kohandatud rakenduse jaoks on OWASP-i Authentication Cheat Sheet sisaldab jaotisi kaitse kohta automatiseeritud rünnakute vastu, CAPTCHA kohta ning logimise ja monitooringu kohta.

Kust alustada

1. Koostage loend kõigist internetis nähtavatest sisselogimispunktidest: Microsoft 365 või OWA, VPN, RDP, SSH, SSO ja Teie enda veebivormid. Sulgege iga haldusport, mis ei pea avatud olema.
2. Kontrollige smart lockout'i läve ja kestust asukohas Entra ID > Authentication methods > Password protection. Pass-through authentication'i korral võrrelge neid Teie AD DS-i lukustuspoliitikaga ülaltoodud reeglite järgi.
3. Koostage sisselogimislogide peale kaks päringut. Esimene loeb tunni kohta allika-IP kaupa kokku ebaõnnestunud sisselogimistega erinevad kontod. Teine ignoreerib allikat: see loeb ajaakna kohta kokku ebaõnnestunud erinevad kontod üldiselt ja jaotab need seejärel ASN-i ja user agent'i järgi. Seadistage häire mõlemale ning hoidke AADSTS50053 eraldi vaates.
4. Lülitage MFA sisse kõigile väljastpoolt ligipääsetavatele teenustele ning lisage seejärel conditional access reeglid haldamata seadmetele ja anonümiseerivatele teenustele.
5. Võrrelge töötajate kontosid teadaolevate andmeleketega, näiteks meie lekkinud paroolide kontrolliga, ning lähtestage kõik, mis kattuvad. Kui Teil ei ole inimesi, kes logisid iga päev jälgiksid, katab selle lünga hallatud seire.