Skip Ribbon Commands
Skip to main content

Ondrej Sevecek's Blog

:

Engineering and troubleshooting by Directory Master!
Ondrej Sevecek's Blog > default
listopad 19
Jak rychlý je BitLocker na Windows 8.1

Zrovna jsem si upgrádnul na notebooku 7200 otáčkový disk na SSD a přeinstaloval se na tenhle nový disk. Mimochodem, parádní fíčura, koupíte si místo DVD jenom SATA rámeček na harddisk a do toho dáte SSDčko. DVD mě bylo na prd a takhle mám víc kapacity a ještě neuvěřitelně rychlý provoz. A to všechno na šet let starém notebooku. A zase to pár let vydrží. Aspoň bych rád.

A tak jsem taky musel znovu zapnout BitLocker šifrování. Při té příležitosti jsem změřil rychlost. Studený boot plus spuštění Outlooku, OneNote, Salamander a Visual Studio a Skype.

Bez BitLocker šifrování 24 sekund.

Při BitLocker šifrování oddílu s operačním systémem 26 sekund.

Paráda.

Jo a mám multiboot do dvou operačních systémů, každý na svém vlastním oddílu zašifrovaném pomocí BitLocker. Takže jen pro informaci a potvrzení - není problém, aby TPM používaly oba dva operační systémy a startovalo to "bez zadávání".

listopad 14
Nekomentované poznámky k SharePoint User Profile Service (UPS)

Tohle ani nečtěte. Jen jsou věci, které si nepamatuju a tak si je sem rád přihodím, abych se na ně mohl zpětně někdy podívat. Tak pardon, že s tím otravuju :-)

"User Information List" = DB table "AllUsers"

_layouts/15/userdisp.aspx?Force=true&ID=9
_layouts/15/people.aspx?MembershipGroupId=0
_layouts/15/useredit.aspx?ID=9

Set-SPUser -SyncFromAd

job "User Profile to SharePoint Quick Synchronization"


$webApp = Get-SPWebApplication https://intranet.gopas.cz
$webApp.UseClaimsAuthentication = $false # $true
$webApp.Update()


(New-SPClaimsPrincipal -Identity 'gps\kamil' -IdentityType 1).ToEncodedString()
# 1 = WindowsSamAccountName (may not exist) i:0#.w|gps\kamil
# 2 = WindowsSecurityGroupName (must exist) c:0+.w|s-1-5-21-3554988821-2548339769-934835410-1497
# 3 = WindowsSecurityGroupSID (may not exist)
# 4 = FormsUser
# 5 = FormsRole 
# 6 = EncodedClaim


$site.RootWeb.Lists | ? { $_.Title -eq 'User Information List' }
# or the same
$site.RootWeb.SiteUserInfoList

$site.RootWeb.SiteUsers | select UserLogin,ID,DisplayName,SystemUserKey,SID,IsSiteAdmin


$webApp.MigrateUsers()
$webApp.ProvisionGlobally()


Move-SPUser -Identity 'gps\helena' -NewAlias 'newDomain\helena'

 

listopad 13
Chyba jako prase

Aktualizujtééééé. KB2992611. Jak jsem už vpravo v rychlovkách psal včera, vyšla úplně extrémně důležitá aktualizace (CVE tady) na TLS (a SSL samozřejmě, i když SSL je roky přešlá mrtvola) knihovnu SChannel, která je ve všech Windows a používá se úplně na všechny TLS komunikace.

Zaslouží si to pozornost, protože:

  • je to remote code execution. To znamená, že vzdáleně nacpete do počítače kód. MS to nezveřejnil přesně, takže se neví ještě, jak moc kódu se tam dá dostat, ale hackeři jsou schopní vždycky něco vymyslet, aby to nemuselo být moc.
  • je to chyba v serverové části toho TLS protokolu, takže to bude napadat všechny možné servery. TLS se používá na IIS samozřejmě. Ale o hodně hůře také v RDP, Exchange (SMTPS), na Active Directory řadičích domény (ADDS DC - domain controller) pro LDAPS. Dále tuto knihovnu samozřemě využívá i TMG a ISA server. Dneska ADFS a Hyper-V replication. Také VPN v podání SSTP, a IKEv2 a i IPSec pokud se ověřujete pomocí AuthIP, takže i DirectAccess například. Je jedno, jestli to je IPHTTPS, nebo Teredo. Stejně je uvnitř AuthIP a TLS ověření.
  • je to TLS, které se ustavuje vždycky jako první, ještě dříve, než se vůbec někdo pokouší ověřovat. Takže to půjde nejspíš využít anonymně.
  • nemá to žádné workarounds ani mitigation factors. Z toho plyne, že proti tomu nefunguje ani ověřování client TLS certificate. Plyne z toho, že neexistují žádné "best practices", ani jiné Windows zabudované ochrany, které by to zmírnily, nebo úplně zastavily. I kdyby se muselo třeba čekat na nějakého klienta, až se připojí, nebo kdyby útočník musel být MITM (man-in-the-middle), tak by to tam bylo uvedeno, protože to výrazně omezuje prostor k útoku. A uvedeno to tam není!
  • je to problém v DLL knihovně, kterou si všechny ty systémy nahrávají do paměti. Nejde tedy o nějakou konkrétní Windows službu, ale o všechny služby, které tuto knihovnu používají. V tom, co jsem vyjmenoval v podstatě není ani jedna služba, která by na počítači neběžela pod účtem SYSTEM. Útočník tedy spustí kód, který je pánem daného počítače.

Vadí vám, že útok poběží pod účtem počítače? Ano. Uživatel SYSTEM je členem skupiny Administrators a může tedy dělat lokálně cokoliv. Stačí třeba, když do autorun klíče přihodí něco, co si spustíte až se přilásíte. Nebo si sám sobě vykrade hesla z IIS, naplánovaných úloh a služeb.

Samozřejmě, do sítě chodí už jen pod účtem počítače (POCITAC$), což je člen skupiny Users na ostatních strojích. Jenže vzhledem k počtu služeb, které jsou dostupné přes TLS takhle půjde napadnout velká část sítě. A pokud někdo napadne byť jen jediné DC, má celý forest v ruce a nemusí nic dalšího řešit. I když vám přepadnou Exchange, tak jste v pekle. Exchange server může obvykle vytvářet a modifikovat většinu účtů v Active Directory.

A tak to je. Psycho.

Pro úplnost - někdo si to plete s chybou v OleAut32 (MS tady). Což je ale něco jiného a ovlivňuje to "jen" klienta IE.

A teď jedna otázka - nedala to tam v devadesátých letech NSA?

listopad 07
Rychlovka - jak nastavit Protect object from accidental deletion pro uživatele a skupiny

Jak jste si jistě všimli od Windows 2008 R2 v jeho Active Directory Users and Computers konzoli (neboli Uživatelé a počítače služby Active Directory) je možné chránit objekty proti náhodnému smazání. Jedná se o zaškrtávátko ve vlastnostech uživatelského účtu nazvané Protect object from accidental deletion.

Tohle je automaticky zapínáno na organizačních jednotkách (organization unit) při jejich vytváření přes GUI. Pokud to děláte skriptem, tak se to nenastaví.

Na uživatelích a skupinách a jiných objektech to nastaveno ve výchozím stavu není. Nehledě na to, že to možná chcete nastavit na více objektů později.

Pomocí skriptu PowerShell to jde úplně snadno:

DSQUERY * 'OU=people,DC=gopas,DC=virtual' -filter '(|(objectClass=user)(objectClass=group)(objectClass=organizationalUnit))' | % { 

  DSACLS ($_.Trim().Trim('"').Trim()) /D Everyone:SDDTDC
}

Předchozí skript pozapíná zákazy mazání na uživatelích (user), skupinách (group) i organizačních jednotkách (organizationalUnit).

Upravit si nejspíš dokážete, pokud ne, dejte vědět :-)

Proč to nejde jednoduše zdědit?

Zděděná oprávnění jsou slabší, než nezděděná explicitní oprávnění z nižší úrovně hierarchie. Takže i zděděné zakazovací (deny) oprávnění je možné přebít nezděděným povolením. Ta klasická hláška, že deny je vždycky silnější je kec. Deny není vždycky silnější ani na NTFS ani nidke jinde. Všude je možné zděděné deny přerazit pomocí explicitní nezděděné povolovací položky allow.

No a ony objekty v Active Directory (ADDS) mají mnoho explicitních nezděděných položek oprávnění (permissions). Dostávají je při svém vzniku z default security descriptor, který je pro jejich typ definován ve schematu. To obsahuje například full control pro Domain Admins, nebo pro Account Operators.

Takže pro Domain Admins a Account Operators je potřeba udělat právě skriptem explicitní deny položky na každém objektu samostatně.

listopad 04
Nástroj a principy forenzní analýzy v okamžiku rychlé reakce - analýza prchavého stavu

To je hodně divný název, že? Tak to je můj překlad anglických termínů jako je forensic analysis, first response a first responder a volatile state.

Prchavý stav a první odpověď

O co jde? Na nějakých zařízeních (v našem případě postavených na Windows), byl nahlášen nějaký bezpečnostní incident (IS incident). Podle normy ISO/IEC 27035 by se to mělo spíše jmenovat událost (IS event), protože to nahlásil pracovník (tedy BFU) a hodnocení na incident může přijít teprve později, až to kvalifikovaně vyhodnotíme.

V takovém okamžiku nastupuje forenzní pracovník skupiny rychlého nasazení (forensis expert of first response). Norma ISO/IEC 27035 to nazývá ISIRT (information security incident response team).

Nebo možná jen kvalifikovaný systémový správce (system administrator), který má za úkol následující úplně prvotní věci:

  • zajistit místo události (suspected crime scene) tak, aby nedošlo poškození jeho důkazní kvality. To znamená zejména zabránit dalšímu kontaktu nekvalifikovaných osob nejen s výpočetním prostředím, ale také s jeho blízkým fyzickým prostředím. To jsou například stoly a věci na nich položené a v zásuvkách uložené, kabeláž i elektrická silová. Prostě ideálně celá kancelář.
  • vyhodnotit rozsah události a případně zajistit i vzdálenější místa, která s událostí souvisí. Pod tím bych si představoval například serverovnu, pokud je podezření, že událost ovlinila i vzdálená data.
  • všechno vyfotit, nejprve z dálky přehledně, potom z větší blízkosti. Pořád ještě ale bez těsných detailů zařízení. Ideálně to také točit na kameru. Kamerku na hlavu si pořídíte za pár korun.
  • a potom se zastavit a zamyslet se

Zamyslet se nad tím, jak moc chce zasahovat do místa činu (crime scene). Nejjednodušší, a bez přemýšlení, je možné prostě všechny počítače korektně vypnout. To znamená slušný, vyžádaný shutdown. Samozřejmě pokud to jde. Minimální zásah samozřejmě vylučuje nějaké zkoušení prolomit zamknutou obrazovku apod.

Prostě vidím, jestli počítač žije a můžu kliknout "vypnout". Pokud nemůžu, protože je třeba zhasnutá obrazovka, lehce zamyšuju bez klikání, třeba se rozsvítí. Pokud na mě vyskočí zamknutá plocha, nebo přihlašovací obrazovka, možná je tam čudlík shutdown. Pokud to vyžaduje přihlásit, požádám majitele počítače, aby se přihlásil. Pokud já jsem policie a on je podezřelý a neudělá mi tu radost, nebudu tam něco zkoušet zadávat a prostě to zkusím vypnout čudlíkem na bedně. Pokud ani to nejde, tak holt natvrdo vytrhnout z napájení.

Následuje detailní zaprotokolování důkazů (tomu se budu věnovat někdy příště). A buď rovnou na místě vytvoření bitových kopií úložišť, nebo odvoz do labu.

Jenže tímto přicházíte o paměťový stav (volatile state) toho počítače. Přijdete o seznam běžících procesů, o obsah jejích pamětí (ne všechno je ve stránkovacím souboru a ten se možná také smaže při vypínání). Mnoho konfigurací také nemusí být trvalých (persistent), jako jsou routey, nahozená TCP a VPN spojení, IPv6 tunely, seznam DNS a NetBIOS překladů apod.

Podle 27035 článku 8.2.1.3 (Incident information update) má člen ISIRT tedy zvážit a případně provést toto: "After the initial discovery of the incident, all volatile data should be collected before the affected IT system, service and/or network is shut down, for a complete information security forensics investigation. Information to be collected includes contents of memory, cache and registers, and detail of any activities running, and the following."

Bez zásahu do scény to nepůjde

K předchozímu odstavci norma připomíná, že "Two or more persons should be present when information security forensics duplication is performed, to assert and certify that all activities have been carried out in accordance with relevant legislation and regulation."

Což je důležité. Pokud chcete z počítače odnést jeho volatile data, musíte do něho nějak více zasáhnout a něco k němu připojit.

Pokud se rozhodnete k tomuto kroku, je důležité si uvědomit, že se zvětšuje prostor pro problémy, které můžete mít s takovými důkazy u soudu, pokud by k němu došlo. Protistrana bude chtít, aby soud vaše důkazy nepřipustil. To samozřejmě bude chtít vždycky, ale když budete do místa činu zasahovat, budete to muset umět soudu vysvětlit.

Podstatné je dokázat, že jste svým zásahem nevnesli do scény falešné důkazy, které by žalovanou stranu neprávem inkriminovaly. Celou situaci výrazně vylepší také to, že tento zásah do místa činu prováděla nezaujatá třetí strana - možná nějaký cizí specialista.

I v případě ohledání místa činu po vraždě tam forensní tým vnáši věci, které tam předtím nebyly. Ale snaží se minimalizovat škody. Mají ochranné obleky, aby z nich moc nepadaly chlupy. Mají rukavice, takže když už nějaké otisky pomatlají, tak alespoň nezanechají svoje. Jestli chcete naložit tlouštíkovo tělo na nosítka, uděláte mu nejspíš nějaké otlaky.

Taky si uvědomte, že na místě činu už nejspíš předtím docela dlouho působili uživatelé, ještě než si sami uvědomili, že se možná něco děje.

Nástroje pro sběr volatile forensic data

Na internetu se dá stáhnout hromada různých nástrojů. Polovina z nich vypadá, jako že se jedná o samotné hekovače, screenshoty jako z keygenu. Druhá polovina funguje jenom na některých typech systémů. Další polovina vyžaduje instalaci Oracle databáze. Osmdesát procent z nich není ani digitálně podepsáno. Devadesát procent z nich nesbírá to všechno, co bych si já představoval. A u sto procent z nich nevíte vůbec, co dělají a jak fungují.

To se vám u mého forensního PowerShell nástroje nestane. Máte celý jeho zdroják. Který je digitálně podepsaný a obsahuje log SHA1, MD5 heší všech svých součástí. Pokud máte PowerShell 3.0 a novější, počítá i SHA256 heše. Používá jenom PowerShell, WMI a zabudované Windows nástroje. Navíc používá tři utilitky přímo od firmy Microsoft, také digitálně podepsané a 100% zdokumentované. Běží všude, kde máte alespoň PowerShell 2.0. Což je dneska už skoro všude.

Pokud budou pochybnosti o jeho chování, umím vysvětlit každé písmeno jeho kódu.

Program vygeneruje sadu textových a CSV souborů, ve kterých jsou výstupy rozličných WMI tabulek a výstupy Windows programů, jako je třeba netsh. Program ze systému pouze čte. Zapisuje pouze do svého výstupního adresáře.

Pokud si o to řeknete, provede pomocí procdump programu (od Microsoftu, staženo ze SysInternals) dump paměti všech procesů. Výstupy také uloží do svého výstupního adresáře. Umí také spustit autorunsc a posbírat i jeho textový výstup - to ale není už moc prchavý stav. Autoruns se dá zjistit kompletně i z offline imidže.

Nakonec celý obsah výstupu znovu přepočítá na SHA1, MD5 a případně SHA256. Soudci chtějí vždycky slyšet, že jste všechno hešovali, protože tak se to má dělat. Jenom si neuvědomují, že to není ochrana proti záměrné změně.

Pokud se chcete pojistit proti záměrné změně, můžete si zadat také heslo, které znáte jenom vy. Program vám všechen inventář podepíše HMAC-SHA256. Takže jenom vy, pokud budete znát heslo, si můžete ověřit pravost těch signatur.

Jediná modifikace

Skript umí, na požádání, také změnit jedno nastavení v registru (ClearPageFileAtShutdown). To říká, jestli se bude při vypínání mazat pagefile. Smazat ho ideálně nechcete, protože může obsahovat zajímavé informace o obsahu pamětí různých procesů.

Skript to udělá jenom když ho o to požádáte. Navíc v každém případě dopředu zaudituje předchozí stav té registrové hodnoty.

Jak takový software do počítače přinesete a jak potom odnesete výsledky?

Nastává otázka, jak tenhle nástroj do důkazního počítače (evidence computer) dostat. Jak už jsem říkal, všechny programy, nebo hardware na fyzický dump RAM paměti, tam budete muset nějak dostat. Pokud je tam tedy vůbec dostávat chcete. I když ty programy spustíte z příkazové řádky ručně, zanecháte něco navíc v systému. I když tam budete přistupovat vzdáleně přes síť tam něco zanecháte.

Pokud už budu vnášet například USB flash do scény, měl bych dodržovat následující:

  • médium zakoupené pouze pro tento případ, u kterého známe přesně jeho dlouhodobé uložení, pokud bylo ve skladu
  • čistě naformátované medium, přejeté ideálně sdelete tak, aby nemohlo obsahovat žádné nežádoucí a falešné důkazy
    • k tomu mám v nástroji rovnou baťáček sdelete-free-space.bat
  • kopie mého nástroje, která je digitálně podepsaná a ohešovaná
  • do papírového protokolu zapíšete čas příchodu na místo a čas začátku sběru prchavých dat
    • hodiny počítače se mohou lišit, možná i záměrně
  • na všechno si seženete svědka, který to bude celou dobu sledovat s vámi
  • ideálně to točíte na kameru a fotíte jako zběsilí
  • zastrčíte do volného USB portu, určitě nic jiného nevytahujete
  • spustíte volatile-forensics.bat. Nezapomenete ho spustit s právy administrátora, pokud to jde. Pokud nejde, zase až tak se moc neděje. Nepůjde zjistit seznam SMB spojení a nepojedou dumpy paměti.
  • může se stát, že ani tento volatile-forensics.bat nepůjde spustit, protože PowerShell execution policy to blokuje na úrovni group policy. Schválně jsem skript udělal tak, že můžete jeho obsah komplet na Ctrl-A, Ctrl-C, right-click překopírovat (copy/paste) do spuštěného okna PowerShellu
    • pokud script spouštíte tímto způsobem (copy/paste), ujistěte se, že aktuální adresář v příkazovém řádku PowerShellu je nastaven opět na tu USB flashku
  • zaznamenejte si do papírového protokolu všechny odpovědi na otázky, které vám skript kladl
  • výstupní soubory se objeví v Out podadresáři aktuálního adresáře. Tedy ideálně opět na USB klíčence. Bez zásahu do harddisku důkazního počítače.
  • jakmile program skončí, zeptá se vás na heslo pro HMAC-SHA256, které si zapamatujte. Svědek ho znát nemusí, spíše by ani neměl.
  • až program úplně skončí, dejte vypnout důkazní stroj (evidence machine) a nechte všechno tak jak je. Včetně vaší flash USB klíčenky.
  • až se všechno vypne, zaprotokolujte a posbírejte všechny počítače a související věci jako důkazy. Včetně vaší forensní USB pen klíčenky. To je teď taky důkaz.

O USB disk takto vlastně přicházíte. Budete ho muset nechat jako součást důkazů. Budete ho také muset předat protistraně, která má právo vidět všechny důkazy a udělat si na ně svoje vlastní posudky. Takže i z vaší klíčenky budete normálně dělat sektorový imidž (sector-by-sector image, bitwise image). A pracovat budete teprve s tímto imidžem.

Všechno je k dispozici zde ve formě ZIP a také ve formě jednotlivých souborů.

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

1 - 14Next
>
 

 Rychlovky lepší než tvítr

 
21.11.2014 19:34
Byl jsem v pondeli na Interstellar.Dost me desilo tech 170 minut,ale super!Nadherne cizi planety.A ten motiv rodice me vcelku vzal.
19.11.2014 8:40
Panebozeee, lsass.exe 1000 hardfaults/sec, 10GB commit. Co to jeee? Uz poslednich 5 minuuuut!
19.11.2014 6:47
Windows 8.1. pravým tlačítkem na taskbar - Properties, záložka Navigation, Replace CMD with PowerShell in the Win+X menu
18.11.2014 4:32
Odinstalace Gugle Chrome prave zrychlila pocitac cca 3x. Tolik ke kvalitam techhle nesmyslu.
13.11.2014 19:55
Windows Experience Index na Windows 8.1 - winsat prepop, gwmi win32_winsat
13.11.2014 19:18
na Windows 8.1 neni Windows Experience Index? Na Windows 8 ho jeste mam
12.11.2014 10:21
a to není žádná sranda - to je každý web server, RDPčko, TMG i DCčko přes LDAPS, nebo Exchange!
12.11.2014 10:16
pekelná chyba: https://technet.microsoft.com/library/security/ms14-066
5.11.2014 19:59
tohle moc lidí nezná - průzkumník - nějaký soubor nebo složka - shift+pravé tlačítko - Copy as path
1.11.2014 14:06
Jankova dnesni hlaska - a co to jako bude za slavu, ze si musim vzit tyhle hezci teplaky?
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ě!