Bezpečnost a PKI

Je opravdu RODC (Read Only Domain Controller) jen pro čtení?

Jiří Hýzler — Sun, 01 Feb 2009 19:59:34 GMT

Než odpovím na otázku v titulku, možná někdo netuší co je to RODC, proto si dovolím nejprve popsat tento typ řadiče.

RODC je novým typem řadiče domény ve Windows Server 2008. Pamětníci Windows NT by mohli namítnout, že zase tak nový typ řadiče to není, protože už v NT byl tzv. BDC (Backup Domain Controller), který by podle názvu RODC odpovídal. Je pravda, že skutečně stejně jako kdysi BDC uchovává nový řadič kopii adresářové databáze pouze pro čtení, ale současně nabízí mnohem více funkcionality.

Hlavními vlastnostmi RODC jsou:

Active Directory (AD) databáze pouze pro čtení.
- Aplikace, které potřebují pouze číst z AD, mohou využívat RODC. Jakmile ale potřebují provést změnu v databázi, musí se obrátit na „zapisovatelný“ DC, tzv. RWDC (Read Write Domain Controller), ze kterého se změna replikuje zpět na RODC.
- Application Compatibility with RODCs: http://technet.microsoft.com/en-us/library/cc754165.aspx
Jednosměrná replikace.
- Směrem z RODC se nic nereplikuje (i kdyby na něm byla změna přímo provedena – např. něco byste smazali v SYSVOLu). Jednosměrná replikace pouze na RODC snižuje komplexnost replikační struktury a snižuje riziko replikace změn z poboček, kde bývá nejčastěji RODC nasazen a kde většinou bývá menší míra zabezpečení serverů.
Filtrované atributy (Filtered Attribute Set – FAS)
- Administrátor může specifikovat atributy (kromě system-critical atributů), které se nebudou replikovat na žádný RODC v lese. To může zamezit vyzrazení některých informací v případě kompromitování RODC.
- Steps to Add an Attribute to the RODC Filtered Attribute Set: http://technet.microsoft.com/en-us/library/cc772331.aspx
Omezení kešování hesel
- Jeden z největších benefitů. Po instalaci RODC neuchovává žádná uživatelská ani počítačová hesla pro přihlášení (kromě vlastního počítačového účtu RODC a krbtgt). Když obdrží požadavek na autentizaci, tak ho automaticky přeposílá na RWDC. Administrátor může nastavit skupinu uživatelských účtů a účtů počítačů, jejichž hesla budou kešovány na RODC (typicky pouze pro zaměstnance pobočky a jejich počítače). Pak tyto účty jsou autentizovány přímo RODC bez použití RWDC. Důvodem omezení replikace hesel na RODC je bezpečnost. V případě kompromitování RODC nemá útočník způsob jak získat hesla např. administrativních účtů v doméně, protože tyto účty se nekešují na RODC, tj. nejsou fyzicky na tomto serveru (pro tyto účty se autentizace provádí na RWDC, který je typicky umístěn jen v centrále). Kompromitované účty zaměstnanců pobočky je navíc možné rychle a hromadně resetovat smazáním účtu počítače RODC na RWDC.
- Více o kešování hesel a fungování autentizace na RODC se dočtete zde: http://technet.microsoft.com/en-us/library/cc754218.aspx
Admin role separation
- Většinou na pobočce DC nezastává pouze funkci repliky AD, ale jsou na něm nainstalovány i další služby. V předchozích verzích bylo obtížné delegovat administraci na pobočkovém řadiči domény, protože buď jste museli delegovaného uživatele zařadit do doménových administrátorů (a tím mohl provádět i změny do AD) nebo jste ho mohli zařadit do skupiny Server Operators a tím sice nemohl provádět změny do AD a při tom měl administrativní oprávnění k operačnímu systému serveru, ale zároveň tím získal možnost administrovat všechny OS řadičů domény v celé doméně. Nyní máte možnost svěřit delegovanému uživateli jen administrativní oprávnění k OS jen na jeden konkrétní řadič domény (např. pro možnost restartovat nějakou aplikaci, aplikování aktualizací, instalaci ovladačů apod.)
Podpora DNS služby
- I DNS server umí fungovat na RODC a i on je pouze pro čtení. Pro konfiguraci DNS není potřeba nic zvláštního nastavovat (postupuje se stejně jako u RWDC), jen všechny požadavky na zápis do DNS databáze budou automaticky přeposílány na RWDC.
Dvou-fázová instalace RODC
- Administrátor může předem na RWDC vytvořit účet pro nový RODC (computer i server object) a delegovat uživatele, který může následně provést instalaci konkrétního RODC. Uživatel pak např. v pobočce už jen spustí instalaci, která může být i navíc automatizována pomocí odpovědního souboru.

RODC může replikovat pouze z Windows Server 2008 RWDC, proto je potřeba alespoň 1 mít nainstalován. Replikace z Windows Server 2003 DC nebo z RODC není možná.

RODC je téměř ideální nasazovat na pobočkách. Na pobočkách totiž je mnohem méně věnovaná pozornost bezpečnosti serverů a to jak fyzické, tak i logické. Většinou na pobočce nebývá stále přítomen administrátor, z prostorových důvodů servery (a tedy ani řadič domény) nebývají uzamčeny v serverovně, ale jsou umístěny přímo v kanceláři (v lepším případě jsou uzamčeny v racku, ale už jsem viděl je i povalovat se na společné chodbě, protože moc hučely). Není tedy divu, že k serverům a DC mají přístup na pobočkách obyčejní zaměstnanci a bohužel i v mnoha případech cizí osoby.

RODC není samospasitelným řešením bezpečnosti DC, ale v kombinaci s instalací na Windows Server 2008 Server Core a technologií BitLocker výrazně zvyšuje bezpečnost tohoto serveru.

Obr: Fyzická bezpečnost DC na pobočce.

A nyní se vrátím konečně k otázce z titulku tohoto článku, zda může RODC zapisovat do vlastní databáze.

RODC má skutečně databázi AD jen pro čtení až na jednu skupinu atributů. V běžné situaci, pokud se pošle na RODC zápisová operace, RODC přesměrovává požadavek na RWDC, který pak tuto změnu replikuje zpět na RODC. Konkrétně, jestliže aplikace se pokusí zapsat na RODC, RODC ji odpoví referencí, informující aplikaci, že by měla svůj požadavek na zápis nasměrovat na RWDC. Pokud aplikace nepodporuje reference, nejspíše nebude fungovat (proto byste je měli důsledně otestovat, než je nasadíte na RODC – viz odkaz výše „Application Compatibility with RODCs“.

Představte si ale situaci, kdy pobočkové RODC nebude mít konektivitu k žádnému RWDC a v té době se někdo pokusí hacknout uživatelský účet nějakým password attackem. Za normální situace, by se na RWDC automaticky inkrementoval atribut BadPwdCount a jakmile by útočník dosáhl počtu povolených pokusů definovaných v politice hesel (v GPO nebo v PSO), účet by byl uzamčen. Protože ale RODC by nemuselo mít konektivitu k RWDC, které by zvýšilo čítač BadPwdCount (to by byla zranitelnost RODC, protože účet uživatele by se nikdy neuzamkl), tak z tohoto důvodu RODC může zapisovat ve vlastní databázi atribut na počet chybných pokusů a přihlášení, tedy BadPwdCount a také atribut LastLogon, aby umožnil případné zamčení účtu.

Co je to SYN attack?

Jiří Hýzler — Sun, 01 Feb 2009 15:10:02 GMT

SYN (TCP požadavek na spojení) je útok, který spadá do skupiny Denial of Service (DoS) a dal by se charakterizovat takto:

Použitím podvržené (spoofed) IP adresy (typicky nepoužívané na Internetu), útočník pošle několik SYN paketů na cílový počítač.
Pro každý SYN packet, keterý cílový počítač obdrží, musí alokovat prostředky a poslat SYN-ACK potvrzení na zdrojovou IP adresu.
Protože cílový počítač neobrží odpověď (ACK) z útočícího počítače, že dostal v pořádku SYN-ACK potvrzení, posílá znovu útočícímu počítači paket SYN-ACK a to celkem 5x v 3, 6, 12, 24 a 48 vteřinových intervalech s nadějí, že vytoužený ACK paket od útočícího PC dostane. Po celou dobu ale musí držet alokované prostředky, než po posledním neúspěšném pokusu je bude moci uvolnit.

Když útočník používá tuto techniku opakovaně, je jasné, že cílovému pocítači brzy dojdou prostředky a nebude schopen akceptovat další spojení a tím odepře služby legitimním uživatelům.

Pro zjištění, zda Váš systém může být zranitelný vůči tomuto typu útoku, napište v příkazové řádce:
netstat -n -p tcp
a podívejte se na řádky, které obsahují status SYN_RECEIVED. Jestliže uvidíte hodně těchto položek, Váš systém je zranitelný na tento útok.

Ochranu Vám samozřejmě poskytne kvalitní firewall, ale i ve Windows je možné pomoci ochraně proti DoS útokům a zkrátit časy pro SYN požadavky. Stačí když v registrech v cestě HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters v DWORD hodnotě SynAttackProtect budete mít nastavenu hodnotu 2.

Pozn.: Hodnota 0 v SynAttackProtect znamená žádnou ochranu. Hodnota 1 omezuje počet SYN opakovaných pokusů a čekacích dob, když je dosažen maximální počet otevřených TCP spojení (TcpMaxHalfOpen), tedy spojením ve stavu SYN_RECEIVED, a když je dosažen maximální počet opakovaných pokusů (TcpMaxHalfOpenRetried). Hodnota 2 v SynAttackProtect funguje podobně jako hodnota 1, ale navíc zahrnuje zpoždění Winsock notification dokud se nedokončí celé three-way handshake (tedy celé TCP spojení). Protože Windows vyvolá SynAttackProtect až po dosažení hodnot v TcpMaxHalfOpen a TcpMaxHalfOpenRetried, doporučuji nastavit i tyto hodnoty v registrech na 100 resp. 80.

Další parametry TCP/IP pro hardening najdete v mém starším článku: http://blog.hyzler.net/archive/2007/07/06/11.aspx

Security hardening IV. - zatím poslední díl

Jiří Hýzler — Thu, 05 Jun 2008 07:15:38 GMT

Zde nabízím ke stažení prezentaci k mé zatím poslední přednášce o Security hardening.

Stojím teď před rozhodnutím, zda v těchto přednáškách pokračovat nebo ne. Bohužel nemám žádnou zpětnou vazbu od posluchačů mítinků, zda alespoň pro někoho jsou tyto informace užitečné a nebo zda bych se neměl raději věnovat "masovějším" tématům, jako např. tipům a trikům pro administraci Exchange serveru nebo Active Directory či obrátit se směrem k uživatelům a ukázat jim třeba nějaké nové "power toys" nebo předvést nějakou svou novou oblíbenou "gamesku". :-).

Budu vděčný za pozitivní i negativní ohlasy, které můžete umístit přímo sem na blog a nebo mi je poslat mailem.

WUG mítinky na téma Security Hardening

Jiří Hýzler — Tue, 18 Mar 2008 07:20:46 GMT

Vzhledem k tomu, že mě několik lidí požádalo o zveřejnění mých prezentací z WUG přednášek na téma Security Hardening, zde jsou ke stažení:

Security Hardening I.
Security Hardening II.
Security Hardening III.

Zároveň si Vás dovoluji pozvat na další, již IV. díl, věnovaný Network Access Protection (NAP) a VPN Quarantine, který proběhne 22.5.2008 v sídle spol. OKsystem. Registrace bude probíhat jako vždy na www.wug.cz .

Těším se na Vaší navštěvu.

Konfigurační parametry protokolu TCP/IP a rozhraní NetBIOS

Jiří Hýzler — Fri, 06 Jul 2007 20:14:33 GMT

Microsoft má tyto parametry popsány v článku: http://support.microsoft.com/kb/q120642/ pro W2K a NT. Pro XP je na to samostatný článek: http://support.microsoft.com/kb/314053/en-us .

Mimochodem všechny TCP/IP parametry najdete na stránkách technetu: http://technet2.microsoft.com/windowsserver/en/library/db56b4d4-a351-40d5-b6b1-998e9f6f41c91033.mspx?mfr=true a určitě také nenechte bez povšimnutí články jak zabezečit TCP/IP konfiguraci proti útokům.

How To: Harden the TCP/IP Stack : http://msdn2.microsoft.com/en-us/library/aa302363.aspx
Tuning TCP/IP Response to Attack : http://technet2.microsoft.com/windowsserver/en/library/910c8482-e5e5-4e2c-9ea4-11301ddfc4661033.mspx?mfr=true

Útoky na vaši síť nemusí být nikterak složité

Jiří Hýzler — Sun, 24 Jun 2007 11:49:35 GMT

Dokladem nadpisu může být zhruba rok starý případ, který se stal na Slovensku a obětí byl Národní bezpečnostní úřad Slovenské republiky:

http://blackhole.sk/node/442

Záhada s certifikátem

Jiří Hýzler — Wed, 20 Jun 2007 13:13:55 GMT

Nedávno jsem řešil zajímavý problém. Ozval se mi zákazník, že jedna jeho zaměstnankyně si požádala prostřednictvím mmc.exe a snap-inu Certificates o certifikát pro SmartCard Logon. CA mají na serveru s Windows Server 2003 Standard Edition (jinak mají nativní doménu Windows Server 2003). Uživatelce se v pohodě vydal, ale jaké bylo její překvapení, když Subject certifikátu, Issued to i Alternative name znělo úplně na jiného uživatele.

Osobně jsem s ní prošel průvodce, který i v Summary obrazovce měl správně zapsané údaje, přesto vydal certifikát na jiné jméno. UPN i Exchange e-mail adresa (i když ta s tím nesouvisí), je v pořádku u té uživatelky nastavena. Vzhledem ke standard edici OS, šablony upravovat nemohou a i kdyby, použili jsme tu "zabudovanou". Děje se to jenom jí a nikomu jinému. Certifikát se jí vydává pořád pro stejného uživatele, alespoň že se jí náhodně nemění jména. :-)

Podle mě něco takového prostě není možné!!

Řešení:

Po té co jsem vyčerpal všechny nápady, od restartu až po přihlášení a vydání certifikátu na jiné stanici (bohužel až pak ze správce vylezlo, že používají cestovní profily), tak jsem ho požádal ať ji smaže cestovní profil a zkusí to na čistém PC. A pomohlo to. Sice do teď nevím, jak se jí to povedlo, protože na otázku co jste dělala, odpověděla uživatelka (i správce) obligátní: nic. Hlavní je, že to teď funguje a že se uživatelce vystavuje certifikát už pro její osobu.