Praktická bezpečnost ve Windows I.

Na druhou stranu je zde řada základních témat, kterým by měl rozumět opravdu každý správce, o návrhářích sítí či větších řešení na bází systému Windows ani nemluvě.

Naším cílem je odstranit jak báje a pověsti, tak překonat některá tabu. A začneme tím, v čem by měl každý správce mít jasno. Následující odstavce představí základní prvky zabezpečení, o jejichž významu bychom neměli v praxi pochybovat.

Práva, oprávnění a kdo se v tom má vyznat

Bezpečnostní architektura systému Windows někdy vyvolává zmatek a dobrým příkladem je právě prolínání dvou oblastí, jež mají vlastně stejný cíl: řídit přístupová oprávnění k určitým zdrojům v systému. Pojďme se podívat na dva mechanizmy, které jsou řadou správců pleteny a zaměňovány, dost často pak úplně nepochopeny.

Operační systém Windows uplatňuje při řízení přístupu „někam“ hned několik mechanizmů. Jedním z nich je přidělování tzv. oprávnění (permissions), což je univerzální cesta, jak definovat přístupové úrovně na různé typy zdrojů od souborů a adresářů přes položky v Registry, objekty v Active Directory až třeba po tiskárny. Pro tato oprávnění je typické, že jsou definována pomocí tzv. seznamů řízení přístupu (Access Control Lists, ACL) a vyskytují se opakovaně na každé položce, tedy v hojném počtu. Kupříkladu každý nový soubor má svůj ACL a v něm může být mnoho záznamů platných za určitých okolností.

Přístupové právo (privilege) je naproti tomu v každém „kusu“ operačního systému jen jednou a je typicky pevně svázáno s určitými akcemi ve Windows, díky nimž jsou řízeny citlivé kroky či operace. Toto právo se vlastně přiděluje také pomocí seznamu, ale váže se vždy v jediném provedení na určitou činnost, kterou daný uživatel buďto provést může, nebo ne.

Zkusme srovnání: soubor lze řídit přístupem pro čtení, zápis či třeba mazání, ale každý to může mít jinak. Právo zálohovat je oproti tomu jen jediné v celých Windows a uživatel je buďto má, nebo nemá. Stejně tak třeba právo restartovat operační systém.

Oba tyto mechanizmy jsou tedy principiálně dosti odlišné a také jejich konfigurace se provádí jinak (úprava ACL na jednotlivých zdrojích, v druhém případě pak skupinové politiky či místní zásady zabezpečení). Znalý správce Windows by tyto mechanizmy neměl nikdy plést.

PKI naruby aneb o self-signed certifikátech

Public Key Infrastructure (PKI) či jinak řečeno bezpečnostní mechanizmy založené na certifikátech a párech veřejný – soukormý klíč dnes patří k běžné mantře zabezpečení informačních technologií.

Operační systémy Windows dnes spoléhají na tyto principy valnou měrou a bez certifikátů a někdy i služeb certifikační autority si řadu funkcí již nedovedeme ani představit. V mnoha situacích pak dochází k použití speciální skupiny tzv. certifikátů self-signed, tedy podepsaných sebou samým. Mnoho správců si však není jisto, co se za ním vlastně skrývá.

Certifikát je vlastně soubor či dokument jako každý jiný. Bezpečnostní aura, která je s ním spojena, také pochází z faktu, že obsahuje některé důležité části (třeba tzv. veřejný klíč), ale hlavně pak z toho, že by měl být vydáván někým, kdo je důvěryhodný. Certifikát sám o sobě žádnou bezpečnost nedělá a jeho klíčový význam pro PKI má právě onen fakt důvěryhodnosti, který pouze technickými prostředky nelze vynutit.

Vezměme si příměr z oblasti velmi aktuální: vysokoškolský diplom je vlastně certifikát; jeho existence a vlastnictví nic neříkají o kvalitě toho, co se v něm píše. Důvěryhodnost diplomu, který jste si vyrobili doma, bude asi mizivá, ačkoliv bude vypadat stejně jako jiné. Jen o chloupek výše na žebříčku důvěryhodnosti bude třeba diplom z práv v Plzni, a na opačném konci škály budou asi diplomy třeba z Karlovy univerzity nebo řekněme z Harvardu.

S certifikáty je to vlastně stejné. Máte-li certifikát od Thawte, bude jeho důvěryhodnost o dost vyšší než v případě certifikátu od české PostSignum, ačkoliv to Česká pošta myslí vážně. No a na onom úplném chvostu pak stojí certifikát připravený „na koleně“, tedy self-signed.

Certifikát self-signed je velmi užitečný typ, který se hojně využívá k testování a podobným akcím. Jde o zcela funkční, technologicky plně vyhovující certifikát, který umí vše co jeho sourozenci. Má-li zašifrovat webový přenos, dokáže to stejně dobře jako třeba podepsat dokument či poštu. Je tedy kompletní, nijak okleštěný, po všech stránkách zcela funkční. Tedy až na tu důvěryhodnost.

Právě proto, že je zamýšlen jako testovací prostředek, je vytvářen pomocnými programy „na koleně“ a v místě, kde by mělo být jméno seriózního vydavatele, má sám sebe. Je plně funkční, ale nikdo by mu neměl věřit. Vyrobit jej může každý a jeho nasazením v produkčních sítích (třeba na ochranu veřejného webu) dochází vlastně k likvidaci klíčového principu PKI – veřejně ověřená identita zde chybí a věřit není čemu.

Plně funkční certifikát ještě bezpečnost nedělá a ten self-signed je opravdu užitečným testovacím kusem, který by měl zůstat v laboratorním prostředí. Pomůže vám sice odhalit, zdali třeba webový server správně funguje i s SSL, důvěru a bezpečí však neposkytne.

Buffer overflow aneb komu co přetéká

Dvě slova v záhlaví tohoto odstavce jsou jistě podvědomě známou magickou formulí z oblasti zabezpečení, a to i těm, kteří si vůbec nedovedou představit, co, kde, komu a kam vlastně přeteče. Řada správců pak považuje nebezpečí tajemně skryté za tímto souslovím za cosi hypotetického, patřícího do dob prvních služeb IIS a dávných verzí Windows. Mylných představ zde žije celá řada.

Buffer overflow, tedy pokud tak označíme počítačový útok, je vlastně rafinované zneužití jedné z klíčových koncepcí počítačů posledních 60 let. Před mnoha lety přišel pan Von Neumann s architekturou, které odpovídají nejen dnešní stroje typu PC, a jedním z jejích pilířů je využití paměti jak pro data, tak pro samotný kód programu (tedy instrukce, jež se provádějí).

Ano, operační systém Windows (a řada dalších) nijak nepozná, co data v paměti jsou – prostě se ukáže na nějaké místo, odkud se mají data dekódovat jako instrukce k provádění, a pokud to dává smysl a funguje to, tak se prostě provádí program. Toho se dá dobře zneužít tak, že do paměti, kde mají ležet uživatelská data, nějaká uložíme a pak je záludně necháme provést jako instrukce se škodlivým (či přinejmenším neočekávaným) následkem.

Kde k takovým problémům může dojít? Těchto míst je řada, ale třeba dobrá příležitost je tam, kde program načítá data od uživatelů nebo třeba z formuláře či vstupního souboru. Ideálně se pak k útoku hodí webová aplikace, která „trčí“ do internetu, a nabízí se tak každému, kdo by to chtěl zkusit. Řada správců se domnívá, že buffer overflow hrozí jejich systémům všude tam, kde nezáplatují Windows.

Jenže to je fatální omyl: spousta děr tohoto typu číhá ve vlastních webových aplikacích, tedy ve vašem vlastním softwaru, který jste si napsali či nechali napsat, třeba jako aplikaci pro IIS. Že máte určitě bezpečnou aplikaci? A v čem je napsána? Třeba v PHP?  A jak víte, že ten skriptovací stroj pro PHP nemá onu díru v sobě?

Buffer overflow je stále živá věc a číhá všude možně, neboť málokterý správce může ověřit všechen kód. Jaké je doporučení?

To základní je: spouštějte minimum aplikací, tedy jen ty, které potřebujete, a sledujte u nich důkladně dodávky záplat výrobcem. To je to nejmenší, co můžete udělat. A dále? Zkuste se podívat, co je ve Windows funkce Data Execution Prevention, a otestujte ji. Právě ona se snaží řešit onu nepříjemnost, kterou nám zařídil génius Von Neumann svým nápadem – DEP se právě snaží označit, kde v paměti leží data, a blokovat jejich záludné spouštění.

Režim jádra aneb v jakém ringu že to hrajeme?

Řada administrátorů je přesvědčena, že pokud operační systém řádně záplatují a neinstalují aplikace pochybného původu a účelu, bezpečnost je zajištěna. Neznalost alespoň základní koncepce toho, jak je standardní bezpečnost vystavěna, jim pak zavírá dveře k pochopení mnoha nebezpečí, kterým je třeba čelit. Jedním z klíčových pojmů je běh v tzv. režimu jádra (kernel mode) a jeho praktické dopady.

Většina dnešních počítačů, které využíváme jako pracovní stanice i servery, má procesor s víceméně shodnou koncepcí. Pokud tato jednotka provádí instrukce programu, nachází se víceméně v jednom ze dvou bezpečnostních režimů: režimu jádra (tedy běží jádro operačního systému a to může všechno) a režimu uživatele (běží uživatelské aplikace a ty mohou jen opatrně a něco).

Řada specializovaných programů (nejen ve Windows) je tedy natažena do paměti a pak spouštěna na procesoru v režimu jádra, kdy neplatí víceméně žádná bezpečnostní omezení a kód může cokoliv. Jaké to jsou? No v zásadě všechny, které si jaku svou část instalují nějaký „ovladač“, tedy kousek aplikace, který je právě zaváděn ve speciálním režimu a spouštěn v módu jádra.

Takže které tedy? Antivirus, dodatečný firewall, řada ovladačů externích zařízení... ale třeba i kódovací knihovny různých přehrávačů videa a zvuku apod. Už tušíte, kde je nebezpečí? Každý kus programu, kterému dovolíte nainstalovat se jako ovladač, je potenciálním bezpečnostním problémem.

Jako administrátoři při takové instalaci ovladače říkáte: Ano, tobě dovoluji běžet v režimu jádra, a tedy ti svěřuji osud a bezpečnost svého systému zcela do tvé laskavosti. Schválně, kdy jste naposledy nainstalovali ovladač nejistého původu k ne zcela potřebné aplikaci, u něhož navíc Windows zoufale volaly, že není digitálně podepsán?

Nyní víme, co je běh v režimu jádra a začnou nám dávat smysl i další důležité pojmy. Copak je rootkit? Ano, to je ona záludná komponenta – ovladač, kterou jste bezděčně nainstalovali a ona teď běží, třeba odesílá data a sama sebe rafinovaně maskuje (nezapomeňte, v režimu jádra může vše). Proč Windows chtějí digitálně podepsané ovladače?

Správně, takové jsou jen málokdy škodlivým kódem, tedy pokud je podpis z důvěryhodného zdroje. A proč máme ve Windows User Access Control a všechna ta otravná hlášení, jestli se ta nebo ona komponenta může opravdu spustit pod právy administrátora? Ano, jistě, zavedení nového ovladače (i ono podloudné) si typicky vyžaduje práva administrátora.

Takže ten dialog vlastně říká: Teď chci práva administrátora, čekal jsi to? Nečekal? A co tedy vlastně spouštíš, že tě to překvapuje? Cože, tys tu instalaci nespustil? Aha, tak si dej pozor, tady se děje něco nekalého! Tak nezapomeňte: Kdo může do režimu jádra, může prakticky vše!