Ondrej Sevecek's Blog

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 vélmi 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 SCOM a 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:

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 DC a 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 server apod.

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

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.

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

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 logon událostem zjistíte také, kdy se nakonec odhlásil.