Autentizace a identifikace - vylepšete si bezpečnost vlastními silami

Každý, kdo používá počítač připojený k sítí, se téměř neustále hlásí k různým
síťovým službám a využívá cizí zdroje, jinak by ostatně ani počítačové sítě

neměly smysl. Většina služeb v dnešní době využívá jistou formu autentizace

uživatele, a to různými metodami. Málokdo se však zamýšlí nad tím, jak taková

autentizace vlastně funguje a jak je bezpečná. Toto malé zamyšlení je cílem

dnešního článku.





Šifrované versus nešifrované přenosy



Mnoho síťových autentizačních metod používá různé kryptografické algoritmy k

šifrování vzájemné komunikace. Bohužel jsou i takové, které tak nečiní. Nyní se

podíváme na ty protokoly, které k autentizaci šifrování nepoužívají.



Každý z vás již jistě dobře ví, že protokoly jako je FTP, POP, Telnet nebo HTTP

šifrování téměř nevyužívají. Většina uživatelů ale nad tímto faktem mávne rukou

a řekne si, že s tím nemůže osobně nic udělat, a dále se problémem netrápí.

Situace však není tak růžová a jednoduchá, jak by se na první pohled mohlo

zdát. Zejména v komerční sféře může mít takové ignorování faktů kritické

následky, nemluvě o narušení soukromí, které není jistě příjemné nikomu. Na

následujících několika řádcích si ukážeme, jaké může mít používání

nešifrovaných protokolů následky, a co vše lze s trochou šikovnosti zjistit.

Nakonec se podíváme na některé bezpečné alternativy nešifrovaných služeb a

povíme si, jak pomocí nich řešit stávající situaci.





Identifikace serveru a služeb



První věcí, kterou je třeba zjistit, je, jakou vlastně verzi a typ služby

provozujete nebo využíváte. Pokusíme se identifikovat různé služby a jak jistě

uvidíte, pokud nejsou správně nastaveny, prozradí tyto služby o sobě velmi

mnoho. Prvním krokem by měla být identifikace cílového systému, který službu

nabízí. Může jít o poštovní server, FTP server nebo webový server. Jako příklad

jsem vybral systémy, které nabízejí mnoho služeb (což mimochodem není příliš

šťastné a bezpečné řešení). V praxi se můžete setkat (je to velmi

pravděpodobné) s tím, že služby budou nainstalovány na různých systémech.

Uvedené služby běžely pod těmito operačními systémy: Linux RedHat 7.3 a Windows

2000 Professional. Na systémech byly spuštěny tyto služby: SMTP server, FTP

server a HTTP server. Na systému Linux ještě SSH server a na systému Windows

telnet server. Nyní se podíváme, jak vypadal portscan každého systému a jaké

služby identifikoval. Ke skenování portů byl použit nástroj nmap

(www.insecure.org/nmap), který platí za jeden z nejlepších produktů své třídy.



Jak vidíme na obrázcích na vedlejší straně, nabízí každý systém podobné služby.

Nyní se pomocí nástroje telnet podíváme na to, jak se jednotlivé služby

identifikují. Alternativně lze použít i nástroj netcat, který je součástí

většiny linuxových distribucí a je k dispozici i pro operační systém Windows.







Z pohledu správce



Nyní uděláme malou odbočku a podíváme se na problém ze strany správce systému.

Z výpisu je vidět, že se většina služeb identifikuje celkem obsáhle, což ale

nemusí být vždy dobře. Pokud útočník zná druh a verzi dané služby, může

zjistit, byla-li v té které konkrétní verzi dané služby objevena nějaká chyba,

a případně takovou chybu zneužít. S tím souvisí sledování změn a pravidelná

aktualizace softwaru. Jak můžete vidět z výpisů, testované systémy jsou

zprovozněny v základní konfiguraci a ke všemu ještě neaktualizované, což by se

u systémů připojených k síti (a nejen u nich) stávat nemělo.



Nyní si tedy povíme, jak znesnadnit útočníkovi identifikaci běžících služeb.

První a základní věcí je vůbec nespouštět služby, které nepotřebujeme. Proč mít

na své lokální stanici spuštěnu službu telnet, když nechceme, aby náš počítač

využíval někdo jiný? Další věcí je oddělení služeb, které slouží uživatelům

vnitřní sítě, a služeb, jež chceme nabídnout veřejnosti. Zde přicházejí ke

slovu firewally a směrovače. Rovněž není od věci uvažovat o implementaci

takzvané DMZ neboli demilitarizované zóny, do které jsou umístěny služby

nabízené veřejnosti, jež chceme oddělit od naší vnitřní sítě. Do DMZ můžeme

umístit poštovní servery, FTP server nebo webové servery. Konfigurace a

strategie firewallu však není tématem tohoto článku, a tak se raději vrátíme k

našemu tématu a povíme si, jak znesnadnit identifikaci běžících služeb.



Jako první si ukážeme, jak odstranit hlavičku poštovního serveru Sendmail. Tuto

změnu můžete provést pomocí konfiguračních maker m4 nebo přímou editací souboru

sendmail.cf, což je jednodušší, neboť jde o změnu jednoho řádku, a to konkrétně

o změnu řádku obsahujícího direktivu SMTPGreetingMessage=j Sendmail $v/$Z; $b.

Tuto direktivu můžete libovolně měnit, můžete se dokonce vydávat za jiný

poštovní server. Možností je mnoho a rozhodnutí leží jen na vás. Pozor ale na

situaci, kdy se o poštovní server stará více správců a nastavení se provádí

pomocí maker m4. Potom je důležité, aby změna byla provedena i v makru, aby

nedošlo k situaci, kdy druhý správce změní nějaké konfigurační direktivy, znovu

vygeneruje a zavede konfigurační soubor, a všechny změny pak přijdou nazmar.

Dalším velice často používaným poštovní serverem je Postfix. I u něj si

ukážeme, jak změnit jeho hlavičku. Změnu provedete v konfiguračním souboru

Postfixu main.cf, kde je třeba upravit direktivu smtpd_banner. Další službou,

kde je žádoucí změnit hlavičku, je FTP. Povíme si, jak to udělat u

nejrozšířenějšího FTP serveru wu-ftpd. V konfiguračním souboru ftpaccess

editujte direktivy greeting full, greeting brief, greeting terse, greeting

test, banner a hostname. Pokuste se s těmito direktivami experimentovat a

zvolte tu, která vám bude nejvíce vyhovovat. U HTTP serveru, což je v unixovém

světě nejčastěji server Apache a ve světě Microsoftu nejčastěji IIS, je situace

poněkud obtížnější. Například u serveru Apache se při změně hlavičky nevyhneme

editaci zdrojového kódu a následné kompilaci. Změnu hlavičky provedete v

hlavičkovém souboru httpd.h, který je uložen v adresáři apachesource/include,

kde apachesource je adresář, v němž máte uloženy zdrojové kódy serveru. V tomto

souboru změňte hodnotu makra SERVER_BASEPRODUCT a SERVER_BASEVERSION. Verzi

HTTP serveru zjistíte velice snadno zasláním následujícího požadavku na port,

na kterém HTTP server běží: HEAD /HTTP/1.0. Nyní se vraťme do pozice uživatele,

jenž se snaží identifikovat běžící služby a zjišťuje jejich vlastnosti.







Z pohledu uživatele



Dejme tomu, že se vám podařilo více či méně úspěšně identifikovat služby, které

využíváte, a z dostupných informací, jimiž bývají nejčastěji domovské stránky

jednotlivých produktů, jste zjistili, zda služba šifruje komunikaci a na jakém

principu provádí autentizaci. Nyní se budeme zabývat postupem pro případ, kdy

zjistíte, že služba šifrování nevyužívá. Abyste pochopili význam nebezpečí,

které vám hrozí, uděláte nejlépe, když si sami zkusíte, čeho je potenciální

útočník schopen. Nejjednodušším způsobem, jak obejít síťovou autentizaci, je

použití snifferu a odchycení hesla právoplatného uživatele. To je mnohem

snazší, než by se mohlo zdát. Jako sniffer je použit produkt ettercap

(sourceforge.net/ettercap), který nabízí špičkový výkon, mnoho standardních

funkcí, další užitečné plug-iny, a navíc využívá GTK interface pro uživatele,

kteří mají rádi grafické prostředí. Pro konzolové uživatele je vedle klasického

rozhraní přichystáno i rozhraní využívající ncurses. Program umí různé druhy

sniffu, ať již jde o ARP sniffing užitečný zejména na přepínaných sítích, IP

sniffing nebo MAC sniffing. V případě, že na vaší síti běží služba arpwatch,

která sleduje změny na síti, a vy se pokusíte o ARP sniffing, bude arpwatch

hlásit spoustu nestandardních situací, zejména flip-flop sniffovaného stroje.

Proto raději na své aktivity předem upozorněte správce sítě.



Nyní již tedy k samotnému testování nešifrovaných služeb. Myslíte si, že je

vaše pošta v bezpečí před cizími zraky? Zkuste zapnout sniffer, a jako source

adresu vyberte poštovní server a jako destination vyberte svůj systém a zapněte

sniffování (typ zvolte podle požadavků sítě). Nyní na svém stroji zkuste

přijmout/odeslat poštu. Vidíte výsledky? To, co vidíte, může vidět kdokoliv na

vaší sítí, případně každý, kdo má do vaší sítě přistup. Situace však může být

ještě horší. Podívejte se na obrázek vlevo dole. Zde jsme spuštěním příslušného

plug-inu zaznamenali celou komunikaci mezi serverem a klientem, jinými slovy

udělali jsme si kopii e-mailu. Co se stane v případě, kdy poštou posíláte

citlivé informace, mající zásadní vliv na fungování vaší firmy?



Nyní se podíváme na protokol ftp. Opět si zapněte sniffer a pokuste se připojit

k libovolnému ftp serveru. Vidíte vaše jméno a heslo? Pokud ano, může ho vidět

i kdokoliv ve vaší síti, případně na cestě mezi vámi a serverem, ale tuto

situaci již opravdu asi neovlivníte. Co se stane v případě, kdy stahujete

citlivá data z firemního ftp serveru, o kterém si myslíte nebo o němž vám bylo

tvrzeno, že je zabezpečen?



Dobře, řeknou si někteří lidé, a co když omezím přístup jen na povolené IP

adresy? I proti tomuto lze vznést námitku, neboť IP adresa může být velice

snadno zfalšována či podvržena. Nyní se ještě podíváme na HTTP komunikaci,

abychom si ukázali, že ani tento druh přenosu není příliš bezpečný. V prostředí

webu se používá mnoho autentizačních metod. Některé jsou založené na funkcích

serveru, některé na skriptovacích jazycích, jež na serveru fungují. Velice

často se však používá HTTP autentizace, nejčastěji pak typu basic. S tímto

druhem autentizace se jistě každý již někdy setkal.



Bohužel i tento typ autentizace lze velice snadno obejít a překonat. Opět

spustíme náš oblíbený ettercap a budeme chytat veškerý provoz mezi webovým

serverem a klientem. V okně prohlížeče otevřeme stránku a pokusíme se vstoupit

do nějaké autorizované oblasti, která je chráněna HTTP autentizací. Pokud

nemáme takový komfortní nástroj jako je ettercap, jenž nám naservíruje všechna

hesla jako na podnose, ale máme k dispozici „pouze“ starý dobrý sniffer,

dostaneme výstup podobný tomuto:



GET /adresar1/adresar2 HTTP/1.0

Autorization: Basic upravena podoba hesla



Jelikož heslo není šifrované, ale pouze upravené pro přenos po síti, je získání

jeho podoby otázkou několika sekund. Stačí nám k tomu například skriptovací

jazyk PHP, Perl atd. Zkuste Perl a base_decode64 nebo její obdobu v PHP. Další

perličkou (slovo nemá souvislost se skriptovacím jazykem Perl ) programu

ettercap je plug-in, který umožňuje zachytávat všechny kopírované soubory přes

protokol HTTP.



Existují také různé autentizační metody, jež využívají sessions, cookies nebo

například hashů md5 algoritmu. Všechny uvedené metody jsou více či méně

bezpečné, ale nemá cenu je zde podrobně rozebírat. Za malou chvilku se podíváme

na metodu, která je při správné implementaci ze všech uvedených nejbezpečnější.







Alternativy



Jestli vás předchozí řádky dostaly do deprese a zoufáte kvůli tomu, že žádná

data nejsou v bezpečí, tak buďte v klidu. Existují metody, jak svá data chránit

a jak nahradit stávající nebezpečné služby jejich bezpečnější alternativou.

Nyní si uvedeme krátký přehled alternativních služeb.





POP, IMAP



Většina poštovních klientů ani POP nebo IMAP serverů šifrování nepodporuje.

Řešením jsou servery APOP a KPOP, které fungují na trochu odlišném principu než

klasický POP server. Princip komunikace spočívá v tom, že server pošle

klientovi požadavek, tento požadavek klient zpracuje tak, že pomocí hesla

vygeneruje odpověď, kterou odešle zpět serveru. K přenosu hesla přes síť tak

vůbec nedochází. Nasazení těchto serverů je bohužel velmi malé. Pokud však máte

vliv a zájem na bezpečnosti dat, nebude pro vás problém daný systém prosadit.

To jsme však řešili pouze otázku autorizace serveru a ne samotného obsahu

elektronické pošty. Pokud si chcete být jisti, že vaši poštu nikdo číst nebude,

sáhněte po kryptografickém nástroji GPG nebo PGP.





FTP



V dnešní době existuje bezpečná náhrada k FTP, a tou je například SCP. SCP

využívá šifrovaného protokolu SSH, a je tudíž daleko bezpečnější než klasické

FTP. Implementace SCP jako náhrada za FTP nese svá rizika. Pokud o tom

uvažujete v prostředí lokální sítě, kterou znáte a ovládáte, není to takový

problém. Pokud uvažujete o náhradě FTP na serveru, jenž je veřejně přístupný,

nese to určitá rizika, zejména v oblasti klientů, které neznáte a neznáte ani

jejich požadavky. Ještě lze říci, že náhrada FTP serveru je vhodnější tam, kde

jsou k dispozici citlivá data, než na serverech, které nenabízejí nic tajného a

mají vysoký bandwidth.





HTTP



Protokol HTTP má svou bezpečnou náhradu v protokolu HTTPS. Ten využívá pro

šifrování dat SSL a celou komunikaci tak činí mnohem bezpečnější. Implementace

SSL je celkem snadná a výrazně zlepší, zkvalitní a učiní důvěryhodnějším vaše

webové sídlo.







„Bezpečné protokoly“



Nyní se podíváme na protokoly, které využívají při přenosu dat šifrování a

další bezpečné metody, a můžeme je tudíž označit jako bezpečné. Půjde zejména o

SSH, SSL a Kerberos. Popíšeme si, na jakém principu fungují, kde se s nimi

můžeme setkat, na co si je třeba při jejich používání dávat pozor. Začneme

protokolem SSH.





SSH



Secure Shell alias SSH je založen na principu šifrování veřejným klíčem. To v

praxi znamená, že pracuje s dvojicí klíčů soukromým a veřejným. V praxi se

nejčastěji setkáme s volnou implementací SSH protokolu OpenSSH, vyvíjenou v

rámci projektu OpenBSD. OpenSSH je dnes standardem ke komunikaci mezi unixovými

systémy. Najdete jej v instalaci všech(?) linuxových distribucí, v xBSD

implementacích a dalších mnoha unix-like systémech. Ve Windows, a to ani ve

verzi 2000 a XP, není žádný šifrovaný protokol standardně implementován a

implicitním nástrojem pro vzdálenou správu (hned po vašem autě) je klasický

telnet, se všemi jeho nevýhodami.



Instalace a práce s SSH je velmi snadná. Nejprve musíme nainstalovat serverovou

část. Záleží na tom, jak program instalujete. Pokud například používáte Linux

RedHat, nabídnou se vám ze standardní instalace k nainstalovaní soubory

openssh-client, openssh-server a openssh. Pokud používáte jinou distribuci nebo

instalujete ze zdrojového kódu, pravděpodobně si stáhnete jen jeden balíček a

ten vám nainstaluje všechny potřebné součásti. Po nainstalování máte jako

klient k dispozici tyto tři nástroje: slogin, scp a ssh. Více o jednotlivých

nástrojích se dozvíte z jejich manuálových stránek.



Další věcí, kterou by měl každý uživatel počítače udělat, je vygenerování svého

privátního a veřejného klíče. To lze učinit pomocí příkazu ssh-keygen. Globální

konfigurační soubor pro klienty se nachází typicky v adresáři /

etc/ssh/ssh_config a konfigurační soubor pro server v souboru

/etc/ssh/sshd_config. Doporučuji řádně přečíst dokumentaci předtím, než začnete

ssh používat, a dát si pozor na změny klíčů, které často svědčí o něčem

nestandardním. Pokud se vám zobrazí hláška o změně klíče, nepište slepě, že si

přejete klíč přijmout, ale raději si zkontrolujte systém fyzicky, pokud k němu

máte přístup, případně kontaktujte svého systémového administrátora a na

případnou změnu ho upozorněte.





SSL



SSL (Secure Socket Layer) je podobně jako SSH založeno na kryptografii s

použitím veřejných klíčů. SSL můžete stejně dobře (stejně nejspíš ne )

implementovat do webového serveru Apache, stejně jako do serveru IIS. Pokud

používáte webový server Apache z nějaké standardní distribuce, budete mít

pravděpodobně zabudovánu podporu SSL přímo do kódu programu. Stačí ji pak pouze

aktivovat v konfiguračním souboru httpd.conf a nechat takto změněný

konfigurační soubor serverem načíst. Většina direktiv je velmi dobře

okomentována a vysvětlena. Pokud instalujete Apache ze zdrojového kódu, budete

muset pomocí direktiv přidat podporu SSL. Více vám napoví příkaz ./configure

-help. Po nainstalování budete muset ještě vygenerovat certifikáty pro váš

server. Tyto certifikáty musí být podepsány certifikační autoritou. Pokud

nechcete platit za podpis certifikátu, který jste si vytvořili jen pro vlastní

testovací účely, můžete si jej sami podepsat. Počítejte ale s tím, že prohlížeč

vás bude při každém otevření certifikátu upozorňovat na to, že jde o

samopodepsaný certifikát.



Stejně jako u SSH, se i zde můžete stát obětí útoku. Aby byl útočník v napadení

systému úspěšný, bude potřebovat vaši spolupráci. Pokud se vám tedy někdy

zobrazí varovná hláška o tom, že byl certifikát změněn, okamžitě věc prošetřete

a neklikejte bezhlavě na OK.





Kerberos



Kerberos je velmi zajímavý projekt, který je určen ke zvýšení bezpečnosti, a

proto se na něj podíváme podrobněji a vysvětlíme si jeho princip a funkce.



Počátky systému Kerberos sahají až do roku 1983, kdy se na MIT (Massachussets

Institute of Technolgy) ve spolupráci s firmami IBM a Digital začalo pracovat

na projektu Athena, jehož cílem bylo zapojení počítačů do sítě a jejich

následné využití k výuce. Vývojáři systému narazili během vývoje na mnoho

problémů, zejména s bezpečností dat a autentizací. Výsledek byl systém

Kerberos, který pracuje jako síťový autentifikační systém. V současné době je

Kerberos k dispozici ve dvou hlavních verzích, a to ve verzi 4 a 5 (přesněji IV

a V). My si nejdříve popíšeme, na jakém principu Kerberos pracuje, a pak se

podíváme na rozdíly mezi verzemi.



Autentifikace je v systému Kerberos založena na znalosti hesel. Tato hesla jsou

uložena na serveru Kerberos a kryptována standardním algoritmem DES, takže

mohou být v případě potřeby dešifrována. Z toho logicky plyne, že server musí

být nejen fyzicky, ale i programově naprosto bezpečný. Na serveru by neměly

běžet žádné jiné služby, a rovněž by měl být umístěn na místě, kde k němu

nebudou mít přístup nepovolané osoby. A jak tedy vypadá následná autentizace v

případě, že používáte server Kerberos? Pro uživatele se naprosto nic nemění.

Těm se zobrazí standardní přihlašovací dialog typu login: a password:. Důležité

je, jak vnitřně Kerberos pracuje, a co z toho pro uživatele plyne. Zde rovněž

vyvstávají rozdíly mezi verzemi IV a V. Podíváme se na obě varianty.





Kerberos IV.



Po zadání jména (login: ) odešle stanice serveru Kerberos zprávu s vaším

uživatelským jménem a informací o tom, že se chcete přihlásit do systému.

Server, jelikož zná vaše heslo a jméno, ověří vaše uživatelské jméno ve své

databázi, a pokud je v pořádku, odešle vám tiket, jejž zašifruje vaším heslem,

které také zná. Když tento tiket dorazí do vašeho systému, požádá vás systém o

zadání hesla. Pokud zadáte správné heslo, dešifruje jím systém tiket a přihlásí

vás do systému. V momentě, kdy vám systém povolí přihlášení, zlikviduje

informaci o vašem heslu a dále výhradně pracuje s tiketem.





Kerberos V.



V této verzi serveru Kerberos čeká stanice až do doby, kdy zadáte své heslo. Až

poté kontaktuje server a odešle mu zprávu s vaším uživatelským jménem a

aktuálním časem, který je šifrován vaším heslem. Server po obdržení této zprávy

zjistí ve své databázi vaše jméno a heslo, a pokusí se dešifrovat časový údaj.

Pokud vše proběhne v pořádku, pošle vám server tiket zašifrovaný vaším heslem.



Z informací tedy v praxi plyne následující:



- Hesla nejsou uložena na žádné stanici v síti kromě serveru Kerberos



- Hesla se při procesu autentizace nepřenáší po síti, pracuje se výhradně s

tikety.





Implementace Kerbera do stávající sítě



Implementace systému Kerberos není jednoduchou záležitostí. Je třeba si

rozmyslet všechny potřeby sítě, vzít v potaz každý detail. Ne pro každého je

použití systému Kerberos vhodným řešením. Samotná instalace již tak složitá

není.





Závěrem



Na závěr lze říci, že používání autentizačních mechanismů není snadná věc.

Pokud to s bezpečností myslíte vážně, musíte začít uvažovat o nahrazení

standardních mechanismů jejich bezpečnějšími alternativami. Proces přechodu na

bezpečnější alternativy není jednoduchou záležitostí a vyžaduje mnoho změn

současného systému. Tento přechod se vám však bohatě vyplatí a nakonec bude

sloužit ke spokojenosti správců sítě a uživatelů.







Nápady, dotazy, návrhy témat, jež vás zajímají a připomínky zasílejte na adresu

igm@centrum.cz. Na vaše dotazy k této problematice se pokusíme najít odpovědi.