Možnosti šifrované komunikace v prostředí MS Windows 7

Rozměr: px
Začít zobrazení ze stránky:

Download "Možnosti šifrované komunikace v prostředí MS Windows 7"

Transkript

1 MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY Možnosti šifrované komunikace v prostředí MS Windows 7 BAKALÁŘSKÁ PRÁCE Stanislav Špaček Brno, jaro 2014

2 Prohlášení Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal a nebo z nich čerpal, v práci cituji s uvedením úplného odkazu na příslušný zdroj.

3 Poděkování Tímto bych chtěl poděkovat RNDr. Marku Kumpoštovi, PhD. za vedení mé bakalářské práce. Zároveň děkuji Mgr. Karolovi Kubandovi za jeho rady, čas věnovaný konzultacím a pomoci při vypracování praktické části.

4 Shrnutí Cílem práce je prozkoumání, porovnání a doporučení možností šifrovaného VPN spojení pomocí protokolů nativně podporovaných operačním systémem Microsoft Windows 7. První část práce se zabývá autentizačními a kryptografickými algoritmy, nezbytnými k ustavení zabezpečeného spojení k privátní síti. Druhá část se podrobněji věnuje popisu VPN protokolů z hlediska zabezpečení, průchodnosti přenosovou sítí a míře podpory na zařízeních s odlišným operačním systémem. Třetí a poslední část práce je pak věnována konfiguraci serveru s operačním systémem FreeBSD tak, aby bylo možné připojit se k němu postupně pomocí všech VPN protokolů podporovaných ve Windows 7. Annotation The aim of this bachelor's thesis is examination, comparation and recommendation of a VPN connection using protocols natively supported by operating system Microsoft Windows 7. The first part of this thesis deals with authentication and cryptographic algorithms necessary to establish a secure connection to a private network. The second part is focused on the description of VPN protocols in terms of security, throughpuu of the interlaced network and the level of support on devices with an operating system different from Windows 7. The third and final part is devoted to configuration of a server running FreeBSD so that it can be connected to by a client, using all VPN protocols supported by Windows 7.

5 Klíčová slova autentizace, FreeBSD, IKEv2, L2TP, PPTP, SSTP, šifrování, VPN, Windows 7 Keywords authentication, encryption, FreeBSD, IKEv2, L2TP, PPTP, SSTP, VPN, Windows 7

6 Obsah Úvod Autentizační a šifrovací protokoly Autentizační protokoly Password Authentication Protocol Microsoft Challenge-Handshake Authentication Protocol Microsoft Challenge-Handshake Authentication Protocol v Internet Key Exchange v Šifrovací protokoly Microsoft Point-To-Point Encryption Protocol IP Security Secure Socket Layer/ Transport Layer Security VPN protokoly podporované Windows PPTP, Point-to-Point Tunneling Protocol L2TP, Layer 2 Tunneling Protocol SSTP, Secure Socket Tunneling Protocol IKEv2, Internet Key Exchange v Srovnání VPN protokolů Konfigurace serveru a klienta PPTP Server Klient Výsledek L2TP Server Klient Výsledek SSTP Server Klient Výsledek IKEv Server

7 3.4.2 Klient Výsledek Závěr Slovník zkratek Literatura a zdroje Příloha A, Konfigurační soubory PPTP Příloha B, Konfigurační soubory L2TP Příloha C, Konfigurační soubory SSTP Příloha D, Konfigurační soubory IKEv

8 Úvod Virtuální privátní síť, neboli VPN, nalézá v současné době mnoho různých využití. Soukromé, kde může sloužit pro vzdálený přístup do domácí sítě z jakéhokoli místa s přístupem k Internetu, i komerční. V komerční sféře značně zjednodušuje práci ve chvíli, kdy je potřeba zabezpečená komunikace mezi více různými pobočkami jedné společnosti. Vytvoření virtuální sítě v tomto případě poskytuje alternativu k položení fyzické sítě mezi pobočkami, což je řešení jak finančně, tak administrativně náročné a mnohdy úplně nemožné. Správně konfigurovaná virtuální privátní síť by měla být ekvivalentní lokální síti. Měla by umožňovat využití veškerých dat, zařízení a jiných služeb k ní připojených bez ohledu na to, kde se fyzicky nachází. V případě přístupu ke zdroji ve stejném fyzickém segmentu virtuální sítě probíhá komunikace stejně jako by probíhala po síti místní. Pokud je ovšem vyžadován přístup ke zdroji v jiném segmentu, musí se server vypořádat s přenosem soukromých dat přes veřejně dostupnou síť. Během něj je prioritou zajištění autentizace a dostatečné úrovně zašifrování přenosu při zachování co nejvyšší přenosové rychlosti tak, aby byla pokud možno zachována iluze přímého lokálního spojení. Práce se věnuje využití virtuálních privátních sítí v prostředí Windows 7, s nímž se lze na uživatelských zařízeních setkat nejčastěji. Tento operační systém funkčně nahradil oblíbený systém Windows XP, jehož podpora skončila v dubnu Protože Windows 8 zatím nepřináší natolik zásadní inovace, aby se k němu vyplatilo přejít soukromým uživatelům a firmám, zůstává systém Windows 7 nejpoužívanějším operačním systémem na trhu. Oproti tomu v komerční sféře se lze stále častěji setkat s využitím open-source softwaru, který není zatížen žádnými licenčními poplatky. V oblasti operačních systémů jsou často využity systémy postavené na jádru Unix, jako například FreeBSD. Praktická část této práce počítá právě s využitím systému FreeBSD jako VPN serveru. První a druhá kapitola práce se zabývá VPN protokoly z teoretického hlediska. Autentizační a šifrovací algoritmy popsané v první kapitole zajišťují autenticitu, integritu a důvěrnost dat během jejich přenosu veřejnou sítí. Bez těchto vlastností by existence VPN postrádala smyslu a proto mají pro její funkci zásadní význam. Při popisu algoritmů je věnována pozornost jejich již známým zranitelným místům a slabinám vůči některým typům útoků. Druhá kapitola pak obsahuje popis protokolů pro ustavení virtuální privátní sítě dostupných ve Windows 7. Zabývá se jimi z hlediska využití autentizačních a šifrovacích algoritmů, zmíněných v první kapitole, a rozebírá vlastnosti přenosové sítě, vyžadované pro jejich provoz. Třetí kapitola navazuje na předchozí dvě předvedením VPN protokolů v praxi. Obsahuje návody na konfiguraci serveru založeného na operačním systému FreeBSD tak, aby bylo možné připojit se k němu ze vzdálených klientských Windows 7 počítačů. Postup je vždy rozdělen na části konfigurace serveru, konfigurace klienta a na část dosaženého výsledku. Poslední jmenovaná část hodnotí vždy náročnost zprovoznění protokolu a případné nedostatky vzniklé chybějící dokumentací či špatnou kompatibilitou. Závěr práce shrnuje teoretické vlastnosti protokolů a konfrontuje je s výsledky dosaženými při provozu v praktické části. Obsahuje zhodnocení protokolů na základě jejich sledovaných vlastností a doporučení odpovídajícího řešení pro různé typy VPN. 3

9 Téma této bakalářské práce bylo vypsáno ve spolupráci s firmou Trusted Network Solutions, která se zabývá poradenstvím v oblasti bezpečnosti síťových spojení a vývojem softwaru zajišťujícího odolnost proti útokům zvenčí pro firemní sítě i jednotlivé uživatele. 4

10 1. Autentizační a šifrovací protokoly Pro správnou interpretaci všech bezpečnostních vlastností a funkcí, které musí být součástí každého VPN protokolu, se první kapitola věnuje autentizaci a šifrování. Různé protokoly VPN totiž podporují odlišné bezpečnostní algoritmy a jejich pochopení značně ulehčí porozumění problematice ustavení VPN spojení. Všechny následující bezpečnostní protokoly jsou součástí některého protokolu VPN. 1.1 Autentizační protokoly Protokoly náležící do této kapitoly zajišťují ověření identity účastníků zabezpečeného spojení. Často je také jejich výstupem klíč, od kterého se odvozují podřazené klíče k pozdějšímu zašifrování komunikace. V případě neprovedení procesu autentizace by se za klienta s povolením přístupu do sítě mohl vydávat kdokoliv, což by de facto zničilo koncept privátní sítě. Protože řada útoků cílí právě na přisvojení si identity uživatele s oprávněním přístupu jako na cíl jednodušší, než přímé prolamování šifry spojení, neměl by být výběr autentizačního protokolu nikterak podceněn. Následující výčet představuje protokoly obsažené ve vestavěném VPN klientském softwaru Windows 7. Protože není cílem této práce podrobně se věnovat autentizačním algoritmům, jejich popis se omezuje na postup samotné autentizace a zmínění zranitelností vůči různým typům útoku. Podrobnější informace lze získat v některé z dostupných publikací [1] Password Authentication Protocol Základní verze autentizačního algoritmu, kterou je možné použít v protokolech založených na PPP, jako PPTP, L2TP a SSTP. Poskytuje pouze tu nejslabší formu ověření identity, kdy klient odesílá své identifikační údaje přenosovou sítí jako čistý, nijak nešifrovaný, text [2]. V prvním kroku autentizace klient pošle serveru žádost o spojení obsahující své jméno a heslo. Server tyto údaje ověří a odpoví v druhém kroku potvrzením či zamítnutím spojení. Na první pohled viditelnou slabinou takového postupu je možnost přečtení všech přihlašovacích údajů z odchyceného paketu klienta. Útočníkovi pak již nic nebrání tyto údaje zneužít a převzít identitu a oprávnění postiženého uživatele. Jedinou výhodou protokolu jsou snad jen zanedbatelné nároky na výpočetní výkon. Využití se omezuje na situace, kdy není dostupné řešení ve formě jiného protokolu Microsoft Challenge-Handshake Authentication Protocol Tento protokol byl vydán Microsoftem jako náhrada předchozího PAP v situacích vyžadujících určitou míru jistoty o totožnosti autentizovaného. Princip ověření spočívá v systému výzva-odpověď (challenge-response) [3]. Poskytuje autentizaci klient-server pro síťové služby systémů Microsoft Windows, mezi které patří i spojení PPTP, L2TP a SSTP. Vznikl modifikací algoritmu CHAP a používá velmi podobnou strukturu zpráv: 5

11 Obrázek 1 Schéma operací protokolu MsCHAP Každá MsCHAP zpráva má rozměr přesně jednoho PPP paketu a obsahuje následující položky: typ zprávy, identifikátor, délku zprávy a data. Povoleny jsou čtyři typy zprávy Challenge, Response, Success a Failure. Identifikátor k sobě jednoznačně přiřazuje zprávy typu Challenge a Response. Klient nejprve kontaktuje server se zájmem o spojení. Server odpovídá zprávou Challenge, která nese jako data náhodný řetězec znaků dlouhý 8 bytů. Klient pak spočítá 24B odpověď provedením funkce LANMAN nad obdrženým řetězcem, s využitím sdíleného hesla [4]. Poté hashuje řetězec ještě jednou funkcí MD4, opět za použití stejného hesla. Serveru odesílá dvě zprávy, jednu s výsledkem LANMAN, druhou s výsledkem MD4. Server porovná hashe získané od klienta se svými, pokud se alespoň jeden z nich shoduje, odpovídá zprávou typu Success, v opačném případě zprávou typu Failure. Tento postup může být v průběhu spojení opakován v libovolných intervalech. Slabinou protokolu je v první řadě užití funkce LANMAN, ke které se po zjištění fundamentálních bezpečnostních vad pouze přidala MD4, z důvodu zachování zpětné kompatibility. Heslo je při zpracování vždy převedeno do upper-case, takže pokud nemá dostatečnou délku a nepoužívá speciální symboly, stává se velice zranitelné slovníkovými útoky a útoky hrubou silou [5]. Druhý bezpečnostní problém se skrývá ve funkci MD4, jež je náchylná k útoku kolizí (collision attack) [6]. Ten spočívá v nalezení různých řetězců takových, aby MD4(řetězec1) = MD4(řetězec2). Jako poslední vadu bych zmínil spoléhání se na jedinou utajenou informaci sdílené heslo. Všechny ostatní, jako například uživatelské jméno, jsou posílány mezi serverem a klientem nezašifrované. Případný útok tak stačí cílit výhradně na jediný šifrovaný údaj. Jako důsledek těchto snadno zneužitelných vad protokolu není jeho užití k autentizaci doporučeno. 6

12 1.1.3 Microsoft Challenge-Handshake Authentication Protocol v2 Protokol MsCHAPv2 měl plně nahradit MsCHAP poté, co v něm byly odhaleny zásadní bezpečnostní chyby designu. Slabiny předchůdce opravuje zejména následujícími změnami: 1. Hash funkce LANMAN není nadále podporována a již není obsahem autentizačních zpráv. K funkci MD4 se místo ní přidává SHA1. 2. Jedinou autentizační výměnou dojde k ověření totožnosti serveru i klienta. Protokol MsCHAP vyžadoval provést handshake klient-server a poté server-klient. 3. Pro šifrování odchozích a dešifrování příchozích dat jsou použity různé klíče. Vyjmenované změny si vyžádaly změnu schématu výměny zpráv mezi serverem a klientem. Některé prováděné hashovací operace ale lze vyhodnotit jako zbytečné, či alespoň zbytečně složité. Postup výměny autentizačních zpráv a kroky prováděné samostatně jednotlivými stanicemi proto přehledněji popisuje následující seznam operací a obrázek. Obrázek 2 Schéma operací protokolu MsCHAPv2 1. Klient kontaktuje server s žádostí o spojení. 2. Server odpovídá náhodným 16B řetězcem ServerChallenge. 3. Klient vygeneruje vlastní 16B náhodný řetězec ClientChallenge. 4. Klient vygeneruje 8B ChallengeHash ze ServerChallenge, ClientChallenge a uživatelského jména. 5. Klient spočítá MD4 hash sdíleného hesla NTHash. 6. Klient vytvoří 24B ChallengeResponse z ChallengeHash za použití hesla uživatele v hashované podobě. Heslo je, stejně jako u MsCHAP, zarovnáno na 21 B a rozděleno na 3 klíče. 7

13 7. Výsledná odpověď serveru sestává z ChallengeResponse, ClientChallenge a uživatelského jména. 8. Server za pomoci sdíleného hesla ověří obsah odpovědi a pokud se shoduje s jeho výpočtem, klient je autentizovaný. 9. Server se klientu autentizuje zprávou obsahující hash ClientChallenge vytvořený pomocí hashe sdíleného hesla a dvou konstantních textových řetězců. Zejména postup v kroku 9, kde server počítá dvakrát za sebou SHA1 hash demonstruje zbytečné využití výpočetního výkonu a de facto zpomaluje celý autentizační proces. Stejně tak sporný přínos má přidání magických konstant "Magic server to client constant" a "Pad to make it do more than one iteration" na konec hashovaných řetězců [7]. Protokol MsCHAPv2 se, přes svou neefektivní konstrukci, dal považovat za bezpečný, pokud bylo zvoleno dostatečně silné heslo, přestože stále jako jeho předchůdce spoléhal pouze na utajení sdíleného hesla. Na bezpečnostní konferenci Defcon v červenci roku 2012 bezpečnostní expert Moxie Marlinspike představil postup značně snižující odolnost proti útoku hrubou silou. Tento postup popsal o něco později v článku na serveru cloudcracker.com [8]. Marlinspike ukazuje, jak využít útok typu divide-and-conquer na tři DES klíče, které vznikly rozdělením hashe sdíleného hesla. Zatímco čistý bruteforce attack na hash by měl složitost přibližně 2 128, útok divide-and-conquer ji snižuje na součet ( ). Ještě mnohem lepšího účinku lze dosáhnout, pokud útočník využije faktu, že třetí klíč je efektivně pouze dva znaky dlouhý, zbylé byly doplněny nulami. Po zjištění této části klíče zbývá 14 B posledních dvou a za použití algoritmu prezentovaného Marlinspikem se složitost snižuje až na pouhých 2 56, což odpovídá jedné úrovni šifrování DES. Marlinspike dále poskytuje nástroje nezbytné k prolomení této šifry v čase kratším než 24 hodin. V současnosti jsou tedy veřejnosti dostupné nástroje, které umí prolomit autentizaci MsCHAPv2 ve velice krátkém čase. Jeho použití je nadále doporučeno Microsoftem pouze v kombinaci s protokolem PEAP [9] Internet Key Exchange v2 Poznámka: Tato podkapitola se věnuje pouze průběhu ustavení SA 1. Informace o VPN protokolu se stejným názvem naleznete v druhé kapitole. Posledním z řady čistě autentizačních protokolů je IKEv2 [10]. Zajišťuje ustavení bezpečnostního přiřazení (SA) mezi dvěma stanicemi výběr šifrovacího protokolu a dohodnutí klíčů pro další komunikaci. Princip protokolu vychází z předchozího IKE, oproti němu ale představuje několik vylepšení. 1. Sjednocuje původně několik dokumentů RFC se specifikacemi IKE do jediného. 2. Snižuje počet vyměněných zpráv při autentizaci z devíti na čtyři zprávy ve dvou fázích IKE_SA_INIT a IKE_AUTH. 1 Z anglického výrazu Security Association bezpečnostní přiřazení. Označuje souhrn bezpečnostních atributů a algoritmů, na nichž je postavena chráněná komunikace mezi dvěma stanicemi. 8

14 3. Obsahuje funkci Dead Peer Detection, která povoluje zrušit ustanovenou SA, pokud klient neodpovídá. 4. Lze povolit obranu proti DoS útokům pomocí cookie zpráv. Obrázek 3 Výměna zpráv IKEv2 Schéma zpráv na obrázku ilustruje průběh ustavení SA. První výměna obsahuje seznam podporovaných šifrovacích algoritmů, pole s hodnotou Diffie-Hellman výměny klíčů a tzv. nonce náhodný řetězec párující k sobě dvojice request/response, zajišťující ochranu proti útokům přehráním (replay attack). Pokud je využita funkce obrany proti DoS útokům, může si server vyžádat od klient potvrzení zasláním zprávy obsahující tzv. cookie opět náhodně vygenerovaný řetězec. Pokud jej klient odešle zpět, potvrdí tím, že nejen zasílá žádosti o spojení, ale rovněž i čeká na odpověď. Druhá fáze již probíhá v zašifrované podobě a zprávy nesou autentizační informace stanic. Ověření totožnosti může proběhnout pomocí certifikátu nebo PSK. Zároveň tyto zprávy vytvoří pomocí identifikátorů podřízené šifrované spojení, tzv. CHILD_SA, po kterém bude probíhat přenos dat mezi stanicemi. Toto podřízené spojení bývá zpravidla zašifrováno dle protokolu IPsec. Nespornou výhodou protokolu IKEv2 je zašifrování celé komunikace ihned po výměně prvních dvou zpráv. Žádné autentizační informace díky tomu nejsou posílány ve formě plain textu a nedají se zjistit prostým odposlechem. Útokům man-in-the-middle lze do jisté míry odolat s využitím oboustranné autentizace ověřením náplně Auth ve třetí a čtvrté zprávě a replay útokům zamezuje použití identifikátoru zprávy (nonce). IKEv2 ve výsledku poskytuje zdaleka nejvyšší úroveň bezpečnosti autentizace ze všech tří představených protokolů. 1.2 Šifrovací protokoly Pokud klient úspěšně projde fází autentizace, vyvstává potřeba zabezpečit přenos dat mezi ním a zbytkem soukromé sítě proti zachycení a přečtení útočníkem. Protože datový paket může cestou veřejnou sítí odchytit téměř kdokoliv, důvěrnost dat je nutné zachovat jejich převedením do formy čitelné pouze adresátu. Tuto funkci zajišťují kryptografické protokoly, 9

15 šifrující data podle klíče známého pouze koncovým stanicím, obvykle některou ze symetrických blokových šifer. Následující protokoly poskytují důvěrnost dat přenášených v rámci virtuální privátní sítě. Kromě prvního jmenovaného, MPPE, mohou poskytnout i funkci autentizace před začátkem přenosu. V rámci VPN protokolů jsou ale často použité v kombinaci s některým z autentizačních algoritmů. Protože si tato práce neklade za cíl podrobně analyzovat procesy šifrování dat, je tento postup popsán u složitějších protokolů pouze povrchně, s důrazem na případné zranitelnosti vůči útoku. Podrobnější informace o šifrovacích protokolech a konkrétních šifrách lze získat v některé z publikací jim přímo věnované Microsoft Point-To-Point Encryption Protocol Šifrovací protokol MPPE byl navržen Microsoftem k zabezpečení vytáčených připojení [11]. Nejčastěji používaný k zašifrování tunelovaného přenosu PPTP mezi stanicemi Windows. Zajišťuje ale pouze důvěrnost dat, spolehlivost autentizace závisí na sdruženém autentizačním protokolu, kterým může být MsCHAP nebo MsCHAPv2. Tyto protokoly také generují informace, z nichž pak MPPE odvodí iniciální klíče k zašifrování komunikace. Klíče mohou mít délku 40-bit, 56-bit nebo 128-bit. Odvození MPPE klíčů po úspěšném dokončení autentizace MsCHAPv2 probíhá podle několika kroků (řetězce jsou označeny stejně jako ve schématu autentizace): 1. MPPE vytvoří společný SHA1 hash z řetězců NThash (16B), 24B odpovědi obdržené od druhé stanice a 27B magické konstanty "This is the MPPE Master Key". 2. Výsledek je zkrácen na 16 B master klíč. 3. Z master klíče vznikne pár klíčů SHA1 hashováním 16B master klíče, 40B řetězce 0x00, 84B magické konstanty a dalšího 40B řetězce 0xF2. RFC definuje různé konstanty pro klíč klient-server a server-klient, takže vygenerované klíče se pro oba směry liší. 4. Oba vzniklé klíče jsou před použitím zkráceny na 16 B. Zranitelné místo protokolu může ležet právě v užití magických konstant k vygenerování šifrovacích klíčů. Obzvláště při využití 40-bit klíče, kdy je horních 24 B klíče pro potřeby funkce RC4 nastaveno pevně na 0xD1269, což funkci značně oslabuje [7]. Vzhledem k tomu, že protokol MPPE vždy vyžaduje přítomnost jedné z verzí protokolu MsCHAP, který však bez kombinace s jiným protokolem (například EAP) poskytuje pouze nízkou úroveň zabezpečení, možnosti jeho využití jsou značně omezené. V současné době se s ním lze setkat prakticky výhradně u PPTP spojení IP Security IPsec je kompletní sada protokolů k zajištění komunikační bezpečnosti na sítích IPv4 i IPv6, do obou IP protokolů byl dodán jako volitelný modul. Veškeré funkce IPsec tedy probíhají na třetí (síťové) vrstvě modelu ISO/OSI. Protokol skrze autentizaci stanic a zašifrování každého zasílaného paketu poskytuje autenticitu, integritu i důvěrnost přenášených dat. Od svého vydání v roce 1993 byl několikrát přepracován a vybaven dalšími moduly, takže dokumentů 10

16 RFC s jeho specifikacemi existuje větší množství. Za stěžejní lze považovat RFC 2401 a 2411[12] [13]. K zabezpečení přenosu slouží zejména části protokolu Authentication Header (AH) a Encapsulating Security Payload (ESP). Před použitím některé z nich musí být mezi komunikujícími stanicemi ustaveno bezpečnostní přiřazení, jež určí i počáteční šifrovací klíče. Pak mohou být data obalena hlavičkou AH, ESP nebo i oběma. AH poskytuje, na rozdíl od ESP, pouze záruku zachování integrity [14]. Pokud mají být data utajena před potenciálním útočníkem, musí být zašifrována pomocí ESP [15]. Umístění IPsec hlaviček v rámci paketu závisí na zvoleném módu. Protokol nabízí buď transportní, nebo tunelovací. V transportním módu se AH nebo ESP hlavička zařadí za IP adresu cíle. Veškeré následující hlavičky jsou pak chráněny na úrovni jim předřazené IPsec hlavičky. V důsledku ale zůstává nechráněná původní IP adresa cíle, což může představovat bezpečnostní riziko. Tunelovací mód obalí IPsec hlavičkou celý datový paket včetně původní hlavičky IP. Nová IP adresa pak může paket směrovat na zabezpečený hraniční server, který se postará o odstranění IPsec obalu a datový paket zašle již nezabezpečený k cíli. Obrázek 4 Paket chráněný Authentication Header Hlavička AH obsahuje pouze několik informací. Next header nese informace o typu protokolu vyšší vrstvy (zpravidla TCP nebo UDP), Security parameters index obsahuje identifikátor SA po kterém komunikace probíhá a Sequence number označuje pořadí zprávy v komunikaci (brání útokům přehráním). Authentication data obsahují kontrolní hash, spočítaný z šifrovacího klíče a obsahu paketu pomocí funkce SHA1. Jakákoli změna paketu v průběhu přenosu, včetně změny adresy v předřazené IP hlavičce, je pak cílovou stanicí detekována při kontrole tohoto hashe. Tato vlastnost nedovoluje provoz IPsec AH přes jakoukoli formu NAT [16]. 11

17 ESP v tunelovacím módu zajišťuje všechny vlastnosti zabezpečení dat autenticitu, integritu i důvěrnost. Transportní mód oproti tomu postrádá garanci autenticity a integrity. Konstrukce paketu chráněného ESP se od AH mírně liší, hlavička ESP je totiž rozdělena na tři části: ESP Header, ESP Trailer a ESP Auth. Obrázek 5 Paket chráněný Encapsulated Security Payload ESP Header obsahuje parametry Security parameters index a Sequence number se stejným významem jako u AH. ESP Trailer s parametry Padding a Pad length zarovnává paket na délku použité blokové šifry. ESP Auth pak nese pouze hash přenášených dat, shodný s AH. Velmi zásadním rozdílem oproti AH je ale absence vnější IP hlavičky v kontrolním součtu. IPsec ESP tedy lze provozovat i přes lokální zařízení NAT. Kryptografická metoda šifrující obsah IPsec ESP komunikace není v RFC přesně specifikována. Záleží na výběru v průběhu ustavování SA. Lze se setkat nejčastěji se symetrickými blokovými šiframi DES, 3DES, Blowfish a AES, z nichž za nejsilnější je považována AES. Délka klíče AES může dosahovat 256-bit, s volitelnými kratšími klíči 192- bit a 128-bit a šifrování provádí na 128-bit datových blocích a doba nutná k prolomení takové šifry bez jakékoliv znalosti o klíči se pohybuje od let pro nejkratší klíč až do let pro nejdelší [17] Secure Socket Layer/ Transport Layer Security Bezpečnostní protokol Secure Socket Layer, který, obdobně jako IPsec, zajišťuje autenticitu, integritu a důvěrnost dat [18]. Po několika aktualizacích byl v roce 1996 nahrazen novějším protokolem Transport Layer Security, založeným na stejném principu [19]. Pracuje na čtvrté (transportní) vrstvě ISO/OSI modelu a používá jak symetrické kryptografie k zašifrování přenášených dat, tak asymetrické při autentizaci, ve formě x.509 certifikátů. Nasazení protokolu závisí na existenci hierarchie certifikačních autorit (CA) a infrastruktury veřejných klíčů (PKI). Každá stanice, například server, který potřebuje potvrdit svou identitu, vygeneruje vlastní certifikát navázaný na jeho FQDN a zašle jej k ověření některé CA. 12

18 Jakmile se pak k takovému serveru připojuje klient, server mu zašle kopii svého certifikátu a klient si jej může ověřit u podepsané CA. Následně se stejným postupem může prokázat i klient. V průběhu autentizace dojde k odvození klíče symetrické šifry pro další komunikaci. TLS handshake probíhá v následujících krocích [20]: 1. Klient odešle serveru žádost o navázání zabezpečeného spojení s údaji o podporovaných šifrách a verzí protokolu a další detaily SA. 2. Server odpovídá výběrem šifrovacího algoritmu, potvrzením SA a vlastním certifikátem k ověření. Může také požadovat certifikát klienta. 3. Klient ověří certifikát a pokud není platný spojení ukončí, jinak za použití dohodnutých detailů SA vytvoří master klíč spojení, zašifruje jej veřejným klíčem serveru a odešle jej. Pokud server vyžadoval certifikát, zašle i ten. 4. Server dešifruje master klíč svým privátním klíčem. 5. Klient i server z master klíče vygenerují tzv. master secret za použití pseudonáhodné funkce a z něj pak odvodí symetrické klíče pro zašifrování další komunikace. 6. Klient odešle dvě oddělené zprávy. První informuje server, že veškerá další komunikace bude zašifrovaná. Druhá obsahuje zprávu o ukončení fáze autentizace. Server odpoví stejným způsobem. Různé verze SSL i TLS projevily náchylnost k některým typům útoků. Útok typu rollback se pokouší donutit server k použití co nejslabšího typu šifry. Pokud server souhlasí, útočníkovi stačí pokusit se tuto šifru prolomit offline na odchycených paketech. Podobný útok využívá zpětnou kompatibilitu mezi SSL 3.0 a 2.0 a donutí server použít starší verzi s několika známými bezpečnostními chybami [21]. Dále byla v nedávné době objevena kritická chyba v zabezpečení OpenSSL verze 1.0.1, umožňující útočníkovi zcizit uživatelská data a soukromé klíče. Nese označení Heartbleed (postihuje OpenSSL komponent Heartbeat), oficiální kód chyby CVE Nejnovější verze 1.0.1g již tuto chybu odstraňuje. Vzhledem k závažnosti chyby a možným následkům by postižené servery měly co nejdříve přejít na novou verzi programu OpenSSL [22]. 13

19 2. VPN protokoly podporované Windows 7 Využití virtuální privátní sítě se sebou nese výhodu přístupu zvenčí ke zdrojům dostupným na soukromé síti při relativně nízkých nárocích na správu poté, co byly nastaveny hraniční servery. Tyto servery mohou být nakonfigurovány pro neustálé statické spojení, jako v případě spojení dvou vzdálených poboček, v tzv. Site-to-Site VPN, nebo naslouchají na portech specifikovaných VPN protokolem a dynamicky přijímají připojení od vzdálených uživatelů v tzv. Point-to-Site VPN. Některé protokoly zmíněné v dalších kapitolách podporují obě konfigurace, nicméně Site-to-Site nastavení jsou k dispozici pouze v operačních systémech Microsoft Windows Server. Protože se práce věnuje šifrovaným spojením mezi počítači využívajícími operační systém Microsoft Windows 7, bude teoretická i praktická část soustředěna převážně na možnosti z hlediska Point-to-Site VPN. Obrázek 6 Site-to-Site VPN Obrázek 7 Point-to-Site VPN Pokud jsou klientské počítače vybaveny operačním systémem Windows 7, existuje několik možností výběru protokolu pro vytvoření virtuální sítě. Nejjednodušší volbou je protokol PPTP [23], který patří k součástem systémů Windows již od roku Zabezpečení, které poskytuje, už ale v současné době nezaručuje příliš vysokou odolnost dat proti změně nebo 14

20 přečtení během přenosu. O stupeň lepší zabezpečení poskytují protokoly L2TP a SSTP [24]. Výhodou L2TP je šifrování dat pomocí protokolu IPsec, ale oproti PPTP má vyšší režijní nároky. Zabezpečení SSTP je na srovnatelné úrovni a navíc spojení zajišťovaná tímto protokolem dokáží projít skrz část firewallů, která by zastavila spojení přes předchozí protokoly. Protože se ale jedná o protokol vyvíjený Microsoftem, jeho podpora na zařízeních od jiných výrobců je slabší. Nejmodernějším protokolem obsaženým ve Windows 7 je IKEv2 [25]. Podporuje IPsec šifrování a má implementovánu funkci automatického obnovení spojení při výpadku přenosové sítě. Rozbor VPN protokolů v této kapitole se věnuje fázím navázání spojení a přenosu dat. Dále uvádí podmínky, které musí být splněny k provozu protokolu. Jedná se o nároky v podobě otevřených portů, kde každý protokol vyžaduje otevření portů se specifickým číslem jak na všech zařízení přenosové sítě, jimiž prochází, tak na straně serveru. Třetím sledovaným hlediskem je bezpečnost s ohledem na podporované autentizační a šifrovací algoritmy z první kapitoly. V posledním odstavci lze nalézt shrnutí výhod a nevýhod pro každý protokol. 2.1 PPTP, Point-to-Point Tunneling Protocol RFC 2637, definující vlastnosti protokolu, bylo vydáno v červenci roku 1999 sdružením několika společností v čele s Microsoftem. PPTP má implementovány všechny služby očekávané od VPN, ale šifrování přenosu a autentizace jsou na nejnižší úrovni ze všech čtyř zde představených protokolů. Hlavní výhodou je relativně snadná konfigurace ve srovnání s ostatními dostupnými protokoly a stále ještě velice široká podpora mezi zařízeními různých výrobců. Z těchto důvodů je protokol obzvláště vhodný pro ustavení domácí VPN, kde umožňuje připojit širokou škálu zařízení s operačními systémy Unix, ios, Android a jiné. Šifrování přenosu bylo v roce 2012 prolomeno útokem hrubou silou, použití pro jakékoli spojení vyžadující důvěrnost nebo autentičnost přenášených dat není nadále doporučeno [9]. Point-to-Point Tunneling Protocol vznikal ve druhé polovině 90. let, tedy v době, kdy bylo stále ještě běžné vytáčené připojení k Internetu pomocí telefonní linky a modemu. Obrázek 8 Klasické vytáčené spojení V tomto druhu připojení byl jeho poslední úsek, mezi ISP a klientem, zprostředkován protokolem Point-to-Point Protocol (PPP). IP pakety totiž nebylo možné posílat samotné po koncové telefonní lince, obalené hlavičkou PPP však ano. Pokud klient potřeboval vyšší rychlost připojení, mohl využít agregace linek tzv. Multilink PPP, ovšem tato funkce 15

21 vyžadovala správné sdružování linek patřících jednomu klientu na straně ISP. Řešení tohoto problému vyústilo v protokol PPTP, který rozdělil Network Access Server na dvě zařízení, PPTP Access Concentrator (PAC) a PPTP Network Server (PNS). Obrázek 9 Tunelované vytáčené spojení Ustavení spojení tedy probíhalo následovně. Po vytočení linky byl nejprve klient připojen na PPTP Access Concentrator, který si vyžádal autentizaci a pak vytvořil PPTP tunel k PNS. Ten mohl sdružit linky se shodnou autentizací a poté zajistit efektivní směrování další komunikace. Vytáčené spojení od klienta díky tomuto rozdělení mohlo končit v lokálním PAC a nemuselo dosahovat až k samotnému NAS, což znamenalo úsporu nákladů při značných vzdálenostech mezi klientem a NAS. PPTP protokol tedy nebyl původně vyvíjen pro vytváření virtuálních sítí, byť se k tomuto účelu ukázal jako vhodný. Aby bylo možné PPTP využít, musí být mezi potenciálními koncovými body dostupná IP konektivita. Protože jakýkoli VPN tunel typicky probíhá Internetem, nepřináší tato vlastnost v praxi obvykle žádné omezení. Na všech mezilehlých síťových prvcích také musí být povoleny porty TCP 1723 pro kontrolní kanál a IP Protocol ID 47 pro datové spojení. PPTP spojení nebude funkční v případě umístění klienta za NAT, který není konfigurován na přeposílání GRE paketů. Ten sice povolí ustavení kontrolního kanálu, ale zahodí všechna přenášená data. Rovněž v případě připojení přes webový proxy server (WPS) nebude pokus o spojení úspěšný [26]. Pokud jsou splněny všechny podmínky kladené na přenosovou síť může být zahájen pokus o připojení k serveru. Protokol k vytvoření VPN využívá dva kanály. První je kontrolní a běží na protokolu TCP. Po tomto kanálu zasílají koncové stanice zprávy oznamující začátek nebo konec přenosu dat a potvrzují příjem. Dále umožňuje zasílání zpráv o změně stavu linky mezi oběma konci a neustále po něm probíhají keep-alive zprávy pro detekci selhání spojení. Každý pokus o PPTP přenos je tedy zahájen vytvořením TCP spojení mezi vzdáleným uživatelem a lokálním PPTP serverem na portu Vzápětí je vytvořeno i kontrolní spojení pomocí zpráv Start-Control-Connection-Request a Start-Control-Connection-Reply. Po ustavení kontrolního kanálu může být vytvořen druhý, sloužící již k vlastnímu přenosu dat. Ten probíhá za pomoci protokolu GRE následovně: 16

22 Obrázek 10 PPTP paket Původní IP datagram je zašifrován některou z metod, kterou poskytuje protokol PPP a je k němu přidána odpovídající hlavička. K výsledku je dále přidána hlavička GRE jednoduchého protokolu k zabalení dat pro přenos přes IP sítě. GRE je pro potřeby PPTP mírně modifikován. Poslední hlavička výsledného paketu patří protokolu IP a obsahuje adresu zdroje a adresu cíle. Výsledek již může být odeslán do přenosové sítě k doručení. Při zpracování paketu na straně PPTP serveru jsou postupně odebírány hlavičky až zbývá pouze zašifrovaný paket PPP. Ten server umí dešifrovat a získá datagram s lokální IP adresou cíle, kterému jej přepošle. Jak naznačilo schéma paketu putujícího nezabezpečenou sítí, PPTP šifrování přímo neřeší. Veškerou starost o bezpečnost nechává na podřízeném protokolu PPP. Ten musí v první řadě zajistit autentizaci stanic a poté zašifrovat každý paket směrovaný vytvořeným tunelem. Pro autentizaci je možné zvolit mezi několika možnostmi, z nichž ale část již poskytuje naprosto nedostačující zabezpečení. Nedoporučuje se výběr Password Authentication Protocol (PAP) nebo Microsoft Challenge Handshake Authentication Protocol (MsCHAPv1). Oba protokoly vykazují zásadní chyby a jsou náchylné k prolomení ve velmi krátkém čase. O něco lepší stupeň zabezpečení zaručuje MsCHAPv2, který opravuje většinu chyb svého předchůdce a umožňuje autentizaci pomocí uživatelského jména a hesla. Nejvyššího možného zabezpečení lze dosáhnout s Extensible Authentication Protocol. Ten umožňuje využít autentizaci s ověřením identity pomocí certifikační autority či MsCHAPv2 jméno a heslo nebo kombinaci obou možností. Zároveň definuje určité postupy pro přenos a uchovávání autentizačních dat, nadále zvyšující odolnost vůči útoku zvenčí. O šifrování PPP rámců se stará jediný protokol Microsoft Point-To-Point Encryption Protocol. K zašifrování dat využívá algoritmus RSA RC4 na klíčích 40-bit, 56-bit nebo 128- bit. Přesná délka klíčů je dohodnuta při ustavení spojení a v průběhu se již nemění. Oproti tomu samotné klíče je možné, a doporučené, měnit v určitých intervalech, nejčastěji až 1 různý klíč na paket. Přestože nejnovější aktualizace zabezpečovacích postupů odstranily většinu zásadních chyb v implementaci protokolu PPTP při použití doporučeného nastavení, stále zbývá několik trhlin obsažených v konstrukci protokolu samotného. Například neexistuje žádná ochrana proti slovníkovým útokům při použití přihlašovacího jména a hesla. To při stále stoupajícím výkonům osobních počítačů klade stále větší nároky na složitost hesla a zvyšuje náchylnost k podlehnutí slovníkovému útoku. Navíc kontrolní TCP spojení nepodléhá autentizaci 17

23 a zprávy po něm zasílané nejsou nijak zašifrovány, což zjednodušuje podvržení nebo modifikaci těchto zpráv a vytváří prostor k jejich zneužití [9]. Protokol PPTP tedy umožňuje poměrně jednoduché vytvoření VPN sítě s plnou funkcionalitou a slabším až průměrným zabezpečením. Plně dostačuje tam, kde bezpečnost není primárním cílem a výpadky dostupnosti v některých lokalitách nezpůsobí žádné škody v domácím využití, pro testovací účely atp. Pro využití v komerční sféře bude vhodnější vybrat některý ze tří zbývajících protokolů L2TP, SSTP, IKEv L2TP, Layer 2 Tunneling Protocol Související RFC 2661 vyšlo již v roce 1999, tedy téměř současně s RFC definujícím PPTP, ale v operačních systémech Windows je podporován až od verze Tento VPN protokol vznikl kombinací vlastností dvou již existujících protokolů. Prvním byl již zmíněný PPTP od Microsoftu, druhým pak L2F vyvinutý Cisco Systems. Jako jeho předchůdce umožňuje rozdělit NAS na dvě zařízení, tentokrát L2TP Access Concentrator (LAC) a L2TP Network Server (LNS) a poskytuje i naprosto stejné výhody, tedy oddělení konce vytáčeného L2 spojení (končí na LAC) od konce PPP spojení (přerušeno až na LNS) a podporu multilink. Přenášeným protokolem je v základu opět PPP, zajišťující autentizaci a šifrování, takže největší výhodou L2TP při použití v jeho základní verzi je schopnost vytvořit tunel přes jakoukoli síť podporující přepínání paketů. Je ovšem možné využít L2TP v kombinaci s protokolem IPsec, který se postará o autentizaci a šifrování namísto PPP, přičemž téměř všechny ostatní vlastnosti zůstanou zachovány. Použití IPsec omezí L2TP tunely pouze na sítě poskytující IP konektivitu, standardní tunel VPN ale typicky probíhá přes Internet, který tento požadavek splňuje. Kombinace protokolů L2TP a IPsec nese oficiální označení L2TP/IPsec a je představena v RFC 3193 [27]. Díky protokolu IPsec poskytuje zabezpečení na velice dobré úrovni a je proto často používaná pro vytváření VPN tam, kde PPTP již nedostačuje. Protože použití základní verze L2TP se sebou nese pouze nepatrné zlepšení bezpečnosti a neexistuje jiný důvod pro jeho preferenci, dále se ve své práci věnuji pouze L2TP za současného použití protokolu IPsec. Jedním z efektů obalení tunelovaných dat do IPsec je vyšší průchodnost skrz firewally nacházející se na veřejné síti mezi stanicemi a tedy mimo naši kontrolu. Není totiž nutné, aby byl port UDP 1701 pro L2TP tunel otevřen na všech těchto zařízeních, postačuje jeho dostupnost na koncových stanicích. Po veřejné síti IPsec komunikuje na portu UDP 500, přes který je ustavena vazba SA, a přes IP Protocol ID 50/51 pro ESP/Authentication Trailer. Tyto porty a protokoly zpravidla nebývají na přenosové síti blokovány, nicméně jejich dostupnost je nutnou podmínkou k úspěšnému uskutečnění spojení. Kontaktovat L2TP server není možné ze zařízení připojených přes WPS a pro průchod přes NAT musí server podporovat funkci NAT-Traversal. Tato funkce umožní v první fázi vyjednávání IPsec klíčů zjistit přítomnost NAT a za pomoci komunikace přes port UDP 4500 zajistit přístup do L2TP VPN. Samozřejmě port UDP 4500 musí být dostupný u klienta, serveru a po celé trase veřejnou sítí [28]. Ustavení L2TP tunelu mezi koncovými body probíhá následovně. Nejprve je nutné vytvoření kontrolního kanálu. Jeho význam je stejný jako u PPTP, tedy zasílání oznámení o vysílání, 18

24 příjmu, změně vlastností linky atp. Probíhá pomocí protokolu UDP na portu 1701 a v případě ztráty paketu se zprávou podporuje přeposlání. Pořadí kontrolních paketů je udržováno pomocí sekvenčních čísel v hlavičce každého takového paketu. Pokud některý dorazí mimo určené pořadí, je zahozen. Data jsou následně přenášena pomocí stejného protokolu i portu, ale na rozdíl od kontrolních zpráv nejsou datové pakety číslovány a pořadí tak nemusí být zachováno. Žádost o vytvoření je zahájena zprávou Start-Control-Connection-Request na kterou by měla protistrana odpovědět Start-Control-Connection-Reply, klient pak ještě jednou potvrdí zprávou Start-Control-Connection-Connected. Součástí výše uvedených zpráv může být volitelný 3-way handshake, podporovaný přímo L2TP a zajišťující autentizaci na úrovni MsCHAPv1. Po těchto třech krocích je možné pokračovat vytvořením datového spojení (session). Jeden L2TP tunel může obsahovat teoreticky až jednosměrných session a mezi dvěma stanicemi může existovat libovolné množství tunelů. Každý z tunelů ale musí mít vlastní kontrolní kanál. Session je pak vytvořena žádostí o povolení k přenosu a jejím potvrzením na kontrolním kanálu příslušného tunelu. Původní IP pakety od klienta posílané do některé session jsou obaleny hlavičkami několika různých protokolů v pořadí ilustrovaném na obrázku. Obrázek 11 L2TP paket PPP rámec tentokrát není zašifrován, spoléhá na ochranu zprostředkovanou některou z vyšších vrstev, jinak se shoduje s PPP rámcem protokolu PPTP. Dále je přidána L2TP hlavička s identifikačním číslem tunelu a příslušné session. ID tunelu se přiřazuje každé stanicí nezávisle, takže každý konec jednoho tunelu bude mít obvykle rozdílný identifikátor. Tyto ID jsou přiřazeny a sděleny protistraně při vytvoření kontrolního spojení. Následující hlavička UDP obsahuje pouze číslo portu 1701 pro zdroj i cíl. IP hlavička obsahuje adresy zdroje a cíle, které jsou použity pro směrování paketu veřejnou sítí. Za IP hlavičku je přiřazena hlavička protokolu IPsec, ta obsahuje informace o algoritmech použitých k zajištění autentizace, integrity a důvěrnosti dat. Za zašifrovanými daty se nachází Encapsulated Security Payload (ESP) s daty zarovnávajícími obsah na délku nutnou pro zvolené blokové šifrování a Authentication Trailer umožňující per-packet ověření totožnosti příjemce a odesilatele. 19

25 Obrázek 12 L2TP/IPsec paket Použití protokolu IPsec přidává k navázání tunelového L2TP spojení několik akcí, nezbytných pro zajištění určité úrovně zabezpečení. Nejprve je nutné vytvoření tzv. Security Association (SA). Tato vazba určuje typ a délku použitých šifrovacích klíčů, druh šifrovacích algoritmů a další parametry. Pro IPsec bývá zpravidla realizována přes protokol Internet Key Exchange (IKE). Po dohodnutí bezpečnostních parametrů SA může být vytvořen zabezpečený kanál pomocí IPsec ESP v transportním módu. Teprve po těchto krocích lze zahájit vyjednávání se vzdáleným serverem o ustavení L2TP tunelovaného připojení. Díky protokolu IPsec jsou chráněna nejen přenášená data, ale také i veškeré informace o tunelovaném přenosu, což znemožňuje útočníkovi snadno zjistit typ probíhající komunikace. Protokol L2TP vykazuje vyšší bezpečnost přenášených dat a vyšší průchodnost přenosovou sítí než protokol PPTP. V rámci jednoho tunelu také může probíhat více než jedna session, takže tento tunel může sloužit pro přenos více VLAN. Pravděpodobně jedinou nevýhodou oproti svému předchůdci je potenciálně nižší rychlost přenosu. Tu se sebou nese využití protokolu IPsec, který má oproti PPP mnohem vyšší režijní náklady na zajištění zabezpečení. Přes tuto negativní vlastnost je zvýšení bezpečnosti natolik výrazné, že preference L2TP před PPTP je doporučená ve všech případech snad kromě jednoduchých domácích VPN sítí. 2.3 SSTP, Secure Socket Tunneling Protocol Po výrazném zvýšení bezpečnosti poskytovaných VPN služeb, které přineslo L2TP, zbývalo vyřešit problém dostupnosti spojení mezi klientem a serverem. Nedostupnost serveru velice často způsobil jeden z následujících důvodů: 1) Na cestě mezi klientem a serverem se nachází zařízení blokující některý z portů nutných pro komunikaci užitého VPN protokolu. 2) Klient se pokouší připojit z místa se soukromým IP adresovým prostorem a zařízení NAT nepodporuje, nebo má zakázáno přeposílání paketů užitého VPN protokolu. 3) Připojení klienta k přenosové síti (Internetu) je zprostředkováno webovým proxy serverem. SSTP měl tyto problémy odstranit, což se díky využití protokolu SSL/TLS povedlo. SSL/TLS je totiž vyžadován pro zabezpečenou HTTP komunikaci (HTTPS) a je proto propouštěn a přeposílán prakticky všemi zařízeními zajišťující směrování v Internetu. Protokol byl představen společností Microsoft v roce RFC nebylo nikdy vydáno, což ve svém důsledku zavinilo pomalejší rozšíření do zařízení konkurenčních společností a tím i slabší podporu mimo operační systémy Windows. V těch je obsažen ve všech verzích od 20

26 Windows Vista Service Pack 1 a Windows Server Dokumentace k protokolu SSTP byla nedávno uvolněna a nyní je volně dostupná na internetových stránkách Microsoftu. Kromě vysoké průchodnosti dále umí vytvořit tunel přes sítě založené na aktualizované verzi protokolu IPv6 a dokáže IPv6 pakety také přenášet uvnitř tunelu. Nutné podmínky, které musí přenosová síť splnit jsou tentokrát minimální. SSTP má pouze jediný požadavek, potřebuje na zařízeních po celé své trase otevřený port TCP 443. Poradí si i s web proxy serverem a NAT bez jakýchkoli úprav jakéhokoli z účastnících se zařízení. Vytvoření zabezpečeného tunelu se tentokrát skládá z více kroků a několika málo volitelných možností. Jednotlivé kroky jsou očíslovány podle pořadí, ve kterém se musí vykonat. 1) Klient kontaktuje SSTP server na jeho veřejné IP adrese na TCP portu 443. Je vytvořeno TCP spojení. 2) Klient odesílá iniciační zprávu protokolu SSL/TLS žádající o ustavení zabezpečeného spojení. V tuto chvíli se musí server prokázat zasláním svého certifikátu. 3) Obdržený certifikát je klientem ověřen. Pokud odpovídá, klient může zvolit klíč relace a zašifrovaný jej odeslat serveru. Jako volitelný krok je možné v této fázi vyžadovat autentizaci klienta jeho vlastním certifikátem. 4) SSTP server obdrží klíč k SSL komunikaci, všechny další zprávy již mohou být zašifrovány. 5) Proběhne request-response vytvoření HTTPS spojení iniciované klientem. 6) Může být vytvořen SSTP tunel zprávou Call-Connect-Request (klient) a Call-Connect- Ack (server). Tento tunel slouží jak pro přenos dat, tak i kontrolních zpráv. 7) V této fázi se autentizuje klient pomocí některé metody, kterou poskytuje protokol PPP. Pokud je úspěšná, klient dostane přidělenu lokální IP adresu a získá přístup k funkcím uvnitř VPN. Obrázek 13 SSTP paket Před odesláním dat tunelem k cílové stanici je nutné postupně je obalit hlavičkami protokolů využitých k přenosu. Výstupní aplikační data nejprve dostanou číslo cílového portu a poté IPv4 nebo IPv6 hlavičku podle verze IP protokolu běžící na VPN síti. Následuje obalení protokolem PPP a SSTP hlavička. Ta obsahuje verzi protokolu, bit určující zda se jedná o kontrolní zprávu a délku připojených dat. Všechna tato data se posílají výhradně zašifrovaná klíčem relace SSL. Druhá TCP hlavička obsahuje číslo portu TCP 443 a nakonec je přiřazena výslednému paketu i druhá IP hlavička s veřejnou adresou SSTP serveru. I tato IP adresa může být verze IPv6 nebo IPv4 podle typu přenosové sítě. V rámci přenosové sítě může útočník tedy zjistit pouze zdrojovou a cílovou adresu a typ přenášené komunikace SSL. Informace o tunelovaném připojení je skrytá v zašifrované části. 21

27 Protokol SSL vyžaduje k autentizaci použití certifikátů ověřených certifikační autoritou. Jedná se o jeden z nejbezpečnějších způsobů autentizace a v případě využití možnosti povinného ověření totožnosti klienta již v SSL fázi poskytuje velmi vysokou míru ochrany. Každý klient připojující se k takovému SSTP serveru ale musí mít instalovaný vlastní ověřitelný certifikát. Vzrůstají tedy nároky na správu takové sítě. SSTP předčí protokoly PPTP a L2TP téměř ve všech ohledech. Poskytuje spolehlivější spojení dostupné i přes síťové prvky blokující ostatní protokoly a autentizace i šifrování je na mnohem vyšší úrovni. Přes tyto výhody má využití protokolu i svá úskalí. Vzhledem k tomu, že byl dlouhou dobu považován chráněným vlastnictvím Microsoftu, nebyl integrován do ostatních operačních systémů. Pokud je tedy nutné do VPN sítě připojit i zařízení s operačním systémem jiným než Microsoft Windows, je třeba využít podpůrný software třetí strany. To může představovat další zvýšení nároků na správu sítě a dotyčných zařízení, pokles spolehlivosti, bezpečnostní problémy atp. Jako další nevýhodu oproti předchozím protokolům lze zmínit chybějící podpora vytváření Site-to-Site VPN spojení. 2.4 IKEv2, Internet Key Exchange v2 Jinak také VPN Reconnect nebo Agile VPN. Jedná se o poslední z řady protokolů dostupných ve Windows 7, v nichž byl poprvé představen, a jeho konstrukce je zaměřena zejména na řešení problému mobility. V případě vzdáleného přístupu ze zařízení, které je v pohybu, může nastat situace, kdy klient na okamžik ztratí spojení k přenosové síti. Jako příklad lze uvést uživatele s notebookem a 3g mobilním připojením k Internetu v jedoucím autě. Jakmile dojde ke ztrátě signálu mobilní sítě, byť pouze na okamžik třeba při průjezdu tunelem, ustavené spojení k VPN serveru je ukončeno. Obnovení a restart všech v tu dobu probíhajících datových přenosů musí uživatel provést manuálně. K řešení obdobných problémů byl k IKEv2 přidán protokol Mobility and Multihoming Protocol (MOBIKE). Ten umožňuje změnit IP adresy již ustaveného tunelu, tedy u existujícího bezpečnostního přiřazení (SA). Mobilní klient tak zůstává připojen k serveru při přechodu mezi různými přístupovými body. Obdobně může při pádu rozhraní použitého k vyjednání tunelového spojení využít jiné, pokud jím disponuje a rozhraní je připojeno k přenosové síti. Mobilní zařízení se tak může libovolně pohybovat mezi přístupovými body i bezdrátovými sítěmi a plynule přecházet mezi wi-fi, 3g (nebo jakýmkoli jiným mobilním připojením, jako starší GPRS nebo EDGE) a fyzickým spojením jako Ethernet při zachování původní autentizace. Protokol MOBIKE je do IKEv2 ve Windows 7 integrován skrze tzv. Mobility Manager, který se stará automaticky o výše uvedené funkce a nechá se do jisté míry konfigurovat uživatelem. Klient může nastavit dobu, po kterou MOBIKE vyčkává na obnovení síťové konektivity, nebo podporu mobility úplně vypnout. Mobility Manager umožňuje VPN tunel přepínat mezi třemi stavy. Stav Connected odpovídá ostatním VPN protokolům a umožňuje přenos dat a funkci aplikací komunikujících se zařízeními v privátní síti. Pokud dojde k pádu rozhraní či jakémukoli jinému problému způsobujícímu nedostupnost VPN serveru a zároveň není dostupné žádné jiné aktivní rozhraní, přepne manager tunel do stavu Dormant. Všechny datové přenosy jsou pozastaveny, nicméně pokud dojde k obnovení spojení, mohou 22

28 pokračovat od bodu přerušení. Jakmile manager detekuje nějaké aktivní rozhraní, přepne tunel do stavu Waiting -to-reconnect a pokouší se kontaktovat VPN server. Pokud server odpoví, tunel přechází zpět do Connected stavu [29]. Protože zabezpečení IKEv2 spoléhá na IPsec, neposkytuje natolik robustní průchodnost přenosovou sítí jako SSTP. Ta, jakož i požadavky na dostupné porty, odpovídá spíše L2TP. IKEv2 vyžaduje otevřený port UDP 500 pro datové přenosy, případně i UDP 4500 pokud server i klient podporují IPsec NAT-Traversal. Posledním požadavkem je port IP Protocol ID 50 pro IPsec ESP. IKEv2 tunel dokáže projít přes NAT při použití NAT-Traversal verze protokolu IPsec. V takovém případě se chová obdobně jako L2TP (viz podkapitola L2TP nutné podmínky). Pokud se klient ovšem nachází za web proxy serverem, nebude schopen IKEv2 VPN server kontaktovat. Pokud jsou splněny všechny podmínky kladené na přenosovou síť může být zahájen pokus o připojení k serveru. Jako první krok při ustavování spojení musí být domluveno bezpečnostní přiřazení (SA). Vyžadováno je ustavení dokonce minimálně dvou SA. Jedno pro IKEv2 jako kontrolní kanál spravující druhý typ podřízených SA. Tato podřízená bezpečnostní přiřazení se nazývají CHILD_SA a pro potřeby IKEv2 VPN se řídí protokolem IPsec. Vyjednávání se skládá ze dvou fází. V první fázi, IKE_SA_INIT, klient kontaktuje server na portu UDP 500, zpráva obsahuje seznam algoritmů podporovaných klientem pro šifrovanou komunikaci. Server může spojení odmítnout v případě, že se v přijatém seznamu nenachází žádný společný algoritmus. Pokud žádost o spojení přijme, odešle klientu potvrzovací zprávu s šifrovacím algoritmem, který bude použit. Obě zprávy také obsahují Diffie-Hellman výměnu k ustavení tzv. master klíče. Po této výměně je veškerá další IKEv2 komunikace zašifrovaná, ale žádná z koncových stanic se zatím neautentizovala. Autentizaci má na starost druhá fáze, IKE_AUTH, která ověří totožnost stanic podle certifikátu nebo pomocí PSK. Zároveň dojde automaticky k ustavení první CHILD_SA. IKEv2 umožňuje později vytvořit další pomocí kontrolních zpráv. Ty mohou být zasílány právě po úspěšné autentizaci obou zařízení a slouží k vytváření, rušení a změnu parametrů jednoho nebo i více IPsec tunelů a musí striktně dodržovat pravidlo request/response (jsou vždy párové). Vytvoření CHILD_SA může zahájit kterákoli z autentizovaných stanic zasláním kontrolní zprávy CREATE_CHILD_SA, protějšek akceptuje odpovědí stejnou zprávou. Pouze v těchto dvou zprávách dojde k dohodnutí bezpečnostních parametrů, odvození prvních IPsec klíčů z master klíče IKEv2 a výběru šifrovacího algoritmu pro nově vzniklé SA. Tunelové spojení k serveru je pak připraveno k přenosu dat. Ukončení spojení může vyvolat rovněž kterýkoli z účastníků a to dvěma způsoby. Zrušením některé CHILD_SA kontrolní zprávou DELETE_PAYLOAD s příslušným identifikátorem, nebo celého IKEv2 kanálu toutéž zprávou, obsahující na místě identifikátoru nulu. Při terminaci kanálu dojde i k automatickému ukončení všech jemu podřízených CHILD_SA spojení. 23

29 Standardní datový paket přenášený tunelem mezi klientem a serverem vypadá následovně: Obrázek 14 IKEv2 paket Původní IP hlavička cílového zařízení v privátní síti a data jsou zašifrovány protokolem IPsec. Nová přidělená IP adresa odpovídá adrese IKEv2 serveru a hlavička Encapsulated Security Payload provádí stejnou funkcí jako u L2TP, tedy zarovnává data na určitou délku. Největší výhodou oproti předchozím protokolům je bezesporu podpora mobility. Nejen že dovoluje uživatelům pohybovat se a při tom měnit přístupové body do sítě. Výhodu přináší i statickým uživatelům ve formě automatické změny rozhraní v případě pádu původního. To vše vždy bez nutnosti znovu zadávat autentizační informace. Poskytovaná úroveň zabezpečení je srovnatelná s L2TP (IPsec) a tedy velice dobrá. Jako nevýhoda se nabízí snad pouze nižší průchodnost přenosovou sítí, kterou, opět obdobně jako u L2TP, zaviňuje IPsec. Ovšem pouze ve srovnání s SSTP, jenž jediný dokáže projít skrz web proxy server. IKEv2 také podporuje vytváření výhradně Point-to-Site VPN. 24

SSL Secure Sockets Layer

SSL Secure Sockets Layer SSL Secure Sockets Layer internetové aplikační protokoly jsou nezabezpečené SSL vkládá do architektury šifrující vrstvu aplikační (HTTP, IMAP,...) SSL transportní (TCP, UDP) síťová (IP) SSL poskytuje zabezpečenou

Více

Bezpečnost vzdáleného přístupu. Jan Kubr

Bezpečnost vzdáleného přístupu. Jan Kubr Bezpečnost vzdáleného přístupu Jan Kubr Vzdálené připojení - protokoly IPsec PPTP, P2TP SSL, TSL IPsec I RFC 4301-4309 IPv6, IPv4 autentizace Authentication Header (AH) šifrování Encapsulating Security

Více

Desktop systémy Microsoft Windows

Desktop systémy Microsoft Windows Desktop systémy Microsoft Windows IW1/XMW1 2013/2014 Jan Fiedor, přednášející Peter Solár ifiedor@fit.vutbr.cz, solar@pocitacoveskoleni.cz Fakulta Informačních Technologií Vysoké Učení Technické v Brně

Více

Seminární práce do předmětu: Bezpečnost informačních systémů. téma: IPsec. Vypracoval: Libor Stránský

Seminární práce do předmětu: Bezpečnost informačních systémů. téma: IPsec. Vypracoval: Libor Stránský Seminární práce do předmětu: Bezpečnost informačních systémů téma: IPsec Vypracoval: Libor Stránský Co je to IPsec? Jedná se o skupinu protokolů zabezpečujících komunikaci na úrovni protokolu IP (jak už

Více

VPN - Virtual private networks

VPN - Virtual private networks VPN - Virtual private networks Přednášky z Projektování distribuovaných systémů Ing. Jiří Ledvina, CSc. Virtual Private Networks Virtual Private Networks Privátní sítě používají pronajaté linky Virtuální

Více

Elektronický podpis. Základní princip. Digitální podpis. Podpis vs. šifrování. Hashování. Jednosměrné funkce. Odesílatel. Příjemce

Elektronický podpis. Základní princip. Digitální podpis. Podpis vs. šifrování. Hashování. Jednosměrné funkce. Odesílatel. Příjemce Základní princip Elektronický podpis Odesílatel podepíše otevřený text vznikne digitálně podepsaný text Příjemce ověří zda podpis patří odesílateli uvěří v pravost podpisu ověří zda podpis a text k sobě

Více

ISMS. Autentizace ve WiFi sítích. V Brně dne 5. a 12. prosince 2013

ISMS. Autentizace ve WiFi sítích. V Brně dne 5. a 12. prosince 2013 ISMS Případová studie Autentizace ve WiFi sítích V Brně dne 5. a 12. prosince 2013 Pojmy Podnikové WiFi sítě Autentizace uživatelů dle standardu 802.1X Hlavní výhodou nasazení tohoto standardu je pohodlná

Více

Moderní komunikační technologie. Ing. Petr Machník, Ph.D.

Moderní komunikační technologie. Ing. Petr Machník, Ph.D. Moderní komunikační technologie Ing. Petr Machník, Ph.D. Virtuální privátní sítě Základní vlastnosti VPN sítí Virtuální privátní síť (VPN) umožňuje bezpečně přenášet data přes nezabezpečenou síť. Zabezpečení

Více

12. Bezpečnost počítačových sítí

12. Bezpečnost počítačových sítí 12. Bezpečnost počítačových sítí Typy útoků: - odposlech při přenosu - falšování identity (Man in the Middle, namapování MAC, ) - automatizované programové útoky (viry, trojské koně, ) - buffer overflow,

Více

OpenVPN. Uvedené dílo podléhá licenci Creative Commons Uved te autora 3.0 Česko. Ondřej Caletka (CESNET, z.s.p.o.) OpenVPN 3. března 2013 1 / 16

OpenVPN. Uvedené dílo podléhá licenci Creative Commons Uved te autora 3.0 Česko. Ondřej Caletka (CESNET, z.s.p.o.) OpenVPN 3. března 2013 1 / 16 OpenVPN Ondřej Caletka 3. března 2013 Uvedené dílo podléhá licenci Creative Commons Uved te autora 3.0 Česko. Ondřej Caletka (CESNET, z.s.p.o.) OpenVPN 3. března 2013 1 / 16 Virtuální privátní sítě Vytvoření

Více

Informatika / bezpečnost

Informatika / bezpečnost Informatika / bezpečnost Bezpečnost, šifry, elektronický podpis ZS 2015 KIT.PEF.CZU Bezpečnost IS pojmy aktiva IS hardware software data citlivá data hlavně ta chceme chránit autorizace subjekt má právo

Více

Desktop systémy Microsoft Windows

Desktop systémy Microsoft Windows Desktop systémy Microsoft Windows IW1/XMW1 2011/2012 Jan Fiedor ifiedor@fit.vutbr.cz Fakulta Informačních Technologií Vysoké Učení Technické v Brně Božetěchova 2, 612 66 Brno Revize 11.12.2011 11.12.2011

Více

Protokol TELNET. Schéma funkčních modulů komunikace protokolem TELNET. Telnet klient. login shell. Telnet server TCP/IP.

Protokol TELNET. Schéma funkčních modulů komunikace protokolem TELNET. Telnet klient. login shell. Telnet server TCP/IP. Protokol TELNET Schéma funkčních modulů komunikace protokolem TELNET Telnet klient Telnet server login shell terminal driver Jádro TCP/IP TCP/IP Jádro Pseudo terminal driver Uživatel u terminálu TCP spojení

Více

Protokol TELNET. Schéma funkčních modulů komunikace protokolem TELNET. Telnet klient. login shell. Telnet server TCP/IP TCP/IP.

Protokol TELNET. Schéma funkčních modulů komunikace protokolem TELNET. Telnet klient. login shell. Telnet server TCP/IP TCP/IP. Protokol TELNET Schéma funkčních modulů komunikace protokolem TELNET Telnet klient Telnet server login shell terminal driver Operační systém TCP/IP TCP spojení TCP/IP Pseudo terminal driver Operační systém

Více

Bezpečnost webových stránek

Bezpečnost webových stránek Teze k diplomové práci na téma: Bezpečnost webových stránek Vypracoval: Jan Kratina, PEF, INFO, 5.ročník Vedoucí projektu: RNDr. Dagmar Brechlerová Jan Kratina 2005 Téma diplomové práce Bezpečnost webových

Více

Desktop systémy Microsoft Windows

Desktop systémy Microsoft Windows Desktop systémy Microsoft Windows IW1/XMW1 2014/2015 Jan Fiedor ifiedor@fit.vutbr.cz Fakulta Informačních Technologií Vysoké Učení Technické v Brně Božetěchova 2, 612 66 Brno Revize 14. 12. 2014 14. 12.

Více

PA159 - Bezpečnost na síti II

PA159 - Bezpečnost na síti II PA159 - Bezpečnost na síti II 2. 11. 2007 PAP (RFC 1334) Autentizační protokoly slabá autentizace plain-text hesla přes sít * Předpokládal přístup přes telefon přímo k autentizačnímu serveru CHAP (Challenge

Více

Šifrování Autentizace Bezpečnostní slabiny. Bezpečnost. Lenka Kosková Třísková, NTI TUL. 22. března 2013

Šifrování Autentizace Bezpečnostní slabiny. Bezpečnost. Lenka Kosková Třísková, NTI TUL. 22. března 2013 Šifrování Autentizace ní slabiny 22. března 2013 Šifrování Autentizace ní slabiny Technologie Symetrické vs. asymetrické šifry (dnes kombinace) HTTPS Funguje nad HTTP Šifrování s pomocí SSL nebo TLS Šifrování

Více

ERP-001, verze 2_10, platnost od

ERP-001, verze 2_10, platnost od ERP-001, verze 2_10, platnost od 2010.08.01. ELEKTRONICKÉ PŘEDEPISOVÁNÍ HUMÁNNÍCH LÉČIVÝCH PŘÍPRAVKŮ ERP-001.pdf (208,89 KB) Tímto technickým dokumentem jsou, v souladu s 80 zákona č. 378/2007 Sb., o léčivech

Více

Kryptografie, elektronický podpis. Ing. Miloslav Hub, Ph.D. 27. listopadu 2007

Kryptografie, elektronický podpis. Ing. Miloslav Hub, Ph.D. 27. listopadu 2007 Kryptografie, elektronický podpis Ing. Miloslav Hub, Ph.D. 27. listopadu 2007 Kryptologie Kryptologie věda o šifrování, dělí se: Kryptografie nauka o metodách utajování smyslu zpráv převodem do podoby,

Více

Autentizace uživatelů

Autentizace uživatelů Autentizace uživatelů základní prvek ochrany sítí a systémů kromě povolování přístupu lze uživatele členit do skupin, nastavovat různá oprávnění apod. nejčastěji dvojicí jméno a heslo další varianty: jednorázová

Více

Šifrování ve Windows. EFS IPSec SSL. - Encrypting File System - Internet Protocol Security - Secure Socket Layer - Private Point to Point Protocol

Šifrování ve Windows. EFS IPSec SSL. - Encrypting File System - Internet Protocol Security - Secure Socket Layer - Private Point to Point Protocol Šifrování ve Windows EFS IPSec SSL PPTP - Encrypting File System - Internet Protocol Security - Secure Socket Layer - Private Point to Point Protocol 18.11.2003 vjj 1 Bezpečnost? co chci chránit? systém

Více

Definice pojmů a přehled rozsahu služby

Definice pojmů a přehled rozsahu služby PŘÍLOHA 1 Definice pojmů a přehled rozsahu služby SMLOUVY o přístupu k infrastruktuře sítě společnosti využívající technologie Carrier IP Stream mezi společnostmi a Poskytovatelem 1. Definice základních

Více

Útoky na HTTPS. PV210 - Bezpečnostní analýza síťového provozu. Pavel Čeleda, Radek Krejčí

Útoky na HTTPS. PV210 - Bezpečnostní analýza síťového provozu. Pavel Čeleda, Radek Krejčí Útoky na HTTPS PV210 - Bezpečnostní analýza síťového provozu Pavel Čeleda, Radek Krejčí Ústav výpočetní techniky Masarykova univerzita celeda@ics.muni.cz Brno, 5. listopadu 2014 Pavel Čeleda, Radek Krejčí

Více

Směry rozvoje v oblasti ochrany informací KS - 7

Směry rozvoje v oblasti ochrany informací KS - 7 VŠFS; Aplikovaná informatika; SW systémy 2005/2006 1 Bezpečnost informací BI Ing. Jindřich Kodl, CSc. Směry rozvoje v oblasti ochrany informací KS - 7 VŠFS; Aplikovaná informatika; SW systémy 2005/2006

Více

Bezdrátové sítě Wi-Fi Původním cíl: Dnes

Bezdrátové sítě Wi-Fi Původním cíl: Dnes Bezdrátové sítě Nejrozšířenější je Wi-Fi (nebo také Wi-fi, WiFi, Wifi, wifi) Standard pro lokální bezdrátové sítě (Wireless LAN, WLAN) a vychází ze specifikace IEEE 802.11. Původním cíl: Zajišťovat vzájemné

Více

ISMS. Síťová bezpečnost. V Brně dne 7. a 14. listopadu 2013

ISMS. Síťová bezpečnost. V Brně dne 7. a 14. listopadu 2013 ISMS Případová studie Síťová bezpečnost V Brně dne 7. a 14. listopadu 2013 Zadání - infrastruktura Modelová firma je výrobní firma, která síťové zabezpečení doposud nijak zásadně neřešila, a do jisté míry

Více

Bezpečnostní aspekty informačních a komunikačních systémů KS2

Bezpečnostní aspekty informačních a komunikačních systémů KS2 VŠFS; Aplikovaná informatika; SW systémy 2005/2006 1 Bezpečnost informací BI Ing. Jindřich Kodl, CSc. Bezpečnostní aspekty informačních a komunikačních systémů KS2 VŠFS; Aplikovaná informatika; SW systémy

Více

PB169 Operační systémy a sítě

PB169 Operační systémy a sítě PB169 Operační systémy a sítě Zabezpečení počítačových sítí Marek Kumpošt, Zdeněk Říha Zabezpečení sítě úvod Důvody pro zabezpečení (interní) sítě? Nebezpečí ze strany veřejného Internetu Spyware Malware

Více

Josef Hajas. hajasj1@fel.cvut.cz

Josef Hajas. hajasj1@fel.cvut.cz Vysázeno v LAT Xu p. Technologie bezpečných kanálů aneb s OpenVPN na věčné časy Josef Hajas hajasj1@fel.cvut.cz Vysázeno v LAT Xu p. Co nás čeká a nemine Motivace, co je to vlastně ta VPN? Rozdělení jednotlivých

Více

Počítačové sítě II. 20. Útoky na síť a její ochrana Miroslav Spousta, 2006 <qiq@ucw.cz>, http://www.ucw.cz/~qiq/vsfs/

Počítačové sítě II. 20. Útoky na síť a její ochrana Miroslav Spousta, 2006 <qiq@ucw.cz>, http://www.ucw.cz/~qiq/vsfs/ Počítačové sítě II 20. Útoky na síť a její ochrana Miroslav Spousta, 2006 , http://www.ucw.cz/~qiq/vsfs/ 1 Bezpečnost sítí cílem je ochránit počítačovou síť a především data/zařízení v nich

Více

Y36PSI IPv6. Jan Kubr - 7_IPv6 Jan Kubr 1/29

Y36PSI IPv6. Jan Kubr - 7_IPv6 Jan Kubr 1/29 Y36PSI IPv6 Jan Kubr - 7_IPv6 Jan Kubr 1/29 Obsah historie, motivace, formát datagramu, adresace, objevování sousedů, automatická konfigurace, IPsec, mobilita. Jan Kubr - 7_IPv6 Jan Kubr 2/29 Historie

Více

Úvod Bezpečnost v počítačových sítích Technologie Ethernetu

Úvod Bezpečnost v počítačových sítích Technologie Ethernetu České vysoké učení technické v Praze FAKULTA INFORMAČNÍCH TECHNOLOGIÍ katedra počítačových systémů Úvod Bezpečnost v počítačových sítích Technologie Ethernetu Jiří Smítka jiri.smitka@fit.cvut.cz 26.9.2011

Více

Úvod - Podniková informační bezpečnost PS1-2

Úvod - Podniková informační bezpečnost PS1-2 VŠFS; Aplikovaná informatika - 2006/2007 1 Bezpečnost informací BI Ing. Jindřich Kodl, CSc. Úvod - Podniková informační bezpečnost PS1-2 VŠFS; Aplikovaná informatika - 2006/2007 2 Literatura Kovacich G.L.:

Více

Obsah. Úvod 13. Věnování 11 Poděkování 11

Obsah. Úvod 13. Věnování 11 Poděkování 11 Věnování 11 Poděkování 11 Úvod 13 O autorech 13 O odborných korektorech 14 Ikony použité v této knize 15 Typografické konvence 16 Zpětná vazba od čtenářů 16 Errata 16 Úvod k protokolu IPv6 17 Cíle a metody

Více

Analýza aplikačních protokolů

Analýza aplikačních protokolů ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE Fakulta elektrotechnická PROJEKT Č. 4 Analýza aplikačních protokolů Vypracoval: V rámci předmětu: Jan HLÍDEK Komunikace v datových sítích (X32KDS) Měřeno: 28. 4. 2008

Více

Analýza síťového provozu. Ing. Dominik Breitenbacher Mgr. Radim Janča

Analýza síťového provozu. Ing. Dominik Breitenbacher Mgr. Radim Janča Analýza síťového provozu Ing. Dominik Breitenbacher ibreiten@fit.vutbr.cz Mgr. Radim Janča ijanca@fit.vutbr.cz Obsah cvičení Komunikace na síti a internetu Ukázka nejčastějších protokolů na internetu Zachytávání

Více

Y36PSI Bezpečnost v počítačových sítích. Jan Kubr - 10_11_bezpecnost Jan Kubr 1/41

Y36PSI Bezpečnost v počítačových sítích. Jan Kubr - 10_11_bezpecnost Jan Kubr 1/41 Y36PSI Bezpečnost v počítačových sítích Jan Kubr - 10_11_bezpecnost Jan Kubr 1/41 Osnova základní pojmy typy šifer autentizace integrita distribuce klíčů firewally typy útoků zabezpečení aplikací Jan Kubr

Více

6. Transportní vrstva

6. Transportní vrstva 6. Transportní vrstva Studijní cíl Představíme si funkci transportní vrstvy. Podrobněji popíšeme protokoly TCP a UDP. Doba nutná k nastudování 3 hodiny Transportní vrstva Transportní vrstva odpovídá v

Více

Autentizace uživatele připojeného přes 802.1X k přepínači Cisco Catalyst 2900/3550 pomocí služby RADIUS

Autentizace uživatele připojeného přes 802.1X k přepínači Cisco Catalyst 2900/3550 pomocí služby RADIUS Autentizace uživatele připojeného přes 802.1X k přepínači Cisco Catalyst 2900/3550 pomocí služby RADIUS Semestrální projekt z předmětu Směrované a přepínané sítě 2004/2005 David Mikula Marek Bielko Standard

Více

DODATEČNÉ INFORMACE K ZADÁVACÍM PODMÍNKÁM č. 2. Název veřejné zakázky: Dodávka SAN switchů včetně příslušenství pro datová centra

DODATEČNÉ INFORMACE K ZADÁVACÍM PODMÍNKÁM č. 2. Název veřejné zakázky: Dodávka SAN switchů včetně příslušenství pro datová centra Zadavatel: Česká republika Ministerstvo zemědělství Název veřejné zakázky: Dodávka SAN switchů včetně příslušenství pro datová centra Sídlem: Těšnov 65/17, 110 00 Praha 1 Nové Město Evidenční číslo veřejné

Více

ODBORNÝ VÝCVIK VE 3. TISÍCILETÍ

ODBORNÝ VÝCVIK VE 3. TISÍCILETÍ Projekt: ODBORNÝ VÝCVIK VE 3. TISÍCILETÍ Téma: MEIV - 2.1.1.1 Základní pojmy Bezdrátové sítě WI-FI Obor: Mechanik Elektronik Ročník: 4. Zpracoval(a): Bc. Martin Fojtík Střední průmyslová škola Uherský

Více

I.CA RemoteSeal. Ing. Filip Michl První certifikační autorita, a.s

I.CA RemoteSeal. Ing. Filip Michl První certifikační autorita, a.s Technické řešení služby I.CA RemoteSeal Ing. Filip Michl První certifikační autorita, a.s. 5. 4. 2018 Agenda Úvod ARX CoSign vs. DocuSign Signature Appliance Architektura Zřízení služby Aktivace služby

Více

Obsah. Část I Základy bezpečnosti...9 Kapitola 1 Základy obvodového zabezpečení...11. Kapitola 2 Filtrování paketů...27

Obsah. Část I Základy bezpečnosti...9 Kapitola 1 Základy obvodového zabezpečení...11. Kapitola 2 Filtrování paketů...27 Obsah Část I Základy bezpečnosti..............9 Kapitola 1 Základy obvodového zabezpečení.................11 Důležité pojmy...12 Hloubková obrana...15 Případová studie hloubkové obrany...25 Shrnutí...26

Více

Jen správně nasazené HTTPS je bezpečné

Jen správně nasazené HTTPS je bezpečné Jen správně nasazené HTTPS je bezpečné Petr Krčmář 12. listopadu 2015 Uvedené dílo (s výjimkou obrázků) podléhá licenci Creative Commons Uveďte autora 3.0 Česko. Petr Krčmář (Root.cz, vpsfree.cz) Jen správně

Více

Provádí ochranu sítě před napadením (ochrana počítačů nestačí) Odděluje uživatele (prvek nespolehlivosti) od prvků ochrany

Provádí ochranu sítě před napadením (ochrana počítačů nestačí) Odděluje uživatele (prvek nespolehlivosti) od prvků ochrany Obranné valy (Firewalls) Vlastnosti Provádí ochranu sítě před napadením (ochrana počítačů nestačí) Odděluje uživatele (prvek nespolehlivosti) od prvků ochrany Filtrování paketů a vlastnost odstínění Různé

Více

Šifrová ochrana informací věk počítačů PS5-2

Šifrová ochrana informací věk počítačů PS5-2 Bezpečnost informací BI Ing. Jindřich Kodl, CSc. Šifrová ochrana informací věk počítačů PS5-2 1 Osnova šifrová ochrana využívající výpočetní techniku např. Feistelova šifra; symetrické a asymetrické šifry;

Více

Bezpečnostní aspekty informačních a komunikačních systémů PS2-1

Bezpečnostní aspekty informačních a komunikačních systémů PS2-1 Bezpečnost informací BI Ing. Jindřich Kodl, CSc. Bezpečnostní aspekty informačních a komunikačních systémů PS2-1 1 Literatura Doseděl T.: Počítačová bezpečnost a ochrana dat, Computer Press, 2004 Časopis

Více

Ochrana mobilních uživatelů před hrozbami Internetu mimo firemní prostředí. Simac Technik ČR, a.s.

Ochrana mobilních uživatelů před hrozbami Internetu mimo firemní prostředí. Simac Technik ČR, a.s. Ochrana mobilních uživatelů před hrozbami Internetu mimo firemní prostředí Simac Technik ČR, a.s. Praha, 5.5. 2011 Jan Kolář, Solution Architect Jan.kolar@simac.cz 1 Hranice sítě se posunují Dříve - Pracovalo

Více

4. Síťová vrstva. Síťová vrstva. Počítačové sítě I. 1 (6) KST/IPS1. Studijní cíl. Představíme si funkci síťové vrstvy a jednotlivé protokoly.

4. Síťová vrstva. Síťová vrstva. Počítačové sítě I. 1 (6) KST/IPS1. Studijní cíl. Představíme si funkci síťové vrstvy a jednotlivé protokoly. 4. Síťová vrstva Studijní cíl Představíme si funkci síťové vrstvy a jednotlivé protokoly. Doba nutná k nastudování 3 hodiny Síťová vrstva Síťová vrstva zajišťuje směrování a poskytuje jediné síťové rozhraní

Více

Projekt: 1.5, Registrační číslo: CZ.1.07/1.5.00/ Digitální podpisy

Projekt: 1.5, Registrační číslo: CZ.1.07/1.5.00/ Digitální podpisy VY_32_INOVACE_BEZP_08 Projekt: 1.5, Registrační číslo: CZ.1.07/1.5.00/34.0304 Digitální podpisy Základní myšlenkou elektronického podpisu je obdoba klasického podpisu, jež má zaručit jednoznačnou identifikaci

Více

Identifikátor materiálu: ICT-3-03

Identifikátor materiálu: ICT-3-03 Identifikátor materiálu: ICT-3-03 Předmět Téma sady Informační a komunikační technologie Téma materiálu TCP/IP Autor Ing. Bohuslav Nepovím Anotace Student si procvičí / osvojí architekturu TCP/IP. Druh

Více

Identifikátor materiálu: ICT-2-04

Identifikátor materiálu: ICT-2-04 Identifikátor materiálu: ICT-2-04 Předmět Téma sady Informační a komunikační technologie Téma materiálu Zabezpečení informací Autor Ing. Bohuslav Nepovím Anotace Student si procvičí / osvojí kryptografii.

Více

Bezpečnost internetového bankovnictví, bankomaty

Bezpečnost internetového bankovnictví, bankomaty , bankomaty Filip Marada, filipmarada@gmail.com KM FJFI 15. května 2014 15. května 2014 1 / 18 Obsah prezentace 1 Bezpečnost internetového bankovnictví Možná rizika 2 Bankomaty Výběr z bankomatu Možná

Více

Šifrová ochrana informací věk počítačů PS5-2

Šifrová ochrana informací věk počítačů PS5-2 VŠFS; Aplikovaná informatika; SW systémy 2005/2006 1 Bezpečnost informací BI Ing. Jindřich Kodl, CSc. Šifrová ochrana informací věk počítačů PS5-2 VŠFS; Aplikovaná informatika; SW systémy 2005/2006 2 Osnova

Více

PA159 - Bezpečnostní aspekty

PA159 - Bezpečnostní aspekty PA159 - Bezpečnostní aspekty 19. 10. 2007 Formulace oblasti Kryptografie (v moderním slova smyslu) se snaží minimalizovat škodu, kterou může způsobit nečestný účastník Oblast bezpečnosti počítačových sítí

Více

Systém Přenos verze 3.0

Systém Přenos verze 3.0 Systém Přenos verze 3.0 (bezpečná komunikace a automatizované zpracování dat) CTlabs spol. s r.o. Pernštejnské Janovice 28, 593 01 Bystřice nad Pernštejnem, tel/fax.: 0505-551 011 www.ctlabs.cz info@ctlabs.cz

Více

Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 Elektronická podpora zkvalitnění výuky CZ.1.07 Vzděláním pro konkurenceschopnost

Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 Elektronická podpora zkvalitnění výuky CZ.1.07 Vzděláním pro konkurenceschopnost Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 Elektronická podpora zkvalitnění výuky CZ.1.07 Vzděláním pro konkurenceschopnost Projekt je realizován v rámci Operačního programu Vzdělávání pro konkurence

Více

Průmyslová komunikace přes mobilní telefonní sítě. Michal Kahánek 22. 9. 2010

Průmyslová komunikace přes mobilní telefonní sítě. Michal Kahánek 22. 9. 2010 Průmyslová komunikace přes mobilní telefonní sítě Michal Kahánek 22. 9. 2010 Program Produkty Moxa pro mobilní komunikaci Operační módy mobilních modemů OnCell Operační módy mobilních IP modemů OnCell

Více

Inovace výuky prostřednictvím ICT v SPŠ Zlín, CZ.1.07/1.5.00/ Vzdělávání v informačních a komunikačních technologií

Inovace výuky prostřednictvím ICT v SPŠ Zlín, CZ.1.07/1.5.00/ Vzdělávání v informačních a komunikačních technologií VY_32_INOVACE_31_20 Škola Název projektu, reg. č. Vzdělávací oblast Vzdělávací obor Tematický okruh Téma Tematická oblast Název Autor Vytvořeno, pro obor, ročník Anotace Přínos/cílové kompetence Střední

Více

Zero-knowledge protokoly. Autentizační protokoly & Autentizace počítačů. Zero-knowledge protokoly. Protokoly vyšší úrovně SSL/TLS. Komponenty SSL/TLS

Zero-knowledge protokoly. Autentizační protokoly & Autentizace počítačů. Zero-knowledge protokoly. Protokoly vyšší úrovně SSL/TLS. Komponenty SSL/TLS PV157 Autentizace a řízení přístupu Autentizační protokoly & Autentizace počítačů Zero-knowledge protokoly Český překlad: protokoly s nulovým rozšířením znalostí Jdou dále než protokoly sdělující hesla

Více

Komunikační napojení účastníků na centrální depozitář cenných papírů

Komunikační napojení účastníků na centrální depozitář cenných papírů Komunikační napojení účastníků na centrální depozitář cenných papírů Obsah Článek 1 Předmět úpravy... 3 Článek 2 Význam pojmů a použitých zkratek... 3 Článek 3 Technický popis účastnického komunikačního

Více

Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 Elektronická podpora zkvalitnění výuky CZ.1.07 Vzděláním pro konkurenceschopnost

Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 Elektronická podpora zkvalitnění výuky CZ.1.07 Vzděláním pro konkurenceschopnost Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 CZ.1.07 Vzděláním pro konkurenceschopnost Projekt je realizován v rámci Operačního programu Vzdělávání pro konkurence schopnost, který je spolufinancován

Více

Studentská unie ČVUT v Praze, klub Silicon Hill. 22. února Ondřej Caletka (SU ČVUT) IPv6 nové (ne)bezpečí? 22.

Studentská unie ČVUT v Praze, klub Silicon Hill. 22. února Ondřej Caletka (SU ČVUT) IPv6 nové (ne)bezpečí? 22. IPv6 nové (ne)bezpečí? Ondřej Caletka Studentská unie ČVUT v Praze, klub Silicon Hill 22. února 2011 Ondřej Caletka (SU ČVUT) IPv6 nové (ne)bezpečí? 22. února 2011 1 / 14 Silicon Hill Studentský klub Studentské

Více

7. Aplikační vrstva. Aplikační vrstva. Počítačové sítě I. 1 (5) KST/IPS1. Studijní cíl. Představíme si funkci aplikační vrstvy a jednotlivé protokoly.

7. Aplikační vrstva. Aplikační vrstva. Počítačové sítě I. 1 (5) KST/IPS1. Studijní cíl. Představíme si funkci aplikační vrstvy a jednotlivé protokoly. 7. Aplikační vrstva Studijní cíl Představíme si funkci aplikační vrstvy a jednotlivé protokoly. Doba nutná k nastudování 2 hodiny Aplikační vrstva Účelem aplikační vrstvy je poskytnout aplikačním procesům

Více

KLASICKÝ MAN-IN-THE-MIDDLE

KLASICKÝ MAN-IN-THE-MIDDLE SNIFFING SNIFFING je technika, při které dochází k ukládání a následnému čtení TCP paketů. Používá se zejména při diagnostice sítě, zjištění používaných služeb a protokolů a odposlechu datové komunikace.

Více

Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 Elektronická podpora zkvalitnění výuky CZ.1.07 Vzděláním pro konkurenceschopnost

Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 Elektronická podpora zkvalitnění výuky CZ.1.07 Vzděláním pro konkurenceschopnost Registrační číslo projektu: CZ.1.07/1.5.00/34.0553 Elektronická podpora zkvalitnění výuky CZ.1.07 Vzděláním pro konkurenceschopnost Projekt je realizován v rámci Operačního programu Vzdělávání pro konkurence

Více

Fakulta elektrotechniky a informatiky Vysoká škola báňská - Technická univerzita Ostrava. Cvičení 5 POČÍTAČOVÁ OBRANA A ÚTOK - POU

Fakulta elektrotechniky a informatiky Vysoká škola báňská - Technická univerzita Ostrava. Cvičení 5 POČÍTAČOVÁ OBRANA A ÚTOK - POU Fakulta elektrotechniky a informatiky Vysoká škola báňská - Technická univerzita Ostrava Cvičení 5 POČÍTAČOVÁ OBRANA A ÚTOK - POU TCP/IP model Síťová (IP) vrstva - IP (Internet protokol) nejpoužívanější

Více

Desktop systémy Microsoft Windows

Desktop systémy Microsoft Windows Desktop systémy Microsoft Windows IW1/XMW1 2016/2017 Jan Fiedor ifiedor@fit.vutbr.cz Fakulta Informačních Technologií Vysoké Učení Technické v Brně Božetěchova 2, 612 66 Brno Revize 25. 10. 2016 25. 10.

Více

Obrana sítě - základní principy

Obrana sítě - základní principy Obrana sítě - základní principy 6.6.2016 Martin Pustka Martin.Pustka@vsb.cz VŠB-TU Ostrava Agenda Základní úvod, přehled designu sítí, technických prostředků a možností zabezpečení. Zaměřeno na nejčastější

Více

Co je Czech Point? Podací Ověřovací Informační Národní Terminál, zredukovat přílišnou byrokracii ve vztahu

Co je Czech Point? Podací Ověřovací Informační Národní Terminál, zredukovat přílišnou byrokracii ve vztahu Czech Point Co je Czech Point? Podací Ověřovací Informační Národní Terminál, tedy Czech POINT je projektem, který by měl zredukovat přílišnou byrokracii ve vztahu občan veřejná správa. Czech POINT bude

Více

TheGreenBow IPSec VPN klient

TheGreenBow IPSec VPN klient TheGreenBow IPSec VPN klient Konfigurační příručka k VPN routerům Planet http://www.thegreenbow.com http://www.planet.com.tw Obsah: 1. Úvod...3 1.1 Účel příručky...3 1.2 Topologie VPN sítě...3 2 VRT311S

Více

Asymetrická kryptografie a elektronický podpis. Ing. Mgr. Martin Henzl Mgr. Radim Janča ijanca@fit.vutbr.cz

Asymetrická kryptografie a elektronický podpis. Ing. Mgr. Martin Henzl Mgr. Radim Janča ijanca@fit.vutbr.cz Asymetrická kryptografie a elektronický podpis Ing. Mgr. Martin Henzl Mgr. Radim Janča ijanca@fit.vutbr.cz Obsah cvičení Asymetrická, symetrická a hybridní kryptografie Matematické problémy, na kterých

Více

Routování směrovač. směrovač

Routování směrovač. směrovač Routování směrovač směrovač 1 Předmět: Téma hodiny: Třída: _ Počítačové sítě a systémy Routování směrovač 3. a 4. ročník SŠ technické Autor: Ing. Fales Alexandr Software: SMART Notebook 11.0.583.0 Obr.

Více

1. Obecná konfigurace autentizace osob. 2. Konfigurace klienta Windows Vista

1. Obecná konfigurace autentizace osob. 2. Konfigurace klienta Windows Vista 1. Obecná konfigurace autentizace osob K autentizaci jakéhokoliv bezdrátového klienta k bezdrátové síti ISS-COP v Brně je nutné nastavit následující parametry. SSID pro učitele: ISSCOP_V1 SSID pro studenty:

Více

Certifikáty a jejich použití

Certifikáty a jejich použití Certifikáty a jejich použití Verze 1.0 Vydání certifikátu pro AIS Aby mohl AIS volat egon služby ISZR, musí mít povolen přístup k vnějšímu rozhraní ISZR. Přístup povoluje SZR na žádost OVM, který je správcem

Více

Přednáška 10. X Window. Secure shell. Úvod do Operačních Systémů Přednáška 10

Přednáška 10. X Window. Secure shell. Úvod do Operačních Systémů Přednáška 10 Přednáška 10 X Window. Secure shell. 1 X Window systém I Systém pro správu oken. Poskytuje nástroje pro tvorbu GUI (Graphical User Interface) a grafických aplikací. Nezávislý na hardwaru. Transparentní

Více

Zabezpečení v síti IP

Zabezpečení v síti IP Zabezpečení v síti IP Problematika zabezpečení je dnes v počítačových sítích jednou z nejdůležitějších oblastí. Uvážíme-li kolik citlivých informací je dnes v počítačích uloženo pak je požadavek na co

Více

Bezpečnost bezdrátové komunikace 9 Téma číslo 1: bezpečnost 10. Základy bezpečnosti komunikačních sítí 13 Bezpečnost sítě 14 Bezpečnostní politika 15

Bezpečnost bezdrátové komunikace 9 Téma číslo 1: bezpečnost 10. Základy bezpečnosti komunikačních sítí 13 Bezpečnost sítě 14 Bezpečnostní politika 15 Bezpečnost bezdrátové komunikace 9 Téma číslo 1: bezpečnost 10 KAPITOLA 1 Základy bezpečnosti komunikačních sítí 13 Bezpečnost sítě 14 Bezpečnostní politika 15 Šifrování 15 Soukromý klíč 15 Veřejný klíč

Více

Počítačové sítě. Lekce 4: Síťová architektura TCP/IP

Počítačové sítě. Lekce 4: Síťová architektura TCP/IP Počítačové sítě Lekce 4: Síťová architektura TCP/IP Co je TCP/IP? V úzkém slova smyslu je to sada protokolů používaných v počítačích sítích s počítači na bázi Unixu: TCP = Transmission Control Protocol

Více

EXTRAKT z české technické normy

EXTRAKT z české technické normy EXTRAKT z české technické normy Extrakt nenahrazuje samotnou technickou normu, je pouze informativním ICS 35.240.60 materiálem o normě. Systémy dopravních informací a řídicí systémy (TICS) Datová rozhraní

Více

Šifrování (2), FTP. Petr Koloros p.koloros [at] sh.cvut.cz. http://sut.sh.cvut.cz

Šifrování (2), FTP. Petr Koloros p.koloros [at] sh.cvut.cz. http://sut.sh.cvut.cz Šifrování (2), FTP Petr Koloros p.koloros [at] sh.cvut.cz http://sut.sh.cvut.cz Obsah Úvod do šifrování FTP FTP server ProFTPd Šifrovaný přístup Virtuální servery Síť FTPek na klíč FTP File Transfer Protokol

Více

Popis zapojení jednotlivých provozních režimů WELL WRC7000N WiFi GW/AP/klient/repeater/switch, 300 Mb/s, R-SMA

Popis zapojení jednotlivých provozních režimů WELL WRC7000N WiFi GW/AP/klient/repeater/switch, 300 Mb/s, R-SMA JOYCE ČR, s.r.o., Fakturační adresa: Venhudova 6, 614 00 Brno, ČR, Korespondenční adresa: Venhudova 6, 614 00 Brno, ČR IČO: 25317571, DIČ: CZ25317571, Tel.: +420 539 088 010, Fax: +420 539 088 000, E-mail:

Více

UKRY - Symetrické blokové šifry

UKRY - Symetrické blokové šifry UKRY - Symetrické blokové šifry Martin Franěk (frankiesek@gmail.com) Fakulta jaderná a fyzikálně inženýrská, ČVUT Praha 18. 3. 2013 Obsah 1 Typy šifer Typy šifer 2 Operační mody Operační mody 3 Přiklady

Více

ElGamal, Diffie-Hellman

ElGamal, Diffie-Hellman Asymetrické šifrování 22. dubna 2010 Prezentace do předmětu UKRY Osnova 1 Diskrétní logaritmus 2 ElGamal 3 Diffie-Hellman Osnova 1 Diskrétní logaritmus 2 ElGamal 3 Diffie-Hellman Osnova 1 Diskrétní logaritmus

Více

Adaptabilní systém pro zvýšení rychlosti a spolehlivosti přenosu dat v přenosové síti

Adaptabilní systém pro zvýšení rychlosti a spolehlivosti přenosu dat v přenosové síti 1 Adaptabilní systém pro zvýšení rychlosti a spolehlivosti přenosu dat v přenosové síti Oblast techniky V oblasti datových sítí existuje různorodost v použitých přenosových technologiích. Přenosové systémy

Více

9. Sítě MS Windows. Distribuce Windows. Obchodní označení. Jednoduchý OS pro osobní počítače, pouze FAT, základní podpora peer to peer sítí,

9. Sítě MS Windows. Distribuce Windows. Obchodní označení. Jednoduchý OS pro osobní počítače, pouze FAT, základní podpora peer to peer sítí, 9. Sítě MS Windows MS Windows existoval ve 2 vývojových větvích 9x a NT, tyto později byly sloučeny. V současnosti existují aktuální verze Windows XP a Windows 2003 Server. (Očekává se vydání Windows Vista)

Více

Správa přístupu PS3-2

Správa přístupu PS3-2 Bezpečnost informací BI Ing. Jindřich Kodl, CSc. Správa přístupu PS3-2 1 Osnova II základní metody pro zajištění oprávněného přístupu; autentizace; autorizace; správa uživatelských účtů; srovnání současných

Více

12. Virtuální sítě (VLAN) VLAN. Počítačové sítě I. 1 (7) KST/IPS1. Studijní cíl. Základní seznámení se sítěmi VLAN. Doba nutná k nastudování

12. Virtuální sítě (VLAN) VLAN. Počítačové sítě I. 1 (7) KST/IPS1. Studijní cíl. Základní seznámení se sítěmi VLAN. Doba nutná k nastudování 12. Virtuální sítě (VLAN) Studijní cíl Základní seznámení se sítěmi VLAN. Doba nutná k nastudování 1 hodina VLAN Virtuální síť bývá definována jako logický segment LAN, který spojuje koncové uzly, které

Více

Uživatelská dokumentace

Uživatelská dokumentace Uživatelská dokumentace k projektu CZECH POINT Popis použití komerčního a kvalifikovaného certifikátu Vytvořeno dne: 20.5.2008 Aktualizováno: 23.5.2008 Verze: 1.3 Obsah Uživatelská dokumentace...1 Obsah...2

Více

Cisco Networking Accademy. 7. Bezdrátové sítě (Wireless Networks)

Cisco Networking Accademy. 7. Bezdrátové sítě (Wireless Networks) Cisco Networking Accademy 7. Bezdrátové sítě (Wireless Networks) Elektromagnetické spektrum vlnová délka a frekvence vhodnost pro různé technologie licenční vs. bezlicenční použití zdravotní omezení IRF

Více

[ 1 ] Ing. Tomáš Melen náměstek pro informatiku a ekonomiku 2009 Státní ústav pro kontrolu léčiv

[ 1 ] Ing. Tomáš Melen náměstek pro informatiku a ekonomiku 2009 Státní ústav pro kontrolu léčiv [ 1 ] [ 2 ] Přístup pro účastníky správních řízení Přístup pro farmaceutické firmy [ 3 ] Program prezentace Cíle prezentovaného řešení Představení prezentovaného řešení Diskuse a dotazy [ 4 ] Cíle prezentovaného

Více

Základy kryptografie. Beret CryptoParty 11.02.2013. 11.02.2013 Základy kryptografie 1/17

Základy kryptografie. Beret CryptoParty 11.02.2013. 11.02.2013 Základy kryptografie 1/17 Základy kryptografie Beret CryptoParty 11.02.2013 11.02.2013 Základy kryptografie 1/17 Obsah prezentace 1. Co je to kryptografie 2. Symetrická kryptografie 3. Asymetrická kryptografie Asymetrické šifrování

Více

Michaela Sluková, Lenka Ščepánková 15.5.2014

Michaela Sluková, Lenka Ščepánková 15.5.2014 ČVUT FJFI 15.5.2014 1 Úvod 2 3 4 OpenPGP Úvod Jak? Zašifrovat email lze pomocí šifrování zprávy samotné či elektronickým podpisem emailových zpráv. Proč? Zprávu nepřečte někdo jiný a nemůže být změněna,

Více

DNSSEC Validátor - doplněk prohlížečů proti podvržení domény

DNSSEC Validátor - doplněk prohlížečů proti podvržení domény DNSSEC Validátor - doplněk prohlížečů proti podvržení domény CZ.NIC z.s.p.o. Martin Straka / martin.straka@nic.cz Konference Internet a Technologie 12 24.11.2012 1 Obsah prezentace Stručný úvod do DNS

Více

IPSec na platformě Juniper (CLI+GUI), kompatibilita s prvky Cisco

IPSec na platformě Juniper (CLI+GUI), kompatibilita s prvky Cisco IPSec na platformě Juniper (CLI+GUI), kompatibilita s prvky Cisco Marek Kotraš, Peter Habčák Abstrakt: Cílem tohoto projektu je ověření funkčnosti protokolu IPSec na platformě JUNIPER a kompatibility s

Více

Síťové protokoly. Filozofii síťových modelů si ukážeme na přirovnání:

Síťové protokoly. Filozofii síťových modelů si ukážeme na přirovnání: Provoz na síti musí být řízen určitými předpisy, aby dorazila na místo určení a nedocházelo ke kolizím. Tato pravidla se nazývají síťové protokoly. Síťových protokolů je mnoho, a každý zajišťuje specifickou

Více

Základní definice Aplikace hašování Kontrukce Známé hašovací funkce. Hašovací funkce. Jonáš Chudý. Úvod do kryptologie

Základní definice Aplikace hašování Kontrukce Známé hašovací funkce. Hašovací funkce. Jonáš Chudý. Úvod do kryptologie Úvod do kryptologie Základní definice Kryptografická hašovací funkce Kryptografickou hašovací funkcí nazveme zobrazení h, které vstupu X libovolné délky přiřadí obraz h(x) pevné délky m a navíc splňuje

Více

PSK2-16. Šifrování a elektronický podpis I

PSK2-16. Šifrování a elektronický podpis I PSK2-16 Název školy: Autor: Anotace: Vzdělávací oblast: Předmět: Vyšší odborná škola a Střední průmyslová škola, Božetěchova 3 Ing. Marek Nožka Jak funguje asymetrická šifra a elektronický podpis Informační

Více

Šifrování dat, kryptografie

Šifrování dat, kryptografie Metody a využití Šárka Vavrečková Ústav informatiky, FPF SU Opava sarka.vavreckova@fpf.slu.cz Poslední aktualizace: 5. prosince 201 Úvod do kryptografie Kryptografie a kryptoanalýza Co to je kryptografie

Více