Jan Hrdinka. Bakalářská práce

Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Vyšší odborná škola informačních služeb v Praze

Jan Hrdinka Realizace zabezpečeného FTP serveru (SFTP a FTPS) a zabezpečeného HTTP (HTTPS) serveru Bakalářská práce

2011

Prohlašuji, že jsem tuto bakalářskou práci na téma Realizace zabezpečeného FTP serveru (SFTP a FTPS) a zabezpečeného HTTP (HTTPS) serveru zpracoval samostatně a využil pouze zdrojů, uvedených v seznamu použité literatury.

V Praze dne 19.8.2011 Jan Hrdinka

Abstrakt: Tato práce je určena zájemcům o způsoby zabezpečení datových přenosů a softwarových řešení pro jejich ochranu. Nabízí popis technologií a aplikací, které šifrují přenášená data, včetně rizik, která při přenosu dat přes internet hrozí. Poskytuje též návod, jak instalovat a konfigurovat software, umožňující zabezpečení přenášených dat, i způsoby ochrany a bezpečnostní doporučení pro jejich uložení. Klíčová slova: internet, datový přenos, ftp, sftp, ftps, http, https, klientské aplikace, serverové aplikace, šifrování, zabezpečení

Abstract: This work is intended for those interested in ways to secure data transfers and software solutions for their protection. It offers a description of used technologies and applications that encrypt transmitted data, including the description of risks by which are data transmissions over the Internet endangered. It also provides guidance on how to install and configure the software to enable secure data transfers, ways of protection and safety recommendations for their storage. Key words: internet, data transfer, ftp, sftp, ftps, http, https, client applications, server applications, cryptography, security

Obsah 1. Úvod ............................................................................................................................. 7 2. Datové přenosy a používané technologie .................................................................... 7 2.1. Architektura datových přenosů ............................................................................ 7 2.2. Protokoly pro přenos souborů .............................................................................. 8 2.2.1. FTP .................................................................................................................. 8 2.2.2. FTP přes SSH ................................................................................................. 10 2.2.3. SFTP .............................................................................................................. 11 2.2.4. FTPS .............................................................................................................. 12 2.3. Protokoly pro výměnu hypertextových dokumentů ........................................... 13 2.3.1. HTTP ............................................................................................................. 13 2.3.2. HTTPS ........................................................................................................... 14 3. Šifrování datových přenosů........................................................................................ 16 3.1. Metody šifrování ................................................................................................. 16 3.2. Dostupné technologie ......................................................................................... 18 3.2.1. SSH ............................................................................................................... 18 3.2.2. TSL a SSL ....................................................................................................... 19 4. Rizika, typy útoků, možnosti zneužití ......................................................................... 20 5. Serverové aplikace ..................................................................................................... 23 5.1. Přehled ................................................................................................................ 23 6. Postup instalace a konfigurace vybraných serverových aplikací ............................... 24 6.1. FTPS a SFTP.......................................................................................................... 24 6.1.1. FileZilla FTP Server ....................................................................................... 24 6.1.2. Titan FTP Server ........................................................................................... 30 6.1.3. Core FTP Server ............................................................................................ 35 6.2. HTTPS .................................................................................................................. 38 6.2.1. Apache.......................................................................................................... 38 6.2.2. Microsoft IIS ................................................................................................. 42 7. Alternativní možnosti konfigurace serverových aplikací ........................................... 45 8. Klientské aplikace ....................................................................................................... 46 8.1. Přehled ................................................................................................................ 46 9. Konfigurace vybraných klientských aplikací ............................................................... 46 5

9.1. FTPS a SFTP.......................................................................................................... 46 9.1.1. TotalCommander ......................................................................................... 46 9.1.2. FileZilla ......................................................................................................... 47 9.1.3. Cute FTP ....................................................................................................... 47 9.2. HTTPS .................................................................................................................. 48 9.2.1. Internet Explorer .......................................................................................... 48 9.2.2. Opera............................................................................................................ 48 10. Závěr ......................................................................................................................... 49 11. Použité zdroje........................................................................................................... 50

6

1. Úvod Tématem této bakalářské práce je realizace zabezpečeného FTP a HTTP serveru. V následujících kapitolách se pokusím srozumitelnou formou vysvětlit principy datových přenosů, popsat technologie využívané pro přenos a šifrování dat, rizika, kterým mohou být uživatelé vystaveni při nedodržování zásad bezpečnosti manipulace s daty a také postup instalace a konfigurace vybraných klientských a serverových aplikací realizujících datové přenosy. Poskytnu také seznam použité literatury, ze které je možné získat více informací o zmíněných tématech. Proč je vlastně nutné datové přenosy zabezpečit? V současnosti, vlivem masového rozšíření osobních počítačů, mobilních zařízení a možností přístupu k internetu, dochází též k přesunu poskytování služeb na internet. Elektronické obchodování, bankovnictví, uzavírání smluv prostředky komunikace na dálku, komunikace se státní správou, emaily i vzdálený přenos souborů vyžadují přenášení citlivých informací, jako jsou jména, rodná čísla, adresy, data narození, čísla kreditních karet a bankovních účtů, hesla pro přístup do různých služeb, elektronickým datovým přenosem přes veřejnou síť, nejčastěji internet. Jsou-li tato data přenášena v nešifrované podobě, může dojít k jejich odposlechnutí a zneužití nedůvěryhodnou osobou. Tato práce si klade za cíl informovat o možných rizicích při využívání služeb na internetu a poskytnout návod, jak své datové přenosy zabezpečit z pohledu obou účastníků elektronické komunikace, uživatele i poskytovatele služeb. Text je určen čtenářům, kteří se orientují v oboru počítačových sítí a jsou alespoň zběžně obeznámeni s hardwarovými a softwarovými prostředky, které jejich provoz realizují. Zájem o zabezpečení svých dat je dle mého názoru pro člena informační společnosti do budoucna jen výhodou.

2. Datové přenosy a používané technologie 2.1. Architektura datových přenosů Realizaci datových přenosů ve veřejných i privátních sítích zajišťuje skupina komunikačních protokolů Transmission Control Protocol/Internet Protocol. Jedná se o nejrozšířenější způsob komunikace nejen v síti internet. TCP/IP se člení do vrstev, které zajišťují přenos dat na úrovni hardwaru, organizaci do datových bloků, spolehlivý přenos těchto bloků a komunikaci s aplikacemi vyžadujícími pro svoji funkci vzdálený přenos počítačovou sítí. Model TCP/IP dělí realizaci datového přenosu do vrstev, zajišťujících jednotlivé stupně přenosu, a definuje komunikační protokoly, které by měly na každé vrstvě pracovat: Vrstva síťového rozhraní – zajišťuje příjímání, vysílání datových bloků (paketů) síťovým rozhraním (prvek umožňující připojení do počítačové sítě) a ovládání přenosového kanálu. Síťová vrstva – zajišťuje nalezení síťové cesty, směrování datových paketů přes uzlové body sítě od odesílatele k příjemci a systém adresování (identifikace klientů TCP/IP sítě IP adresami). Zde pracuje Internet Protocol (přenos datových paketů), Internet Control Message Protocol (předávání stavových a chybových hlášení) a Address Resolution Protocol (převod fyzické adresy síťového rozhraní na IP adresu). Transportní vrstva – slouží aplikacím z následující vrstvy pro ovládání datového toku, nastavení režimu přenosu a přizpůsobení konkrétním požadavkům aplikace. Protokoly Transfer 7

Control Protocol (spolehlivý datový přenos) a User Datagram Protocol (nespolehlivý, ale rychlý datový přenos). Aplikační vrstva – zde pracují samotné aplikace, které využívají nižší transportní vrstvu realizující datový přenos s určitými parametry, aby mohly zajistit uživatelům služby poskytované protokoly FTP, FTPS, SFTP, HTTP, HTTPS. Na rozdíl od referenčního modelu OSI se sedmi vrstvami je zajištění přenosu a spolehlivé předávání datových paketů ponecháno na nastavení transportní vrstvy a samotných aplikacích. V modelu OSI tuto funkci realizují nižší komunikační vrstvy. Standardy v oblastech síťové architektury a komunikačních protokolů vyvíjí organizace IETF (Internet Engineering Task Force). Jedná se o mezinárodní organizaci správců sítí, designérů a výrobců hardwaru, jejímž cílem je publikovat doporučení, která mají zajistit správnou funkci a vývoj internetu (volně citováno z [2] – TCP/IP Foundations).

2.2. Protokoly pro přenos souborů 2.2.1. FTP File Transfer Protocol je velmi rozšířený protokol umožňující přenos souborů mezi dvěma počítači v TCP/IP síti. Pracuje na aplikační vrstvě TCP/IP modelu a pro samotný přenos dat a jeho řízení využívá protokol TCP z transportní vrstvy. Kromě přenosu souborů oběma směry umožňuje i funkce známé z běžného správce souborů, vytváření a mazání adresářů, výpis jejich obsahu, procházení adresářovou strukturou a změny názvů. FTP využívá architekturu klient – server. FTP server umožňuje vzdálený přístup k datům na lokálním disku, případně, podle konfigurace, poskytuje diskový prostor pro ukládání dat uživatelům. FTP server aplikace nabízejí i další funkce, jako je řízení přístupu na základě uživatelských účtů (přihlašovací jméno a heslo), omezení uživatelských oprávnění jen na některé operace (pouze čtení, čtení i zápis), přístup pouze do části souborového systému, veřejný přístup anonymních uživatelů, šifrování přenášených dat a další způsoby zabezpečení. Uživatel, který chce realizovat vzdálený přenos souborů, potřebuje aplikaci typu FTP klient, která umožňuje připojení k FTP serveru a provádění souborových operací na vzdáleném disku. Operace a navazování/ukončení spojení je řízeno pomocí sady FTP příkazů standardizovaných ve specifikaci protokolu FTP. Zjednodušený FTP klient je v současnosti integrován v každém webovém prohlížeči i v řadě správců souborů (Total Commander, Explorer v OS Windows) a je možné využít i specializovaných aplikací, které nabízejí pokročilé funkce (správa a uložení nastavení připojení k FTP serveru, automatické opakování přenosu v případě, šifrování, řízení množství přenesených dat, časové plánování přenosu jen na určitou dobu). FTP klienti zpravidla obsahují grafické uživatelské rozhraní a základní konfigurace přenosu je prováděna automaticky, k jejich využívání tedy není nutná znalost FTP příkazů ani použití příkazové řádky. Protokol FTP je nezávislý na platformě a klientské i serverové aplikace jsou dostupné pro libovolný operační systém. FTP používá pro svoji funkci dva komunikační kanály – řídící a datový. Řídícím komunikačním kanálem ovládá uživatel FTP server. Jsou přes něj přenášeny přihlašovací údaje, sloužící k autentizaci uživatele, následné FTP příkazy a textových odpovědí serveru na tyto příkazy. Datový slouží k přenosu výpisů obsahu adresářů a samotných dat. Řídící spojení zahajuje vždy klient, komunikace probíhá následovně – klient vyšle požadavek na zahájení 8

řídícího spojení serveru, klientská aplikace si vyžádá od svého operačního systému náhodný volný síťový port větší než TCP 1023 (rozsah 0-1023 je organizací ICANN rezervován pro specifické služby), server očekává požadavky na spojení standardně na síťovém portu TCP 21, proběhne autentizace uživatele a mezi těmito dvěma porty je vytvořeno řídící spojení. Uživatel poté může serveru zadávat FTP příkazy, server tyto příkazy plní a odesílá zpět v řídícím kanálu hlášení o provádění příkazů. V okamžiku požadavku na přenos dat je vytvořen datový kanál, který může vzniknout dvěma způsoby, podle režimu spojení, který byl v řídícím kanálu nastaven a FTP server jej umožňuje: Aktivní režim – původní režim, se kterým byl FTP navržen. Řídící spojení navazuje klient, datové spojení navazuje server ze svého portu TCP 20 na volný port klienta větší než TCP 1023. Po navázání spojení již může probíhat přenos dat oběma směry, případně je odesílán výstup operace na základě příkazu, který byl FTP serveru zadán (např. výpis obsahu adresáře). Tento režim přenosu se může ukázat jako problémový, pokud klient přistupuje k serveru ve veřejné síti z privátní, která používá směrovač a technologii NAT. Protože datové spojení navazuje server, je ve směrovači klienta nutné povolit příchozí spojení z portu TCP 20 serveru na port klienta vyšší než TCP 1023, který se může, při různých spojeních, měnit a zpravidla bývá firewallem blokován. Pokud je v privátní síti umístěn server a dochází k překladu adres směrovačem, stačí zajistit pouze směrování příchozích spojení pro port TCP 21 na odpovídající IP adresu v privátní síti pro zřízení řídícího kanálu.

Obr. 2—1 – Aktivní FTP přenos Pasivní režim – řídící i datové spojení navazuje klient. Tento režim vznikl v reakci na rozšíření technologie NAT z důvodů omezeného počtu veřejných IP adres a jeho cílem je zjednodušení navazování datového kanálu pro klienty z privátních sítí. Na klienta a konfiguraci jeho směrovače nejsou kladeny žádné speciální požadavky, není potřeba povolovat a směrovat příchozí spojení, protože řídící i datový kanál navazuje on. Řídící spojení vzniká běžnou cestou na port TCP 21 serveru, při požadavku o vytvoření datového kanálu nepoužije server port TCP 20, ale využije náhodný volný port větší než TCP 1023, na kterém očekává navázání datového kanálu klientem. Tuto informaci (IP adresu a číslo portu) odešle klientovi v řídícím kanálu jako odpověď na příkaz pro přechod do pasivního režimu. V případě, že je v privátní síti server, je nutné nastavit v jeho konfiguraci dostatečný rozsah portů vyšších než TCP 1023 pro příchozí datová spojení, protože současně může probíhat komunikaci s více klienty, a zajistit jejich správné směrování na IP adresu serveru v privátní síti. Pasivní režim používá většina FTP klientů, které jsou implementovány ve webových prohlížečích, specializované aplikace dovolují režim přenosu uživateli zvolit. 9

Obr. 2—2 – Pasivní FTP přenos V souhrnu je aktivní režim výhodnější pro správce serveru, ale klade vyšší nároky na konfiguraci směrovače klienta. Pasivní režim je výhodnější pro klienta, náročnější na konfiguraci FTP serveru, pokud je umístěn v privátní síti a dochází k překladu adres. Aby byla zajištěna kompatibilita přenesených dat mezi různými operačními a souborovými systémy, může přenos v datovém kanálu probíhat ve dvou módech. ASCII a binárním. Pokud jsou přenášeny soubory, které obsahují prostý text, různé operační systémy používají odlišné znaky nebo sekvence ASCII znaků pro formátování obsahu textu, především označení konce řádků. Soubory obsahující text musí být přenášeny v módu ASCII, kdy během přenosu dojde ke konverzi těchto ukončovacích znaků, aby bylo zajištěno korektní zobrazení v cílovém operačním systému. Příkladem souborů obsahující prostý text je *.txt, *.htm, *.html, *.css. Binární mód nezasahuje do obsahu souborů a jsou přenášeny v originální podobě, zde by zásah do formátování dat a nahrazení některých znaků poškodilo jejich obsah a staly by se nečitelnými pro cílovou aplikaci. Veškeré audio, video, obrazové formáty, ale i soubory *.pdf, *.doc jsou formátovány binárně a je nutné je v tomto módu přenášet. FTP klienti používají metody pro rozlišení obsahu souborů, nejčastěji přednastavený filtr podle jejich přípony, a v případě volby automatické konfigurace přenosu sami nastaví odpovídající režim pro každý přenášený soubor, manuální volba typu přenosu je stále možná FTP příkazem v řídícím kanálu. FTP bývá nejčastěji využíván k přenosu většího množství souborů se zachováním adresářové struktury, především v oblasti webhostingu pro správu obsahu webových stránek a přenášení dat do vzdálených datových úložišť. Pokročilí FTP klienti umožňují automatickou synchronizaci obsahu lokálního a vzdáleného adresáře, je tak možné nakonfigurovat zálohování dat bez uživatelského zásahu na vzdálený disk nebo aktualizace obsahu webové stránky, která je vyvíjena lokálně, a modifikované soubory jsou samy FTP klientem přenášeny na hostitelský server. V současnosti není FTP považován za bezpečný, protože veškeré příkazy, přihlašovací údaje i data jsou přenášena v nešifrované podobě jako prostý text a datové pakety je možné v uzlovém bodě sítě zachytit a odposlechnout, proto byla vytvořena rozšíření a alternativy protokolu, které tento nedostatek napravují.

2.2.2. FTP přes SSH Tato metoda zabezpečení spočívá v navázání šifrovaného spojení mezi klientem a serverem prostřednictvím SSH (Secure Shell), k přenosu dat je poté použit běžný FTP. SSH označuje sadu aplikací a zabezpečený síťový protokol, které zajišťují přihlášení se k vzdálenému počítači, spouštění aplikací a příkazů i přenos dat. Pracuje na principu asymetrické 10

kryptografie. Veškerá komunikace probíhá přes šifrovaný komunikační kanál, který umožňuje směrování portů a vytvoření bezpečného tunelu pro jiné, samostatně nešifrované síťové protokoly. Běžné FTP spojení je tak zapouzdřeno do šifrovaného kanálu, který není možné bez znalosti šifrovacích klíčů účastníků SSH komunikace v reálném čase dešifrovat. Odchozí komunikace FTP klienta je z jeho počítače směrována do SSH tunelu a šifrována, v této podobě projde přes nedůvěryhodnou síť (veřejná síť, např. Internet), je přijata SSH serverem a z něj směrována na port TCP 21 FTP serveru. FTP využívá dva komunikační kanály, řídící a datový, oba je nutné přesměrovat přes SSH tunel a na výstupní straně správně směrovat komunikaci k cílovým portům FTP serveru. Tento způsob přenosu vyžaduje kromě FTP server/klient aplikací též SSH server/klient aplikace, které slouží k vytvoření SSH tunelu, šifrování a dešifrování datového přenosu, zajišťují směrování příchozí/odchozí komunikace na správné porty služby FTP a autentizaci účastníku prostřednictvím výměny šifrovacích klíčů. Musí být též použit pasivní režim FTP přenosu (klient zahajuje řídící i datové spojení), aby mohlo dojít k směrování komunikace přes SSH tunel a došlo k šifrování přenosu v obou kanálech.

Obr. 2—3 – SSH tunelování Zabezpečení FTP přes SSH vyžaduje náročnou konfiguraci směrování komunikace mezi FTP a SSH protokoly na straně klienta i serveru a instalace dalších aplikací pro zřízení SSH tunelu. FTP používá pro svou komunikaci rozsah portů TCP větších než 1023 a pro každý možný musí být nastaveno směrování přes SSH tunel. Tato metoda zabezpečení tedy není vhodná pro FTP servery, které bude využívat velký počet uživatelů pro své přenosy dat současně z důvodu komplexnosti nastavení směrování, v praxi se používá jen ve velmi specifických situacích a pro malý počet uživatelů.

2.2.3. SFTP SSH File Transfer Protocol je alternativa k běžnému FTP. Jedná se o zcela nový síťový protokol, který má zajišťovat stejné funkce jako FTP, ale opravit jeho nedostatky, zpravidla bývá součástí instalačních balíčků SSH serverů. Umožňuje obdobné souborové operace jako FTP – výpis obsahu adresářů, procházení jejich strukturou, tvorbu a mazání adresářů, kopírování a přejmenování souborů. Na rozdíl od FTP umí též navazovat přerušené datové přenosy a ke komunikaci mezi serverem a klientem využívá pouze jeden datový kanál, přes který jsou, vždy šifrovaně, přenášeny příkazy i samotná data, v případě komunikace uživatelů v privátních sítích s NAT, je tak usnadněna konfigurace směrování síťového provozu. Umožňuje též přenášet dodatečné informace, především atributy souborů, které jim byly přiřazeny v souborovém systému (příznak pouze pro čtení, čas a datum vytvoření, poslední úpravy). SFTP byl navržen jako protokol nezávislý na platformě, serverové i klientské aplikace jsou dostupné pro každý operační systém. Ověřování uživatelů a šifrování datového přenosu nezajišťuje SFTP sám o sobě, ale využívá k tomu jiný síťový protokol, nejčastěji SSH, může však pracovat i s 11

jiným. Při použití SFTP není nutné manuální směrování portů, instalace a konfigurace dalších SSH klient/server aplikací, veškeré nezbytné komponenty jsou implementovány přímo v SFTP klientovi nebo instalačním balíčku SFTP serveru. SFTP bývá součástí SSH aplikací a standardně využívá port TCP 22.

2.2.4. FTPS File Transfer Protocol přes TLS/SSL rozšiřuje běžný FTP o možnost šifrování veškerých přenášených informací využitím protokolů Transport Layer Security a jeho předchůdce Secure Sockets Layer. Oba protokoly poskytují dostatečnou úroveň zabezpečení, z důvodů zpětné kompatibility se současnou infrastrukturou podporují nové aplikace i starší protokol SSL. TSL umožňuje šifrovanou i nešifrovanou komunikaci na stejném portu, SSL pouze šifrovanou. FTPS používá dva komunikační kanály – řídící a datový, oba s možností šifrování protokoly TSL/SSL. Princip FTPS spočívá ve vytvoření šifrovaného datového kanálu do kterého je zapouzdřen přenos jiných protokolů využívaných na Internetu. Tímto způsobem bývá nejčastěji zabezpečena komunikace mezi uživatelem a webovým serverem prostřednictvím HTTP, přenos dat v poštovních službách POP3, SMTP, IMAP a datové přenosy FTP. TLS/SSL zajišťují ověření identity účastníků komunikace pomocí certifikátů, vydávaných důvěryhodnou certifikační autoritou, u které je před navázáním datového přenosu možné ověřit, zda uživatel opravdu komunikuje s požadovaným serverem a nedošlo ke skrytému přesměrování komunikace na jiný server, v případě, že vypršela platnost certifikátu nebo se nepodaří ověřit identitu serveru, zobrazí aplikace varování a datové spojení není navázáno. Certifikáty vydává certifikační autorita zpravidla za pravidelný udržovací poplatek, existují ale i certifikáty nabízené zdarma. Samotný přenos je šifrován metodou veřejných klíčů. Každý účastník vlastní dva šifrovací klíče, privátní a veřejný. Sekvenci dat, zašifrovanou veřejným klíčem je možné dešifrovat pouze pomocí klíče privátního. Před zahájením zabezpečené komunikace se serverem si klient vyžádá jeho veřejný klíč, kterým data určená k přenosu zašifruje, přístup k nim je poté možný pouze s privátním klíčem serveru, který není nikdy komunikován ve veřejných sítích a vlastní jej pouze příjemce. Ověřování identity probíhá zpravidla pouze na straně serveru (přenos dat v oblasti webhostingu, elektronické obchody), v oblastech, kde je vyžadována vyšší úroveň zabezpečení (firemní datová úložiště, elektronické bankovnictví, peněžní služby), bývá kontrolována identita na obou stranách (certifikáty pro klienty v této situaci vydává správce serveru, ti si jej musí nainstalovat do své klientské aplikace). Součástí TLS/SSL je i hash funkce, která umožní kontrolu, zda přenášená data nebyla modifikována nebo zda nedošlo k chybě přenosu. FTPS server může pracovat ve dvou režimech: Implicitní TLS/SSL – zabezpečená komunikace mezi serverem a klientem je vždy vyžadována. Požadavek klienta na nezabezpečený přenos je automaticky serverem odmítnut, to platí i v případě, že FTP klient uživatele TSL/SSL nepodporuje. Pro tento režim je zpravidla využíván port TCP 990. Explicitní TLS/SSL – server umožňuje klientovi zvolit režim přenosu, nabízí nešifrovanou i šifrovanou komunikaci, pro obě využívá port TCP 21. Ještě před odesláním přihlašovacích údajů k FTPS serveru může FTPS klient změnit režim přenosu z nešifrovaného do TSL/SSL odesláním příkazu v řídícím kanálu, v něm pak probíhá veškerá řídící i datová komunikace.

12

2.3. Protokoly pro výměnu hypertextových dokumentů 2.3.1. HTTP Hypertext Transfer Protokol je síťový protokol, který slouží k výměně hypertextových dokumentů mezi dvěma počítači v TCP/IP síti. Pracuje na aplikační vrstvě TCP/IP modelu a k přenosu dat může využívat protokoly TCP nebo UDP z transportní vrstvy. Jeho původním účelem byl pouze přenos hypertextu (elektronické textové dokumenty obsahující odkazy na další dokumenty, grafické prvky, obrázky, tabulky), v současnosti však umožňuje i přenos dat v různých formátech, multimediální obsah a spouštění webových aplikací. HTTP využívá architekturu klient – server. Uživatelé, kteří chtějí přistupovat k obsahu hypertextových dokumentů, pracují s aplikací typu HTTP klient (webový prohlížeč). Ten odesílá požadavky prostřednictvím TCP/IP sítě HTTP serveru, kde je tento obsah uložen, a zajišťuje jeho nalezení, přenos přes veřejnou síť a korektní zobrazení. HTTP server standardně naslouchá požadavkům HTTP klientů na portu TCP 80, na jeho lokálním disku je uložen hypertextový dokument, jehož zobrazení klient požaduje, a odešle zpět HTTP odpověď současně s obsahem požadovaného dokumentu. Nemusí se nutně jednat jen o statický hypertextový dokument, ale i o libovolný soubor nebo dynamicky generovaný výstup webové aplikace, provozované na HTTP serveru, která obsah vytváří na základě požadavku od klienta. Obsah odeslaný zpět klientovi nemusí být tvořen jen daty uloženými lokálně na HTTP serveru, ale může pocházet i z dalšího HTTP serveru, kam je požadavek přesměrován, nebo je získán webovou aplikací napojením na jinou službu (SQL databáze). HTTP obsahuje též metody pro přenášení dat od klientů k serveru a to v podobě formulářů a nahrávání souborů, se kterými dále pracuje webová aplikace. Obsah bývá zpravidla členěn a prezentován systémem webových stránek. Jedná se o elektronické dokumenty, které mohou obsahovat text, odkazy na další webové stránky, soubory, multimédia, formuláře, tabulky, obrázky a webové aplikace. K tvorbě webových stránek je využíván nejčastěji značkovací jazyk HTML, existují ale i jiné varianty. Jednotlivé prvky webové stránky jsou označeny HTML značkami, které určují typ obsahu, formátování a způsob, jakým s nimi má HTTP klient pracovat, webový prohlížeč tento kód přijme a sestaví z nich webovou stránku, kterou zobrazí uživateli. Webové stránky mohou obsahovat i skripty (kód, který je zpracován na straně klienta a výstup zobrazen v prohlížeči) a webové aplikace (provozované na straně serveru), k jejich tvorbě jsou využívány programovací jazyky JAVA, PHP, .NET a jiné. Jejich podporu musí zajistit vývojáři HTTP serveru a webového prohlížeče. Veškerou výměnu dat mezi serverem a klientem zajišťuje protokol HTTP. Pro přístup k hypertextovým dokumentům, souborům a službám ve veřejných i privátních sítích TCP/IP slouží Uniform Resource Locator. Definuje síťovou adresu serveru, kde je požadovaný obsah uložen, cestu k jeho umístění na serveru a protokol použitý pro jeho získání. Uživatel zadává URL svému webovému prohlížeči, který jej zpracuje, vyšle požadavek serveru a pokud je cílový obsah nalezen, odešle ho v odpovědi zpět klientovi a webový prohlížeč jej zobrazí. URL používá následující syntaxi: protokol://doménový_název:port/cesta Příklad URL: http://www.seznam.cz/st/img/2011/logo.png. Nejprve je určen protokol, který webový prohlížeč použije k dosažení cílového souboru (většina webových prohlížečů podporuje více komunikačních protokolů, např. HTTPS, FTP, FTPS). Dále je specifikována IP adresa cílového serveru (77.75.76.3) nebo jeho doménový název (www.seznam.cz), za kterým 13

může následovat číslo portu TCP, kam má webový prohlížeč požadavek odeslat. V případě, že není port v URL uveden, prohlížeč automaticky zvolí standardní port pro zvolený protokol (v tomto případě TCP 80). Převod mezi IP adresami a doménovými názvy vznikl z důvodu usnadnění práce s URL uživatelům a zajišťuje jej Domain Name System. Webový prohlížeč se nejprve připojí k DNS serveru, v jeho databázi nalezne odpovídající záznam a zahájí HTTP přenos na IP adresu serveru, pro který je doménový název registrován. Za lomítkem se nachází umístění požadovaného souboru na cílovém serveru (/st/img/2011/logo.png, pokud by byl URL ve tvaru – http://www.seznam.cz/logo.png nacházel by se v kořenovém adresáři diskového prostoru vyhrazeného HTTP serveru). Tento způsob procházení adresářové struktury HTTP serveru je možné v jeho konfiguraci zakázat a zpřístupnit klientům pouze úvodní webovou stránku a soubory prostřednictvím hypertextových odkazů. V URL je možné předávat data pro skripty a webové aplikace spouštěné na HTTP serveru (http://www.eshop.cz/ katalog.php?produkt=2147). PHP skript, který je součástí webové stránky, vygeneruje nový HTML dokument se zobrazením produktu číslo 2147. Ten je poté odeslán klientovi. Lze také odkazovat na určitou součást webové stránky, na jejíž pozici se přesune okno webového klienta po jejím zobrazení (http://www.eshop.cz/katalog.htm#katalog). URL umožňuje i předávání přihlašovacích údajů k různým službám před doménovým názvem, tato metoda je nebezpečná, hrozí jejich odposlechnutí (ftp://login:[email protected]/logo.png). Pro realizaci datového přenosu může HTTP využít Transmission Control Protocol nebo User Datagram Protocol. Preferovanou metodou je TCP, která obsahuje metody pro zajištění spolehlivosti datového přenosu. Každý odeslaný datový blok je postupně opatřován identifikátory a kontrolním hash součtem, které jsou u příjemce kontrolovány, pokud dojde ke ztrátě datového paketu během přenosu nebo jeho poškození, klient si vyžádá opakování přenosu od serveru. Umožňuje i zpomalení datového přenosu, aby ho obě strany dokázaly bez chyb zpracovat. Tento způsob nemusí být vhodný pro přenosy médií, kde je kladen požadavek na rychlost přenosu před jeho kvalitou, např. živé vysílání videa, streamovaná internetová rádia. Zde je vhodnější použít UDP, ztracené a poškozené pakety nejsou kontrolovány, klient ani neprovádí zpětné potvrzení o úspěšném/neúspěšném přenosu jako TCP. Pokud by byl pro přenos vysílání internetového rádia využit protokol TCP, v případě poškození datových paketů by se přehrávání zastavilo, dokud by nedošlo k opakovanému zaslání dat serverem a po jeho opětovném navázání by vzniklo zpoždění oproti vysílání v reálném čase. Je-li pro přenos využit UDP, přenášená data nejsou kontrolována, pokud se vyskytne chyba, dojde ke krátkodobému výpadku nebo dočasnému snížení kvality přijímaného datového toku, samotný přenos není přerušen, kvůli opakování zasílaní poškozených/ztracených datových paketů. UDP zase není vhodné pro přenos obsahu webových stránek, souborů a jiných multimédií, kde je vyžadován bezchybný přenos, korektní zobrazení a kvalita. Standardní verze HTTP přenáší veškerá data v nešifrované podobě a neověřuje identitu komunikujících stran, proto byla vytvořena jeho rozšíření, které tyto funkce umožňují.

2.3.2. HTTPS HTTP přes TLS/SSL nebo také HTTP Secure rozšiřuje HTTP přenos o možnost ověření identity komunikujících stran a šifrování veškerých přenášených dat vložením zabezpečené komunikační vrstvy TLS/SSL mezi transportní a aplikační vrstvu TCP/IP modelu, na které HTTP pracuje. HTTPS je používáno během přístupu na webové stránky obsahující důvěrné informace, v internetovém bankovnictví a pro přístup do služeb, které vyžadují předávání citlivých údajů, 14

jako jsou přihlašovací jména, hesla, osobní údaje, čísla bankovních účtů nebo kreditních karet a hrozí riziko jejich zneužití v případě odposlechu třetí stranou. HTTPS server naslouchá požadavkům klientů standardně na portu TCP 443, zpravidla bývá zachována i možnost HTTP komunikace na portu TCP 80 pro statické webové stránky s veřejně dostupnými informacemi, které není nutné nijak zvlášť zabezpečovat. Teprve před přístupem k části webové stránky s citlivými údaji, přihlašovacím oknem do webové aplikace nebo před přenosem dat je uživatel přesměrován na zabezpečený HTTPS server (tuto roli může vykonávat stejný fyzický server zajišťující i běžný HTTP přístup, virtuální server i odlišný fyzický). Ověřování identity účastníků komunikace zajišťuje systém digitálních certifikátů. Jedná se o elektronický dokument, obsahující veškeré nezbytné údaje jednoznačně identifikující účastníka komunikace, vydaný důvěryhodnou nezávislou institucí – certifikační autoritou. Ta zajišťuje veškerou nezbytnou administrativu spojenou s jejich vydáváním a udržováním, zpracovává žádostí o vydání nových certifikátů, ověřuje správnost a platnost údajů, jež žadatel o digitální certifikát poskytl a provozuje služby, které umožní vzdálené elektronické ověřování identit komunikujících stran. Vydáním certifikátu tato instituce potvrzuje platnost údajů vyplněných v žádosti o jeho vydání, stanoví dobu platnosti (zpravidla bývají vydávány na jeden rok), připojí k němu sadu veřejného a privátního klíče, sloužící pro šifrování komunikace prostřednictvím TSL/SSL, a opatří jej vlastním digitálním podpisem pro možnost ověření instituce, která tento certifikát vydala. Certifikáty jsou distribuovány v podobě datových souborů. Správce serveru, hodlající umožnit klientům ověřit jeho identitu a šifrovat přenášená data, certifikát nainstaluje na svém HTTPS serveru a nakonfiguruje možnost komunikace využitím protokolů TSL/SSL. Připojení k HTTPS serveru, ověřování certifikátů a šifrovací metodu musí podporovat i klientská aplikace uživatele. Seznam používaných certifikačních autorit a podporu TSL/SSL nabízí implicitně většina současných webových prohlížečů. Před navázáním šifrovaného datového přenosu a výměnou citlivých dat (zadáním URL definující použití protokolu HTTPS) si aplikace vyžádá zaslání certifikátu, ověří jeho platnost u certifikační autority a zkontroluje, zda je cílový server opravdu zamýšlenou protistranou komunikace. Následně je mezi klientem a serverem automaticky vyjednán způsob šifrování (nejsilnější možný, podporovaný oběma stranami) a dojde k vytvoření dočasného šifrovacího klíče, jímž je veškerá následná komunikace šifrována. V případě vypršení platnosti certifikátu, nebo když cílový server neodpovídá údajům uvedeným v certifikátu, zobrazí aplikace varování, dle své konfigurace, a zabrání uživateli v další komunikaci se serverem nebo umožní pokračovat pouze po jeho výslovném souhlasu i přes varování (volně citováno z [12] – Co to je digitální certifikát).

15

Obr. 2—4 – Navazování HTTPS spojení Kontrola identity probíhá nejčastěji jen na straně serveru (klient si ověřuje protistranu, se kterou zamýšlí komunikovat), tento způsob bývá využíván nejčastěji, např. během komunikace s elektronickými obchody a službami vyžadujícími přenos citlivých údajů. V některých případech může být i vzájemné (obě strany ověřují identitu), to je využito v oblastech elektronického bankovnictví, jako rozšiřující služba zabezpečení, nebo při přístupu k firemním webovým serverům s interními informacemi. Správce takového serveru má možnost regulovat přístup důvěryhodných klientů, kterým umožní se k serveru připojit pouze po ověření jeho identity serverem na základě certifikátu. V tomto případě může certifikáty vygenerovat žádoucím uživatelům i sama firma, prostřednictvím specializované aplikace, budou ovšem sloužit k ověření identity jen na jejich serverech. Je též možné povolit i přístup vybraným uživatelům s certifikáty, které vydala důvěryhodná certifikační autorita. HTTPS zajišťuje pouze ověření identit a šifrování datového přenosu, samotné soubory s certifikáty a diskový prostor, kde jsou data po přenosu uložena u klienta i na serveru, je též nutné chránit a zamezit k nim přístup i proti jiným způsobům jejich získání, než je odposlechnutí během přenosu v TCP/IP síti.

3. Šifrování datových přenosů 3.1. Metody šifrování K šifrování přenášených dat zmíněnými protokoly je využíván šifrovací klíč. Jedná se o řetězec znaků (jeho délku a možné znaky stanoví šifrovací metoda), který je matematickou funkcí (šifrovací algoritmus) aplikován na sekvenci znaků určenou k bezpečnému přenosu, vznikne odlišná sekvence znaků, jež je přenesena přes veřejnou síť k adresátovi. Původní sekvenci je z ní možné získat pouze za podmínky znalosti šifrovacího klíče a dešifrovacího algoritmu (inverzní matematická funkce, aplikací klíče převede šifrovanou sekvenci znaků zpět na původní). S šifrovacím klíčem je možné pracovat několika způsoby, SSH, TSL a SSL využívají následující: 16

Šifrování pomocí privátního klíče – také symetrická kryptografie. K šifrování i dešifrování přenášených dat slouží jeden privátní klíč. Aby mohli oba účastnící komunikace symetrickou šifru použít, musí každá strana tento klíč vlastnit. Zde nastává problém, jak šifrovací klíč bezpečně předat protistraně, aniž by ho získala nepovolaná osoba. Šifrovat komunikaci je možné teprve po výměně šifrovacích klíčů, bezpečný datový kanál lze vytvořit, až když oba účastníci komunikace společný klíč znají. K výměně klíčů je nutné použít jiný bezpečný komunikační kanál. Ve firemním prostředí je možné např. osobní předání, to je ovšem nerealizovatelné při komunikaci ve veřejných TCP/IP sítích. Výhodou symetrického šifrování je relativní nenáročnost šifrovacích algoritmů na výpočetní výkon, tedy jeho rychlost i při šifrování velkých objemů dat. Slabinou právě výměna klíčů.

Obr. 3—1 – Symetrická kryptografie Šifrování pomocí veřejného klíče – neboli asymetrická kryptografie využívá dvou šifrovacích klíčů, nazývají se veřejný a privátní. Privátní klíč slouží k dešifrování zasílaných dat, veřejný k jejich zašifrování. Veřejný klíč je vytvořen z privátního, aplikací sledu matematických funkcí, tato operace je jednosměrná, privátní z něj nelze zpětně odvodit. Privátní klíč není nikdy předáván při komunikaci s protistranou, jeho vlastník jej má v bezpečné podobě uložený na svém počítači a musí k němu zamezit přístup dalším osobám. Pokud chce přijímat zašifrovaná data, sdělí odesílateli svůj veřejný klíč, který slouží k pouze k zašifrování. Data zašifrovaná jeho veřejným klíčem je možné dešifrovat pouze použitím odpovídajícího privátního klíče, může tak být bezpečně předáván i v nezabezpečených komunikačních kanálech. Tato metoda opravuje nedostatky předávání šifrovacího klíče u symetrické kryptografie, použité matematické operace jsou ale velmi náročné na výpočetní výkon počítače a při šifrování velkých objemů dat je tato metoda velmi zdlouhavá. Šifrování pomocí veřejného klíče využívá i elektronický podpis a systém digitálních certifikátů pro ověření identity účastníků komunikace (identita v certifikátu je svázána se sadou šifrovacích klíčů a certifikát potvrzuje, že vlastníkem privátního klíče je právě tento subjekt). Strana, která chce ověřit identitu příjemce komunikace, si vyžádá jeho veřejný klíč, kterým zašifruje libovolný řetězec znaků a odešle jej protistraně. Ta zprávu dešifruje a obsah vrátí v nezašifrované podobě odesílateli. Pokud se shoduje s původním zvoleným řetězcem znaků, je potvrzena identita adresáta, protože zpráva mohla být dešifrována pouze vlastníkem privátního klíče, který k této identitě náleží (volně citováno z [4] - Internet Security).

17

Obr. 3—2 – Asymetrická kryptografie Pro šifrování samotného přenosu citlivých dat je využívána protokoly SSH, TSL, SSL kombinace obou metod z důvodu úspory času (asymetrická kryptografie je bezpečnější, ale časově náročná). Všechny šifrovací protokoly vyžadují spolehlivý transportní protokol, nejčastěji TCP. UDP není možné použít. Účastníci komunikace si prostřednictvím asymetrického šifrování ověří identitu a vymění si jeden dočasný šifrovací klíč, určený pouze pro následující datový přenos. Přístup k němu mají jen oni dva a je předán také v zašifrované podobě. Veškerá následující komunikace je šifrována symetricky právě tímto dočasným klíčem. Tato hybridní metoda šifrování kombinuje výhody obou principů, bezpečnost výměny klíčů asymetrického šifrování a rychlost přenosu symetrického šifrování.

3.2. Dostupné technologie 3.2.1. SSH Zabezpečený komunikační protokol SSH využívají SFTP aplikace k autentizaci uživatelů, řízení přístupu a šifrování přenášených dat. K ověřování identit a šifrování používá metodu veřejného klíče. Správce SFTP serveru vygeneruje uživateli privátní a veřejný klíč, které mu bezpečným kanálem předá (osobní předání, poštovní zásilka), veřejný klíč je poté uložen v databázi FTPS serveru a přiřazen k identitě uživatele. V okamžiku přijetí požadavku na navázání spojení s klientem zašle server klientovi kontrolní zprávu šifrovanou jeho veřejným klíčem, klientská aplikace jí dešifruje párovým privátním klíčem a vrátí serveru. Shoduje-li se jejich obsah, klient je autorizován a je mu umožněna výměna dat s SFTP serverem. Další přenos už probíhá symetrickou šifrou s dočasným klíčem předaným také asynchronní metodou. SFTP server umožňuje i další způsoby autorizace, symetrické šifrování, u kterého ověření uživatele zajišťuje pouze uživatelské heslo, a vzdálené ověření, kdy si uživatel vygeneruje sadu privátního a veřejného klíče sám. Při prvním kontaktu se serverem mu sdělí svůj veřejný klíč, server jej přiřadí k identitě ve své databázi a další komunikaci s touto identitou umožní jen vlastníkovi zaslaného veřejného klíče. Zde je nutné zajistit, aby první kontakt proběhl opravdu s vybraným klientem, např. první přihlášení prostřednictvím dočasného hesla, sděleného bezpečným kanálem. Když autorizace uživatele proběhne, při dalších připojeních už není nutné zadávat uživatelské heslo, ověření automaticky zajišťují SFTP aplikace kontrolní zprávou šifrovanou veřejným klíčem. I když SFTP server umožňuje ověření jen uživatelským heslem, preferovanou metodou je sada veřejného a privátního klíče, sdělená klientovi jiným způsobem než elektronickým datovým přenosem. Stejným způsobem může i klient ověřovat identitu serveru, za předpokladu, že získá jeho veřejný klíč bezpečným kanálem. Klientská i serverová aplikace musí podporovat přenosový protokol SFTP a stejný šifrovací protokol, který k samotnému uskutečnění datového přenosu, ověřování identit a práci s klíči používá. Pro SFTP bývá nejčastěji používán šifrovací protokol SSH, v jeho aktuální verzi SSH-2, můžou být ovšem použity i jiné protokoly, a standardně je nabízena i podpora starších 18

verzí SSH z důvodů zpětné kompatibility s větším množstvím aplikací. Kromě ověření a šifrování zajišťuje SSH i kontrolu přenesených dat a upozornění na chybu v přenosu nebo neoprávněný zásah do komunikace (pozměnění datových paketů třetí stranou). To je řešeno metodou kontrolních součtů. Na sekvenci přenášených znaků je aplikován sled matematických operací, které vygenerují krátký řetězec znaků sloužící ke kontrole (kontrolní součet). Změna jediného bitu v kontrolovaném souboru znaků vyvolá i změnu kontrolního řetězce, algoritmus je navržený tak, aby každý vytvořený kontrolní součet byl unikátní a neopakoval se. Ten je přenesen spolu s daty, přijímací strana na data aplikuje stejný algoritmus a porovná nově vytvořený kontrolní řetězec se zaslaným. Pokud se liší, došlo k chybě přenosu nebo neoprávněnému zásahu a přijatá data jsou odlišná od odeslaných, mohlo též dojít k chybě v přenosu kontrolního součtu, v obou případech je však nutné přenos opakovat. Tato metoda kontroly se nazývá Message Integrity Codes a zajišťuje zachování integrity přenášených dat. Jejím rozšířením je Message Authentication Code, který kromě integrity zajišťuje i ověřování identity odesílatele (v algoritmu pro tvorbu kontrolního součtu je využit i jeho veřejný klíč), kontrolní řetězec je předáván v zašifrované podobě a dešifrováním tohoto řetězce privátním klíčem prokáže odesílatel svojí identitu. Neshodují-li se kontrolní řetězce, odesílatel není vlastníkem privátního klíče náležejícího k identitě nebo došlo k chybě/pozměnění přenosu.

3.2.2. TSL a SSL Šifrovací protokoly TSL a SSL využívá FTPS a HTTPS jako nadstavbu zabezpečující ověřování identity komunikujících stran, kontrolu a šifrování přenášených dat. Používají principy symetrické kryptografie pro šifrování datového toku a asymetrické pro ověřování, výměnu klíčů a kontrolu přenášených dat. Výměna klíčů a ověřování identit neprobíhá pouze mezi účastníky komunikace, ale je zajišťovaná třetí stranou, které důvěřují obě strany, certifikační autoritou. Identitu, která náleží k páru šifrovacích klíčů, určuje digitální certifikát. Údaje uvedené v certifikátů, formu a strukturu jejich zápisu stanovuje mezinárodní norma X.509. Povinné údaje, které musí každý certifikát obsahovat, jsou unikátní sériové číslo (slouží pro identifikaci certifikátu), informace o majiteli certifikátu, době, po kterou je platný, veřejný klíč (včetně algoritmu použitého k ověřování), informace o certifikační autoritě, jež ověřila platnost údajů v něm uvedených, a poskytuje služby umožňující jejich ověřování. Majitelem certifikátu může být firma, fyzická osoba i skupina osob (přístup k šifrovacím klíčům mají všichni její členové). Osobní certifikáty obsahují jméno a kontaktní údaje vlastníka certifikátu, firemní obsahují kromě jména a kontaktních údajů firmy i doménové názvy serverů, na kterých provozuje služby jako je FTPS, HTTPS a chce umožnit ověření své identity klientům. Certifikáty může vydávat i sama firma, když chce ověřovat před začátkem komunikace identitu svých klientů. Na serveru musí být v tomto případě nainstalována aplikace zajišťující generování certifikátů klientům, správu certifikátů a systém jejich ověřování. Tvorbu vlastních certifikátů může provádět i sám uživatel, prostřednictvím specializované aplikace, musí však zajistit, aby byl na cílovém serveru přijat (není ověřen certifikační autoritou), tento způsob je možný jen po předchozí dohodě s provozovatelem serveru. Serverové i klientské aplikace obsahují seznam a certifikáty běžně používaných důvěryhodných certifikačních autorit, u kterých je možné jimi vydané certifikáty ověřit, v aplikacích je možné zakázat přijímání certifikátů od určitých certifikačních autorit i rozšiřovat seznam o nové (např. v situaci, kdy uživatelům vydává certifikáty provozovatel serveru, jehož služby hodlají využívat).

19

TSL je nástupce protokolu SSL, rozšiřuje nabídku funkcí o podporu více šifrovacích algoritmů, šifrování kontrolních řetězců přenášených dat (pouze vlastníci klíčů mohou ověřit, zda přenos proběhl úspěšně) a umožňuje nešifrovanou i šifrovanou komunikaci na stejném síťovém portu bez dalšího směrování. SSL umožňuje pouze šifrovaný přenos na speciálním vyhrazeném portu. TSL je zpětně kompatibilní s protokolem SSL, během navazování šifrovaného přenosu je mezi klientskou a serverovou aplikací zvolen nejnovější šifrovací protokol, který obě strany podporují. Úroveň zabezpečení je v nejnovějších verzích SSL a TSL obdobná, TSL však nabízí více možností konfigurace a způsobů přenosu, je uznáván jako standard a rozšiřuje se počet aplikací a služeb, které jej podporují.

4. Rizika, typy útoků, možnosti zneužití Všechny zmíněné komunikační protokoly mají zabránit přístupu nepovolaných třetích stran k citlivým informacím, předávaným datovými přenosy v TCP/IP sítích. Jedná se však pouze o jeden ze stupňů ochrany, který dokáže nežádoucímu přístupu zabránit. Data je třeba chránit v místě jejich uložení u uživatele, pracovat s nimi a přenášet je v důvěryhodné aplikaci, zajistit proti odposlechnutí během přenosu veřejnou sítí, zabránit záměně identit komunikujících stran a bezpečně uložit v diskovém prostoru cílového serveru. Zde ovšem cesta dat nekončí, webová aplikace, se kterou uživatel komunikuje, může během jejich zpracování komunikovat s dalším webovým serverem i úplně jinou službou, např. uložení klientových dat do databáze SQL serveru. Bezpečnost těchto komunikačních kanálů mezi servery musí zajistit jejich provozovatelé, včetně diskových prostorů, kde jsou poté fyzicky uložena. Rizika mohou přicházet z veřejné i privátní sítě. Nejčastější typy útoků neoprávněnými osobami za účelem získání důvěrných informací jsou následující: Odposlech datového toku – v každém uzlovém bodu TCP/IP sítě, přes který jsou přenášené datové pakety směrovány, může dojít k jeho odposlechu specializovanou aplikací sledující síťový provoz bez vědomí účastníků komunikace. Využívají-li k přenosu běžný FTP nebo HTTP protokol, veškerá data jsou přenášena v nešifrované podobě jako běžný text, včetně přihlašovacích údajů, uživatelských jmen a hesel. Útočník analyzuje zachycené datové pakety a jejich rekonstrukcí může získat kopii přenášených souborů (v případě FTP) nebo citlivé informace obsažené v předávaných hypertextových dokumentech. Protokoly FTP a HTTP komunikují též přihlašovací jména a hesla k účtům na FTP serverech a ve webových aplikacích. Zachycením hesla může následně získat přístup k souborům a službám, které uživatel na cílovém serveru využívá. Nejčastějším cílem bývají čísla kreditních karet při přístupu do elektronických obchodů, hesla elektronického bankovnictví a přihlašovací údaje k FTP službám, kde uživatel přechovává soukromé soubory nebo jej využívá ke správě webové stránky na serveru hostitele.

20

Obr. 4—1 – Odposlech datového přenosu Tomuto typu útoku lze zabránit šifrováním datového přenosu využitím komunikačních protokolů SFTP, FTPS a HTTPS.K odposlechu datových paketů nemusí dojít jen ve veřejné síti, získá-li útočník přístup do privátní části uživatelovi sítě, může jednak přistupovat k citlivým informacím ve sdíleném diskovém prostoru jeho počítače a také sledovat veškerý síťový provoz. Síťové rozhraní běžně naslouchá jen datovým paketům, které jsou pro něj určené. Specializované aplikace umožňují tuto konfiguraci změnit a zachytit i datové pakety určené pro ostatní klienty sítě (v sítích, kde aktivní prvky, např. rozbočovač, rozesílají datové pakety všem klientům sítě). Zamezit přístupu nepovolaných osob do privátní je možné ochranou přístupových bodů, především u bezdrátových sítí, filtrováním MAC adres (unikátní identifikátory síťových rozhraní). Přistup do těchto sítí je tak umožněn jen vybraným uživatelům. Dále je nutné i v privátních sítích využívat služeb sdílení diskového prostoru chráněných heslem a využívat aktivní síťové prvky, které omezují všesměrovou komunikaci datových paketů a obsahují bezpečností moduly zabraňující napodobení MAC adres. K odposlechu datového přenosu může též dojít i v rámci uživatelova počítače, mezi síťovým rozhraním a komunikující aplikací. Podaří-li se útočníkovi nainstalovat do uživatelova operačního systému spyware, získá přístup k citlivým informacím ještě před jejich odesláním veřejnou sítí. Spyware je aplikace, která odesílá útočníkovi citlivé údaje na dálku, veřejnou sítí. Získává je odposloucháváním komunikace mezi aplikací a síťovým rozhraním, přímo z využívané aplikace nebo zachycením vstupu z klávesnice. Spyware bývá nejčastěji součástí zdarma šířeného softwaru. Je nainstalován současně s požadovanou aplikací bez vědomí uživatele. Chránit se je možné antispyware softwarem a instalací aplikací pouze z důvěryhodných zdrojů (volně citováno z [11] - Sniffing: Odposlech datové komunikace). Krádež identity – útočník se vydává za jednoho z účastníků komunikace. Získá-li přihlašovací jméno a heslo uživatele určité služby (FTP přístup k souborům, elektronické bankovnictví, jiná webová aplikace) může provádět stejné operace jako by byl sám uživatel. Může se též vydávat za provozovatele určité služby, např. kopií vzhledu webové stránky, kterou se uživatel přihlašuje do elektronického bankovnictví. Získané údaje poté použije pro vlastní prospěch u skutečného poskytovatele této služby k provádění platebních operací nebo krádeži dat. Na falešný server přivede uživatele podvržením URL odkazu, napodobením doménového názvu skutečného poskytovatele služby, přesměrováním komunikace bez vědomí uživatele zásahem do jeho operačního systému nebo využitím spywaru. Spyware v tomto případě modifikuje nastavení uživatelova webového prohlížeče nebo FTP klienta a zamění IP adresu poskytovatele služby za útočníkův server při překladu doménových jmen. Má-li přístup k lokálnímu disku uživatele, může též změnit nastavení v systémovém souboru hosts (operační 21

systém jej využívá k přiřazení doménových názvů k IP adresám, pro jejich překlad poté není vyžit DNS server, ale seznam v tomto souboru). Krádeži identity je možné se bránit jejich ověřováním metodou výměny veřejných šifrovacích klíčů a digitálními certifikáty. Soubory s digitálními certifikáty a sadu šifrovacích klíčů je nutné chránit i v místě jejich fyzického uložení dalším způsobem.

Obr. 4—2 – Záměna identit Modifikace datového toku – nebo také útok „Man in the middle”. Útočník v tomto případě přeruší komunikační kanál mezi klientem a serverem a naváže dvě nová spojení s oběma stranami. V datovém spojení s klientem se vydává za server, při spojení se serverem za klienta. Datové pakety, které si mezi sebou zasílají, odposlouchává, modifikuje i vkládá úplně nové, které ani jedna strana neodeslala. Tento typ útoku je možný, získá-li útočník přístup ke konfiguraci aktivního síťového prvku zajišťujícího směrování nebo uzlovému bodu TCP/IP sítě, přes který komunikace probíhá. Příchozí i odchozí komunikaci přesměruje na vlastní server, kde pak útok probíhá. Cílem modifikace datového toku je narušit proces ověřování identity mezi komunikujícími stranami pozměněním obsahu předávaných ověřovacích řetězců, případně donutit jednu stranu k přijetí podvrženého certifikátu. Útoku je možné zabránit využitím digitálních certifikátů, ověřovaných u důvěryhodné třetí strany (certifikační autority) a kontrolováním integrity přenášených datových paketů výměnou šifrovaných Message Authentication Codes, které kontrolují, zda nedošlo k jejich modifikaci.

Obr. 4—3 – „Man in the middle” Útoky na hesla – metoda spočívá v uhádnutí přístupových údajů uživatele k webové službě nebo zašifrovaným souborům. Využívá dva základní postupy. Slovníkový útok předpokládá, že uživatel zvolil takové heslo, které pro snadné zapamatování obsahuje jména, běžně používaná slova nebo veřejně známé kombinace čísel (rok narození). Často bývá také stejné jako přihlašovací jméno uživatele. Slovníky obsahují seznamy těchto slov a jejich často volených kombinací. V případě, že uživatel takové heslo používá, dojde k jeho odhalení ve velmi krátkém čase. Způsobem obrany je stanovení podmínky na délku hesla, použité znaky a nutnost využití speciálních znaků při jeho vytváření. Druhým postupem je využití útoku hrubou 22

silou. Zde jsou postupně zkoušeny všechny možné kombinace znaků, čísel a speciálních znaků (!, @, #, %, ^ …). Tento útok je v případě dlouhých hesel a využití speciálních znaků velmi časově a výpočetně náročný. Už vyzkoušení všech možných kombinací hesla, dlouhého alespoň 9 znaků, obsahujícího číslice, malá a velká písmena abecedy a běžně používané speciální znaky by se na současném počítači pohybovalo podle [15] – Lámání hesel, v řádu desítek let. Než by došlo k vyzkoušení všech kombinací, šifrovaná informace ztratí význam, nebo by došlo ke změně hesla pro přístup do webové služby (např. elektronické bankovnictví vyžaduje změnu hesla v pravidelném intervalu). Zkoušení delších hesel je tímto způsobem naprosto nemožné z důvodu vysokého množství možných permutací znaků. V konfiguraci serverových aplikací, používajících pro ověření uživatele heslo, lze těmto postupům zabránit omezením počtu neúspěšných pokusů o přihlášení a nastavením povinné časové prodlevy mezi pokusy. Útočníci zpravidla používají jiné metody, jako je odposlechnutí uživatelského hesla nebo krádež identity. Při útoku, jehož cílem je získání citlivých informací, bývá často používána kombinace zmíněných metod. Např. odposlechnutí nešifrovaného hesla FTP přístupu k webhostingu, pozměnění zdrojového kódu HTML souborů a přesměrování uživatelů na webový server útočníka, kde uživatel vyplní přihlašovací údaje do formuláře v domnění, že komunikuje se skutečným poskytovatelem služby. Zdaleka k největšímu množství krádeží dat a přístupových údajů dochází selháním lidského faktoru. Uživatelé používají nedostatečná hesla nebo stejné heslo pro více služeb, nevyužívají zabezpečené komunikační protokoly, instalují software z nedůvěryhodných zdrojů obsahující spyware, svěřují citlivé osobní informace provozovatelům nedůvěryhodných webových služeb, nezabezpečují své datové nosiče a důvěřují klamavým emailů, v nichž se odesílatel vydává za jiný subjekt, často tak sdělí citlivé informace útočníkovi sami. K úniku dat a přihlašovacích údajů může dojít i na straně provozovatele serveru, kdy je za něj zodpovědný zaměstnanec, mající přístup ke konfiguraci serveru a samotným datům, nebo je zpřístupní za úplatu třetí straně.

5. Serverové aplikace 5.1. Přehled Instalaci a konfiguraci vybraných aplikací budu realizovat ve virtuálním prostředí aplikace VMware Workstation. Vytvořím klientský a serverový virtuální počítač s IP adresami 192.168.2.60 pro server a 192.168.2.70 pro klienta. Na klienta nainstaluji operační systém Microsoft Windows XP, na serveru Microsoft Windows Server 2008 R2. Multiplatformní aplikace mívají obdobný postup konfigurace v každém operačním systému. Serverové a klientské aplikace zvolím na základě v současnosti nejčastěji používaného softwaru distribuovaného zdarma i s komerční licencí, který zajišťuje přenos zabezpečenými protokoly FTPS, SFTP a HTTPS. Serverové aplikace jsou dostupné i pro jiné operační systémy než MS Windows. FTP aplikací je nabízeno velké množství. Výběr zdarma šířených aplikací provedu na základě oblíbenosti aplikací mezi uživateli populárního datového úložiště serveru CNET. Přidám též jednoho zástupce komerční sféry Titan FTP server.

23

5—1 – Populární FTP aplikace, zdroj: CNET, dostupné z WWW: http://download.cnet.com/windows/ftp-software/ V oblasti nasazení webových serverů dominují dvě majoritní řešení. Zdarma nabízený webový server Apache nadace Apache Software Foundation a komerční produkt společnosti Microsoft IIS. V následujících kapitolách budu konfigurovat obě varianty.

5—2 – Podíl nasazených webových serverů, zdroj: NetCraft Web Survey, dostupné z WWW: http://news.netcraft.com/archives/2010/06/16/june-2010-web-server-survey.html

6. Postup instalace a konfigurace vybraných serverových aplikací 6.1. FTPS a SFTP 6.1.1. FileZilla FTP Server Instalaci FileZilla FTP Serveru zahajuji získáním instalačního balíčku pro platformu Microsoft Windows z webových stránek autora a spuštěním procesu instalace ve virtuálním počítači s operačním systémem Windows Server 2008.

24

Obr. 6—1 – Instalace komponent Během instalace zvolím potřebné komponenty (samotný FTP server a administrační rozhraní, které slouží k jeho lokální i vzdálené konfiguraci), umístění aplikačních dat v souborovém systému a definuji port, určený pro komunikaci s administrační aplikací. Způsob spouštění FTP serveru volím automatický, ihned po startu operačního systému.

Obr. 6—2 – Konfigurace administračního rozhraní Instalace je hotová a mohu přistoupit ke konfiguraci FTP serveru. Mým cílem je vytvořit dva vzorové uživatelské účty pro klienty, jeden bude využívat běžný protokol FTP a druhý šifrovaný přístup FTPS. FTPS klient využije, kromě šifrování datového přenosu, také možnosti ověření identity serveru prostřednictvím X.509 certifikátu. Spouštím administrační aplikaci, ve které vyplním síťovou adresu serveru, komunikační port určený během instalace a při dalších přihlášeních také heslo (první přihlášení probíhá bez hesla). Po navázání spojení mám přístup ke konfiguraci FTP serveru a monitorování jeho provozu.

25

Obr. 6—3 – Administrační rozhraní FTP serveru Základní nastavení zahrnuje komunikační porty, na kterých bude server naslouchat požadavkům klientů, mým cílem je umožnit klientům připojení prostřednictvím protokolů FTP i FTPS, definuji tedy port TCP 21 pro komunikaci protokolem FTP a port TCP 990 pro FTPS. Počet současně připojených uživatelů nechávám neomezený.

Obr. 6—4 – Konfigurace FTP V dalším kroku zamýšlím zabezpečit přístup k administračnímu rozhraní a zamezit nevyžádaným změnám v jeho konfiguraci. Nastavím přístupové heslo a omezím možné přístupy ke konfiguraci FTP serveru pouze na lokální přístup a přístup z druhého virtuálního počítače v síti (klienta). Server nyní přijímá pouze komunikaci s administračním rozhraním ze dvou přístupových bodů a moje identita je ověřována heslem.

26

Obr. 6—5 – Zabezpečení administračního rozhraní Dále přistupuji ke konfiguraci FTPS přístupu. Pro datové přenosy a přihlášení protokoly TSL/SSL vyhradím rozdílný síťový port od běžného FTP přenosu, TCP 990 pro snadné odlišení způsobu přístupu. Zakazuji též možnost nešifrované komunikace přes tento port, na uživateli bude šifrovaný přenos vyžadován (režim implicitní TSL/SSL).

Obr. 6—6 – Konfigurace FTPS Zde je nutné nainstalovat také digitální certifikát, sadu šifrovacích klíčů a definovat cesty k jejich umístění v souborovém systému lokálního počítače. FileZilla FTP Server umí pracovat se standardizovanými certifikáty X.509 vydanými certifikační autoritou, nabízí i možnost vytvářet vlastní. Uživatelé jsou v aplikaci FileZilla spravování na straně serveru, později s nimi budu muset komunikovat za účelem předání přihlašovacích údajů, ověření na základě vlastního certifikátu je v tomto případě dostatečné, protože jim zároveň mohu předat informace nezbytné pro identifikaci FTP serveru. Během tvorby vyplním povinné informace, které musí certifikát obsahovat, včetně doménového názvu nebo adresy serveru v síti. Uživateli budou sloužit pro kontrolu identity při přihlašování k tomuto serveru. Samotný datový soubor 27

s certifikátem opatřím heslem, které bude vyžadováno pro další manipulaci, toto heslo vyplním v konfiguraci certifikátu, aby s ním server mohl pracovat.

Obr. 6—7 – Tvorba vlastního certifikátu Posledním krokem konfigurace je vytvoření uživatelských účtů, přidělení přihlašovacích údajů a nastavení oprávnění manipulací se soubory na FTP serveru. Uživatele je možné zařadit do skupin a konfiguraci provádět hromadně pro celou skupinu. Vytvořím tedy dvě skupiny pro uživatele FTP a FTPS přístupu. Po uživatelích FTPS budu vyžadovat připojení prostřednictvím šifrovaného kanálu.

Obr. 6—8 – Tvorba skupin uživatelů Skupinám přiřadím oprávnění k manipulaci se soubory i adresáři v diskovém prostoru FTP serveru. Zároveň definuji diskový prostor, ke kterému budou moci prostřednictvím FTP a FTPS přistupovat. Sdílené adresáře je možné definovat na úrovni jednotlivých uživatelů i pro celou skupinu, v tomto případě umožním celé skupině přístup do adresáře s názvem odpovídajícím typu připojení. 28

Obr. 6—9 – Konfigurace práv skupin a diskového prostoru Nyní zbývá jen tvorba účtů pro jednotlivé uživatele a zařazení do správných skupin. Uživatele „klientftp“ zařazuji do skupiny FTP, veškerá oprávnění a sdílený diskový prostor je převzat z nastavení skupiny. Uživatele „klientftps“ zařazuji do druhé skupiny, na které je vyžadováno přihlašování a šifrování protokolem FTPS. Uživatelům vygeneruji bezpečná hesla specializovanou aplikací a předám jim je bezpečným kanálem současně s informacemi o serveru, které při prvním přihlášení ověří v certifikátu.

Obr. 6—10 – Tvorba uživatelských účtů Server je v tomto okamžiku plně funkční a umožňuje FTP přístup na adrese 192.168.2.60:21 a FTPS na 192.168.60:990. Uživatel tuto adresu vyplní ve svém FTP klientu společně s uživatelským jménem a heslem. FTPS klientům je zobrazen obsah certifikátu serveru a shodují-li se s informacemi předanými správcem, může jej přijmout a vyžívat šifrovaného přenosu protokolem TLS/SSL.

29

Obr. 6—11 – Kontrola certifikátu uživatelem

Obr. 6—12 – Datový přenos protokolem FTPS

6.1.2. Titan FTP Server Titan FTP Server je distribuován pod komerční licencí, využiji tedy 30-denní zkušební verzi, kterou autor nabízí před zakoupením plné licence. Podporované protokoly jsou FTP, SFTP i FTPS, nakonfiguruji tedy server pro možnost využití všech podporovaných možností. Instalační balíček obsahuje FTP server a klienta administračního rozhraní, aplikaci, která slouží k jeho lokální i vzdálené konfiguraci. Během instalace zvolím obě komponenty, definuji místo uložení aplikace v souborovém systému, port pro komunikaci s administračním rozhraním a vytvořím účet správce serveru zabezpečený heslem. Tím je instalace hotova, spouštím lokálně administračního klienta a připojuji se k FTP serveru za účelem provedení konfigurace požadovaných služeb.

30

Obr. 6—13 – Přihlášení k uživatelskému rozhraní Titan FTP Server Titan FTP server umožňuje spravovat více virtuálních serverů na jednom fyzickém počítači. Vytvořím tedy nový server, který bude obsluhovat požadavky klientů všech tří komunikačních protokolů. Pomocí průvodce vyplním jeho název, popis, síťovou adresu a vyhradím diskový prostor pro uživatelské účty, jejich data a správu certifikátů a šifrovacích klíčů. Zvolím též síťové rozhraní, které bude server využívat ke komunikaci s klienty, tedy virtuální síťovou kartu s adresou 192.168.2.60.

Obr. 6—14 – Tvorba nového serveru Dále zvolím protokoly, které mohou klienti vyžít pro komunikaci se serverem a přístup k diskovému prostoru. Volím všechny tři možnosti, FTP, SFTP i FTPS.

31

Obr. 6—15 – Komunikační protokoly Nový server je vytvořen a mohu přistoupit ke konfiguraci jednotlivých způsobů připojení. Komunikační kanály odliším pomocí síťových portů, na kterých bude probíhat pouze specifikovaný datový přenos. TCP 21 pro běžný FTP, TCP 990 pro FTPS. Na vyhrazeném portu FTPS chci umožnit pouze šifrovaný datový přenos, volím tedy režim implicitního TSL/SSL, který bude zabezpečené spojení na klientech vyžadovat. Definuji též port, kde bude komunikace protokolem FTPS probíhat.

Obr. 6—16 – Konfigurace FTPS Nainstaluji též X.509 certifikát, kterým budou uživatelé ověřovat identitu serveru. Opět je možné použít vlastní i certifikát vydaný certifikační autoritou. Vytvořím tedy certifikát pomocí průvodce Titan FTP Server aplikace, vyplním identifikační údaje serveru a opatřím jej heslem. V konfiguraci FTPS zvolím nově vytvořený certifikát a vyplním heslo, jímž je manipulace s certifikátem zabezpečena. 32

Obr. 6—17 – Tvorba certifikátu Pro komunikaci SFTP protokolem vyhradím port TCP 22. SFTP neumožňuje nešifrovaný způsob datového přenosu, je na klientech vyžadován automaticky. Zvolím ze seznamu podporované šifrovací algoritmy (musí je podporovat i SFTP klient uživatelů) a hash algoritmus, který bude generovat Message Authentication Codes, zajišťující integritu přenášených dat. Ověřování identit a šifrování výměny dočasného šifrovacího klíče zajišťuje sada veřejných a privátních klíčů. Hash otisk veřejného klíče je zaslán klientovi na začátku datového přenosu a je porovnám s otiskem, který mu sdělil správce serveru bezpečným kanálem.

Obr. 6—18 – Konfigurace SFTP Tvorbu a ověřování klíčů SFTP nezajišťuje třetí strana, ale správci serverů a samotní uživatelé. Vytvořím tedy pomocí průvodce sadu veřejného a privátního klíče, který bude server využívat. Zvolím algoritmus, jenž jej vytvoří, jeho délku, umístění na lokálním disku a heslo pro přístup k souboru, kde je uložen. Vytvořenou sadu klíčů poté zvolím pro použití při přenosech SFTP. 33

Obr. 6—19 – Tvorba šifrovacích klíčů serveru Posledním krokem je definování oblastí diskového prostoru pro data uživatelů a tvorba uživatelských účtů. Vytvořím tři sdílené adresáře, podle typu přístupu, který bude klient využívat. Pro běžný FTP, SFTP i FTPS. Přiřadím též uživatelská oprávnění na souborové operace, jež budou moci klienti v tomto prostoru realizovat.

Obr. 6—20 – Přiřazení sdíleného diskového prostoru Na závěr již jen vytvořím samotné uživatelské účty, přihlašovací hesla, rozřadím je do skupin a přidělím práva skupině k přístupu do vyhrazeného diskového prostoru. Mezi vybranými FTP servery podporuje Titan FTP největší množství komunikačních protokolů a způsobů ověřování identit. Nabízí také přehledné a detailní grafické uživatelské rozhraní.

34

Obr. 6—21 – Tvorba skupin a uživatelských účtů Zároveň s přihlašovacími údaji sdělím klientům využívajícím SFTP i otisk veřejného šifrovacího klíče serveru bezpečným kanálem. Při prvním přihlášení jej porovnají s klíčem, který server sdělí jejich FTP klientovi, pokud se shodují, identita serveru je ověřena.

Obr. 6—22 – Ověření identity serveru při SFTP spojení

6.1.3. Core FTP Server Core FTP Server podporuje běžný FTP, FTPS i SFTP. Jeho nejzajímavější funkcí je možnost ověřování identity uživatelů, na kterou se v této kapitole zaměřím. Po spuštění instalačního balíčku volím komponenty, které bude server využívat. Jedná se o podporu TLS/SSL pro protokol FTPS a SSH2 pro protokol SFTP.

Obr. 6—23 – Volba komponent Po dokončení instalace konfiguruji FTPS server, vyhrazuji pro něj určitý síťový port (TCP 990), vyhradím uživatelům diskový prostor a označuji volbu povinného šifrování na tomto 35

portu. Součástí konfigurace je i instalace vlastního certifikátu stejným způsobem jako v předchozí kapitole.

Obr. 6—24 – Konfigurace FTPS Při konfiguraci SFTP serveru, kromě vyhrazení síťového portu, diskového prostoru a omezení možností přenosu pouze na SFTP protokol, vybírám též možnost ověření uživatelů veřejným klíčem a umožňuji jim komunikaci se serverem pouze po jeho ověření.

Obr. 6—25 – Konfigurace SFTP Konfigurace je hotová, mohu pokračovat tvorbou uživatelských účtů. Součástí jejich vytváření bude i generování privátního a veřejné klíče, pomocí nichž je bude server ověřovat.

36

Obr. 6—26 – Tvorba uživatelského účtu Po přidělení uživatelského jména, hesla a oprávnění k operacím v diskovém prostoru serveru přistoupím ke generování sady šifrovacích klíčů pro uživatele. Využiji k tomu generátor obsažený v této aplikaci. Zvolím názvy souborů s jednotlivými klíči, místo jejich uložení, délku a šifrovací algoritmus. Datové soubory s klíči opatřím heslem, které bude vyžadováno při další manipulaci.

Obr. 6—27 – Generování sady šifrovacích klíčů Soubory s šifrovacími klíči předám bezpečným kanálem uživateli, který je nainstaluje ve svém SFTP klientu. Posledním krokem je přiřazení veřejného klíče k uživatelskému účtu klienta. Při navazování SFTP přenosu, je mu zaslána kontrolní zpráva šifrovaná jeho veřejným klíčem, podaří-li se jí SFTP klientu dešifrovat prokáže, že je vlastníkem párového privátního klíče a aplikace mu umožní přístup k SFTP serveru.

Obr. 6—28 – Přiřazení klíče k uživateli

37

6.2. HTTPS 6.2.1. Apache Webový server Apache standardně neobsahuje grafické uživatelské rozhraní jako ostatní aplikace. Jeho konfigurace probíhá změnou konfiguračních souborů *.conf v místě jejich uložení v instalačním adresáři web serveru. Existují však doplňkové aplikace, které umožňují spravovat web server přes vlastní grafické rozhraní. Instalaci zahajuji získáním instalačního balíčku Apache serveru z webu autora pro platformu Microsoft Windows. Ten spouštím na virtuálním počítači, budoucím webovém serveru. Během instalace zvolím nezbytné komponenty – web server a podporu knihovny OpenSSL (implementace TLS/SSL protokolů, distribuovaná zdarma pod veřejnou licencí), která je nezbytná pro funkci HTTPS serveru. Definuji též umístění instalace aplikační části web serveru. K tomuto serveru budu přistupovat prostřednictvím IP adresy z lokálního počítače, později jako klient z jiného počítače v síti. Jako doménový název serveru volím „localhost“, jedná se o využití standardního nastavení hosts souboru operačního systému, které zajistí překlad doménového názvu v URL http://localhost/ na IP adresu lokálního síťového rozhraní. Budu tak moci jednoduše ověřovat provedené změny konfigurace ve webovém prohlížeči.

Obr. 6—29 – Instalace Apache Instalace je hotova a nyní mohu přejít ke konfiguraci HTTP a HTTPS serveru. K tomu využiji zdarma dostupnou aplikaci ApacheConf, která umožňuje právě změnu konfiguračních souborů web serveru v grafickém prostředí. Prvním krokem je propojení aplikace ApacheConf s webovým serverem Apache. Nastavím použitou verzi Apache serveru, cestu k umístění konfiguračních souborů a volím vlastní název serveru (slouží pouze pro snadnou identifikaci v grafickém rozhraní aplikace).

38

Obr. 6—30 – Propojení Apache a ApacheConf aplikací Nyní mohu konfigurovat webový server prostřednictvím grafického rozhraní. Mým cílem je nakonfigurovat dva způsoby připojení využitím protokolů HTTP a HTTPS. Provoz bude probíhat na různých portech (standardně používaných TCP 80 pro HTTP, TCP 443 pro HTTPS), za účelem snadného odlišení použitého protokolu. Na lokálním disku vytvořím dva adresáře webhttp a webhttps, do každého umístím jednoduchý hypertextový dokument, a uživateli bude zobrazen dokument z adresáře podle typu přístupu. Konfigurace HTTP přístupu spočívá v nastavení portu, na kterém bude server naslouchat požadavkům klientů, příkazem „Listen“ a číslem portu (TCP 80), aplikace vloží tento řádek do odpovídajícího konfiguračního souboru httpd.conf. Dále definuji cesty k instalačnímu adresáři Apache serveru a umístění kořenového adresáře hypertextových dokumentů pro klienty HTTP. Nastavuji tedy cestu k adresáři webhttp, příkazem „DocumentRoot“.

Obr. 6—31 – Konfigurace HTTP Konfiguraci HTTPS přístupu provedu vložením následující sady příkazů do konfiguračního souboru serveru (httpd.conf), postup konfigurace vychází z dokumentu [13] Setting Up a Secure Apache 2 Server a technické dokumentace, která je součástí Apache web serveru: 39

Listen 192.168.2.60:443 – aktivuje naslouchání serveru na komunikačním portu HTTPS LoadModule ssl_module modules/mod_ssl.so – aktivuje podporu SSL modulu při startu serveru Dále je nutné definovat objekt VirtualHost, který umožní provozovat více kořenových adresářů s hypertextovými dokumenty na jednom fyzickém serveru, klienta do nich přesměruji definováním použitého komunikačního portu. - začátek objektu a volba přístupového kanálu SSLEngine on – aktivace modulu SSL, zvoleného během instalace DocumentRoot “C:/Apache2.2/htdocs/webhttps” – kořenový adresář hypertextových dokumentů pro HTTPS přístup SSLCertificateFile “C:/Apache2.2/conf/server.crt” – umístění souboru s vytvořeným certifikátem SSLCertificateKeyFile “C:/Apache2.2/conf/server.key” – umístění souboru s privátním klíčem serveru - ukončení objektu Konfigurace HTTPS přístupu je hotova, nyní musím vytvořit certifikát s veřejným klíčem serveru a datový soubor s privátním klíčem. Využiji k tomu OpenSSL modul instalovaný spolu s Apache web serverem. Jeho součástí je aplikace openssl.exe, která umožní generovat digitální certifikáty a šifrovací klíče. Tvorbu certifikátu budu provádět postupem, uvedeným v dokumentu [14] - How to create a self-signed SSL Certificate. Nejprve vygeneruji privátní klíč serveru, povinně musím vyplnit heslo k manipulaci se souborem klíčem a vhodně jej pojmenuji.

6—32 – Vygenerování privátního klíče serveru Dalším krokem je vytvoření nepodepsaného digitálního certifikátu X.509. Během jeho tvorby vyplním veškeré požadované informace o webovém serveru Apache a hlavně jeho síťovou adresu, podle které bude moci uživatel ověřit identitu serveru. Aplikace OpenSSL vygeneruje standardizovaný certifikát a veřejný klíč ze zadaného privátního klíče. Privátní klíč je uložen v souboru server.key, certifikát server.crt.

40

6—33 – Vytvoření nepodepsaného certifikátu Volitelným krokem tvorby certifikátu je odstranění přístupového hesla k souboru s privátním klíčem. Je-li ponecháno, zvyšuje se úroveň zabezpečení přístupu k privátnímu klíči, ale Apache server poté vyžaduje jeho zadání při každém spuštění. Vyplňování hesla zdržuje při konfiguraci serveru, kdy dochází k častým změnám konfiguračních souborů a restartům serveru. V případě, že je server již nakonfigurován, je vhodné heslo ponechat.

6—34 – Odstranění zabezpečení certifikátu heslem Vytvořený certifikát je nyní možné odeslat k ověření certifikační autoritou. Pro účely testování konfigurace serveru je možné si též certifikát sám podepsat. Vlastní podpis certifikátu provedu zadáním odpovídajícího příkazu aplikaci OpenSSL. Posledním krokem je přesunutí certifikátu a privátního klíče do vyhrazeného adresáře Apache serveru a nastavení cest k těmto souborům

6—35 – Podpis digitálního cerifikátu Nyní je konfigurace serveru kompletní a klientům HTTP i HTTPS je zobrazován hypertextový dokument z jiného adresáře. Pro aplikaci každé změny v konfiguračních souborech je nutný restart celého Apache serveru.

Obr. 6—36 – Apache HTTP Klientovi HTTPS přístupu zobrazí webový prohlížeč varování, že jde o certifikát podepsaný serverem a zobrazí informace, které jsem vyplnil při vytváření certifikátu. 41

Obr. 6—37 – Apache HTTPS

6.2.2. Microsoft IIS Internet Information Services je webový server, který nabízí společnost Microsoft jako součást operačního systému Windows 2008 Server R2. Konfigurace probíhá v grafickém rozhraní operačního systému a nativně podporuje i TLS/SSL šifrování. Nejprve musím ve správě serveru přidat novou roli (typ služby, který bude zajišťovat) – webový server IIS. Průvodce zvolí veškeré nezbytné komponenty pro vykonávání této role a provede instalaci.

Obr. 6—38 – Přidání nové role serveru Ke konfiguraci webového serveru IIS využiji aplikaci IIS Manager nainstalovaný společně s webovým serverem. Mým záměrem je umožnit klientům komunikaci s webovým serverem protokoly HTTP a HTTPS po standardních portech. Vytvořím dva adresáře (webhttp, webhttps), podle typu přístupu, a umístím do nich jednoduchou webovou stránku, která bude klientovi zobrazena.

42

Obr. 6—39 – IIS Manager V IIS Manageru zvolím vytvoření nové webové stránky a v zobrazené kartě nakonfiguruji HTTP přístup. Vyplním jméno webové stránky pro jejich pozdější snadné rozlišení, uvedu cestu k místu jejich uložení na webovém serveru a definuji směrování všech příchozích požadavků protokolem HTTP na port TCP 80 do kořenového adresáře této webové stránky, aby byl při přístupu uživateli zobrazen odpovídající hypertextový dokument.

Obr. 6—40 – Konfigurace HTTP přístupu Součástí procesu konfigurace HTTPS je i instalace certifikátu na webový server, který uživatelům umožní ověřování jeho identity. Microsoft IIS umožňuje přímé zaslání požadavku o vydání digitálního certifikátu, import již získaného a tvorbu vlastního. Vytvořím vlastní certifikát, vyplním informace o serveru a přístupové heslo k souboru s certifikátem.

Obr. 6—41 – Instalace certifikátu 43

Nyní mohu přistoupit ke konfiguraci HTTPS přístupu. Vytvořím novou organizační jednotku, vhodně ji pojmenuji pro snadné rozlišení od ostatních. Jako kořenový adresář, kam bude uživatel při HTTPS přístupu přesměrován, volím odpovídající webhttps. Protokolu HTTPS vyhrazuji síťový port TCP 443, veškerá komunikace s tímto portem bude přesměrována na šifrovaný datový kanál. Vybírám též certifikát serveru, který bude využit pro ověření identity a šifrování protokolem HTTPS.

Obr. 6—42 – Konfigurace HTTPS Obsah hypertextového dokumentu v adresáři webhttps je určen pouze k šifrovanému přenosu, na závěr tedy zakážu možnost nešifrovaného datového spojení s portem TCP 443, HTTPS bude po uživatelích vyžadován.

Obr. 6—43 – Vynucení použití šifrování Konfigurace je hotova a klienti se mohou přihlašovat prostřednictvím HTTP i HTTPS k webovému serveru využitím URL s IP adresou serveru. Port je webovým prohlížečem zvolen automaticky podle definice protokolu v URL (výhoda využívání standardních portů služeb při konfiguraci serveru).

44

Obr. 6—44 – HTTP přístup Klientovi, který se přihlašuje protokolem HTTPS, je zobrazena odlišná webová stránka a webový prohlížeč ho upozorní na vytvoření šifrovaného komunikačního kanálu a existenci digitálního certifikátu. Pokud údajům obsaženým v certifikátu důvěřuje, může pokračovat v přístupu na webový server.

Obr. 6—45 – HTTPS přístup Microsoft IIS nenabízí tak rozsáhlé možnosti konfigurace jako web server Apache, při dostatečné znalosti jeho dokumentace, ale jeho konfigurace je nesrovnatelně uživatelsky přívětivější a rychlejší.

7. Alternativní možnosti konfigurace serverových aplikací Aktivní/pasivní přenos FTP a FTPS – možné definovat v konfiguraci FTP serveru, podle místní síťové infrastruktury. Lze vynutit použití pouze jednoho způsobu komunikace se serverem nebo obou současně, volba je pak na uživateli. V zájmu provozovatele serveru je umožnit přístup ke službám, co nejsnazší cestou, optimálně s možností volby. Správa uživatelů – některé serverové aplikace (Titan FTP Server, Microsoft Windows IIS) umožňují propojení správy uživatelů se síťovou doménou a systémem Active Directory Windows Server. Uživatelské účty jsou poté spravovány centrálně v jedné aplikace a nevznikají kopie účtů ve zvláštním sytému FTPS a HTTPS serveru, který je třeba zvlášť spravovat. V sítích, kde je síť spravována doménovým řadičem, je propojení nejvýhodnější formou správy uživatelů. Vzájemné ověřování identit a řízení přístupu – aplikace jako je Cute FTP klient, Titan FTP server nebo Microsoft IIS umožňují nejen ověření identity serveru klientem, ale i opačný proces. V tomto případě musí být klientům vygenerován digitální certifikát (mohou si jej 45

opatřit i sami) nebo sada privátních a veřejných klíčů (SFTP). Certifikát nebo veřejný šifrovací klíč klienta je zařazen do seznamu ověřených v konfiguraci serveru a přístup je možné omezit jen na vlastníky certifikátů a klíčů. Vynucení použití šifrovaného komunikačního kanálu – většina serverových aplikací obsahuje metody pro vynucení zabezpečené šifrované komunikace. Uživatelům je pak přístup nešifrovaným protokolem úplně znemožněn. Zabezpečené i nezabezpečené datové přenosy je možné u některých komunikačních protokolů provozovat na stejném síťovém portu. Pro snadné rozlišení komunikace bývá vhodné definovat každému komunikačnímu protokolu odlišný port. Toto rozdělení zpřehlední komunikaci mezi fyzickými a virtuálními servery. Přijímání certifikátů, podepsaných pouze certifikačními autoritami – konfigurace každé FTPS a HTTPS aplikace, serverové i klientské obsahuje seznam důvěryhodných certifikačních autorit. Je možné přidat certifikát webového serveru jako důvěryhodnou autoritu. Zabezpečuje-li tento server přístup ke svým službám uživatelskými certifikáty, které podepisuje svým digitálním podpisem, mohou se pak uživatelé ověřovat i svými osobními certifikáty navzájem na adrese ověřovací služby serveru.

8. Klientské aplikace 8.1. Přehled Klientských aplikací je k výběru mnoho. Opět zvolím uživateli oblíbené FTP aplikace serveru CNET, rozšířeného správce souborů s možností FTP/FTPS komunikace a dva zástupce webových prohlížečů pro HTTPS přístup.

9. Konfigurace vybraných klientských aplikací 9.1. FTPS a SFTP 9.1.1. TotalCommander Správce souborů TotalCommander nativně podporuje pouze protokol FTP. Je ovšem možné nainstalovat knihovnu OpenSSL (veřejná implementace šifrovacích protokolů) a chybějící funkci doplnit. Obsahuje správce připojení s možností uložení nastavení relace.

Obr. 9—1 – Konfigurace Total Commander FTP/FTPS klienta 46

9.1.2. FileZilla Zdarma dostupný multiplatformní klient. Podporuje všechny šifrovací protokoly, SFTP i FTPS. Použitý komunikační protokol se zvolí během konfigurace připojení k FTP serveru, spolu se zadáním uživatelského jména a hesla.

Obr. 9—2 – Konfigurace FileZilla FTP/FTPS/SFTP klienta

9.1.3. Cute FTP Pokročilý FTP, SFTP i FTPS klient. Oproti předchozím aplikacím podporuje i ověřování na straně klienta využitím osobního certifikátu při TSL/SSL spojení i ověřování párem šifrovacích klíčů při použití SFTP. Mezi zvolenými aplikacemi nabízí podporu největšího množství komunikačních protokolů a způsobů ověřování identit.

Obr. 9—3 – Konfigurace Cute FTP klienta V konfiguraci SSH2 protokolu je nutné definovat cestu k datovým souborům se sadou klíčů a přístupové heslo pro manipulaci s nimi. Veřejný klíč v tomto případě musí být asociován s jeho účtem na SFTP serveru, který jej poté přijme.

47

Obr. 9—4 – Správa veřejných klíčů

9.2. HTTPS 9.2.1. Internet Explorer Webový prohlížeč v OS Windows nativně podporuje komunikaci protokolem HTTPS. V nastavení zabezpečení lze spravovat seznam důvěryhodných certifikačních autorit i importovat osobní certifikáty pro ověření serverem. Komunikace HTTPS protokolem je zahájena zadáním URL začínající ftps://.

Obr. 9—5 – Správa certifikátů v IE

9.2.2. Opera Rozšířený webový prohlížeč Opera také podporuje ověřování a šifrování na základě digitálních certifikátů obou stran komunikace. Umí pracovat s novějším protokolem TSL i starším SSL. Přechod do HTTPS režimu uživatel provede zadáním URL začínající ftps://.

48

Obr. 9—6 – Správa certifikátů ve webovém prohlížeči Opera

10. Závěr Úkolem této bakalářské práce bylo prozkoumat současné technologie a softwarová řešení zajišťující bezpečný přenos dat. Z těchto produktů vybrat reprezentativní vzorek, provést instalaci, prozkoumat a analyzovat různé možnosti konfigurace. Tyto cíle jsem postupně plnil v jednotlivých kapitolách tvorbou bakalářské práce a dokumentováním postupu. V úvodu jsem vymezil důvody proč je nutné datové přenosy šifrovat a proč by zabezpečení dat měla být věnovaná zvýšená pozornost. Během první kapitoly jsem se věnoval vysvětlení základních principů, protokolů a zařízení, které zprostředkovávají výměnu dat v TCP/IP sítích. Následoval rozbor aplikačních protokolů, které zajišťují datové přenosy za účelem poskytování určitých služeb uživatelům, zejména přenos souborů ve veřejných sítích a předávání informaci prostřednictvím hypertextových dokumentů. Analyzoval jsem běžně používané komunikační protokoly, nejčastěji bez možnosti ochrany dat uživatele, a hledal k nim zabezpečené alternativy, nadstavby a rozšíření. Při vypracování těchto kapitol jsem často narážel na nedostatek literatury v českém jazyce, podklady pro jejich zpracování jsem musel hledat v zahraniční literatuře, nejčastěji v angličtině. V třetí kapitole jsem rozebral a vysvětlil funkci bezpečných komunikačních protokolů, zkoumal typy šifrovacích algoritmů, základní principy kryptografie a způsoby nasazení těchto metod v reálných aplikacích. Během čtvrté kapitoly jsem se zabýval riziky, která uživatelům při komunikaci v sítích hrozí, nejčastějšími metodami krádeží dát, využitím dezinformací k zmatení uživatele a krádežím identit. Dospěl jsem k překvapivému závěru, že největší hrozba nepřichází během datových přenosů, ale vlivem neznalosti nebo nezodpovědnosti samotných uživatelů, kteří často sdělí citlivé informace nedůvěryhodným osobám sami. Při samotné instalaci a konfiguraci rozšířených softwarových produktů jsem měl možnost se blíže seznámit s prostředím operačního systému Microsoft Windows Server 2008 a procesy, které zprostředkovávají služby, se kterými jsem se dosud běžně setkával jen z pohledu klienta. U každého softwarového produktu jsem musel nastudovat postup a možnosti konfiguraci, aby spolehlivě zajišťoval zabezpečeného datové přenosy a ověřování identity uživatelů. Mezi produkty nabízenými zdarma a pod komerční licencí jsem pozoroval výrazné rozdíly v možných alternativách konfigurace a podporovaných síťových protokolech. Komerční produkty zpravidla nabízely širší škálu podporovaných technologií a především překonávaly zdarma nabízený software v oblasti uživatelské přívětivosti. Konfigurace do požadovaného 49

stavu, která ve volně šiřitelné aplikaci zabere i několik desítek minut a vyžaduje studium dokumentace, je možné realizovat s vyspělým uživatelským rozhraním jen prostřednictvím informací předaných správci serveru v aplikačním okně za nesrovnatelně kratší dobu. V průběhu konfigurace jednotlivých produktů jsem sledoval a dokumentoval možné způsoby konfigurace, které jsem shrnul do několika bodů v závěru kapitoly. Vycházel jsem přitom z teoretických podkladů, které byly součástí první části bakalářské práce. Zabezpečení datových přenosů je velmi významný obor, který s přesunem služeb na internet, nabývá na stále větší důležitosti. Doufám, že jsem v této bakalářské práci, dostatečně srozumitelným způsobem přiblížil čtenáři problematiku způsobů ochrany dat, technologické zázemí, poskytl bezpečnostní doporučení, jak se bránit útokům na citlivé informace a nabídl zhodnocení funkcí vybraných softwarových řešení, zároveň s dostatečným návodem pro konfiguraci na vlastním FTP nebo webovém serveru.

11. Použité zdroje [1]

CASAD, Joe. Sams Teach Yourself TCP/IP in 24 Hours, 3rd Edition. Sams, 2004. 480 s. ISBN-10: 0-672-32565-9.

[2]

BLANK, Andrew G. TCP/IP Foundations, 1st Edition. Sybex, 2004. 304 s. ISBN-10: 0782-14370-9. Kapitoly o vrstvách TCP/IP modelu, s.27-65.

[3]

VACCA, John R. Practical Internet Security. Springer, 2006. 557 s. ISBN-10: 0-38740533-X. Kapitoly Basic Security Issues a Real Threats that Impact Security, s. 22-46

[4]

RHEE, Man Young. Internet Security: Cryptographic Principles, Algorithms and Protocols. Wiley, 2003. 424 s. ISBN-10: 0-470-85285-2. S. 57-240.

[5]

Chromý, Jan, Ph.D. Elektronické podnikání. 2. přepracováné vyd. Praha : VŠH, 2007. 108 s. ISBN 978-80-86578-59-0. Kapitola Zabezpečení elektronického podikání, s. 6781.

[6]

SHIFLETT, Chris. HTTP Developer's Handbook. Sams, 2003. 312 s. ISBN-10: 0-67232454-7. Kapitola Security, s. 189-250.

[7]

RIBAK, Jay. Slacksite.com [online]. [cit. 2011-08-13]. Active FTP vs. Passive FTP, a Definitive Explanation. Dostupné z WWW: .

[8]

POMAZAL, Jiří. Www.flops.cz *online]. 6.11.2010 [cit. 2011-08-11]. Jak zabezpečit přístup k hostingu: FTPS, SFTP, SSH?. Dostupné z WWW: .

[9]

KLOKAN, Petr. Www.root.cz [online]. 15.5.2000 [cit. 2011-08-15]. SSH a SCP pro Windows a zadarmo. Dostupné z WWW: .

[10]

BERGFELD, Carlos. Www.techsoup.org [online]. 28.8.2009 [cit. 2011-08-14]. An Introduction to Transport Layer Security. Dostupné z WWW: .

[11]

OBR, Jiří. Www.itbiz.cz *online+. 6.3.2009 *cit. 2011-08-14]. Sniffing: Odposlech datové komunikace. Dostupné z WWW: . 50

[12]

DOLEŽAL, Dušan. Interval.cz *online]. 21.3.2003 [cit. 2011-08-15]. Co to je digitální certifikát. Dostupné z WWW: .

[13]

LOPEZ, Daniel. Www.informit.com [online]. 29.11.2002 [cit. 2011-08-14]. Setting Up a Secure Apache 2 Server. Dostupné z WWW: .

[14]

Akadia. Www.akadia.com [online]. a [cit. 2011-08-22]. How to create a self-signed SSL Certificate. Dostupné z WWW: .

[15]

ČERMÁK, Miroslav. Www.cleverandsmart.cz *online+. [cit. 2011-08-12]. Lámání hesel. Dostupné z WWW: .

[16]

KOTLAŘÍK, Jan, Bc. www.spsbv.cz [online]. [cit. 2011-08-15]. IPSec. Dostupné z WWW: . Kapitoly SSL a TSL.

51