Ondrej Sevecek's Blog

Mám tu pár pozitivních ohlasů na svůj článek o zážitcích s 802.1x, tak sem se rozhod, že to doplnímo IPSec.

V poslední době se snažím prosazovat čím dál tím víc IPSec šifrování (tunely, ale i transport) kdekoliv to jen jde. Samozřejmě je to vždycky problém pro řešení potíží a v případě transportního šifrování pro spolehlivost. Tedy spolehlivost z pohledu neočekávaných problémů. A schopnosti adminů řešit případné potíže.

Ale možná to za tu bezpečnost stojí.

Prostě musíte udržovat certifikáty, ty se musí spolehlivě vydávat. A hlavně máte problém slepice-vejce (což programátoři nazývají z opačné strany obvykle deadlock). Když potřebuju pro přístup na certifikační autoritu IPSec, abych si vydal certifikát a přitom IPSec potřebuje ke své funkci ten certifikát, tak se vystavuju potenciálním problémům :-)

Tady se zaměřím hlavně na transportní IPSec pro šifrování vnitřní sítě. Tedy komunikace mezi stanicemi, servery a DC. A bude se jednat jen o několik poznámek, co jsou podle mě těžko k dohledání. Zbytek se nakliká podle normálních návodů.

Ověřování

K ověřování počítačů s IPSec máte na výběr buď Kerberos, nebo certifikáty. Osobně výrazně preferuju certifikáty. Zapnout si Kerberos je moc pěkné, a mohlo by to vypadat i jednoduše, ale není. Na to, aby jel Kerberos, musí si počítače nejprve vydat Kerberos tikety od nějakého DC. K tomu potřebuje mluvit s DC pomocí několika protokolů - DNS, LDAP a GC, Kerberos, případně NTP, SMB (XP a 2003 ještě Ping) apod.

Takže s DC byste museli mít stejně skoro všechno otevřené. A navíc, pokud by DC z nějakého důvody nebyla dostupná, mašiny to totálně odřízne a budete mít problém dostat se na ně i jen na RDP (já vím, že na doménový účet se na RDP z keše stejně nepřihlásíte, ale na lokální ano).

Další problém je, že počet a IP adresy DCček se poměrně často, a poměrně volně, a bez problémů mění. Udělat a udržovat na tohle IP adresové filtry v IPSec politice je nepohodlné. Narozdíl od toho, certifikačních autorit (AD CS) a jejich CRL/OCSP distribučních bodů máte minimum, plus se to tak často nemění.

Stejně ale diskuze potřebnosti

Měl bych dát IPSec i pro přístup na službu Kerberos? Ten je přece sám od sebe zabezpečený. Ale i přesto jeho bezpečnost stojí na kvalitě uživatelských hesel. Takže by se tu IPSec hodil.

Potřebuju IPSec pro sdílené soubory (SMB/CIFS) a DNS a NTP a LDAP? Ideálně ano, buď to není nijak šifrované, nebo se to šifruje produkty uživatelských hesel, takže lépe je to zašifrovat do IPSec.

Měli byste mít IPSec pro vzdálenou plochu RDP? Pokud na ní mám TLS (SSL), tak mě to zase tak moc nevzrušuje.

Je potřeba mít HTTPS chráněno IPSec? Ne, je tam přece to TLS. Musím mít WSUS, CRL a OCSP chráněno IPSec, i když je to jen přes nezašifrované HTTP? Ne, protože tyto odpovědi jsou stejně digitálně podepsané.

Je potřeba mít IPSec uvnitř serverové VLANy? No pokud je to oddělená VLAN od klientů, tak bych to striktně nepotřeboval. Hlavně aby komunikace klient vs. server byly šifrované. Servery mezi sebou, na separované VLANě, můžete zvážit nechat volně a omezit si tak starosti.

Takže pojďme na certifikáty a AD CS

Certifikáty si vydávám pomocí technologie autoenrollment automaticky. Dneska už ideálně z Windows 2008 R2 CAčky, v režimu Enterprise, stačí vám Standard Edition.

Pokud máte strach, tak její vydávací DCOM rozhraní by mohlo být nejspíš dostupné bez IPSec, aby to mohlo jet i v případě problémů. AD CS používá port TCP 135 a DCOM dynamický port (ten se ale dá jednoduše zafixovat podle návodu zde). Na druhé straně, bez DC a Kerberos ověření se tam stejně nedostanete. Ale dobře, na lokální účet ano.

Rozhodně, CA je v tomto případě klíčovou službou, o kterou byste neměli přijít.

Budeme vydávat certifikáty pro stanice a servery. Certifikáty mají svoje podmínky, které jsou poněkud nepřesně popsané například zde. Tu mám lepší popis, který mám otestovaný. Po x dnech různých problémů v produkcích :-)

IPSec se nejprve autentizuje pomocí Main Mode a dvou možných protokolů - IKE, nebo AuthIP. Windows XP a Windows 2003 umí jen IKE. Protokol AuthIP se používá až od Windows Vista a Windows 2008. Windows 2012 a Windows 8 už umí i IKEv2.

IKE potřebuje následující certifikát. Sice si můžete vytvořit kopii výchozí šablony IPSec, ale není to dokonalé:

Pozor pokud máte Windows Vista a Windows 2008 a novější. Jestli se počítač rozhodne, že bude dělat místo obyčejného IKE raději AuthIP, tak v certifikátu musí být vždy Client Authentication. Bez toho to nepojede. Takže úprava tabulky pro AuthIP: je následující:

Poznámka: je vidět, že výchozí šablona IPSec je nedostatečná pro AuthIP. Zatímco výchozí šablona Computer by sice stačila, ale úplně zbytečně obsahuje Server Authentication a moc nepotřebných Key Usage.

Případně můžete AuthIP vypnout úplně. Pokud nedělám mapování účtů počítačů (Enable certificate to account mapping) ani nepotřebujete druhé ověření uživatele, stačí vám IKE. Windows 2012 a Windows 8 už umí i IKEv2 i pro IPSec transport (a ne jen tunnel jako Windows Vista a Windows 2008):

HKLM\System\CurrentControlSet\Services\IKEEXT\Parameters
IKEFlags = DWORD = binaryOR 0x40

Pravidelnost vydávání IPSec certifikátů

Vydávám autoenrollmentem. Autoenrollment má v šabloně (certificate template) příkaz vydat certifikát už několik dnů před jeho plánovaným vypršením - záložka General, políčko Renewal period. Počítejte taky s tím, že autoenrollment běží jen po startu a pak jednou za 8 hodin. Tak bacha, aby se to stihlo.

Můžete vydávat i na nějak krátkou dobu, něco jako týden, nebo měsíc. Ale pozor. Jestliže počítač nemá platný certifikát, skončil s IPSec. Chtělo by to nějaký monitoring, pro jistotu. Můžete si třeba trošku potunit SCOM, on to sám reportuje blbě - ale to je na dlouhý článek, takže někdy jindy.

Nebo si udělejte jednoduše naplánovanou úlohu, která vám pošle mail v okamžiku, kdy vám ten certifikát pomalu končí. Následující skript vypíše varování, když vám pomalu končí certifikát s použitím IPSec IKE Intermediate - stačí upravit, nebo vložit do SCOMu:

$criticalDays = 2


$criticalExpiration = (Get-Date).AddDays($criticalDays)

$dnsHost = Get-WmiObject Win32_ComputerSystem | `
  % { '{0}.{1}' -f $_.DnsHostName, $_.Domain }

$certsByName = dir cert:\LocalMachine\My | `
  ? { $_.Subject -eq ('CN={0}' -f $dnsHost) }

$validCerts = $certsByName | % {

  $oneCert = $_
  $oneCert.Extensions | `
    ? { $_.Oid.Value -eq '2.5.29.37' } | `
    % { $_.EnhancedKeyUsages } | `
    ? { $_.Value -eq '1.3.6.1.5.5.8.2.2' } | `
    % { $oneCert } | `
    ? { $_.NotAfter -gt $criticalExpiration }
}

if ($validCerts -eq $null) {

  Write-Host ('Error: There is no IPSec certificate valid for more than {0} days' -f $criticalDays) -ForegroundColor Red
}

CRL a OCSP distribuční body

To je ten největší problém.

V certifikátech, které budou mít stanice a servery jsou odkazy na LDAP a HTTP cesty pro ověření platnosti (revocation). IPSec ve výchozím stavu ověřuje platnost certifikátů. Na Windows 7 a Windows 2008 je preferovanou metodou OCSP, které je pouze na HTTP a je přenosově úspornější.

Pokud OCSP k dispozici není, tak se sklouzne na CRL. CRL cesty máte obvykle LDAP a HTTP. HTTP může být anonymní, LDAP vyžaduje ověření. Abyste tedy měli robustní ověření platnosti, dejte si nejlépe HTTP cestu pro OCSP i CRL. A hlavně ty distribuční body vynechte z IPSec.

I tak je ale dobře zvážit nasazení politiky (Group Policy, GPO), která prodlouží platnost CRL i OCSP odpovědí, pakliže nové není z nějakého důvodu k dispozici. Je to za cenu lehoučce nižší bezpečnosti, ale zase to nádherně zrobustní okrajové stavy. Tohle funguje až od Windows Vista a Windows 2008:

Prostě vytvoříte nový Group Policy Object (GPO) a v něm rozbalíte Computer Configuration - Policies - Windows Settings - Security Settings - Public Key Policies - Certificate Path Validation Settings, záložka Revocation, Allow CRL and OCSP responses to be valid longer than their lifetime (not recommended).

Jiné řešení je do IPSec certifikátů vůbec nedávat CRL ani OCSP cesty. To umí Windows 2008 R2 a novější AD CS certifikační autorita. Znamená to, že počítače nebudou CRL ani OCSP vůbec kontrolovat. Opět se jedná o jakési snížení bezpečnosti. Tedy nelze IPSec certifikáty vůbec zneplatnit. Ale pokud je vydáváte jen na krátkou dobu, nemusí to být až takový ústupek.

Musíte si to zapnout ve vlastnostech šablony certifikátu (certificate template) na záložce Server - položka Do not include revocation information in issued certificates:

No ještě poslední možnost je vypnout CRL kontrolu v případě IPSec přímo na počítačích. Pomocí registrové hodnoty:

netsh ipsec dynamic set config strongcrlcheck value=0

HKLM\System\CurrentControlSet\Services\PolicyAgent\Oakley
StrongCrlCheck = DWORD 0

Postup implementace

Nejprve bych zapnul autoenrollment a nachystal šablonu certifikátů. Potom bych je nechal všem počítačům vydat. Na to budete muset počkat nějakou dobu, než je všichni dostanou. Group Policy se aplikuje při startu a potom každých 120 minut. Autoenrollment běží také při startu a potom každých 8 hodin.

Pozor! Pokud chcete vynutit ručně autoenrollment, musíte použít certutil. Příkaz gpupdate nemá nic společného s autoenrollmentem a nefunguje k jeho vyvolání! Takže certutil je to kouzlo:

certutil -pulse

Až to všichni mají, můžete začít pokusovat :-)

Rizikové situace?

Hlavní riziko je v situaci, kdy počítač (hůře DC) nemá platný certifikát a nemůže se tedy nikam dostat. A možná si ani vydat certifikát nový. Jak se pro tuto situaci vybavit?

Nevyžadujte IPSec pro přístup na AD CS certifikační autoritu. Nevyžadujte IPSec pro přístup na CRL a OCSP distribuční body. A nainstalujte si stránku pro Certificate Authority Web Enrollment (certsrv). A zase pro přístup na tuto stránku nevyžadujte IPSec. Nebo ještě lépe, nainstalujte si rovnou Certificate Enrollment Web Service a Certificate Enrollment Policy Web Service:

Tihle dva kámoši (Certificate Enrollment Web Service a Certificate Enrollment Policy Web Service) jsou plně moderní, podporují i CNG šablony v3 a v4 (certificate template version Windows 2008 a Windows 2012) a umí je použít takové to normální GUI rozhraní. Ona prehistorická webová stránka vyžaduje nebezpečné ActiveX a vůbec je to zastaralá mrcha.

Má to nevýhodu, že ty webové služby (web service) potřebují Enterprise Edition Windows 2008 R2. Ale když začnete už rovnou s Windows 2012, tak to máte ve všech edicích, a fičíte z kopcééé.

Dobře. Takže přístup na CA a příbuzné služby je bez IPSec. Ale co když se nedostanu ani na DC? Dokud se na DC dostane sama certifikační autorita, je všechno v pořádku. Při nejhorším se ověříte pomocí NTLM. Tuhle ještě další poznámečka - systém nechce používat NTLM :-) Zvažte, jestli to nezapnout (funguje až od Windows 7 a Windows 2008 R2):

Tedy nastavení je Group Policy tady: Computer Configuration - Policies - Windows Settings - Security Settings - Local Policies - Security Options - Network security: Allow Local System to use computer identity for NTLM.

Co když se na DC nedostane ani sama certifikační autorita (CA)? Nic vám nevydá. Ale to opravíte. Stačí, když si buď IPSec vypnete na ní samotné a na jednom blízkém DC, nebo to jen přepnete na preshared-key. Takže si nesmíte tuhle lokální možnost odebrat. Nechte si možnost dělat úpravy v IPSec pravidlech na lokále, i když to celé nastavujete přes GPO! Alespoň na DC a CA.

Dobrá zásada zní - mít vždy na všech strojích certifikáty platné alespoň na takovou dobu, po jakou ta mašina bude vypnutá. Takže jestli to vypínám, možná stojí zato požádat si o nový certifikát.

Co když se stane, že mašina se už opravdu nikam dostat nemůže, protože má nějakou zadrbanou GPO politiku. A tím pádem si nemůže ani stáhnout lepší z DC. A vy nemůžete dělat úpravy na tom počítači? Deadlock! Jak se zbavíte účinnosti GPO na lokále?

Stačí přece vyhodit počítač z domény! To vám nic trvalého nezpůsobí. Až to opravíte, stačí ho znovu připojit.

Uf tak přeju přijemnou zábavu s rozjížděním :-)