V pátek jsem se zákazníkem řešil, jak zrychlit zneplatnění certifikátu (certificate revocation). Oni mají přihlašování čipovými kartami (smart card logon - PKINIT). A zdálo se jim, že mít CRL s celodenní platností není moc vhodné. To je pravda. K tomu ale něco až v druhé části.
Nejprve jsem chtěl, abyste si uvědomili něco jiného. Pokud se přihlašujete pomocí Kerberos (což je výchozí), tak dostáváte tickety, které platí 10 hodin (opět výchozí nastavení). I přihlašování čipovou kartou je ve skutečnosti Kerberos, který na základě karty generuje ty stejné tickety. Z toho vyplývají určité otázky ohledně zákazu účtu.
Zajímají nás pouze síťové přístupy
Nejprve si ujasněme, že nás zajímají hlavně síťové přístupy. To, že uživatel po přihlášení na stanici, na ní může pracovat až do smrti, nám nevadí. Tomu stejně nejste schopni zabránit, protože přihlášení z cache (cached logon) nikdy nevyprší (moje starší věci zde a zde).
Ale do sítě se už nemusí dostat. Pro přístupy do sítě musíte mít vždy nějaké online přihlašovací údaje. Tam keš nefunguje.
Budeme se tedy zabývat v podstatě třemi síťovými ověřovacími metodami - Kerberos, NTLM (obecně všechny tři verze LM, NTLM, NTLMv2) a Schannel. V případě Kerberos se můžete ověřit heslem, nebo privátním klíčem certifikátu na čipové kartě (PKINIT). V případě NTLM se ověřujete pouze heslem. V případě Schannel se ověřujete pomocí TLS client certificate authentication - tohle umí HTTP.SYS (a tedy IIS, AD FS, nebo WinRM, nebo SQL reporting services apod.). O TLS client certificate authentication jsem psal už například tady.
Takže máme tři metody. Všechny tři metody budou do sítě muset ověřit každé nově vznikající TCP spojení, nebo i častěji. V případě HTTP a Kerberos se například ověřuje i každý požadavek. Prostě aby řeč nestála.
K tomu "TCP spojení" bych ještě upozornil, že například sdílené soubory (SMB), nebo prohlížeče (HTTP) si nechávají svoje spojení otevřené i potom, co už nic nestahují, nebo i když pozavíráte všechna okna (případ u SMB). Čistě z toho důvodu, aby to nemuseli znovu nákladně otevírat, kdyby si uživatel v dohledné době vzpomněl, že chce pokračovat. Timeout u těch spojení je ale obvykle v oblasti několika sekund (SMB má 20 sec), nebo minut (IEčko má 1 minutu).
Zákaz účtu při NTLM a Schannel
Tyto dva protokoly vyžadují pass-through ověření každého spojení přímo online na DC. Pokud zakážete uživatelský účet, projeví se to tedy hned při nejbližším pokusu uživatele dostat se někam do sítě. Stejně jako změny členství ve skupinách, jak jsem tu již jednou psal.
Zákaz účtu při Kerberos ověření
Je jedno, jestli se ověřujete pomocí hesla, nebo čipové karty (smart card logon). V obou případech vám domain controller vytvoří TGT ticket. Tento platí 10 hodin. Po tuto dobu se už znovu nevytváří.
Pokud jdete později na nějakou síťovou službu, musíte k tomu mít TGS ticket (service ticket). Ten vám opět musí vydat DC. Vydá vám ho na základě předchozího TGT. TGS ticket platí od okamžiku vydání maximálně po dobu platnosti původního TGT. Takže zase něco méně, než 10 hodin.
Jak se tedy projevuje zákaz účtu? Jestliže už máte TGT, zákaz účtu se už znovu nekontroluje. Od toho to taky má delší platnost, aby se ušetřila zátěž na DC. To znamená, že s platným TGT se můžete dostat v pohodě ještě dalších 10 hodin do sítě. Tečka.
Poznámka ke členství ve skupinách. TGT obsahuje jen global a universal skupiny. Zatímco TGS obsahuje navíc i domain local skupiny. Změna členství ve skupinách se tedy projeví také nejhůře až za 10 hodin.
Kdybyste to chtěli zrychlit, můžete zkrátit životnosti TGT a TGS tiketů v politice. Nemám moc zkušeností s takovou změnou. Jediné co můžu říct je, že u jednoho zákazníka jsem kdysi nastavoval 2 hodiny, u jiného jsme to dali dokonce na 35 minut pro TGS a (1 hodina pro TGT) a zdá se, že všechno žije. Ale byl bych opatrný. To může záviset hodně na prostředí a službách.
Ještě poznamenejme, že připojení, která se ověřují pomocí RADIUS (jako jsou VPN, nebo WiFi), se také ověřují jen při ustavení toho spojení a je čistě na implementaci, jestli to má nějaké opětovné ověření v průběhu připojení, nebo ne.
Tohle jsou důvody, proč i ISO/IEC 27002 doporučuje zvážit podle bodu 9.2.6 Removal or adjustment of access rights, jestli není vhodné člověka, kterého vyhazujete, fyzicky odstřihnout od možnosti vůbec pracovat - například ho pryč doprovodí bezpečák. Měli byste mít také seznam připojení, která by bylo vhodné mu explicitně utnout ručně (VPN, terminál apod.).
Odbočka - vtipná příhoda ke slovíčku "bezpečák". Kdysi jsme byli s kamarádem na akci. Byl hrozně pyšný, že má tričko s nápisem RSA Security. Potom vychladl, když se ho nějaké holky ptaly, jestli má obušek, nebo nosí i pistoli :-)
Smart card logon a zneplatnění přihlašovacího certifikátu
Pokud používáte přihlašování čipovými kartami, bojujete ještě s jedním problémem. Když člověk někde ztratí, nebo jen zapomene kartu (smart card), měli byste mu její certifikát zneplatnit (revoke). Tohle jde udělat i dočasně (certificate hold - ano, v tomto případě to není nic proti filosofii, protože se tím jen přihlašujete a neděláte non-repudiation).
Zneplatněné certifikáty se musí objevit na CRL (certificate revocation list), který se vydává jen občas. Výchozí nastavení je myslím jednou denně.
Je jedno jestli máte delta CRL, nebo používáte i OCSP. Jde vždycky o interval platnosti tohoto delta CRL seznamu, se kterým musíte počítat.
Ano, CRL můžete vydat ručně rovnou v okamžiku, kdy certifikát zneplatňujete. To ano, to samozřejmě uděláte. Jenže klienti a řadiče domény (DC) mohou mít předchozí CRL/OCSP nakešované na celou dobu jeho platnosti.
Zabývejme se tedy otázkou, jak tohle co nejvíce zrychlit. Prostě nastavit jeho platnost na co nejkratší dobu. Něco jako 1 hodina například?
Proti této touze nás budou ale brzdit požadavky na dostupnost certifikační autority (CA) a CRL/OCSP distribučních bodů. Případně LDAP replikační prodlevy na ADčku (AD replication delay), pokud tedy publikujete do LDAPu.
CRL publikační interval, požadavky na dostupnost CA a jak to vylepšit
OCSP odpovědi se generují z CRL, takže s tímto se tu není potřeba zabývat. Nehledě na to, že OCSP je nejspíš docela zbytečné vůbec pro interní autiritu mít.
AD CS publikuje CRL podle registrové hodnoty CrlPeriodUnits.- nastavitelné i přes GUI ve vlastnostech položky Revoked Certificates. Podle toho se uvnitř CRL objeví hodnoty Effective date a Next update. Tedy to určuje platnost CRL. Jsou tam ještě přesahy o pár minutek kvůli rozhození hodin, ale to není podstatné.
Blbé je toto. Přestavte si, že autorita, nebo CRL distribuce, selže těsně okolo okamžiku další publikace CRL. Všechno přestane fungovat a nebudete mít dostatek času to opravit. Na vylepšení tohoto problému se používá buď registrová hodnota CrlOverlapPeriodUnits, nebo prostě jenom naplánovaná úloha na publikaci CRL častěji (certutil -crl a certutil -crl delta).
Detaily jsou mimo tento článek. Prostě to znemaná, že platnost CRL je potom dána CrlPeriodUnits plus CrlOverlapPeriodUnits. Viz. můj obrázek:
Pokud tedy publikujete CRL častěji, než je jeho skutečná platnost pro klienty - certutil -crl, nebo právě CrlOverlapPeriodUnits - požadavky na jeho dostupnost jsou dány právě tímto jeho časem.
Jenže to je možná pořád moc krátko. A přitom bych rád měl co nejrychlejší CRL. Potom si můžete pomoci ještě dalším nastavením, které funguje pro Windows Vista a Windows 2008 a novější. Podle následujícího obrázku. Prodlouží to platnost CRL, pokud nelze stáhnout novější (certificate path validation settings - allow CRL and OSCP responses to be valid longer than their lifetime).
Zde je obvykle diskuze. Když mám krátké CRL a přitom ho tady znovu prodloužím, není to nebezpečné? Trošičku, ale jen opravdu maličko :-) To by musel nějaký MITM být schopen zablokovat uživateli schopnost stáhnout aktuální CRL. Já tvrdím, že pokud by už byl schopen zablokovat stahování CRL, nebo OCSP, tak to už může udělat takovou škálu mnohem lepších útoků, než aby blokoval CRL. Navíc se nám jedná o přihlašování čipovou kartou.
To by vektor útoku musel být následující. Fyzicky ukradnu kartu a potom ještě počítači, ale i všem DCčkům, zablokuju CRL, abych se mohl přihlásit. No nesmysl. Jestli ten MITM umí zablokovat CRL pro všechna DCčka, proč by kradl někomu čipovku? To už zaútočí někde jinde a přitom pohodlněji.
Takže můžete mít CRL platnost opravdu kraťoučkou, například hodinu a přitom mít požadavek na jeho dostupnost v oblasti několika hodin.