Skip Ribbon Commands
Skip to main content

Ondrej Sevecek's Blog

:

Engineering and troubleshooting by Directory Master!
Ondrej Sevecek's Blog > default
říjen 24
Výkonová charakteristika Group Policy

Já rád dělám hodně Group Policy Objectů (GPO). Každý obsahuje jen maličko nastavení. Jmenují se přesně podle toho, co dělají. Viz. přiložený obrázek - v tomto pokusu jich bylo 63, z toho některé mají zapnuté Enforce. V mnoha z nich je jen jedna hodnota. Na několika z nich je dokonce WMI filter. V některých používám Group Policy Preferences. Prostě klasický mix všehochuti.

Ano, jsou to jenom testovací GPO. Normálně jich udělám tak čtyřikrát tolik :-) Navíc já nevypínám tu druhou část - většina těch objeků má nastavení v Computer Configuration, ale přitom má "zapnutou" i část User Configuration. Uživatelská část je ale prázdná. Ano, mohl bych ji vypnout, abych systému přímo naznačil, že se do uživatelské části nemá vůbec dívat. Ale pro pokus jsem to neudělal.

Už jsem několikrát slyšel, že to je tragicky špatně a jsem "prase". Nejsem. To je asi tak špatně, jako že mě se líbí černá auta a někomu se líbí červená.

Podívejme se, jaký to má dopad na různé výkony.

Velikost SYSVOL

Sysvol žere ve skutečných datech 168 kB. Na disku to ale spotřebovává 788 kB, protože je to hodně souborů a každý se musí zarovnat na celý cluster. Souborů a adresářů je to 699.

Zjevně je to malinký objem, ale hrozba číhá v počtu souborů a adresářů. Jejich stahování na stanice je velice závislé na RTT (round-trip-time) mezi klientem a DC. Takže strach o výkon je zde jistě oprávněný. Otázka je, jestli je opodstatněný.

Testování GPUPDATE

Předně si uveďme, jak to budu testovat. Pro DC i stanici jsem si nastavil jen jedno CPU, abych jednodušeji zachytil jejich spotřebu. Oba dva mají dosta RAM paměti na to, aby se jim tam všechno v pohodě vešlo. Síť má RTT sub-milisecond, takže blesk. To nevadí, změříme počet a přepočítáme to.

Podstatné je, že na stanici spouštím jenom gpupdate bez parametrů. Nepoužívám parametr /force. Parametr force je na řešení potíží a vyvolá kompletní novou reaplikaci všech objektů. To se ale za normálních podmínek neděje. Klienti si stahují každý GPO jen jednou. Pokud se jeho obsah nezměnil od poslední aplikace, už to znovu neaplikují.

Klienti poznávají novinky podle verze GPO v LDAP a v SYSVOL. To je info, které normálně vidíte v GPMC konzoli na záložce Details.

Takže pomocí gpupdate bez parametrů simuluji to, co dělají všechny počítače v síti každých cca 2 hodiny.

Klient je Windows 8, Windows 2008 R2 a Windows 2003 bez GP preferences klienta. Řadič domény DC byl Windows 2012 R2. Každé CPU jádro bylo Intel Core i5 750 2.67 GHz.

Spotřeba CPU na stanici a DC

Změřil jsem CPU na stanici. Vylétlo to na chviličku na 100%, což se dalo čekat, mám jenom jeden procesor. Celá akce trvala cca 5 sekund. Normálně to samozřejmě běží na pozadí a uživatel o tom vůbec neví. Tady máte obrázek, samozřejmě jsem to měřil vícekrát na všech třech klientských operačních systémech.

Na Windows 2003 bez preferencí to dalo ve špičce 50% CPU a trvalo to jenom 3 sekundy.

Na řadiči domény to vzalo ve špičce dokonce jenom 5% CPU. Je to moc?

Řekněme, že ta špička 5 % je po dobu 1 sekundy. Kolik bych musel mít stanic, aby to udělalo trvalých 5% jednoho CPU na DC? Každý klient si aktualizuje politiku každé dvě hodiny. Rozloží se to řekněme rovnoměrně.

Trvale by znamenalo 3600 gpupdate během hodiny. Za hodinu se aktualizuje polovina stanic. Takže cca 7200 stanic by vytížilo jedno jádro CPU jednoho DC na 5% trvale. Začíná mi to rvát žíly.

Síťové charakteristiky

Obrázek zachycuje projev na síti v průběhu gpupdate.

Maximální hodnota byla 122 kB/s, takže cca 1 Mbps. Průměrně bych to odhadl na 800 kbps. Tentokrát bez výraznější špičky, po celou dobu aplikace, oněch 5 sekund.

Jak to vypadá s celou zátěží síťovky jednoho DC? Trvalý stah 800 kbps by během hodiny udělalo 720 stanic, to je tedy 1440 stanic v síti při dvouhodinovém gpupdate. Abyste dali tomu jednomu DCčku trvale alespoň 10 Mbps, museli byste mít 18 000 stanic.

Projev delšího RTT na pomalých pobočkových linkách

Co když je klient připojen přes pomalou (velká latency, tedy dlouhý RTT) linku z nějaké pobočky a nemá tam DC? Na síti to bude znamenat delší prodlevy mezi jednotlivými pakety. Tím se prodlouží čas aplikace. Ale úměrně tomu klesne špičková zátěž CPU a spotřeba linky v šířce pásma (bandwidth).

Závěr?

Abyste jedno jedinné DC zatěžovali při těchto mých 63 GPO objektech trvale na 5% jedinného jádra CPU a dávali mu trvale 4 Mbps, museli byste mít 7200 stanic.

Kamón.

říjen 23
Rychlá odpověď - CRL a OCSP cesty v certifikátech a pořadí jejich vyhodnocování

Příšel dotaz

  1. v certifikátu jsou dvě HTTP cesty na OCSP. Jakto, že to zkouší jenom tu první, i když je to vnitřní cesta, která z venku určitě dostupná není. A proč to proboha nezkusí i tu druhou, veřejně přístupnout?
  2. proč jsou ve stejném rozšíření (AIA - authority information access) navíc k OCSP cestám ještě také cesty na certifikáty autority?

Rychlá odpověď

Ano, přesně tak – od Windows 7 se (docela náhle, předtím to tak nebylo) pro kontrolu CRL i OCSP používá jen první URL. Všechna ostatní URL se jednoduše ignorují. Pokud by tam bylo ale třeba více různých druhů URL (jako je HTTP, LDAP, FTP apod.), tak se z každého druhu použije první.

Takže příklad:

CRL cesty v CDP rozšíření (CRL distribution point):

  • http1
  • http2
  • ldap1
  • ldap2

OCSP cesty v AIA extension:

  • http1
  • http2
  • http3

Použije se to v pořadí: OCSP http1, CRL http1, CRL ldap1. Nic jiného. Pro pořádek, už jsem tu psal o EAP-TLS klientovi, který dokonce vyhodnocuje jen úplně první cestu vůbec a kašle na nějaké typy.

Jinak v AIA jsou od jakživa cesty na CRT/CER certifikáty autorit. To nemá nic společného s CRL ani s OCSP. Prostě tam byly ty cesty vždycky, aby si to klient mohl případně jednoduše stáhnout. Až později přidávali standard pro OCSP, tak se z nějakého (asi kompatibilita) důvodu rozhodli, že ty OCSP cesty nedají do CRL (CDP) rozšíření, ale dají to raději do AIA rozšíření.

Poznámka - ono to ani do CDP dát nešlo, protože v tom nejsou žádné OIDy, které by určovaly typ toho CRL URL a pletlo by se to.

říjen 21
Doplňkové poznámky ke večerjší konferenci #HackerFest

Jak zamezit spouštění PowerShell skriptů

Včera jste viděli množství PowerShell útoků. To v člověku automaticky vyvolává otázku - není tedy lepší ten PowerShell nějak zakázat?

Zaprvé není. Je to úplně jedno. Cokoliv uděláte v jazyce PowerShell, uděláte klidně přímo v C#. Zkompilujete a spustíte normálně ve formě exe. Ani tak vám to žádný antivirus nebude blokovat. Kdyby to chtěl blokovat, dělal by to i v případě PowerShellu. Důvod, proč to neblokoval, byl jedině ten, že to prostě blokovat nechtěl. Antiviry detekují jen a pouze známé binární signatury.

Například můj keylogger, co jsem napsal v PowerShellu, vlastně vůbec není v PowerShellu. Když se do něho podíváte, zjistíte, že je to celé v podstatě hlavně C# kód vložený dovnitř pomocí here-string. Pokud se tento kód spouští z jazyka PowerShell, stejně se musí zkompilovat.

PowerShell normálně ten text jen vyextrahuje a spustí na tom C# kompilátor (program csc.exe máte normálně jako součást instalace .NET frameworku). Vznikne DLL někde v tempu, tu si PowerShell zase načte zpět a takhle ji používá. Možno v klidu sledovat například pomocí process monitoru (procmon), který stáhnete ze SysInternals.

Všimli jste si během mé přednášky, že by to vadilo některému antiviru? Ten vznik DLL? Binární knihovny, která keylogeruje? Ne. Ani pod úplně obyčejným uživatelem.

Všimli jste si, že by antiviru vadilo, že jsem si ze sítě stáhl EXE soubor. Nebyl podepsán firmou Microsoft a přitom jeho popisek byl úplně přesně stejný, jako popisek všech Windows exe? Není to podezřelé?

Tak tolik asi k tzv. heuristice, kterou ty antiviry údajně dělají.

Zadruhé, pokud byste ho zakázat chtěli, musíte mít na paměti, že to moc nevynutíte. Rozhodně nestačí použít Set-ExecutionPolicy. Tohle nastavení se dá obejít přímo parametrem -ExecutionPolicy programu powershell.exe. Stačí tedy spouštět vaše skripty nepřímo z příkazové řádky, nebo z BAT.

Pokud se chcete zbavit i parametru -ExecutionPolicy, musíte ten zákaz udělat přes group policy z domény. Tam je to potom silnější. Nastavení najdete v počítačové části GPO objektu zde:

Computer Configuration - Policies - Administrative Templates - Windows Components - Windows PowerShell
Turn on Script Execution = Disabled

Nesmíte povolit podepsané skripty (allow only signed scripts). I obyčejný uživatel si může nainstalovat svoji vlastní důvěryhodnou autoritu a svůj vlastní podpisový (code signing) certifikát a jupí. Takže byste to museli úplně zakázat.

A to je stejně na nic. PowerShell příkazovou řádku si zločinec může spustit vždycky bez ohledu na politiku. Skript do ní prostě jenom překopíruje ze schránky a nikdo mu v tom bránit nebude. To byste museli zakázat úplně powershell.exe. Na to máte například Software Restriction Policies (SRP) už od Windows XP. Nebo na Enterprise edicích Windows je v podstatě stejný AppLocker (Application Control Policies).

Nakonec si uvědomte, jak jednoduché je stát se lokálním administratorem a prostě tahle nastavení z registrů vymazat. Při nejhorším offline.

Takže není cesta. Prostě zapomeňte. A začněte se chovat bezpečně. To byla taky ta zpráva, kterou moje přednáška měla udělovat.

Skrytá registrová hodnota a další poznámky

Zmiňoval jsem se také krátce o ukládání PowerShell skriptů v registrových hodnotách. Tak k tomu jen doplnění.

Ano, do řetězcové hodnoty v registrech od Windows Vista se vleze neomezeně :-) Omezeně jen hláškou "insufficient system resources", asi kvůli málo paměti? Na mé testovací virtuálce jsem do jedné registrové hodnoty vecpal 290 MB.

Nebo může ten skript nacpat rovnou do jména té registrové hodnoty. Jméno může mít až 16383 znaků. Jenom to musí založit až z PowerShell 3.0, protože dvojka uměla jenom 255 znaků na jméno hodnoty. Má to navíc pro útočníka pěknou vlastnost. Regedit hodnoty, jejichž jméno je delší než 255 znaků, prostě nezobrazuje. Stačí to udělat delší a nebude to vůbec přes regedit vidět.

Samozřejmě vzniká otázka, jak to tam hacker vloží, aby se v tom neobjevovaly speciální znaky. Případně, aby to nebylo možno na první pohled považovat za PowerShell. Ne že bych očekával od nějakého antiviru, že by se na to soustředil. Oni se většinou soustředí hlavně na BSOD, zátuhy, točení procesoru a mazání kdoví čeho.

Tak jak? Útočník to zkonvertuje na Base64 a má to. Bez mezer a většiny speciálních znaků, jenom US-ASCII znaky zapsatelné z klávesnice. Bleskovka zde:

[Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes('text, co nepujde jenom tak precist'))
# result: dGV4dCwgY28gbmVwdWpkZSBqZW5vbSB0YWsgcHJlY2lzdA==

Závěr

Ano, pochopili jste to dobře. Žádný antivirus vás neochrání před cíleným, ručně provedeným útokem člověka, který sedí u vás v síti a ví co dělá. Nevěřte řečem o heuristice. To je totální nesmysl.

A dávejte si prostě jenom pozor!

říjen 20
Prezentace z konference #HackerFest2014

Moje prezentace z naší konference GOPAS HackerFest 2014 je k dispozici ke stažení tady: GOPAS HackerFest 2014

říjen 15
Mají distribuční skupiny SID?

Včera jsem dostal podnět k napsání tohoto článečku na základě tohoto, kde někdo píše, že distribution group se dá v SharePoint údajně použít pro přidělení přístupu. Je to tam tak jednoduše mimochodem zmíněno, takže se stalo, že autorské emvípí (MVP) zmátlo jiné emvípí a tak to třetí emvípí musí napravit.

Nedá. Oficiální článek o verzi SharePoint 2013 je zde. Ano, Microsoft poskytuje návod, jak údajně "expand a distribution group and add the individual members to a SharePoint group" - například tady.

Když si ten support přečtete, tak pochopíte, že se jedná o ruční vybrání seznamu emailových adres z té skupiny a natvrdo naplnění do SharePointu. Já se nehádám, to samozřejmě jde udělat pomocí PowerShell skriptíku na 2 řádky.

Ale fakt je, že distribution group se pro zabezpečení použít nedá. Podívejme se proč.

A současně zničme populární fámu, že distribuční skupina nemá SID.

Distribution group má SID

Ano. Distribuční skupina je v podstatě úplně stejná skupina v Active Directory LDAP databázi, jako jakákoliv jiná bezpečnostní skupina. Je to typ objektu (class) group. Má objectSID atribut a ten se taky naplní unikátním SIDem hned při vytváření. SID se generuje běžným unikátním způsobem za použití RID FSMO master role.

Poznámka - o RID managerovi si můžete přečíst v několika mých starších poustech jako je tady, zde, tuten, tenhleten nebo tudlenc.

Jeden rozdíl mezi security group a distribution group je hodnota atributu groupType. V případě distribution group ne-obsahuje zapnutý bit 0x80000000, který tam je jen pro security group (viz. ADS_GROUP_TYPE_ENUM). Druhý rozdíl je v atributu sAMAccountType, kde je pro distribution group hodnota 268435457 (NON_SECURITY_GROUP_OBJECT), zatímco security group tam má hodnotu 268435456 (GROUP_OBJECT).

Jinak je to z pohledu LDAP úplně stejné.

Distribution group se nevyhodnocuje při ověřování a nepřidává se do access token

Proč by se tedy distribution group nedala použít k zabezpečení? No ona by se i dala. SID má, takže použít se v podstatě dá. Jenom je vám to na nic. Protože v této skupině v podstatě "nejste".

Při příhlašování si DC vytváří seznam vašich skupin. Tento seznam potom putuje přes NTLM, nebo Kerberos tiket do uživatelova access token. O téhle skupině jsem tu psal už ohledně omezení na počty položek, nebo když jde o aktualizaci členství ve skupinách.

V každém případě se do něho nedostane nic jiného, než bezpečnostní skupiny. Domain controller při ověřování uživatele členství v distribučních skupinách vůbec nevyhodnocuje. Prostě je v databázi nehledá a ignoruje.

SID distribuční skupiny se tedy může objevit na NTFS, nebo v SharePointu. Nebude mít ale efekt, protože stejný SID se v access tokenu uživatele nikdy neobjeví.

Zřetězené členství

Jen pro úplnost dodejme, že byste mohli mít v ADčku dokonce skupiny zřetězené do mixu. Jakože distribuční skupina by byla členem bezpečnostní a to by zase mohlo být členem jiné distribuční apod. Asi to nenaklikáte, ale principiálně by to šlo.

V každém případě to ale poruší řetěz skupin, takže členství při ověřování se vyhodnocuje pouze v souvislé security group oblasti.

říjen 13
Jak rychle se projeví zákaz účtu nebo zneplatnění certifikátu

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

říjen 10
Nějaké nové obrázky z Windows Server 10 technical preview

Udělal jsem ještě nějaké další screenshoty z Windows Server 10 technical preview, tak tady jsou, pouze s minimálními komentáři.

IEčko je tam pořád pouze verze 11.

Tohle dělá už i Windows 2012 R2, ale rád jsem si to típnul, protože už konečně zase jde třídit seznam ACE (access control entries) ve vlasnostech NTFS souborů a adresářů. Ve Windows 2012 to nešlo, což mě dost obtěžovalo. Ale pánové vás varují, že to možná až tak dobře nechápete, jak to zabezpečení (permissions) vlastně funguje!

Následují obrázky z GUI Hyper-V. Bylo přidáno jakési podivné rozšíření pro Azure. Velikost výchozí RAM paměti se zvětšila na 1GB, protože Windows 8 a Windows 2012 už dlouho vyžadují tohle minimum pro instalaci. Nová nastavení pro checkpoint (dříve snapshot). Popisky jsou totálně chaotické, zřejmě se autor vyhulil, nebo to byl ind. Rozhodně se tu objevují jakési novinky - standard checkpoint a production checkpoint. Hned příští týden si to znovu nainstaluju a zjistím co to opravdu znamená.

GUI trošku jinak zobrazuje IP adresu virtuálky, zvláště když máte více síťovek. Dělá to jedna z integration services (IS) nazvaná Data Exchange, pořád stejně jako ve Windows 2012. Prostě jenom předělali GUI.

Pro zájemce, dá se zjistit i verze operačního systému. Viz můj skriptík - musíte jen změnit jméno virtuálky na začátku příkazu:

'client7' | % { Get-WmiObject -Namespace root\virtualization\v2 -Class Msvm_ComputerSystem -Filter "ElementName='$_'" } | % { $_.GetRelated("Msvm_KvpExchangeComponent").GuestIntrinsicExchangeItems | Select @{ n = 'What' ; e = { ([xml] $_).SelectSingleNode("/INSTANCE/PROPERTY[@NAME='Name']/VALUE").'#text' } }, @{ n = 'Value' ; e = { ([xml] $_).SelectSingleNode("/INSTANCE/PROPERTY[@NAME='Data']/VALUE").'#text' } } }

Při instalaci Active Directory (AD DS) nelze vybrat a ani později nelze povýšit na vyšší forest functional level (FFL) ani domain functional level (DFL), než je starší Windows 2012 R2.

A na konec jakýsi Soft restart. Zdá se, že to umí otočit, aniž by museli projíždět BIOS. Pěkné. Použije se to například pomocí příkazu shutdown a parametru /soft. Ale nevím jak to funguje. Ve virtuálce se to otáčí komplet, dokonce mi to dává vybrat bootovat z DVD. Možná to vyžaduje nějakou hardware podporu.

shutdown /r /soft /t 0 /f

říjen 10
Skutečná ověřovací aktivita jednotlivých DC

Včera jsem tu psal o parametru /logon_query programu netlogon. Říkal jsem, že je to v podstatě nesmyslný parametr, protože to měří jen NTLM ověřování. Navíc ve Windows 2012 je buď chyba, nebo to záměrně úplně zrušili.

Abych jenom nereptal, mám tu lepší řešení. Zjistit sumu hodnot atributů logonCount pro každé DC. To je nereplikovaný atribut (podobně jako je lastLogon, o kterém jsem se zmiňoval tady), který u každého účtu zachycuje historicky počet ověření jeho přihlašovacích údajů - tedy hesla, nebo certifikátu v případě Schannel, nebo PKINIT (smart card logon). Tohle samozřejmě bere i Kerberos.

Na každém DC bude mít u každého účtu tento atribut hodnotu takovou, kolikrát ho to dané DC za svůj život ověřilo. Hodnota se nenuluje ani při restartu. Takže je to historicky od instalace daného DC. A pokud jste instalovali to DC z IFM (install from media), tak tam bude hodnota plus to z té zálohy.

Takže hodnota je přesnější, ale má to špatnou vlastnost v tom, že to je od instalace toho DC. Ale pokud to budete měřit rozdílově, tedy změna hodnoty od včerejška, nebo za poslední týden, uvidíte v tom mnohem přesnější informace o tom, jak je ověřování rozloženo mezi jednotlivé řadiče domény (domain controller).

Tento skript na ukázku vypíše sumu hodnot logonCount pro každé DC ve forestu.

dsquery server | % { $_.Trim('"') } | % { ([ADSI] "LDAP://$_").serverReference } | % { ([ADSI] "LDAP://$_").dNSHostName } | select @{ n = 'dc' ; e = { $_ } }, @{ n = 'logonCountSum' ; e = { dsquery * domainRoot -filter '(logonCount>=1)' -attr logonCount -server $_ -limit 0 | ? { $_ -match '\s+\d+\s+' } | Measure-Object -Sum | Select-Object -Expand Sum } }

Pokud bych měl jen zmínit nějaké zajímavosti k jeho PowerShell implementaci, tak si všimněte, že to používá ADSI a ne ten podivný AD module for PowerShell, takže to poběží úplně kdekoliv. Je to taky napsáno na jeden řádek, což by mohlo ukazovat krásu (nebo prasárnu) PowerShellu. A nakonec si všimněte operátoru -match, který krásně vybírá čísla pomocí regulárního výrazu (regex).

říjen 09
Co (ne)zobrazuje nltest /logon_query

V pondělí mi přišel dotaz ohledně parametru /logon_query programu nltest. Jak se zdá, na Windows 2012 už nefunguje, tedy vrací hodnotu 0. Parametr jsem neznal, tak jsem to trošku prozkoumal a závěr je ten, že mě ani nikdy zajímat neměl. Protože je úplně na nic. Proto taky asi přestal na Windows 2012 řadičích domény (DC) fungovat. Nebo spíš jenom chybka?

Co to zobrazuje za hodnotu?

V tomhle článku na technetu píšou, že se jedná o Queries the cumulative number of NTLM logon attempts at a console or over a network. Což je dost nesmyslná nebo alespoň matoucí informace. Tak jsem to pozjišťoval.

Pomocí Network Monitoru jsem zjistil, že se to připojuje přes SMB named pipes  do Netlogon interface na DC, kde to pomocí funkce NetrLogonControl2Ex a I_NetLogonControl2 zjišťuje hodnotu struktury NETLOGON_INFO_3, ve které je netlog3_logon_attempts. To má ovšem stejně na prd vypovídací hodnotu, jako předchozí popisek :-)

Takže jsem to musel vyzkoušet

Hodnota se nuluje po restartu operačního systému DC. Restartovat službu Netlogon ani NTDS nestačí. Na každém DC to má jinou hodnotu.

Hodnota se zvyšuje při každém NTLM pass-through ověření o jedničku (všechny verze LM, NTLM i NTLMv2). Tzn. pokud uživatel přistupuje na nějakou síťovou službu přes NTLM po síti. S konzolí (console) to nemá nic společného. To potom ten cílový server použije svoje blízké DC k ověření uživatele (nltest /sc_query) - použije svůj Netlogon secure channel vůči tomuto blízkému DC.

Hodnota se nemění, pokud se uživatel ověřuje pomocí Kerberos. Hodnota se nemění, ani když se používá Schannel ověření uživatele pomocí TLS client certificate (SSL). Hodnota se nemění ani když probíhá PAC validation (privilege attribute certificate) při Kerberos ověření do služby, která běží pod obyčejným uživatelem.

Obě tyto věci - Schannel a PAC validation jdou také pass-through přes ten cílový server, takže by se mohlo čekat, že to zvýší čítač. Nezvýší.

Na co to tedy je?

Prakticky na nic. Vědět absolutní počet NTLM ověření nedává smysl, protože tohle ověření v prvé řadě vůbec nechcete. Ani NTLMv2 neposkytuje plně vzájemné ověření klienta a serveru (mutual authentication) a to kompletně ani při NTLMv2 session security. Používá to starší HMAC-MD5. Zatímco Kerberos dělá vždycky mutual authentication a navíc může být AES.

Jediné, co vám to může indikovat je fakt, že máte těch NTLM ověření nějak moc.

Hodnota na každém DC bude jiná. Za prvé to závisí na době běhu daného DC stroje. Při jeho restartu se to nuluje.

Zadruhé NTLM ověřování je spíše anomálie. Budou ho dělat jen některé služby, které jsou špatně nastaveny, takže jim nejede Kerberos. Každý počítač má svůj Netlogon secure channel trvale jen s jedním blízkým DC. Jestli máte například jen jeden server, který z nějakého důvodu dělá NTLM ověřování (typicky ne-nastavený SQL server) - bude se ten čítač zvyšovat jen na jednom DC.

Jeho hodnota bude pak obvykle záviset na počtu TCP spojení do takové špatně nastavené služby. Samozřejmě ve velkém prostředí to může být poměrně rovnoměrné na všech DC, ale taky nemusí.

Prostě informace na nic. Krom faktu, že to ukazuje, že nějaké NTLM ověřování vůbec máte.

říjen 02
První zážitky s Windows 10 preview

Windows 10 Preview for Enterprise jsou tady. Podívejte se na nějaké úplně první obrázky a zkušenosti. A ještě jedna zajímavost ohledně čísla 10. Cca před týdnem byl naplánován online meeting a představení Windows 9 pro MVP, kterého jsem se včera účastnil. Všimněte si, že se to ještě před týdnem jmenovalo Windows 9.

Typuju, že Windows Nein asi nebyl úplně dobrý název pro německý trh :-)

Instaluju do Hyper-V takže je jistě zajímavé, že instalačka už rovnou obsahuje ovladače pro synthetic zařízení (integration services), jako je SCSI sběrnice. To je případ už od Windows 8.1 a Windows 2012 R2. Takže na Windows 2012 R2 Hyper-V se to dá nainstalovat do VM Generation 2, což má UEFI "BIOS" a neobsahuje to vůbec emulated zařízení.

Jak se zdá, verze operačního systému Windows 10 preview z dne 1.10.2014 je 6.4 build 9841, tedy 6.4.9841.

Instalace v stejná jako kdykoliv předtím.

Aaa, jak se dívám, můžu být rád, že jsem vybral Customize namísto Use express settings:

A konečně jsme tu

Jo tak tohle jsou ty napjatě očekávané desktopy. Přesněji nejvíce očekávaná enterprise fíčura roku.

Vokna bez rámečku! Vypadá to hezky, to nemůžu říct. PowerShell pětka (PowerShell 5.0). Celkem příkazů 1229. Na Windows 8.1 je jich 2087.

Menu WinX stále neobsahuje PowerShell.

A nová skupina s mongolsko-čínským popiskem - System Managed Accounts Group_ploc :-) Pěkné. To budou asi ty žádané enterprizové fíčury!

Žeby něco jako multifaktorová autentizace do různých služeb? No uvidíme...

Taky nemalá partička dalších kámošů, jejichž popisky se nepodařilo dodat. I když ty VMIC jsou Hyper-V integration services, jak to tak pozoruju. Ovšem změna, už to běží rovnou v SVCHOST procesu. Kůl.

Prostě blbosti. Hlavně že se to jmenuje Windows 10 a zase na tom nepojede půlka programů :-) Další obrázky zase příště.

říjen 01
Pozvánka na konference a prezentace z konference minulé!

Tak už se nám to povážlivě blíží! GOPAS pořádá konference, kde budu přednášet i já.​

Nejbližší je lahůdková konference HackerFest, bude už tento měsíc v Praze, nezapomeňte se přihlásit. Na HackerFestu budu mít přednášku na téma:

Útoky, které žádný antivirus nezachytí

Druhou je již (doufám) tradiční ShowIT v Bratislavě, bude v únoru (februári). Jak se dívám, marketing ještě nebyl schopen aktualizovat web, tak to berte jako první vlaštovku a začněte se těšit!

Také jsem chtěl využít příležitosti a zveřejnit zde prezentaci z pondělní "minikonference" Duel HyperV a VMWare pořádanou v GOPASu v Bratislavě. Moji prezentaci najdete zde.

září 26
Zapnutí Kerberos delegace pro Hyper-V live migration

Když zapínáte Hyper-V live migration na Windows 2012, tak už nepotřebujete cluster (jak jsem tu psal zrovna před pár dny). K tomu, abyste live migration zapnuli mezi několika hyper-v hosty, musíte jim povolit Kerberos constrained delegation na hodnotu Trust this computer for delegation to specified services only - use Kerberos only. K tomu, aby Kerberos delegace fungovala, musí být počítačové účty nodeů vaší farmy členem skupiny Windows Authorization Access Group (WAAG) - viz článek o Kerberos delegaci.

Jenže to musíte povolit všem nodeům vzájemě a ještě navíc musíte povolit delegaci i do SMB storage. Což je drbačka i v případě dvou členů farmy, natož když jich máte více.

Tak jsem si na to napsal skript v PowerShell. Je to napsáno obecně pro Windows 2003 a novější, takže nepoužívám ActiveDirectory module, který nemám rád už z principu, že to nepoužívá LDAP, ale nějakou podivnou web servisu. Navíc ten ActiveDirectory mobule blbne na Windows 8.1, hanba :-)

Myslím, že je jasné, že změnit musíte akorát první tři proměnné.

$domain = 'gopas.virtual'
$nodes = @('noda', 'nodb', 'nodc')
$storages = @('stor', 'stor2')



$domainDN = ($domain.Split('.') | % { "DC=$_" }) -join ','

$WAAG = dsquery * $domainDN -filter "(&(sAMAccountName=Windows Authorization Access Group)(objectClass=group))" | % { $_.Trim('"') } | % { [ADSI] "LDAP://$_" }

$nodes | % {

  dsquery * $domainDN -filter "(&(sAMAccountName=$_`$)(objectClass=computer))" 

} | % { $_.Trim('"') } | % {

  $oneNode = [ADSI] "LDAP://$_"
    
  $spns = $nodes -ne $oneNode.name | % { 
    
    'Microsoft Virtual System Migration Service/{0}' -f $_
    'Microsoft Virtual System Migration Service/{0}.{1}' -f $_, $domain
  }

  $spns += $storages | % { 

    'cifs/{0}' -f $_
    'cifs/{0}.{1}' -f $_, $domain
  }
    
  Write-Host '-----------------------'
  Write-Host ('One host: {0} | {1}' -f $oneNode.name.Value, $oneNode.dNSHostName.Value)
  Write-Host ('SPNs: {0}' -f ($spns | Out-String))
 
  $oneNode.PutEx(3, 'msDS-AllowedToDelegateTo', $spns)
  $oneNode.SetInfo()


  $WAAG.Add($oneNode.Path)
}

Tak užívejte :-)

září 25
Proč nevěřím Hyper-V GenerationID a neodvažoval bych se používat snapshot (checkpoint) pro obnovu DC

Už jsem tu psal několikrát (tady a tady) o obnově řadičů domény a s tím souvisejícím GenerationId, pokud domain controller běží ve virtuálním počítači. Od Windows 2012 Hyper-V a pokud váš konkrétní virtuální DC je také alespoň Windows 2012, údajně ho "můžete bezpečně obnovit" z virtualizačního snapshotu (neboli dnes checkpointu).

Jak za jízdy (já si to nazývám live-snapshot), tak i z vypnutého snapshotu (offline-snapshot).

Podívejme se, jak to celé funguje a sami zvažte, jestli je dobrý nápad na to spoléhat.

GenerationId a jeho infrastruktura

Je to jednoduché. Ve virtuálkách, které mají nainstalovanou a vůbec správnou verzi integračních komponent (Hyper-V integration services) existuje ovladač jádra gencounter.sys (název v device manageru je Microsoft Hyper-V Generation Counter).

Tento driver se zavádí v režimu Manual. To znamená, že ho spouští něco jiného, nejspíš během svého vlastního startu.

Active Directory domain controller (ADDS DC) ve verzi Windows 2012 a novější se prostě tohoto driveru zeptá pokaždé, když chce dělat nějakou replikaci, nebo možná i někdy častěji, když je k tomu nějaký důvod. Zeptá se na aktuální GenerationId a zapíše si ho do nereplikovaného atributu msDS-GenerationID, který má ve své LDAP databázi na svém computer objektu (přímo na účtu počítače, obvykle v OU=Domain Controllers).

Pokud se GenerationId od posledně změnilo, rovnou provede opravu InvocationId a stane se novou instací LDAP databáze.

Smutná fakta

Pokud ten ovladač gencounter.sys z nějakého důvodu nenaběhne, prostě se vůbec nic nestane! DC vám vůbec nic nezaloguje, normálně naběhne, ale když potom obnovíte snapshot, tak se to prostě jenom nedozví, a normálně replikuje, jako by se nechumelilo. Žádný error v žádném logu. Ani v System logu, nikde.

Můžete to jednoduše vyzkoušet tak, že v registrech v HKLM\SYSTEM\CurrentControlSet\Services\gencounter změníte hodnotu Start = 4, tedy na Disabled a restartujete.

Ano, tohle byste normálně neudělali. Ale jakou máte tedy jistotu, že ten ovladač skutečně běží? Co když prostě jenom nenaběhne kvůli málo paměti? Kvůli nějakému timeoutu při restartu, nebo to prostě spadlo kvůli kdovíjaké chybě?

Spoléhat se na to podle mě nejde. Takže jako jsem říkal už předtím, obnovovat snapshot DC je nebezpečná hra s ohněm.

1 - 14Next
>
 

 Rychlovky lepší než tvítr

 
30.10.2014 20:18
Po pekelne hejtickem dnu na pivu s Pepou Dvorakem. Teda bavi se s zenskejma a ne se mnou :-)
27.10.2014 7:43
Ctyri sojky u vrsovickeho nadrazi!
25.10.2014 9:56
zajimalo by me, proc ma Java zapotrebi vsude otravovat s tim podivnym Ask toolbarem?
23.10.2014 17:30
Bratr mel pravdu, plisnove syry maji projimave ucinky
17.10.2014 18:19
CHFI: Computer Hacking Forensic Investigator!!!
17.10.2014 12:59
zdá se, že na jakémkoliv telefonu jde zjistit IMEI zavoláním na *#06# to je zajímavé.
17.10.2014 12:56
dnešní fyzikální okénko: http://palkovsky.blog.idnes.cz/c/196273/Rychlosti-se-nescitaji.html
14.10.2014 22:01
tak soft restart na Windows 10 server asi nefunguje - nebo to chce nejakou hw podporu?
13.10.2014 18:58
Prave jsem dostal na googlu kapcu "debil".
12.10.2014 14:04
Napeti pred konferencemi #hackerfest a msfest vrcholi! Uz za tyden!
10.10.2014 19:44
http://status.modern.ie
9.10.2014 13:36
na RDP terminal se da jit bez licence, kdyz nejede licencni server, nebo nechcete konzumovat licenci – staci do MSTSC klienta zadat do adresy /admin
9.10.2014 13:33
Windows 2012 based Remote Desktop Session Host (RDP session host) error: The remote session has been disconnected because there are no Remote Desktop License Servers available to provide a license. Hotfix download: http://support2.microsoft.com/kb/2916846
9.10.2014 13:03
Dva ucty se stejnym heslem - bacha. Kdyz zjistim jedno heslo, rovnou ho zkusit na vsechny ostatni ucty je hracka. Bez zamknuti!

7.10.2014 13:33
a máme tu program mých 4 přednášek na konferenci http://www.ms-fest.cz, která proběhne 19.10 v Brně!
2.10.2014 23:37
Na serverech 10 je něco, co se jmenuje "Windows Volume Replication". Jestli to je synchronní replikace, tak paráááda!
2.10.2014 22:45
aha, takže ovladač na disketu ve Windows 10 není ani po instalaci. Tak ne že bych to potřeboval na železe, ale potřebuju to pro Hyper-V virtuálky a autounattend.xml.
2.10.2014 21:29
windows 10 nemají v instalačce ovladač na disketu? ach bože.
2.10.2014 19:37
konference HackerFest už v pondělí 20.10. http://www.hackerfest.cz
2.10.2014 19:34
... a když to je kratší než 140 znaků, tak k tomu není link na twitteru. Jsem dobrej!
2.10.2014 19:23
Mám nový automatický re-tweeter pro SharePoint. To je božíííííííí. Cokoliv hodím do SharePointu se mi automaticky přepošle na twitter. Konečně jsem to dodělal.
1.10.2014 18:43
Uz se stahuje Windows 10 Enterprise Preview!
1.10.2014 7:54
Jo taaak Windows 10? Kam to cislovani asi povede?
30.9.2014 18:25
Zitra vecer se tesim na predstaveni Windows 9 pro MVPiky! Snad budu moct neco uverejnit i tady!
26.9.2014 11:46
dneska jsem vymyslel optimální český překlad pro failover cluster - přepadový chuchvalec.