Bezpečnostní auditování ve Windows – přihlašovací události


Dneska bych se rád pověnoval základům bezpečnostnímu auditování ve Windows a zvlášť demystifikaci událostí Logon (přihlášení) a Account Logon (přihlášení k účtu, ověření pověření). Oboje obsahuje slovo "logon", což je dost matoucí, protože oba dva druhy představují v podstatě něco úplně jiného.

Plno dalších detailů se můžete dozvědět i na mém školení GOC175 v GOPASu. Samozřejmě přijďte také na velmi aktuální konferenci ShowIT, kde sice moc o událostech nebude, ale zase to bude událost sama pro sebe.

Události typu logon event se mají spíše jmenovat session event. Zatímco události account logon event bych spíše nazýval authentication event. A to už by pomalu mohlo být přehlednější.

Oba dva druhy mohou být důležité. Pro oba dva druhy můžete využít i Alerty, nebo Rules ve SCOMa sledovat různé bezpečnostní zajímavosti. Případně se to velmi hodí pro zkoumání situace po nějakém incidentu. Jenom je vždycky potřeba přesně rozumět tomu, na co oba dva druhy jsou.

Už jsem se o auditování dříve zmiňoval, zde a zde a zde jsou nějaké tři starší článečky, které ho využívají.

Nejprve k otázce Account Logon (přihlášení k účtu, ověření pověření) event událostí

Account logon vzniká na počítačích, které přímo ověřují uživatelský účet – například heslo (password), nebo čipovou kartu (smart card), nebo certifikát (certificate). Tedy ve většině případů na Active Directory Domain Controller (AD DS DC), kdy se jedná o doménový účet. Pokud se jedná o lokální účet, tak taková událost samozřejmě vznikne přímo na počítači, který ten účet lokálně ověřuje, ale toho nebude nejspíš tolik, takže o tom ani nebudeme už dál přemýšlet.

Takové ověření bude buď pod-kategorie Kerberos Authentication Service (přihlašovací služba protokolu Kerberos) při vydávání TGT tiketu. Nebo Credentials Validation (ověření pověření) v případě NTLM ověření heslem a Schannel ověření TLS client authentication certifikátem. Může to být i Kerberos Service Ticket Operations (operace lístku služby Kerberos), tam jde o vydávání TGS ticketu na základě předchozího TGT ticketu. Ale pořád se to loguje na DC v okamžiku "ověřování" uživatelských tajných přihlašovacích údajů (secret authentication information podle CSN/ISO/IEC 27002)

Uvnitř události se nachází například číselná hodnota důvodu, proč se ověřit identitu nepodařilo. Není to tam napsáno textem, ale čísla lze jednoduše překládat pomocí ERR programu. Tady je tabulečka s důležitými kódy chyb, význam by měl být obykle jasný rovnou ze systémové hodnoty:

Stavový kód

Hodnota

Význam

STATUS_WRONG_PASSWORD

0xC000006A

 

STATUS_PASSWORD_RESTRICTION

0xC000006C

snažíte se přihlásit prázdným heslem v případě, že na účtu toto heslo skutečně je prázdné, ale je zakázáno se s ním přihlásit

STATUS_LOGON_FAILURE

0xC000006D

 

STATUS_ACCOUNT_RESTRICTION

0xC000006E

 

STATUS_INVALID_LOGON_HOURS

0xC000006F

 

STATUS_INVALID_WORKSTATION

0xC0000070

 

STATUS_PASSWORD_EXPIRED

0xC0000071

 

STATUS_ACCOUNT_DISABLED

0xC0000072

 

STATUS_LOGON_NOT_GRANTED

0xC0000155

 

STATUS_LOGON_TYPE_NOT_GRANTED

0xC000015B

 

STATUS_ACCOUNT_EXPIRED

0xC0000193

 

STATUS_PASSWORD_MUST_CHANGE

0xC0000224

 

STATUS_ACCOUNT_LOCKED_OUT

0xC0000234

 

KDC_ERR_NONE

0x0

 

KDC_ERR_NAME_EXP

0x1

 

KDC_ERR_SERVICE_EXP

0x2

 

KDC_ERR_BAD_PVNO

0x3

 

KDC_ERR_C_OLD_MAST_KVNO

0x4

 

KDC_ERR_S_OLD_MAST_KVNO

0x5

 

KDC_ERR_C_PRINCIPAL_UNKNOWN

0x6

 

KDC_ERR_S_PRINCIPAL_UNKNOWN

0x7

 

KDC_ERR_PRINCIPAL_NOT_UNIQUE

0x8

 

KDC_ERR_NULL_KEY

0x9

 

KDC_ERR_CANNOT_POSTDATE

0xA

 

KDC_ERR_NEVER_VALID

0xB

 

KDC_ERR_POLICY

0xC

 

KDC_ERR_BADOPTION

0xD

Kerberos delegation (delegace, neboli double-hop) není povolena a přitom se o ni žádolo

KDC_ERR_ETYPE_NOTSUPP

0xE

špatný typ šifrování (encryption type), jako jsou problémy s AES, nebo DES a RC4 apod.

KDC_ERR_SUMTYPE_NOSUPP

0xF

 

KDC_ERR_PADATA_TYPE_NOSUPP

0x10

 

KDC_ERR_TRTYPE_NO_SUPP

0x11

 

KDC_ERR_CLIENT_REVOKED

0x12

účet zakázán

KDC_ERR_SERVICE_REVOKED

0x13

 

KDC_ERR_KEY_EXPIRED

0x17

heslo vypršelo, tohle platí i v případě čipové karty

KDC_ERR_PREAUTH_FAILED

0x18

špatné heslo, nebo neplatný certifikát – tohle jsou v Kerberos události, které také způsobují například zamykání účtu. Pokud Kerberos pre-authentication vypnete, tak se vám například ani nebudou zamykat účty.

KDC_ERR_PREAUTH_REQUIRED

0x19

tohle není vůbec chyba. Znamená to, že Kerberos vyžaduje pro ověření preauthentication a zrovna tento požadavek byl bez "hesla". Takže se to musí zkusit ještě jednou. Takhle to dělá Vista/7/8/2008 a novější ve výchozím stavu.

KRB_AP_ERR_SKEW

0x25

rozhozené hodiny

U Account Logon event jde o okamžiky ověření. Když se například ráno přihlašujete do Windows, tak se na blízkém DC objeví právě jeden Kerberos Authentication Service event. A potom dalších pár hodin nic. Když se z počíteče nebo ze sítě "odhlašujete", tak se už nic neobjevuje. To je proto, že pro "odhlášení" se vůbec nekontaktuje DCa tím pádem není ani co logovat.

Události typu Logon (přihlášení a odhlášení) event

Tyto události se narozdíl od událostí typu Account Logon event objevují primárně ne na DC, ale právě na stanicích a serverech, tedy tam, kde uživatel konkrétně pracuje. Tedy má tam session. Zde jsou k dispozici i logoff eventy, protože počítače vědí přesně, kdy končí session – jak interaktivní přihlášení, RDP, nebo ověřené síťové spojení.

Samozřejmě se uživatelé objevují občas i na řadičích domény (DC), protože si odtud stahují Group Policy, nebo se dívají do AD LDAPu, ale to je teď druhořadé.

Berme to tak, že Logon eventy se vám budou objevovat na stanicích a serverech. Zde vznikají v okamžiku vzniku paměťové struktury access token (o access tokenech jsem psal už tady, tady v souvislosti s aktualizací členství ve skupinách a třeba i tady v souvislosti s UAC).

Vznikají v okamžiku, kdy vzniká session. To znamená v okamžiku interaktivního přihlášení (interactive), přihlášení na RDP (remote interactive), připojení na existující RDP (unlock), odemknutí zamknutého desktopu (unlock), spuštění služby (service) nebo naplánované úlohy a IIS apppool (batch). Dokonce vzniká i pokud session vzníká z cache bez ověření na řadiči domény (cached logon). Toto je tedy na daném počítači, kde pracujete.

Ale logon event vzniká i pro každé TCP spojení, na kterém jste se ověřili. Taková událost (network logon) vzniká na serveru, kde to TCP spojení končí. Na klientovi nevzniká nic. Díky tomu jste schopni sledovat, který uživatel se kdy připojil na který file server, SQL server, web serverapod.

Typ session se uvádí v události v položce logon type (typ přihlášení):

Type

Value

Interactive

2

Network

3

Batch

4

Service

5

Unlock

7

NetworkCleartext

8

NewCredentials

9

RemoteInteractive

10

CachedInteractive

11

CachedRemoteInteractive

12

CachedUnlock

13

Vzhledem k tomu, že každá jak lokální, tak i síťová session někdy skončí, tak o ní daný počítače, nebo server obvykle přesně ví (kromě případu tvrdého resetu). Můžete tedy logovat i logoff (odhlášení) událost. Dozvíte se tedy přesně, kdy se například síťové spojení ověřilo a kdy skončilo. To se dá párovat pomocí Logon ID (neboli logon session ID, neboli ID přihlášení).

Je zajímavé, že do logon kategorie patří i account lockout (uzamčení účtu). To se ale neaudituje na řadičích, které účet zamykají, ale audituje se to na počítačích, na kterých právě kvůli zámku nemohla vzniknout daná session. Takže to bude vždycky jenom failure audit. Na řadičích DC se v takovém případě audituje Account Management event (událost správa účtu).

Pro přehlednost obrázky

Podívejte se na následující obrázky. Na prvním vidíte interaktivní přihlášení (interactive logon). Nejprve se zalohuje account logon event na řadiči domény a v zápětí na stanici logon event.

ss1

Když pak jdete do sítě (network logon), zaloguje se nejprve na AD DC řadiči opět nejprve account logon, protože se musí vydat Kerberos TGS lístek, nebo se musíte NTLM ověřit heslem. A hned potom se zaaudituje logon event na cílovém serveru, kde končí dané TCP spojení.

ss2

Shrnutí

Díky událostem account logon se dozvíte odkud a kdy a kdo se na řadičích domény DC ověřoval. Díky logon událostem se dozvíte na konkrétních počítačích, kdy na ně skutečně daný uživatel přišel, tedy na obrazovku, nebo kdy se připojil ze sítě. Díky logonudálostem zjistíte také, kdy se nakonec odhlásil.

– Ondřej Ševeček, MVP, www.sevecek.com

Comments (2)

  1. Robert Bisom says:

    Článek super, ale nefunguje mi tam jediný odkaz – všechno vede někam na hq.sevecek.com, kamž evidentně neznám jméno a heslo pro přihlášení:)

  2. blogCZSK says:

    Dobrý den,

    omlouváme se za tuto chybu. Nyní už jsou odkazy aktivní.

Skip to main content