Autentizace síťových portů pomocí protokolu 802.1x ve firemním prostředí

Transkript

1 Mendelova univerzita v Brně Provozně ekonomická fakulta Autentizace síťových portů pomocí protokolu 802.1x ve firemním prostředí Diplomová práce Vedoucí práce: Ing. Petr Jedlička, Ph.D. Bc.Tomáš Malinka Brno 2013

2 Poděkování Děkuji společnosti, v níž bylo 802.1x implementováno, za poskytnuté zázemí při tvorbě této práce. Dále bych chtěl poděkovat společnosti Per4mance s.r.o. za cenné rady a připomínky při psaní této práce a vedoucímu práce Ing. Petru Jedličkovi, Ph.D.

3 Čestné prohlášení Prohlašuji, že jsem práci: Autentizace síťových portů pomocí protokolu 802.1x ve firemním prostředí vypracoval samostatně a veškeré použité prameny a informace uvádím v seznamu použité literatury. Souhlasím, aby moje práce byla zveřejněna v souladu s 47b zákona č. 111/1998 Sb., o vysokých školách ve znění pozdějších předpisů a v souladu s platnou Směrnicí o zveřejňování vysokoškolských závěrečných prací. Jsem si vědom, že se na moji práci vztahuje zákon č. 121/2000 Sb., autorský zákon, a že Mendelova univerzita v Brně má právo na uzavření licenční smlouvy a užití této práce jako školního díla podle 60 odst. 1 autorského zákona. Dále se zavazuji, že před sepsáním licenční smlouvy o využití díla jinou osobou (subjektem) si vyžádám písemné stanovisko univerzity, že předmětná licenční smlouva není v rozporu s oprávněnými zájmy univerzity, a zavazuji se uhradit případný příspěvek na úhradu nákladů spojených se vznikem díla, a to až do jejich skutečné výše. V Brně dne 20. prosince 2013

4 Abstract Malinka, T. Network authentication using 802.1x ports in the corporate environment. Diploma thesis. Brno, This thesis describes the draft and implementation of a new security with 802.1x in the corporate environment. The work is divided into two parts. The first part outlines the topic theoretically and the second part solves specific draft using 802.1x and its implementation in the corporate environment. The implementation is outlined with configuration of end clients, switches including RADIUS server and settings in AD. During the implementation, there is also described the authentication of devices by Mac Authentication Bypass. Keywords 802.1x, RADIUS, EAP, AAA architecture, authentication, authorization, accounting. Abstrakt Malinka, T. Autentizace síťových portů pomocí protokolu 802.1x ve firemním prostředí. Diplomová práce. Brno, Diplomová práce se zabývá návrhem a implementací nového zabezpečení na perimetru sítě pomocí 802.1x ve firemním prostředí. Práce je rozdělena na několik částí, kde v první části je popsáno zpracovávané téma teoreticky, v další části je pak řešen konkrétní návrh pomocí 802.1x a jeho implementace v reálném firemním prostředí. Implementace je popsána včetně konfigurace koncových klientů, switchů i RADIUS serveru a nastavení v AD. Součástí implementace je i autentizace zařízení pomocí Mac Authentication Bypass. Klíčová slova 802.1x, RADIUS, EAP, AAA architektura, autentizace, autorizace, účtování.

5 Obsah 5 Obsah 1 Úvod a cíl práce Úvod Cíl práce Bezpečnost sítě Pohled na bezpečnost Bezpečnost z hlediska infrastruktury AAA architektura Zabezpečení přístupu k síti pomocí AAA Autentizace Metody autentizace Autorizace Accounting Protokoly využívané v architektuře AAA TACACS TACACS Kerberos Diameter RADIUS Proces autentizace a autorizace v protokolu RADIUS Proces účtování v protokolu RADIUS Atributy RADIUS Srovnání protokolů RADIUS a TACACS Protokol 802.1x Komponenty 802.1x Výhody 802.1x Nevýhody 802.1x Protokoly 802.1x... 34

6 Obsah EAP protokol Metody EAP MD5-Challenge LEAP EAP-TLS EAP-TTLS EAP-MSChapV PEAP EAPoL Porty v autorizovaném a neautorizovaném stavu Podporované topologie Posloupnosti operací Inicializace Autentizace Autorizace Účtování Ukončení Analýza Firemní standard Stávající firemní zabezpečení Port security Spanning tree VLAN Omezený počet MAC adres na switchi ACL Návrh nového zabezpečení Výhody 802.1x v konkrétním firemním prostředí Nevýhody v konkrétním firemním prostředí Potřebný hardware a software Implementace 50

7 Obsah Konfigurace 802.1x na koncových klientech Zapnutí autentizační služby na počítači Konfigurace síťového rozhraní Automatické zapnutí služby a konfigurace síťového rozhraní Připojení k síti Ostatní zařízení Konfigurace 802.1x na switchi Umožnění autentizace 802.1x na switchi Konfigurace 802.1x na RADIUS serveru Instalace a konfigurace NPS Konfigurace síťových zásad Redundantní RADIUS server MAB Kontrola logů Omezení výrobní haly Rozšíření implementace do budoucna Závěr 72 9 Literatura 74 A Seznam zkratek 78

8 Seznam obrázků 8 Seznam obrázků Obr. 1 Vnitřní a 13 Obr. 2 Autentizace pomocí 802.1x 13 Obr. 3 Výměna požadavků mezi klientem, NAS a 21 Obr. 4 RADIUS účtování 22 Obr. 5 Formát atributu RADIUS 23 Obr. 6 RADIUS versus TACACS+ 25 Obr. 7 Rozdíli v umístění mezi RADIUS a 26 Obr. 8 Ukázka provozu u 28 Obr. 9 Ukázka provozu u 29 Obr. 10 Přístup na portu před a 30 Obr. 11 Role jednotlivých zařízení 802.1x 31 Obr. 12 Jednotlivé komponenty 802.1x 33 Obr x kabelové připojení 37 Obr. 14 EAPoL komunikace 38 Obr. 15 Wifi LAN připojení 40 Obr. 16 Jednotlivé posloupnosti operací 802.1x 41 Obr. 17 Služby ve Windows 7 51 Obr. 18 Vlastnosti služby ve Windows 7 52 Obr. 19 Vlastnosti připojení k místní síti 54 Obr. 20 Rack osazený třemi cisco switchi 55 Obr. 21 Konfigurace portu switche v průběhu testování 60 Obr. 22 Instalace NPS výběr Role 62

9 Seznam obrázků 9 Obr. 23 Instalace NPS přes Server Manager 62 Obr. 24 Vytváření nového RADIUS klienta 63 Obr. 25 Specifikace povolení přístupu 64 Obr. 26 Specifikace jednotlivých parametrů 66 Obr. 27 NPS Event Viewer 69 Obr. 28 Kiwi Log Viewer 70

10 Seznam tabulek 10 Seznam tabulek Tab. 1 Funkce RADIUS versus TACACS+ 25 Tab. 2 Formát rámce EAPoL 37 Tab. 3 Typy paketu 37 Tab. 4 Mechanismy ukončení relace. 43

11 Úvod a cíl práce 11 1 Úvod a cíl práce 1.1 Úvod Zabezpečení firemní síťové infrastruktury patří v praxi k hlavním prioritám. Důvodem, proč nelze otázky zabezpečení zanedbávat, je řada jak vnějších, tak i vnitřních hrozeb, které ohrožují důležitá firemní aktiva. Na existující rizika musíme reagovat implementací adekvátních bezpečnostních opatření na různých úrovních síťové infrastruktury. Jednou z možností zabezpečení vnitřní firemní infrastruktury na úrovni řízení přístupu je i implementace 802.1x. Tento protokol, přesněji IEEE 802.1x protokol, umožňuje ochranu a zabezpečení přístupu k síťovým prostředkům a k informačním systémům na úrovni jednotlivých komunikačních portů. Jedná se o protokol, jenž umožňuje využívat spolehlivou autentizaci jednotlivých koncových zařízení napříč celou firemní infrastrukturou. Důležitým aspektem autentizace koncových klientů je také kompatibilita veškerých využívaných komponentů a technologií s protokolem 802.1x. Pro potřeby autentizace koncových klientů je třeba nakonfigurovat nejen koncové klienty nebo switche, ale také RADIUS servery a AD. Hlavní předností protokolu 802.1x je zamezení přístupu neautentizovaným zařízením a uživatelům do firemní infrastruktury. Mezi další výhody patří také lepší správa a monitorování přístupu uživatelů do sítě. V neposlední řadě je přínosem i zjednodušení přiřazování VLAN k jednotlivým portům, a tím přehlednější a lépe spravovatelné nastavení přiřazování přístupu uživatelů a zařízení k jednotlivým firemním zdrojům. 1.2 Cíl práce Cílem této práce je návrh a implementace nového optimálního způsobu zabezpečení přístupu do vnitřní počítačové sítě konkrétní firmy pomocí 802.1x. Hlavním cílem práce je konfigurace firemních koncových klientů, jež se musí autentizovat do počítačové sítě, konfigurace switchů a instalace a konfigurace RADIUS serveru. Návrh nového způsobu zabezpečení pomocí 802.1x obsahuje také návrh autentizace jednotlivých zařízení v daném firemním prostředí a výběr správných metod autentizace s využitím 802.1x s ohledem na funkčnost celého návrhu v praktickém každodenním provozu.

12 Bezpečnost sítě 12 2 Bezpečnost sítě 2.1 Pohled na bezpečnost Každá počítačová síť by měla být navržena tak, aby vyhovovala všem požadavkům na bezpečnost sítě. Na bezpečnost počítačových sítí je v dnešní době kladen velký důraz, hlavně pak kvůli zabezpečení citlivých dat, které by mohl potenciální útočník zneužít. Jednou z definic bezpečnosti, kterou uvádí server je: Pod pojmem bezpečnost IT obvykle rozumíme ochranu odpovídajících IS a informací, které jsou v nich uchovávány, zpracovávány a přenášeny. Součástí takto obecně chápané bezpečnosti IT je i komunikační bezpečnost, tj. ochrana informace přenášené mezi počítači, fyzická bezpečnost, tj. ochrana před přírodními hrozbami a fyzickými útočníky a personální bezpečnost, tj. ochrana před vnitřními útočníky. (Gity, 2005) Bezpečnost počítačových sítí mohou narušovat různé typy útoků, a to buď pasivní, nebo aktivní. Mezi pasivní útoky lze zahrnout tzv. odposlouchávání, kdy je snahou útočníka pomocí odposlouchávání získat určitá data, která by mohl později zneužít. Aktivní útoky jsou ve většině případů lépe rozeznatelné oproti pasivním. Hlavní snahou aktivních útoků je modifikace dat, nebo vytváření falešných dat. (Informatika, 2007) 2.2 Bezpečnost z hlediska infrastruktury Aby se těmto útokům předešlo, je vhodné myslet na zabezpečení sítě již při jejím návrhu, tedy při vytváření celkové topologie sítě. Jedním z prostředků pro bezpečnost je seskupování počítačů se stejnými, nebo podobnými nároky do jednotlivých podsítí a vytvoření DMZ Demilitarized zone. Demilitarizovaná zóna je většinou samostaná zóna, oddělená od ostatních zařízení v síti, zprostředkovávající určité služby. DMZ je většinou přístupná jak z vnější, tak z vnitřní sítě, ovšem s různorodými pravidly, kdy přistup z vnější sítě má omezenější pravidla než z vnitřní. (Vymazal, 2003)

13 Bezpečnost sítě 13 Vnitřní a vnější síť, DMZ Obr. 1 Zdroj: Pro zabezpečení sítě se kombinuje zpravidla více bezpečnostních opatření souběžně. Mezi základní bezpečnostní prvky patří antivirový software a firewall, který má za cíl ochránit jak neoprávněný přístup z vnější sítě WAN do vnitřní sítě, tak omezit přístupy v rámci vnitřní sítě. Neoprávněné přístupy v rámci vnitřní sítě se mohou řešit více způsoby, jedním z takovýchto opatření je využití autentizace uživatelů pomocí 802.1x. Obr. 2 Autentizace pomocí 802.1x Zdroj:

14 AAA architektura 14 3 AAA architektura 3.1 Zabezpečení přístupu k síti pomocí AAA Architektura AAA (Authentication, Authorization, Accounting), neboli autentizace, autorizace a účtování, poskytuje rozšířené zabezpečení síťové infrastruktury. Kromě autentizace uživatele (zařízení), poskytuje i mechanismy pro přidělování přístupových práv ke zdrojům a disponuje prostředky pro účtování využívání těchto zdrojů. (Horáková, 2013) Neoprávněný přístup do firemní sítě a popření identity může znamenat potenciální hrozbu útočníka na firemní prostředí a zneužití síťových služeb a zařízení ve firmě. Tomuto se snaží předcházet architektura AAA, která si klade za cíl zamezení neoprávněného přístupu i popření identity. (Kalina, 2010) Autentizace Autentizace poskytuje metodu identifikace uživatele, kdy musí každý uživatel prokázat svoji totožnost. Musí tedy dokázat, že je to opravdu on, za koho se vydává, a to za pomoci uživatelského hesla a jména, výzvy a odpovědi, tokenové karty, nebo jinou metodou ověření (Wenstrom, 2003). Mimo ověření na základě znalosti (hesla), vlastnictví (token, čipová karta apod.) lze využít i biometrické ověření otiskem prstu na snímači, nebo za pomocí snímání oční rohovky, kterou má každý jedinec odlišnou. Autentizace může být buď jednosměrná, kdy se autentizuje pouze jedna strana vůči druhé, nebo obousměrná, kdy se autentizují obě strany navzájem. (Kalina, 2010) Metody autentizace Při přístupu uživatele do sítě jej potřebujeme autentizovat. K tomu můžeme využít jednu z následujících metod: Bez uživatelského jména a hesla Tato metoda autentizace je nejméně vhodná a nejméně bezpečná. Uživateli stačí přijít pouze na správnou metodu přístupu do sítě a již se dostane do této části síťového systému bez nutnosti znalosti hesla. Využívá se hlavně ve veřejných sítích, kde je minimální požadavek na bezpečnostní politiku, nebo kde je bezpečnost zajištěna jiným prvkem. Například lze využít seznam pro řízení přístupu, tzv. ACL (access control list). (Wenstrom, 2003) Statické uživatelské jméno a heslo Uživatelské jméno a heslo, jenž se používá k autentizaci, je v případě statického nastavení je po celou dobu stejné, dokud není změneno samotným uživatelem nebo systémovým administrátorem. Odposlechem hesla cizí osobou může dojít k dlouhobému a neoprávněnému využívání tohoto hesla pro přístup do sítě. Takto zneužité heslo a neoprávněný přístup není ihned

15 AAA architektura 15 zřetelný, pokud si toho sám uživatel nevšimne. Například kontrolou logování místa a času přihlášení pod jeho uživatelským jménem, které neučinil on sám. (Wenstrom, 2003) Uživatelské jméno a heslo se stárnutím Metoda hesla se stárnutím je založena na platnosti hesla po omezenou dobu. Po této době, zpravidla 3 mesíců, heslo vyprší a musí se obnovit. Takové heslo je sice prolomitelné, ale v menší míře než statické jméno a heslo. (Wenstrom, 2003) Záleží na konkrétním nastavení, jestli je po expirování původního hesla umožněn alespoň přístup do systému a změna hesla, nebo je přístup odepřen uplně a musí se žádat administrátor o nové heslo. Při autentizaci u 802.1x by byla změna hesla obtížná. Daleko lepším způsobem je využít automatický , který uživatele upozorní v určitém časovém předstihu, že jeho heslo expiruje. (Kalina, 2010) Jednorázové heslo (OTP) Jednorázové heslo, neboli tzv. One-time password je jednou z nejbezpečnějších metod přihlašování postavenou na uživatelském jménu a heslu. Jednorázové heslo je platné pouze pro jedno přihlášení, takže není náchylné k útokům přehrávání. Pokud je již jednou použité heslo odposlechnuto, stává se bezcenným. Tato metoda je založena na tajné přístupové frázi, podle níž se vygeneruje seznam hesel, kde samotná přístupová fráze umožňuje pouze jedno přihlášení. Podobná metoda jednorázových hesel S/Key se využívá hlavně u terminálových přihlášení.(wenstrom, 2003) S/Key, jednorázové heslo pro přihlášení z terminálu Oproti metodě jednorázových hesel, se zde generuje první heslo pomocí tajné přístupové fráze a každé další heslo je generováno na základě šifrování hesla předchozího. Serverový software S/Key vygeneruje seznam dostupných hesel, odkud se distribuují uživatelům. (Wenstrom, 2003) Tokenové karty Je jedna z velmi silných a vůči útokům odolných metod, založena na vlastnictví unikátního zařízení, zpravidla v podobě tokenové karty, a znalosti, nejčastěji v podobě PINU tokenové karty. Tokenová karta se složitostí kalkulačky a velikosti kreditní karty funguje na principu vygenerování bezpečného hesla po zadání PINU. Toto bezpečné heslo se využívá pro bezpečné přihlášení, kdy se kontroluje přes tokenový server, jenž ověří jeho platnost. Tato metoda je velmi spolehlivá a odolná vůči neoprávněným útokům, ovšem zárověň i velmi složitá, proto se v rámci klasického přihlašování do počítačových sítí moc nepoužívá. (Kalina, 2010) Certifikáty Další metodou bezpečné autentizace do sítě je využití osobního certifikátu, který je elektronicky ověřen a nahrazuje tzv. průkaz totožnosti. Může být

16 AAA architektura 16 uložen buď přimo v počítači uživatele, nebo na externím datovém zařízení. Tento osobní elektronicky podepsaný certifikát je datovou strukturou umožňující ověření konkrétního uživatele. Kromě ověření uživatele při přístupu do sítě může být využit při vzdáleném přihlášení uživatele přes VPN do firemního prostředí, pro šifrování dat, nebo pro elektronické podepisování. (Kalina, 2010) Autorizace Autorizace, neboli přidělení oprávnění, následuje po správné autentizaci. Tato služba rozhoduje o přidělení prostředků, ke kterým bude mít uživatel přístup, a povolí operace, jaké může uživatel s těmito prostředky provádět. (Wenstrom, 2003) Lze nastavit například restrikce v podobě přístupu do sítě pro konkrétní uživatele v určitém časovém rozmezí nebo zajistit přístup ke specifickým složkám pouze pro uživatele s určitými právy. Princip autorizace nemusí být vždy jako samostatný proces, ale právě u radius protokolu probíhá autentizace a autorizace soušasně. (Kalina, 2010) Accounting Jedná se o mechanismus poskytující jednotlivé prostředky pro zaznamenávání a měření využívání zdrojů uživatelem. Zaznamenává tedy vše, co uživatel v systému dělal a k jakým prostředkům přistupoval. Zaznamenaná data se dají využít při pozdějším auditu, při dokazování přístupu, nebo například pro stanovení poplatků. Pomocí účtování lze sledovat využívání síťových prostředků a detekovat přístup do sítě. (Wenstrom, 2003) 3.2 Protokoly využívané v architektuře AAA V architektuře AAA se využívají hlavně následující protokoly: TACACS, TACACS+, DIAMETER a RADIUS. Případně v kombinaci s těmito zmíněnými i další protokoly, jako je LDAP, PPP, nebo EAP. (Kalina, 2010) TACACS Vzdálený autentizační protokol TACACS (Terminal Access Controller Access- Control System) vyvinutý firmou Cisco systems se využívá pro komunikaci s autentizačním serverem. Tento protokol používá TCP nebo UDP a standardně port 49. Protokol je popsaný v dokumentu RFC 1492 a běžně se používá ve spojení s unixovým systémem. TACACS umožňuje vzdálenému přístupovému serveru komunikovat s autentizačním serverem, aby rozhodl, zda má uživatel přístup do sítě či nikoli. (Finseth, 1993) Principem TACACS je odesílání uživatelského jména a hesla na unixový TACACS autentizační server TACACS démon, označovaný též jako TACACSD. Tento autentizační server rozhodne, zda požadavek příjme nebo zamítne, a odpověď na požadavek zašle zpět. Starší verzi protokolu TACACS nahradil novější protokol nazývaný XTACACS. Tento protokol byl již také nahrazen

17 AAA architektura 17 novějšími modernějšími protokoly jako TACACS+, RADIUS nebo DIAMETER. (Wenstrom, 2003) TACACS+ Tento AAA protokol částečně vychází z TACACS protokolu, ovšem není s tímto starším protokolem zpětně kompatibilní. Protokol byl původně vytvořený pro americké ministerstvo obrany pro autentizaci síťových zařízení například routery, switche či firewally. Aktuální verze tohoto standardu byla vyvinuta firmou Cisco Systems. TACACS+ je od RADIUS protokolu odlišný hlavně v tom, že jednotlivé AAA služby odděluje zvlášť, naopak RADIUS autentizaci aautorizaci spojuje do jednoho celku. Další odlišností TACACS+ je využívání spolehlivého TCP na portu 49, oproti DIAMETER protokolu využívajícího nespolehlivý UDP. TACACS+ zjednodušuje správu sítě a zvyšuje bezpečnost dané sítě. Je to dáno centralizací správy uživatelů na síti a možností jednotlivého nastavení politik přístupu uživatelů a skupin, příkazů, umístění, času, masky nebo typu zařízení. Protokol TACACS+ zaznamenává do svých logů kompletní přehled o činnostech, tedy každý login uživatele, včetně všech příkazů, které byly uživatelem použity. Tento protokol je v souladu se všemi bezpečnostními normami, a proto je doporučován pro nasazení například ve finančnictví, v systémech určených pro lékařství nebo ve vládní sféře. (TACACS.net, 2010) Kerberos Síťový autentizační protokol Kerberos je podrobně popsaný v RFC Tento protokol zajišťuje bezpečnou autentizaci neboli bezpečné ověření uživatele přes nezabezpečenou síť. Protokol byl vyvinut v Massachusetts Institute of Technology jako součást projektu Athena. Dříve vytvořený protokol Kerberos v4 byl později přepracován na nynější v5, kde bylo doplněno mnoho funkcí, které v předchozí verzi chybí. Autentizace jednotlivých uživatelů za pomoci modelu Kerberos je založena na důvěryhodné třetí straně. (Burda, 2005) Primárně byl vytvořen pro model vzájemné autentizace klient-server, kdy si ověří klient i server navzájem svou identitu. Kerberos využívá symetrickou kryptografii, a je volně dostupný z MIT, s velmi podobnými autorskými právy jako BSD. MIT poskytuje Kerberos ve formě zdrojového kódu. Každý, kdo chce tento protokol využít, si ho může sám prohlédnout a ujistit se, že je bezpečný. (MIT, 2013) Jak bylo popsáno výše, při autentizaci se využívá důvěryhodné třetí strany. V případě Kerberos je důvěryhodnou třetí stranou služba KDC (Key Distribution Center) spuštěna v každém řadiči domény, jako součást adresářové služby Active Directory. KDC spravuje databázi uživatelů, tedy zajišťuje uložení všech hesel klienta a dalších důležitých informací o účtu. Uživatel v systému klienta za pomoci hesla prokáže svou vlastní identitu službě KDC. Následkem toho tato služba odpoví tím, že klientovi vystaví speciální tiket (Ticket-Granting Ticket). S tímto tiketem získává klient přístup ke službě TGS (Ticket-Granting Service), jenž je součástí metody ověřování. Služba TGS následné klientovi vystaví tzv. lístek služby,

18 AAA architektura 18 s kterým může klient nejen prokazovat svoji identitu službě, ale zároveň lze prokázat identitu služby pro klienta. (Microsoft, 2013a) Diameter Diameter je protokol AAA architektury využívaný pro přístup k síti. Jedná se o rozšířeného následovníka protokolu RADIUS, který není zpětně přímo kompatibilní, ale poskytuje rozšířenou cestu pro RADIUS. Hlavním bodem, značícím že se jedná o rozšíření RADIUS protokolu, vyplývá už ze samotného názvu Diameter, tedy v překladu do češtiny průměr. Oproti tomu název RADIUS je v českém překladu pouze poloměr. Byl vyvinut, aby splňoval stále rostoucí nároky a požadavky kladené na AAA protokoly. Jedním z hlavních rozdílů mezi RADIUS protokolem a Diameter protokolem je ten, že Diameter protokol využívá spolehlivý transportní protokol TCP nebo SCTP, kdežto RADIUS využívá nespolehlivý UDP. Tento protokol je důkladně popsán v RFC Ve spojení s Diameter protokolem lze využít zabezpečení, které tento protokol podporuje, a to Ipsec (povinný) nebo TLS (volitelný). Omezení adresního prostoru pro AVPs (Attribute Value Pairs) neboli dvojice hodnot atributů se zvětšilo na 32 bitů, oproti 8 bitům u RADIUS. Dále je možné využít u tohoto protokolu stavový i bezstavový model. V rámci inovací tohoto protokolu bylo modifikováno například dynamické objevování sousedů, což bylo u předchozího protokolu řešeno staticky, zavedení schopnosti vyjednávání, oznamování chyb nebo vylepšenou podporou roamingu. Tento protokol je zarovnaný na 32 bitové hranice a snadněji rozšířitelný. (Red Hat, 2013) RADIUS RADIUS protokol (Remote Authentication Dial in User Service) neboli Uživatelská vytáčená služba pro vzdálenou autentizaci je jeden z dalších AAA protokolů popsaný v RFC Radius Accounting neboli Účtování RADIUS je zase popsané v RFC Tento distribuovaný protokol zamezuje neoprávněnému přístupu do sítě a tím zajišťuje její bezpečnost. V RADIUS protokolu je služba autentizace a autorizace sloučena, naopak služba účtování je samostatně. Tento protokol byl vyvinut firmou Livingston Enterprises, která se stala později součástí společnosti Lucent Technologies. RADIUS je možné využívat ve spojení s ostatními AAA protokoly, kterými jsou TACACS+ nebo KERBEROS, případně s lokálními databázemi zabezpečení. Firma Cisco podporuje RADIUS protokol u celé řady aktivních prvků, síťových přístupových serverů, směrovačů, přepínačů sítě Ethernet, PIX Firewallů, koncentrátorů řady VPN 3000 a přístupových serverů CiscoSecure ACS. Protokol RADIUS je implementován v mnoha síťových prvcích, kde je vyžadováno zvýšeného stupně zabezpečení. Jedná se o plně otevřený protokol, který je distribuován v podobě zdrojového kódu. Toto umožňuje jakoukoliv úpravu pro spolupráci s libovolným dostupným systémem zabezpečení. Jeho masivní rozšíření je způsobeno mimo jiné možností rozšíření dvojic atributů a hodnot výrobcem mimo původní specifikaci popsanou v RFC RADIUS

19 AAA architektura 19 stanovuje atribut, jenž je závislý na výrobci. Zde mohou jednotlivý výrobci sami podporovat rozdílné rozšířené atributy. Tato možnost, kterou výrobci mají, může někdy způsobovat nestandardní chování a nejednotnost produktů pro servery zabezpečení, jelikož si může každý výrobce zvolit jiné rozdílné atributy. (Wenstrom, 2003) Hlavním účelem RADIUS protokolu, jak již bylo zmíněno dříve, je autentizace uživatelů na síti, uložených v databázi na serveru zvaném RADIUS server. Při připojování uživatelů do sítě vyzve switch tyto uživatele k autentizaci a autentizační údaje předává na RADIUS server ke kontrole. Na základě výsledku, oproti databázi povolených uživatelů, RADIUS server informuje switch, jestli může být uživateli povolen přístup do sítě nebo nikoliv. Switch podle této informace od RADIUS serveru povolí nebo zakáže uživateli přístup do sítě. RADIUS server má širší rozsah pravomocí, než jen povolení či zakázání přístupu uživatelů do sítě. RADIUS server může posílat zpět informace o připojených uživatelích, jako jsou jejich IP adresy nebo VLANy, do kterých by měl mít uživatel přístup. Mimo těchto parametrů poskytuje RADIUS server také účetní služby. Naopak switch informuje RADIUS server o tom, jak dlouho byli jednotliví uživatelé připojení k síti, nebo kolik daný uživatel odeslal či přijal paketů. Přístupový switch přijme uživatelské jméno a heslo, pomocí PAP (Password Authentication Protocol) nebo pomocí CHAP (Challenge Handshake Authentication Protocol), a předá toto uživatelské jméno spolu s heslem na RADIUS server kvůli autentizaci. Na tento požadavek o ověření odpoví RADIUS server klientovi pomocí PAP nebo CHAP v podobě povolení nebo zakázání požadavku. Ve většině případů bývá uložena databáze uživatelů přímo na RADIUS serveru. NAS (Network Access Server) je switch, přes který se uživatelé připojují do sítě, a který komunikuje s RADIUS serverem pomocí výměny RADIUS atributů. Uživatelská jména i hesla jsou v této komunikaci považovány za atributy RADIUS paketů a jsou posílána pomocí výměny paketů spolu s ostatními posílanými informacemi v této komunikaci. (Allied Telesis, 2012a) Proces autentizace a autorizace v protokolu RADIUS Autentizace a autorizace u RADIUS využívá několik paketů pro vzájemnou komunikaci. Mezi tyto pakety patří Access-Request, Access-Accept, Access-Reject a Access-Challenge. Vzájemná komunikace při autentizaci a autorizaci je podle serveru (Allied Telesis, 2012a) následující: Prvotní inicializace požadavku o přístup do sítě je ze strany klienta, který posílá požadavek na Network Access Server. NAS musí získat autentizační data klienta, potřebná pro ověření identity uživatele, které přidá do RADIUS Access-Request paketu. Tento RADIUS Access-Request paket pak odešle na RADIUS server. Pokud nebyl RADIUS server nakonfigurován pro autentizaci požadavků z NAS, pak tento Access-Request paket jednoduše zahodí.

20 AAA architektura 20 V případě, že je RADIUS server správně nakonfigurován pro ověřování z NAS, přijme tento požadavek a řídí se datem obsaženým v tomto Access-Request paketu. Následně ověří uživatele na základě dat, uložených ve vlastní databázi na daném serveru, nebo může ověření probíhat v rámci databáze uživatelů uložených na jiném serveru. Pokud se nepodaří uživatele ověřit nebo pokud nemá mít uživatel povolení přístupu do sítě, RADIUS server odešle odpověď na NAS požadavek v podobě Access-Reject paketu, který zapříčiní, že NAS bude uživatele blokovat a nepovolí mu přístup do sítě. V některých případech se může stát, že RADIUS server vyhodnotí platného uživatele, ale pro definitivní potvrzení povolení přístupu do sítě potřebuje ještě další informace, aby předešel tomu, že prvotní žádost o přístup není pouze podvrh. RADIUS server tedy vyšle Access-Challenge paket na NAS, který daný požadavek doplnění informací přepošle uživateli. NAS opět přeposílá doplněné informace vyslané na základě Access-Challenge od uživatele na RADIUS server v podobě dalšího Access-Request paketu. Na základě doplněných informací odpoví RADIUS server v podobě povolení nebo zakázání přístupu uživatele do sítě. V případě, že RADIUS server rozhodne o zákazu přístupu uživatele do sítě, ať už z důvodu neplatného uživatele nebo z jiných důvodů, posílá RADIUS server zpět na NAS Access-Reject paket. Pokud potvrdí RADIUS server platnost uživatele a povolí mu přístup do sítě, odešle na NAS Access-Accept paket. Tento paket obsahuje mimo jiné i RADIUS atributy, jenž NAS využívá.

21 AAA architektura 21 Výměna požadavků mezi klientem, NAS a RADIUS Obr. 3 Zdroj: Proces účtování v protokolu RADIUS U RADIUS účtování jsou pouze dva pakety: Accounting-Request a Accounting- Response. Pakety Accounting-Request jsou vždy posílány z NAS do RADIUS serveru a Accounting-Response naopak z RADIUS serveru do NAS. Accounting- Request pakety vždy nesou atributy Acct-Status-Type s určitými hodnotami. Nejčastěji jsou tyto hodnoty následující: Start, Stop, Interim update. Pakety používané pro RADIUS účtování ve většině případů nepoužívají stejný UDP port jako při autentizaci, ale využívá se defaultní port pro RADIUS účtování (Allied Telesis, 2012a) RADIUS Accounting-Request paket poslaný z NAS do RADIUS serveru nese hodnotu atributu Acct-Status-Type=start. Hodnota start značí začínající spojení. Kromě několika údajů obsahuje i unikátní identifikátor spojení. (Allied Telesis, 2012a) RADIUS server potvrdí příjem tohoto zahajovacího paketu a odpoví na tento požadavek paketem Accounting-Response. (Wenstrom, 2003) Během spojení jsou posílány z NAS do RADIUS serveru pakety Accounting- Request s hodnotou atributu Acct-Status-Type=Interim update. Hodnota Interim update neboli průběžné aktualizace, označuje pravidelné aktualizované zasílání paketů v průběhu spojení. (Allied Telesis, 2012a) Na tyto Interim update odpovídá RADIUS server pakety Accounting-Response. (Allied Telesis, 2012a)

22 AAA architektura 22 Pokud má být uživatelské síťové spojení ukončeno, NAS zašle opět na RADIUS server Accounting-Request paket s hodnotou Acct-Status-Type=Stop. (Allied Telesis, 2012a) Většinou NAS vysílá Accounting-Request paket, dokud nedostane potvrzení od RADIUS serveru v podobě Accounting-Response o potvrzení ukončení spojení. (Allied Telesis, 2012a) RADIUS účtování Obr. 4 Zdroj: Atributy RADIUS Jednotlivé atributy protokolu RADIUS přenášejí v požadavku a v odpovědi konkrétní informace o autentizaci, autorizaci a konfiguraci. Konec seznamu atributů je určen délkou RADIUS paketu. (Wenstrom, 2003) Atributy se zapisují na konec paketu RADIUS, kde může být uveden jeden nebo více atributů. Některé atributy mohou být zařazeny i vícekrát, a jejich specifikace je uvedena v každém atributu. Pokud jsou přítomny atributy se stejným typem, je důležité ponechat jejich pořadí. U atributů s různým typem nezáleží na jejich pořadí. Formát atributu se skládá z typu, délky a hodnoty. Jednotlivá pole se vysílají zleva doprava. (Rigney, 2000)

23 AAA architektura 23 Formát atributu RADIUS Obr. 5 Zdroj: Typ Pole Typ má délku jednoho oktetu a označuje celkový typ atributu RADIUS. Základní typy, počínaje typem 1, které obsahuje uživatelské jméno, typ 2 uživatelské heslo, 3heslo CHAP, 4 NAS IP adresa, 5 NAS port, 6 typ služby, 7 Protokol rámce, 8 IP adresa rámce, 9 IP maska rámce apod. Hodnoty jsou vyhrazeny pro experimentální použití. Hodnoty jsou vyhrazeny pro specifické použití a rozsah hodnot jsou rezervovány pro případné další použití. RADIUS server, stejně tak jako RADIUS klient, může ignorovat atributy s neznámým typem. (Rigney, 2000) Délka Pole Délka má, stejně jako pole Typ, délku jednoho oktetu. Označuje celkovou délku atributu, tedy všech polí Typ, Délka i Hodnota. Pokud je atribut přijat v Access-Request, ale s neplatnou délkou, měl by být vyslán jako Access- Reject. Pokud je atribut s neplatnou délkou přijat v paketu Access-Accept, Access-Reject nebo Access-Challenge, tento paket musí být změněn jako Access-Reject nebo jednoduše zahozen. (Rigney, 2000) Hodnota Pole Hodnota může mít buď nulovou délku, nebo délku i o více oktetech. V poli Hodnota jsou obsaženy informace týkající se konkrétního atributu. Formát a délku pole Hodnota určuje obsah polí Typ a Délka. (Wenstrom, 2003) Formát pole Hodnoty může být jeden z pěti datových typů: text, řetězec, adresa, celočíselný datový typ nebo čas. (Rigney, 2000) Srovnání protokolů RADIUS a TACACS+ Oba dva protokoly jsou využívány pro AAA služby na síťových prvcích. RADIUS byl vytvořen k autentizaci a příhlašování přes vytáčené připojení vzdálených uživatelů do sítě. TACACS+ se nejčastěji používá pro administrátorský přístup do síťových zařízení jako jsou routery a switche. Od toho se také odvíjí oba dva názvy daných protokolů RADIUS Remote access Dial-In User Service a TACACS+ Terminal Access Controller Access Control Service Plus. (TACACS. net, 2011)

24 AAA architektura 24 Funkce Hlavním rozdílem je oddělení jednotlivých funkcí AAA u TACACS+ protokolu, tudíž implementace serverů zabezpečení může být modulární. Naproti tomu RADIUS protokol spojuje Autentizaci a Autorizaci v jednu část a zvlášť separuje pouze funkci účtování. Tento způsob sloučení Autentizace a Autorizace může způsobovat nižší flexibilitu v implementaci. (Wenstrom, 2003) RADIUS protokol nezaznamenává příkazy (logy) spojené s administrátorem. Protokol zaznamenává pouze začátek, konec a mezičasové záznamy spojení. Tudíž pokud jsou zde přihlášeni dva nebo více administrátorů v jeden čas, není pak možné určit, který příkaz z daného záznamu logu RADIUS protokolu provedl konkrétní administrátor. Při vývoji protokolu TACACS+ byl tento problém odstraněn. Standard TACACS+ odděluje funkcionalitu autorizace a umožňuje tak dodatečnou flexibilitu a jednotlivou kontrolu přístupu každého administrátora, který může spouštět ten či onen příkaz na konkrétním zařízení. Každý příkaz potvrzený uživatelem je poslán zpět na centrální TACACS+ server k autorizaci. Tento server opět příkaz zkontroluje na základě autorizačního listu příkazů pro každého uživatele nebo skupiny. TACACS+ může definovat politiky založené na uživatelích, typu zařízení, místě nebo denního času. Služby TACACS+ mohou běžet na Doménovém řadiči nebo na PC, a využívat lokální konfiguraci uživatelů a skupin pro kontrolu přístupu k zařízení v dané síti. (TACACS.net, 2011) RADIUS byl vytvořen pro koncové klienty využívající AAA, zatímco TACACS+ pro administraci AAA. RADIUS může být využit pro administraci AAA menší sítě, pokud není vyžadována autorizace, nebo v případě homogennosti této sítě, tedy pokud se jedná o jednotnou síť. V mnoha případech se jedná o nehomogenní, členité síťové prostředí, nebo jsou požadovány autorizační politiky pro síťové zařízení. V takovém případě se stává nasazení TACACS+ protokolu lepší volbou, než je tomu v případě RADIUS. (TACACS.net, 2011)

25 AAA architektura 25 RADIUS versus TACACS+ Obr. 6 Zdroj: Tab. 1 Funkce RADIUS versus TACACS+ Funkce RADIUS TACACS+ Podpora AAA Autorizace a Autentizace jsou sloučené, účtování je zvlášť Autentizace, Autorizace i účtování jsou zvlášť Přenosový protokol UDP-nespojovaný TCP-spojově orientovaný Výzva/odpověď Jednosměrná Obousměrná Podpora protokolů Chybí NetBEUI Plná podpora Integrita dat Konfigurace autorizace Logování Podpora výrobců Porty Využití Šifruje se pouze heslo uživatele Vyžadováno, aby každé síťové zařízení obsahovalo konfiguraci autorizace Omezené logování Menší podpora než u TACACS+ UDP port 1645/1646, 1812/1813 Navrženo pro koncové klienty AAA Zdroj: Podpora ze strany prodejců Šifruje se celý paket TACACS+ Centrální správa pro konfiguraci autorizace Plné logování všech příkazů Podpora od mnoha hlavních výrobců TCP port 49 Navrženo pro administraci AAA Mnoho prodejců podporuje oba dva protokoly RADIUS i TACACS+. Mezi nejznámější se řadí například Cisco, Linksys, Juniper, HP, Netgear, Ericsson, 3COM, Nortel a další. (TACACS.net, 2011)

26 AAA architektura 26 Umístění Všeobecně se nedoporučuje umístění RADIUS a TACACS+ služeb na jeden a tentýž server. Lze usoudit, že v obou dvou případech se jedná o AAA protokoly, a tudíž by bylo umístění obou dvou služeb na jeden server výhodnější, už jen z důvodu nákupu jedné licence na os serveru. Obě dvě služby jsou nicméně využívané pro jiné účely, s rozdílným využíváním zdrojů. Při kombinování těchto služeb by mohlo dojít ke snížení síťové bezpečnosti, což by mělo negativní dopad na celkovou bezpečnost, která je na síť kladena. V podnikové síti mohou neoprávnění vzdálení uživatelé řídit jinou funkční skupinu, než oprávění interní administrátoři. Kombinace těchto rolí může porušovat bezpečnostní principy jednotlivých funkcí. (TACACS.net, 2011) TACACS+ servery by měly být umístěny v plně bezpečné interní síti. Hlavním požadavkem je zamezení přímého přístupu z nebezpečného nebo částečně bezpečného prostředí sítě. RADIUS servery jsou naopak většinou umístěny v částečně bezpečné síti. (TACACS.net, 2011) Rozdíli v umístění mezi RADIUS a TACACS+ Obr. 7 Zdroj: Přenosový protokol RADIUS používá nespolehlivý protokol UDP, naproti tomu TACACS+ spojově orientovaný TCP protokol. TCP nabízí oproti UDP několik výhod. TCP zajišťuje spolehlivé doručování, UDP nedává záruky na datagramy, které přenáší po síti. UDP u RADIUS zjednodušuje implementaci klientů i serverů, na druhé straně je ale RADIUS protokol méně robustní a musí se implementovat na RADIUS servery určité opatření. Toto opatření kvůli zvýšení bezpečnosti spočívá v opakovaném vysílání paketů a nastavení časových limitů. UDP ale i přesto postrádá určitou úroveň podpory, kterou TCP nabízí: TCP poskytuje zvláštní potvrzení o tom, že žádost byla obdržena v určitém časovém intervalu, bez ohledu na to, jak je autentizační mechanizmus pomalý.

27 AAA architektura 27 TCP poskytuje okamžitou informaci o poškozeném serveru, neběžícím serveru, nebo pokud se server resetuje. Lze určit, v jakém aktuálním stavu momentálně server je, a kdy bude opět funkční, pokud se využívá dlouhodobého TCP připojení. UDP nemůže oproti TCP rozeznat rozdíly u serveru, nelze tedy zjistit, zda je server pomalý, vypnutý nebo z jiného důvodu nedostupný. Při použití TCP lze detekovat pády serveru a při připojení k více serverům součastně, může zůstat zachováno spojení. Požadavky se budou posílat na dostupné servery, u kterých je známo, že jsou zapnuté a běží. TCP je více přizpůsobivý z hlediska velikosti dat při přenosu po síti. (Cisco, 2008) Šifrování paketu RADIUS protokol šifruje pouze heslo v paketu požadavku přístupu, který je posílán z klienta na server. Zbytek paketu u RADIUS není šifrovaný, tudíž ostatní informace, které jsou uvedeny v paketu, mohou být zneužity. Tyto informace jako např.: uživatelské jméno, účtování, apod., by mohly být zachyceny neoprávněnou třetí stranou. U TACACS+ protokolu je tomu přesně naopak, tedy je šifrováno celé tělo paketu, ale ponechává se standardní TACACS+ hlavička. Hlavička TACACS+ protokolu obsahuje pole, které udává, zdali je tělo TACACS+ šifrované či nikoliv. Pro účely ladění se doporučuje mít tělo paketu nezašifrované, což zvyšuje efektivitu ladění. Pro normální ostrý provoz je tělo TACACS+ paketu naopak plně šifrované, kvůli zajištění vysoké bezpečnosti při přenosu. (Cisco, 2008) Podpora více protokolů TACACS+ disponuje širší podporou vytáčených protokolů a protokolů sítí WAN. (Wenstrom, 2003) RADIUS postrádá podle (Cisco, 2008) některé protokoly, jako například: AppleTalk Remote Access protocol NetBIOS Frame Protocol Control Protocol Novell Asynchronous Services Interface (NASI) X.25 PAD spojení Správa na routeru RADIUS neumožňuje uživatelům kontrolu nad příkazy, které mohou být vykonány na routeru a které nikoliv. Z tohoto důvodu není RADIUS příliš vhodný pro správu routeru, ani není příliš flexibilní pro koncové služby. TACACS+ poskytuje oproti RADIUS naopak dvě metody kontroly povolení příkazů na serveru na jednotlivé uživatele nebo na skupiny. První metoda spočívá v přiřazení privilegované úrovně příkazům a potvrzení routeru, spolu s TACACS+ serverem, zdali má uživatel pro danou privilegovanou úroveň povolení či nikoliv. Druhá metoda je specifikována přímo v TACACS+ serveru a vztahuje se na jednotlivé uživatele nebo na skupiny. Na základě uživatelů nebo skupin jsou přesně definovány příkazy, které jsou povoleny. (Cisco, 2008)

28 AAA architektura 28 Vzájemná spolupráce Schopnost RADIUS protokolu vzájemné a efektivní spolupráce v souladu s RFC záleží na více faktorech. I když někteří dodavatelé implementují RADIUS, nemusí to hned znamenat, že bude vzájemně spolupracovat s jiným RADIUS protokolem, ať už od stejného nebo jiného dodavatele. Společnost Cisco implementuje většinu atributů RADIUS a stále přidává další. Pokud koncoví zákazníci využívají standardní atributy RADIUS na svých serverech, je možné využít vzájemnou kompatibilitu i s jinými dodavateli, využívající stejné atributy. Stále více dodavatelů ale implementuje specifické rozšířené atributy RADIUS, které pak nejsou schopné efektivní spolupráce s atributy RADIUS od jiných dodavatelů. (Cisco, 2008) Provoz Síťový provoz mezi klientem a serverem je u RADIUS a TACACS+ značně odlišný. Je to způsobeno rozdílností jednotlivých protokolů a jejich náročností. Následující síťový provoz mezi klientem a RADIUS/TACACS+ serverem, v případě že je využito řízení routeru s ověřením, exec povolení, oprávnění příkazů (nelze u RADIUS), exec účtování a ovládání účtování (nelze u RADIUS). Ukázka provozu u RADIUS Obr. 8 Zdroj:

29 AAA architektura 29 Ukázka provozu u TACACS+ Obr. 9 Zdroj: Účtování U protokolu RADIUS je součástí účtování větší množství informačních polí, než u protokolu TACACS+. Toto staví RADIUS protokol do lepší pozice z hlediska účtování, oproti TACACS+ s méně informacemi účetních záznamů. (Wenstrom, 2003)

30 Protokol 802.1x 30 4 Protokol 802.1x Kontrola přístupu portů na síti umožňuje správci sítě omezit využívání IEEE 802 LAN přístupové body (porty) pro bezpečnou komunikaci mezi autentizovaným a autorizovaným zařízením. Tento standard 802.1x specifikuje architekturu, funkční prvky a protokoly, které podporují vzájemnou autentizaci mezi klienty připojenými na porty stejné LAN sítě, a bezpečnou komunikaci mezi porty. První vydání IEEE standardu 802.1x bylo publikováno v roce Pár let poté, v roce 2004, již bylo publikováno druhé vydání tohoto standardu. Pozdější vydání tohoto standardu IEEE 802.1x bylo publikováno až v roce (IEEE standard, 2010) 802.1x standard je IEEE (Institute of Electrical and Electronics Engineers) standard pro kontrolu přístupových portů na síti, poskytující výkonné zabezpečení a silnou ochranu dat. Toto úspěšné a silné zabezpečení dat učinilo z 802.1x hlavní součást dnešních velmi úspěšných systémů pro kontrolu přístupu k síti. (Juniper networks, 2010a) Obr. 10 Přístup na portu před a po 802.1x Zdroj: Dot1X_Deployment/Dot1x_Dep_Guide.html#wp vlastní úprava Hlavním cílem kontroly přístupu portů na síti je omezení přístupu do sítě. Kontrola přístupu portů na síti řídí přístup do sítě, zamezuje neoprávněnému a nechtěnému přenosu dat před neznámými nebo neoprávěnými uživateli. Má za cíl chránit síť před krádeží a ztrátě dat zaviněné třetí stranou a zamezení narušení sítě. (IEEE standard, 2010) Tato bezpečnostní funkce 802.1x kontrola přístupu portů na síti umožňuje kontrolovat provoz, kdo všechno může posílat skrze porty switche, a přijímat z konkrétních portů na switchi data. Neboli 802.1x se stará o kontrolu autentizovaných uživatelů, kteří se přes konkrétní porty připojují do sítě. Kontrola přístupu portů na síti totiž omezuje provoz neautentizovaným uživatelům a povoluje provoz pouze autentizovaným uživatelům, kteří se prvně musí autentizovat RADIUS serverem. Hlavním cílem je tedy zamezení připojení neověřeného uživatele a jeho počítače do sítě, a tím související zamezení přístupu k síťovým zdrojům. (Allied Telesis, 2012b)

31 Protokol 802.1x 31 Standard 802.1x byl původně vytvořen pro využití v síti s pevným, kabelovým připojením, později byl ale rozšířen i v bezdrátových sítích díky silné autentizaci a ochraně osobních údajů. Tento IEEE standard 802.1x zajišťuje bezpečnou výměnu uživatelských přihlašovacích údajů, stejně tak jako ověřujících informací zasílaných z/do síťových zařízení x pracuje na 2. vrstvě modelu ISO/OSI 1, tedy na linkové (spojové) vrstvě. Nespornou výhodou standardu 802.1x je jeho dlouhodobé testování jak v drátových, tak bezdrátových sítích, a jeho dlouholeté nasazení v praxi. (Juniper networks, 2010a) S narůstajícím počtem uživatelů ve firmě, kteří se připojují do sítě, dodavatelů a hostů využívajících interní síťové připojení v dané firmě, je kontrola přístupu na portech nepostradatelnou součástí firemního síťového zabezpečení. Proti neoprávněnému připojení, například vlastního zařízení přineseného do firemního prostředí, se lze účinně bránit zavedením jednoho z několika systému kontroly přístupu portů do sítě, v tomto případě zavedením 802.1x. Využití automatické kontroly portů pro přístup do LAN na okraji sítě je nejefektivnější řešení s ohledem na velikost firmy x umožňuje dynamické povolení, nebo zakázání portů na základě identity uživatele, nebo zařízení, které se k tomuto portu připojuje. (Cisco, 2011) 4.1 Komponenty 802.1x Autentizace uživatele a zařízení pomocí 802.1x lze ověřit jak zařízení, tak Standard 802.1x, který vyžaduje ke své práci následující tři komponenty: Obr. 11 Role jednotlivých zařízení 802.1x Zdroj: onfiguration/guide/sw8021x.html. Supplicant, ve většině případů označovaný také jako klient, je koncový uživatel nebo koncový uzel, který chce získat přístup do sítě prostřednictvím 1 International Organization for Standardization/Open Systems Interconnection.

32 Protokol 802.1x 32 portu přepínače. (Allied Telesis, 2012b) Klient, respektive pracovní stanice, která požaduje přístup do sítě LAN, odpovídá na požadavky, které ji zasílá switch. Na pracovní stanici, respektive na klientu, musí být povoleno 802.1x. (Juniper networks, 2010a) Authenticator je zařízení umístěné mezi vnějším zařízením uživatele, které má být autentizováno a použitou infrastrukturou, která autentizaci provádí. Authenticator může být buď switch, v případě drátového připojení do sítě, nebo AP 2 v případě bezdrátového připojení. (Juniper networks, 2010a) Authenticator řídí fyzický přístup k síti na základě ověřování stavu klienta. Funguje jakoby prostředník, tzv. proxy, mezi klientem a ověřovacím RADIUS serverem, který vyžaduje od klienta informace o jeho identitě. Authenticator je také zodpovědný za zapouzdření a rozbalení EAP rámců a za vzájemnou komunikaci s RADIUS serverem. Princip authenticatora spočívá v přijetí EAPOL rámců, které předává k ověření na RADIUS server s tím, že záhlaví Ethernetových rámců jsou rozbaleny a EAP rámce jsou znovu zapouzdřeny do RADIUS formátu. Tyto EAP rámce při rozbalování a změně na RADIUS formát nejsou nijak dotčeny, ani modifikovány. Důležité ale je, aby autentizační server EAP rámce podporoval v nativním formátu. Po přijetí rámců zpět z RADIUS serveru na authenticator jsou smazány záhlaví rámců a ponechány pouze EAP rámce, které jsou opět zapouzdřeny do EAPOL a odeslány na supplicant. Authenticator roli může zastávat jakékoliv zařízení, které podporuje RADIUS klienta a podporuje protokol 802.1x. (Cisco, 2007a) Authentication server neboli RADIUS server vykonává skutečnou autentizaci klienta. Tento RADIUS server ověřuje klientovu identitu a na základě autentizačních informací získaných od klienta přes authenticator rozhodne, zdali klientovi povolí přístup do sítě nebo přístup zakáže. Ověřovací server je v některých případech označován také jako PdP (Policy decision point). (Cisco, 2007a) RADIUS server přijímá radius zprávy obsahující uživatelské informace, a tyto porovnává s databází korektních přístupů. RADIUS server tyto přijaté RADIUS zprávy porovnává většinou s Microsoft Active Directory, LDAP nebo s jinou databází či adresářovým uložištěm. (Juniper networks, 2010a) 2 Access point, přístupový bod pro bezdrátové připojení uživatelů.

33 Protokol 802.1x 33 Obr. 12 Jednotlivé komponenty 802.1x Zdroj: _9_ea1/configuration/guide/Sw8021x.html. + vlastní úpravy 4.2 Výhody 802.1x Autentizace uživatele a zařízení pomocí 802.1x lze ověřit jak zařízení, tak uživatele pro korektní povolení přístupu do sítě. (Cisco, 2011) Bezpečnost 802.1x je velmi silná a bezpečná metoda autentizace x pracuje na druhé vrstvě modelu ISO/OSI, tudíž umožňuje řešení bezpečnosti autentizace do LAN již na okraji sítě. (Cisco, 2011) Přehlednost 802.1x poskytuje vyšší přehlednost a viditelnost z pohledu autentizace uživatele, což může být užitečné v rámci pravidelných bezpečnostních auditů ve firmě. Díky 802.1x lze snadno spojit autentizační informace s ostatními, tedy například uživatelské jméno spolu s IP adresou, mac adresou, switchem, i portem na switchi. Tyto informace je možné využít pro další statistické zpracování a pro případné řešení problémů s autentizací uživatele. (Cisco, 2011) Služby založené na identitě díky správné autentizaci uživatelů se známou identitou, je možné využít dynamicky poskytované služby šité na míru konkrétnímu firemnímu prostředí. Podle identity ověřovaného uživatele, žádajícího o přístup do sítě, je možné nastavit jemu odpovídající přístup, na který má nárok. Například nastavení přístupu uživatele do určité VLAN apod. (Cisco, 2011) Transparentnost v mnoha případech je 802.1x nastavena tak, aby byla transparentní pro koncové uživatele. (Cisco, 2011) Neověření uživatele po nesprávném ověření uživatele nebo po neověření uživatele z důvodu jeho nesprávné identity, lze tohoto uživatele přiřadit alespoň do omezené VLANy. Tím je uživateli umožněn přinejmenším omezený přístup do sítě. Ve speciální restriktivní VLANě lze například využít přístup k antivirovým updatům, windows updatům a důležitým záplatám operačního systému apod. (Cisco, 2011) 4.3 Nevýhody 802.1x Zpoždění ve výchozím nastavení 802.1x není umožněn uživateli přístup do sítě, aniž by se autentizoval. To může způsobit problémy uživatelům, kteří potřebují okamžitý přístup do sítě po připojení do LAN. Musí ovšem počítat se

34 Protokol 802.1x 34 spožděním před samotným připojením, které je způsobeno autentizací pomocí 802.1x. (Cisco, 2011) Podpora starších zařízení ve výchozím nastavení 802.1x neposkytuje přístup do sítě uživatelům a jejich zařízením, které nepodporují 802.1x, tudiž je nelze nijak ověřit. Alternativou, kterou lze v tomto případě využít, je MAB 3 nebo webová autentizace pro ověření koncových uživatelů. (Cisco, 2011) Následné zabezpečení po korektním ověření uživatele pomocí 802.1x, je tomuto uživateli povolen přístup do sítě, který není dále kontrolován. Po úspěšné autentizaci uživatele a otevření portu na switchi, je nutné spolu s autentizací přes 802.1x využívat ještě další bezpečnostní systémy, pro co nejvyší zabezpečení sítě proti útokům. (Cisco, 2011) 4.4 Protokoly 802.1x Pro správné fungování autentizace pomocí 802.1x je důležité, aby na jednotlivých zařízeních správně fungovaly protokoly potřebné k autentizaci EAP protokol EAP extensible authentication protokol je formát zprávy definovaný v RFC Požadavky na připojení vzdáleného přístupu při využití EAP jsou ověřovány pomocí některého z ověřovacích mechanismů. Přesná metoda, která se využívá při ověřování, závisí hlavně na vzájemné dohodě mezi klientem a ověřovatelem. (Microsoft, 2013b) Jednoduše lze říci, že tento autentizační rámec zprostředkovává přenos klíčů podle jednotlivých metod. Tyto autentizační metody se nazývají metody EAP. Některé metody jsou určeny výhradně pro bezdrátové sítě a jejich požadavky jsou popsány v RFC Běžně využívané EAP metody používané při autentizaci pomocí 802.1x jsou EAP-TLS a PEAP-MSCHAPv2. (Aboba, 2004) Konkrétní metoda při ověřování EAP se nazývá typ EAP. Úspěšné ověření může proběhnout jedině za předpokladu, že obě dvě strany, tedy klient i ověřovatel, podporují stejný typ EAP. (Microsoft, 2013b) Formát EAP paketu je složen z několika částí, a to: kódu, identifikátoru, délky a dat. Kód identifikátoru o velikosti jednoho oktetu může nabývat několika stavů a to stavu typu: 1 požadavek, 2 odpověď, 3 úspěch, nebo 4 selhání. Identifikátor zabírá stejně jako kód velikost jednoho oktetu a napomáhá při vzájemném spojování požadavků a odpovědí na ně. Délka velikosti dvou oktetů určuje celkovou délku EAP paketu určenou v oktetech, včetně všech polí: kódu, identifikátoru, délky a dat. Pole data může být libovolné platné délky, tedy nula až několika přípustných oktetů. (Aboba, 2004) 3 MAC Authentication Bypass.

35 Protokol 802.1x Metody EAP EAP zajišťuje určité funkce a sjednává autentizační metody, které se nazývyjí EAP metody. EAP metod je velké množství, řádově desítky metod, z nichž nejznámnější jsou například EAP-TLS, EAP MD5-Challenge a další. Mezi tyto metody patří i méně známé, kterými jsou EAP-AKA, EAP-SIM, EAP-GTC, EAP-EKE, EAP-POTP, EAP-PWD, EAP-FAST a dalších několik desítek metod. (ERONEN, 2005) Mezi hojně využívané metody patří tyto následující: MD5-Challenge Metoda ověřování EAP-MD5 Challenge, celým názvem EAP-Message Digest 5 Challenge, disponuje pouze minimálním zabezpečením. Tato metoda je popsána v RFC 3748 a využívá ověření pouze EAP serveru, nikoliv vzájemnou autentizaci. Proto je velmi citlivá na slovníkové útoky. (Juniper networks, 2010b) Metoda pouze hashuje heslo pomocí algoritmu MD5 (Kalina, 2010) LEAP Lightweight Extensible Authentication Protocol je proprietární metoda EAP, kterou vyvinula společnost Cisco Systems pro využívání v IEEE wifi LAN prostředí. Slouží ke vzájemnému prokázání identity mezi uživatelem a síťovou infrastrukturou. Je kompatibilní se síťovými autentizačními mechanismy jako je RADIUS a dosahuje dobrých výsledků v rámci výpočetního výkonu. (Cisco, 2007b ) EAP-TLS Metoda EAP-TLS neboli EAP Transport Level Security je velmi využívaný typ ověřování EAP v zabezpečovacích systémech, pracujících s certifikáty. Metoda EAP je jedna z nejlepších metod ověřování a určení klíčů. Zajišťuje volbu metody šifrování, vzájemné ověřování a určení šifrovaných klíčů mezi klientem a ověřovatelem. EAP-TLS využívají pouze servery pro vzdálený přístup a se službou směrování, které jsou členy domény a využívají ověřování windows nebo RADIUS. EAP-TLS nepodporují servery, které jsou pouze členy pracovních skupin. (Microsoft, 2013b) EAP-TLS se využívá především v kombinaci s bezdrátovým připojením, kde je kompatibilní s většinou wifi zařízení. Pro zabezpečení komunikace s RADIUS serverem využívá PKI 4. Pro správnou autentizaci tedy uživatel potřebuje mimo jiné i vlastní privátní klíč. (Cisco, 2004) EAP-TTLS EAP Tunneled Transport Layer Security je rozšířením metody TLS a je stejně tak silný, jak původní TLS metoda. Odpadá zde nutnost instalace certifikátu na každém klientu, ale stačí pouze instalace certifikátu na serveru. Poté, co je server ověřen, se 4 PKI-Public Key Infrastructure označuje infrastrukturu správy a distribuce veřejných klíčů v asymetrické kryptografii.

36 Protokol 802.1x 36 provádí ověření uživatele na základě jeho hesla, které je posíláno zabezpečeným tunelem. Tento tunel je vytvořen na počátku komunikace na základě certifikátu serveru. (Juniper networks, 2010c) EAP-MSChapV2 EAP Microsoft Challenge Handshake Authentication Protocol verze 2 je vzájemná autentizační metoda, podporující autentizaci na základě uživatelského hesla. Během autentizačního procesu pomocí metody EAP-MSChapV2 musí oba účastnící, klient i RADIUS server, prokázat určité společné znalosti uživatelského hesla pro úspěšnou autentizaci. (Juniper networks, 2010d) PEAP Protected Extensible Authentication Protocol je součástí protokolů řady EAP. PEAP využívá pro komunikaci mezi klientem a RADIUS serverem protokol TLS pro vytvoření zašifrovaného kanálu mezi těmito dvěma účastníky. Protokol PEAP neurčuje metodu ověřování, ale poskytuje další zabezpečení ostatních protokolů ověřování EAP, například protokolu EAP-MSChapV2. Díky protokolu PEAP, který používá protokol TLS, jímž je vytvořen šifrovaný tunel, lze využít pro komunikaci a vzájemnou výměnu informací při autentizaci již méně bezpečnou metodu ověření. Nejčastěji se spolu s protokolem PEAP využívá protokol EAP-MSChapV2. Díky bezpečnému tunelu vytvořeného prostřednictvím kanálu protokolu TLS se stává komunikace mezi klientem a RADIUS serverem velmi bezpečnou a předchází se tak možným útokům na tuto komunikaci. PEAP využívá vzájemné ověřování, kdy je možné ověření RADIUS serveru ze strany klienta, ale také ověření klienta ze strany serveru. Mezi výhody PEAP protokolu patří i rychlé obnovení připojení při přecházení mezi jednotlivými přístupovými body. Při přecházení klienta mezi jednotlivými přístupovými body odpadá nutnost opětovného požadavku na ověření u dalších přístupových bodů, čímž se zkracuje doba připojení o zpoždění mezi požadavkem klienta a odpovědí serveru. Princip rychlého opětovného připojení při přecházení mezi jednotlivými AP spočívá v tom, že jednotlivé přístupové body ve stejné síti jsou nakonfigurovány jako klientské počítače služby RADIUS pro RADIUS servery. Při přecházení mezi AP nakonfigurovanými jako klienti stejného RADIUS serveru již není potřeba opětovného ověření při každém dalším novém spojení, pouze pokud se klient připojuje na přístupový bod nakonfigurovaný jako klient služby RADIUS pro jiný RADIUS server. (Microsoft, 2013c) EAPoL Extensible Authentication Protocol over LAN je síťový ověřovací protokol využívaný při autentizaci pomocí 802.1x. EAPoL, podobně jako EAP protokol je jednoduše zapouzdřen a může pracovat na jakékoliv síti LAN. Standard IEEE 802.1x nedefinuje pouze kabelové připojení a protokol AEPoL využívaný pro LAN,

37 Protokol 802.1x 37 ale také EAP over Wifi, tzv. EAPoW využívaný v IEEE bezdrátových spojeních pro získání WEP klíče. (VoCAL, 2013) 802.1x kabelové připojení Obr. 13 Zdroj: Dot1X_Deployment/Dot1x_Dep_Guide.html#wp vlastní úpravy Formát rámce EAPoL se skládá ze sedmi polí, rozčleněných podle určitých vlastností a na různě dlouhé velikosti bloků. (VoCAL, 2013) Tab. 2 MAC Header Formát rámce EAPoL Ethernet Type Version Packet Type Packet Body Length 12 bytes 2 bytes 1 byte 1 byte 2 bytes Packet Body variable length Frame Check Sequence 4 bytes Zdroj: Prvním polem je MAC Header o velikosti 12 bytů, kde prvních 6 bytů v tomto poli označuje cílovou adresu a zbylých 6 bytů značí zdrojovou adresu. Druhým polem Ethernet type je dvoubytový EAPoL kód. Třetím polem je pole s názvem Version označující aktuální verzi. Další pole Packet type, o velikosti jednoho byte, které označuje jakého typu tento rámec je. (VoCAL, 2013) Tab. 3 Typy paketu Typ paketu Název Popis EAP-Packet Obsahuje zapouzdřený EAP rámec EAPOL Start EAPOL-Logoff EAPOL-Key EAPOL-Encapsulated-ASF-Alert Supplicant může vyslat EAPOL Start rámec, aniž by musel čekat na výzvu od Authenticatora. Používá se k přepnutí portu opět do neautorizovaného stavu, pokud se supplicant odpojí ze sítě. Využívá se k výměně informací o kryptografických klíčích Poskytuje metodu umožňující ASF upozornění (např.: specifické SNMP nástrahy), jenž mají být přeposlány přes port, který je v neautorizovaném stavu.

38 Protokol 802.1x 38 Zdroj: Mezi další pole patří Packet Body Length o velikosti dvou bytů, označující délku těla packetu. Pokud je tělo paketu prázdné, hodnota je nastavena na 0. Následující pole Packet Body označující počet bytů v celém paketu je velikosti 2 byty. Poslední pole Frame Check Sequence o velikosti 4 byty obsahuje kontrolní součet pro případnou kontrolu dat a detekci chyb (VoCAL, 2013). EAPoL komunikace Obr. 14 Zdroj: + vlastní úpravy 4.5 Porty v autorizovaném a neautorizovaném stavu Jednotlivé stavy portů na switchi určují, zdali bude mít uživatel povolen přístup do sítě či nikoliv. Ve výchozím nastavení je port v neautorizovaném stavu a zabraňuje veškerou komunikaci, kromě 802.1x paketů. Po úspěšném ověření uživatele přechází port do autorizovaného stavu a je uživateli umožněna veškerá komunikace, na kterou má nárok. (Cisco, 2007a) V případě, že klient nepodporuje 802.1x, ale je připojen k portu switche, jenž je nastaven na 802.1x autentizaci, vyšle switch žádost ke klientovi o zaslání

39 Protokol 802.1x 39 autentizačních údajů. Klient díky tomu že nepodporuje 802.1x, na tuto žádost nemůže odpovědět a port zůstává v neautorizovaném stavu. Uživatel tím pádem nezíská přístup do sítě. (Cisco, 2007a) V opačném případě, pokud uživatel podporuje 802.1x, ale porty na switchi nejsou na 802.1x nastaveny, vyšle klient žádost ke switchi. Klient vyšle žádost v podobě EAPoL Start rámce, ale ze switche na tuto žádost nezíská žádnou odpověď. Klient opětovně vysílá EAPoL Start rámce v takovém počtu opakování jaké je nastaveno, dokud nedostane ze switche žádnou odpověď. Jakmile po určitém počtu odeslaných žádostí nemá žádnou odpověď, začne klient odesílat rámce tak, jako by byl port v autorizovaném stavu. (Cisco, 2007a) Port switche lze pomocí příkazu nastavit na různé stavy, které jsou podle (Cisco, 2007a) náskledující: Force-authorized neboli výchozí nastavení, které je nastaveno pro všechny porty na switchi před samotnou implementací 802.1x. Tento příkaz zakáže autentizaci na portu a povolí tím veškerý provoz na tomto portu, aniž by bylo vyžadováno jakékoliv ověření uživatele, které je u 802.1x. Force-unauthorized tento příkaz nastaví port do neautorizovaného stavu s tím, že není možné přes tento port uživatele autorizovat. Switch není schopen přes tento port poskytnout autentizační služby a port zůstává v neautorizovaném stavu. Auto nastavení umožňuje autentizaci klienta pomocí 802.1x na daném portu. Port je v neautorizovaném stavu a povoluje přenos pouze EAPoL rámců posíláných přes port. Switch vyžaduje po klientovi jeho identifikační údaje a zasílá je na RADIUS server. Po úspěšné autentizaci je obdržen Accept rámec a port je otevřen, neboli je změněn ze stavu neautorizovaného do autorizovaného a povoluje veškerou komunikaci přes tento port. Pokud autentizace z nějakého důvodu selže, port zůstává v neautorizovaném stavu a není možná žádná komunikace přes tento port, kromě EAPoL rámců. Pokud autentizace selže, klient vysílá v určitém počtu opakování požadavek na switch znovu. Každý klient, který žádá o přístup do sítě, je identifikován pomocí jeho vlastní MAC adresy. Pokud vyšle klient EAPoL-logoff zprávu, znamená to, že chce autentizaci ukončit a port se přepne do neautorizovaného stavu. V případě, že se stav portu změní z up na down nebo že na port přijde již zmíněná EAPoL-logoff zpráva, port se opět změní do neautorizovaného stavu. 4.6 Podporované topologie Autentizace 802.1x je podporována ve dvou topologiích: point to point a wireless LAN (Cisco, 2007a). U point to point topologie je autentizován na jednom portu switche pouze jeden klient. Tento klient se autentizuje klasickou metodou 802.1x a po úspěšné autentizaci je port povolen, klient tím pádem získává přístup do sítě. Po odpojení

40 Protokol 802.1x 40 klienta je port automaticky nastaven do neautorizovaného stavu a při připojení jiného klienta je vyžadován stejný proces autentizace, jako tomu bylo u klienta předešlého. (Cisco, 2007a) Druhá wireless LAN topologie naznačuje bezdrátovou topologii, kde je port nakonfigurován u 802.1x jako víceuživatelský port, který přechází do autorizovaného stavu po tom, kdy je některý klient autentizován. Pokud je port v autorizovaném stavu, mohou se na něj ostatní uživatelé nepřímo připojit a získávají tak přístup do sítě. Pokud přejde port do neautorizovaného stavu, všichni připojení klienti automaticky ztrácí přístup do sítě. (Cisco, 2007a) Wifi LAN připojení Obr. 15 Zdroj: _9_ea1/configuration/guide/Sw8021x.html. + vlastní úprava 4.7 Posloupnosti operací Celý proces všech operací využitých při 802.1x, lze rozdělit do jednotlivých posloupností: inicializace, autentizace, autorizace, účtování a ukončení. (Cisco, 2011)

41 Protokol 802.1x 41 Obr. 16 Jednotlivé posloupnosti operací 802.1x Zdroj: Dot1X_Deployment/Dot1x_Dep_Guide.html#wp Inicializace Autentizace s využitím 802.1x může být inicializována pomocí switche nebo klienta. V případě inicializace ze strany switche je detekováno nahození portu na switchi a na základě této informace switch začne vysílat autentizační požadavek v podobě EAP-Request-Identity směrem ke klientovi (supplicantovi). Pokud neobdrží switch žádnou odpověď, opakuje vysílání požadavku v určitém předem nastaveném počtu opakování. Inicializace na autentizaci může dojít i ze strany supplicanta směrem ke switchi. V takovém případě vysílá supplicant EAPoL-Start rámec, čímž žádá switch o autentizaci portu a přístupu do sítě. Tímto lze urychlit proces autentizace, kdy supplicant nemusí čekat na žádost ze switche EAP-Request Identity, ale sám přímo vysílá odpověď na tuto žádost. EAPoL-Start rámce jsou nutné v případech, kdy supplicant není schopen zpracovat žádost ze switche, tedy EAP-Request. Taková situace může nastat v případě připojení klienta, na kterém právě bootuje operační systém, jenž není momentálně schopný odpovědět na žádost. Případně pokud není přímé fyzické spojení supplicanta se switchem, například pokud je supplicant připojen přes IP telefon nebo přes hub. (Cisco, 2011)

42 Protokol 802.1x Autentizace Během autentizace přenáší switch EAP zprávy mezi klientem a autentizačním serverem. Jedná se o přenos EAP zprávy obsažené v EAPoL rámcích do RADIUS paketu a naopak. Pro tuto výměnu je v první řadě důležité se dohodnout na EAP metodě. Další vlastnosti této výměny závisí na předem dohodnuté metodě. Dohodnutá EAP metoda definuje typ ověření, podle kterého je možné potvrdit platnost identity klienta. V závislosti na této metodě může klient použít k ověření své identity heslo, certifikát nebo jiný druh ověření, například ověření kartou. (Cisco, 2011) Autorizace Pokud se klient prokáže platným ověřením, RADIUS server odpoví zprávou Access- Accept, se zapouzdřenou EAP success zprávou uvnitř. Tímto je povolen uživateli přístup přes port. RADIUS server může volitelně k Access-Accept zprávě připojit i dynamické síťové politiky omezující přístup uživatele přes port. Těmito politikami jsou většinou dynamické VLAN 5 nebo ACL 6. Pokud jsou nastaveny jednotlivé dynamické politiky, switch podle něj nastaví uživateli přístup na portu. Pokud tyto politiky chybí, switch port otevře bez těchto omezení. (Cisco, 2011) Jestliže se uživatel neprokáže platným ověřením nebo pokud je přístup zamítnut kvůli některému z omezení dynamických politik, RADIUS server pošle nazpět RADIUS Access-Reject zprávu se zapouzdřenou EAP-Failure zprávou. Tímto je port stále uzavřen a uživateli zakázán přístup do sítě, případně pokud je na switchi nastavena omezená VLAN, je na portu povolen omezený přístup do tzv. Auth-Fail VLAN. Uživatel se může znovu pokusit o nové ověření, případně využít jiný způsob autentizace, pokud je tato možnost k dispozici. (Cisco, 2011) Účtování Zdali proběhne autorizace a jednotlivé nastavené politiky na switchi, může tento switch odeslat RADIUS Accounting-Request zprávu na RADIUS server s konkrétními detaily autorizace. (Cisco, 2011) Ukončení Jednou z důležitých části 802.1x je správné a okamžité ukončení otevřeného portu a celé autentizace. V případě správného neukončení relace a ponechání otevřeného portu by mohlo dojít ke ztrátě dat a narušení bezpečnosti sítě. Nejlepším způsobem zabezpečení sítě při ukončování relace u 802.1xje ukončení relace ihned po fyzickém odpojení zařízení z daného portu. V některých případech není takového nastavení možné zcela dosáhnout, a to v případě, pokud je zařízení 5 VLAN-virtuální LAN. 6 ACL-access control list, neboli seznam pro řízení přístupu.

43 Protokol 802.1x 43 připojeno nepřímo do sítě, tedy přes rozbočovač nebo přes IP telefon. (Cisco, 2011) Tab. 4 Mechanismy ukončení relace. Použitý případ Přímo připojené všechny koncové zařízení Jedno zařízení na portu Žádný IP telefon Koncové zařízení připojené přes IP telefon Nanejvýš 2 zařízení na portu (telefon + pc) Koncové zařízení připojené přes rozbočovač Fyzický rozbočovač Přemostěný virtuální rozbočovač Mechanismus ukončení Link down (Shozený port) U cisco telefonů CDP, vylepšený způsob pro ukončení po odpojení druhého portu. U IP telefonů, které nejsou od cisca: proxy EAPoL-Logoff + časovač nečinnosti. Inactivity timer (Časovač nečinnosti) Zdroj: ment/dot1x_dep_guide.html#wp Link down Ukončení relace je jedna z důležitých operací 802.1x. Nejjednodušší způsob ukončení relace je odpojení zařízení ze sítě, resp. z portu. Při odpojení zařízení z portu se port zavře a switch smaže předešlou relaci. Při opětovném připojení stejného zařízení nebo při připojení nového zařízení switch začne ověřování 802.1x od začátku. (Cisco, 2011) EAPoL Logoff Hlavním cílem EAPoL Logoff zprávy je umožnění sdělení ukončení relace ze strany klienta ke switchi. Jakmile switch tuto zprávu od klienta příjme, ukončí relaci. Ačkoliv EAPoL-Logoff nemá mnoho aplikací, proxy EAPoL-Logoff je proti tomu velmi užitečná zpráva. Například pokud je zařízení v síti připojeno přes IP telefon, tento může vyslat proxy EAPoL-Logoff zprávu v případě, že je koncové zařízení odpojeno od IP telefonu. Telefon nahrazuje MAC adresu koncového datového zařízení, čímž je proxy EAPoL-Logoff zpráva k nerozeznání od EAPoL-Logoff zprávy zaslané přímo z koncového zařízení. Na základě EAPoL-Logoff zprávy switch okamžitě ukončí relaci. Na switchi není vyžadována žádná speciální přídavná funkcionalita spojená s ukončením relace a EAPoL-Logoff, jelikož tato zpráva je podporována dle IEEE standardu. Ovšem u IP telefonů je tomu už trochu jinak, téměř všechny cisco IP telefony a některé IP telefony ostatních výrobců proxy EAPoL-Logoff zprávy podporují,

44 Protokol 802.1x 44 u ostatních ale tato funkcionalita chybí a nemohou tak zasílat tento typ zpráv značící ukončení relace. (Cisco, 2011) CDP Cicso Discovery Protocol je protokol druhé síťové vrstvy modelu OSI, využívaný u aktivních prvků cisco. Tento protokol zjišťuje parametry sousedních zařízení, které jsou přímo připojené. Je to jeden z velmi dobrých způsobů, jak zjistit že všechny 802.1x realce jsou ukončené. Jednotlivé IP telefony od cisca mohou vysílat CDP na switch, který podle těchto protokolů pozná, který port je ve shozeném stavu a na základě toho může vymazat jednotlivé relace autentizace 802.1x koncových zařízení. (Cisco, 2011) Inactivity timer Tento časovač nečinnosti pracuje na principu sledování činností jednotlivých koncových zařízení. Pokud switch zhodnotí podle časovače nečinnost koncového zařízení, tedy pokud vyprší čas časovače nečinnosti, switch ukončí všechny relace, které s tímto koncovým zařízením byly spjaty. Časovač nečinnosti u 802.1x lze nastavit dvěma způsoby, a to staticky přímo na portech switche nebo dynamicky přiřazené jako RADIUS Idle-Timeout Atributy. Ve velké míře je lepší využít nastavení přes RADIUS atributy, což umožňuje lepší kontrolu koncových zařízení, u kterých je sledován čas nečinnosti. Ne vždy je ale užitečné využít právě možnosti časovače, například u IP telefonů, které umožňují posílání proxy EAPoL-Logoff zprávy, je tato zpráva daleko účinnější v rozpoznání odpojení koncového zařízení a ukončení relace, než u časovače nečinnosti. Stejně tak u zařízení, u kterých je předpoklad dlouhodobého připojení, je vhodné nastavit časovač nečinnosti na delší časový úsek. Díky časovači nečinnosti ovšem nelze se stoprocentní jistotu určit, že i když tento čas vyprší, že bylo koncové zařízení fyzicky opravdu odpojeno ze sítě. Například u síťové tiskárny, která odpovídá pouze občas na jednotlivé žádosti, se může stát, že časovač nečinnosti vyhodnotí toto zařízení jako odpojené po tom, co tento čas neaktivity vyprší. Switch vymaže veškerou relaci u tohoto koncového zařízení a v případě tisku musí proběhnout autentizace a ověření znovu. (Cisco, 2011)

45 Analýza 45 5 Analýza Společnost, ve které má být implementace 802.1x provedena, se zabývá výrobou různých komponentů pro teplárenský průmysl, ale také vývojem a inovacemi v nejrůznějších průmyslových odvětvích, proto je pro ni otázka bezpečnosti na jednom z důležitých míst. Hlavním cílem a mottem firmy je kromě snahy o stoprocentní kvalitu svých produktů, stoprocentní bezpečnost všech zaměstnanců. Mimo jiné také pokud možno co nejlepší zabezpečení firemní infrastruktury. V posledních několika letech je zabezpečení firemní infrastruktury této konkrétní firmy velice důležité, protože potencionální riziko napadení sítě ve všech segmentech firemní infrastruktury s postupem času a s vývojem nových technologií stále roste. Důležitými prvky zabezpečení je nejen úspěšná ochrana datových center, ale také obrana proti napadení interní infrastruktury, zabezpečení úniku citlivých informací nebo včasné rozpoznání a zamezení přístupu koncových klientů napadených virem. Na zabezpečení firemní infrastruktury je aplikováno již několik bezpečnostních prvků v tomto firemním prostředí, ovšem stále je zde možné aplikovat další prvky. Některé formy zabezpečení firemní infrastruktury vyžadují vynaložení velmi vysokých finančních nákladů na pořízení nových technologií, specializujících se na ochranu sítě. Lze využít i jiné formy zabezpečení, které nevyžadují zdaleka tak vysoké náklady na pořízení nových technologií, ale ve všech případech musí jít o určitý kompromis mezi bezpečností a funkcionalitou. Pokud bude firemní infrastruktura opravdu bezpečná, z důvodu maximálního možného nastavení bezpečnostních prvků a opatření, tato bude na druhou stranu méně využitelná v praxi, kdy budou nastávat delší odezvy, bezpečnostní omezení apod. Veškeré zabezpečení je nutné nejprve důkladně zvážit, aby vyhovovalo daným potřebám a možnostem této konkrétní firmy. Z tohoto důvodu jsou v tomto firemním prostředí vykonávány mimo jiné různé bezpečnostní audity, které odhalují možné slabiny zabezpečení, nebo navrhují další možnosti efektivního opatření, zabraňujícímu napadení interní sítě. 5.1 Firemní standard Vzhledem k tomu, že se jedná o velkou společnost působící na českém trhu již desetiletí, která si klade za cíl maximální ochranu zabezpečení firemního prostředí podle vlastních interních bezpečnostních nařízení, nebude v celé práci záměrně uveden název této společnosti. Se security teamem, s vedením IT oddělení firmy a s projednáním této problematiky spolu s vedoucím práce, zde nebude záměrně uveden kromě názvu společnosti ani detailní popis a implementace stávajícího zabezpečení firemní infrastruktury. Stávající zabezpečení firemní infrasturktury bude popsáno pouze obecně, bez detailů a konkrétních konfiguračních skriptů, které by mohly být potencionálně zneužity v budoucnosti, což se rozchází s bezpečnostními standardy firmy o ochraně a zabezpečení vnitřní firemní infrastruktury.

46 Analýza 46 Veškeré hardwarové vybavení, tedy koncoví klienti a servery jsou dodávané od společnosti Dell s celkovým řešením softwaru od Microsoftu. Tedy jak operační systémy na koncových klientech, které jsou Windows 7, tak také Windows Server 2003, 2008, 2008 R2 i 2012, jež jsou instalované na jednotlivých serverech. Aktivní síťové zařízení je celkově řešeno ve firemním prostředí od společnosti Cisco, která patří mezi špičku ve vývoji a výrobě síťových zařízení. Vyskytuje se zde i několik síťových zařízení, resp. switchů od výrobce 3COM a TP-LINK, tyto slouží ovšem pouze pro testovací účely a nejsou zapojeny do infrastruktury firmy. 5.2 Stávající firemní zabezpečení Stávající zabezpečení je řešeno s ohledem na co nejlepší zabezpečení firemní infrastruktury. Zabezpečení je nastaveno v souladu s doporučením renomovaných firem, které působí v tomto oboru již několik let a mají mnoho zkušeností se zabezpečením v praxi. Některé bezpečnostní řešení je dodáváno externí firmou jako outsourcované kompletní řešení. Kombinace několika různých bezpečnostních nastavení spolu udává vysoké procento celkového zabezpečení firemní infrastruktury. Zabezpečení je nastaveno na různých úrovních firemní infrastruktury a to zabezpečení přímo na koncových klientech, zabezpečení na switchích a následně zabezpečení na dalších aktivních síťových zařízeních a serverech. Zabezpečení firemní infrastruktury na perimetru sítě, tedy zabezpečení implementováno přímo v konfiguraci switchů je následující: Port security Na každém switchi ve firemním protředí je nastavena port security, což je jedna z metod zabezpečení přístupu do sítě. Jedná se o kontrolu příchozích paketů na portu z povolené MAC adresy. Pokud pakety přichází z jiné než povolené MAC adresy, komunikace je blokovaná. Je nastaven i pevný čas pro mazání dynamických MAC adres na portu, pomocí klíčového slova aging time. Pomocí port security je nastavena pouze jedna MAC adresa na port Spanning tree Spanning tree protokol, hojně využívaný a mnohokrát také nezbytný nástroj pro zabránění smyček v síti. Je nastaven jak u redundantních spojení, tak na všech switch zařízeních. U těchto switchů zabraňuje smyčkám při špatném propojení switchů, což se již několikrát omylem stalo. Tímto je také zamezena tvorba smyček při neodborném propojení obsluhou, kdy se jeden z portů disabluje a nedojde k zahlcení sítě VLAN V tomto firemním prostředí jsou také hojně využívané VLANy neboli virtuální LAN. Jedná se o logické rozdělení sítě, které není závislé na fyzickém uspořádání jednotlivých prvků. Jde o segmentaci velké fyzické infrastruktury na několik

47 Analýza 47 menších sítí uvnitř. Jedná se většinou o nastavení jedné VLAN pro několik vzájemně podobných zařízení nebo zařízení vykonávající tutéž činnost, jakožto tiskárny apod. Případně zavedení VLAN pro určitou oblast výrobní linky, což s sebou nese bezesporu mnoho výhod. Pokud je napadena jedna VLANa, neměla by tato omezit další výrobní VLANu, a tudíž by neměla být ohrožena celková výroba Omezený počet MAC adres na switchi Na switchi je nastaven omezený maximální počet MAC adres, které jsou schopny se k danému switchi připojit ACL Jedním z bezpečnostních opatření je zavedení ACL, tedy Access Control List, což je zjednodušeně řečeno seznam pravidel řídící přístup k nějakému objektu. Z bezpečnostních důvodů zde nebudu uvádět, o jaké ACL se konkrétně jedná.

48 Návrh nového zabezpečení 48 6 Návrh nového zabezpečení Po zvážení všech možností zlepšení zabezpečení fyzického přístupu do firemní sítě a na základě posouzení bezpečnostních potřeb bylo navrženo zabezpečení portů ve firemním prostředí pomocí 802.1x. Návrh byl projednán s pracovníky a s managerem IT oddělení firmy. Návrh byl na základě tohoto projednání přijat a bylo rozhodnuto o jeho implementaci. Těžiště návrhu spočívá v implementaci protokolu 802.1x, což má přispět k další minimalizaci ohrožení firemní sítě. Určité procento útoků s cílem zcizit data, ohrozit síť nebo jiným způsobem poškodit firemní infrastrukturu se v praxi odehrává uvnitř firemního prostředí a je prováděno přímo zaměstnanci firmy, kteří ve velké míře, ať už vědomě či nevědomě, ohrožují celou infrastrukturu. Jedná se o případy, kdy se například sami zaměstnanci snaží připojit do firemní infrastruktury soukromé zařízení, které je mnohdy infikované malwarem, nebo jinak škodlivým softwarem. 6.1 Výhody 802.1x v konkrétním firemním prostředí Hlavním uvažovaným přínosem nasazení protokolu 802.1x by mělo být usnadnění stávající problematiky s připojením nechtěného hardwaru do vnitřní infrastruktury. Další nespornou výhodou je autentizace, která je součástí implementace a případné dohledávání uživatelských aktivit v logu. S využitím 802.1x lze také daleko lépe řídit přístup do sítě přes jednotlivé porty switche, nastavovat jednotlivým skupinám, jednotlivcům, nebo všem uživatelům různá pravidla související s povolením přístupu do sítě, případně nastavit podmínky, za kterých se mohou autentizovat. V neposlední řadě se implementací 802.1x odstraní možné riziko, při neoprávněném připojení do LAN zásuvek, na kterých jsou nastaveny speciální VLANy, například pro management apod. 6.2 Nevýhody v konkrétním firemním prostředí Nevýhody v tomto firemním prostředí mohou nastat s prodlevami při samotné autentizaci a nemožností tak okamžitého připojení do sítě. U některých výrobních zařízení je tento problém zvlášť podstatný a nelze opomenout, proto se musí každé specifické firemní síťové zařízení nastavit a otestovat individuálně. 6.3 Potřebný hardware a software Hardware, který je nezbytný pro návrh a následnou implementaci 802.1x, je v plné míře dostupný ve firemním prostředí. Stávající switche, konkrétně cisco Catalyst 2950, cisco Catalyst C2960, Cisco 3750G a Cisco Catalyst C4506 disponují podporou pro nastavení 802.1x. Radius server bude nastaven na operačním systému Windows server 2008 R2, jehož jedna licence je momentálně v této firmě nevyužita a lze ji použít pro tyto

49 Návrh nového zabezpečení 49 účely. Nasazení RADIUS, neboli služby pro vzdálenou autentizaci, na jiném již běžícím serveru s OS Windows server 2008 R2 nebylo umožněno. Využití pouze jedné služby (RADIUS) na tomto serveru je značně neefektivní, proto se počítá do budoucna s dalším využitím i jiných služeb na tomto serveru. Koncové stanice jsou od jednoho výrobce Dell. Konkrétně to jsou notebooky značky Dell typu Latitude E6400, E6410, E6420 a E6430. Stolní počítače jsou také od stejného výrobce a to následující typy: Dell Optiplex 760, 780, 790 a Téměř na všech zařízeních jsou nainstalovány image operačního systému Windows 7, proto bude následná implementace a testování zaměřeno právě na tento OS a jeho kompatibilitu s 802.1x.

50 Implementace 50 7 Implementace Z důvodu konfigurace jak koncových klientů, tak RADIUS serveru kde jsou nainstalované operační systémy od Microsoftu s anglickou jazykovou mutací a konfigurace cisco zařízení pomocí speciálních příkazů v anglickém jazyce a celkově používání odborné IT terminologie, budou v práci uváděny některé názvy, odborné termíny nebo jiné části v anglickém jazyce. 7.1 Konfigurace 802.1x na koncových klientech Všechny počítače ve firemním prostředí jsou od firmy Dell. Tedy notebooky řady Dell Latitude E6400, E6410, E6420 a E6430. Stolní počítače od stejného výrobce jsou řady Optiplex 760, 780, 790 a Taktéž servery jsou od tohoto výrobce. Veškeré nastavení a konfigurace na koncových klientech je prováděna právě na těchto typech zařízení. Všechny koncové stanice ve firemním prostředí, kterých se týká autentizace pomocí 802.1x, mají nainstalovanou image Windows 7, 32 bitů. Je zde také několik počítačů i s operačním systémem Linux, tyto jsou ovšem určeny pouze pro testování speciálního software a nejsou zapojeny do sítě, proto u nich není nutné nastavovat autentizaci pomocí 802.1x Zapnutí autentizační služby na počítači Nejprve bylo potřeba při konfiguraci 802.1x ve Windows 7 nastavit službu, která běží na počítači. Přes hlavní nabídku Start lze vyhledat Services (služby), které zobrazí všechny služby na počítači. Případně lze služby spustit přes vyhledávací okno Windows pomocí příkazu services.msc. Z nich bylo třeba nastavit Wired AutoConfig Services (Automatická konfigurace pevné sítě), neboli DOT3SVC, která je odpovědná za provádění ověřování 802.1x v rozhraních sítě Ethernet. Tato služba je v defaultním nastavení Windows vypnutá.

51 Implementace 51 Obr. 17 Služby ve Windows 7 Po rozkliknutí této služby byly zobrazeny její vlastnosti. Případně přes pravé tlačítko/properties (vlastnosti). Ve vlastnostech této služby musí být startup type (typ spuštění) přenastaven na Automatic (Automaticky), pokud tomu tak není. Defaultně je tato služba vypnutá, ovšem uživatel s oprávněním jako admin má možnost jednotlivé služby zapínat, a proto může být již tato služba zapnutá. Tato služba DOT3SVC musí být nakonfigurována tak, aby byla spuštěna pro poskytnutí přístupu síťovým prostředkům. Po nastavení typu spuštění na automaticky je nutné samotnou službu zapnout pomocí tlačítka Start. Cesta ke spustitelnému souboru je C:\Windows\System32\svchost.exe.

52 Implementace 52 Obr. 18 Vlastnosti služby ve Windows Konfigurace síťového rozhraní Po zapnutí autentizační služby bylo nutné nastavit vlastnosti rozhraní síťové karty konkrétních počítačů. Po zapnutí služby Wired AutoConfig Services se ve vlastnostech síťové karty každého počítače zobrazila nová záložka Authentication (ověřování). Bez předchozího zapnutí služby není tato záložka ověřování zobrazena. Přes Windows Start/Control Panel (Ovládací panely)/network and Sharing Center (Centrum síťových připojení a sdílení)/change adapter setings (Změnit nastavení adaptéru) bylo třeba vybrat připojení, na kterém je nutno nastavit 802.1x autentizaci. V tomto případě vlastnosti na Local Area Connection. Ve vlastnostech LAN v záložce Authentication (ověřování) bylo třeba zatrhnout Enable IEEE 802.1x authentication (Povolit ověřování podle standardu IEEE 802.1x) a Choose a network authentication method (Zvolit metodu ověřování v síti), kde bylo zvoleno s ohledem na optimální metodu, kterou je možné ve firemním prostředí použít Microsoft: Protected EAP (PEAP). V nastavení autentizační metody pod výběrem Settings bylo zrušeno defaultní nastavení pro Validate server certificate, jenž by vyžadovalo vysokou míru administrativní práce navíc, v podobě vytváření a exportování certifikátu na každého koncového klienta. Při využití Validate server certificate by nebylo možné automatické generování, exportování a instalace certifikátu na každého koncového klienta pomocí efektivního využití group policy, ani pomocí jiné automatizované metody, jak rozdistribuovat následné certifikáty na všechny koncové klienty. Dalším problémem by byla omezená platnost certifikátu, kdy v tomto firemním prostředí se podle standardu firmy generují certifikáty s expirační dobou jednoho roku, tedy po uplynutí této doby by bylo nutné opět vytvářet a instalovat nový certifikát, což by opětovně navýšilo administrativní nároky. V neposlední řadě zde vznikají ojediněle problémy nastavení certifikátu u jednotlivců, kteří nemají na konkrétním zařízení

53 Implementace 53 nastaveny admin práva. Z těchto důvodů byla autentizace pomocí certifikátu zavržena a ve vlastnostech Protected EAP Properties byla zvolena Autentizační metoda Secure password (EAP-MSCHAP v2) s konfigurací v podobě zrušení Automatically use my Windows logon name and password (and domain if any). Taktéž byly zrušeny všechny možnosti nastavení u výběru Autentizační metody Select Authentication Method, tedy Enable Fast Reconnect, které se využívá hlavně u autentizace pomocí wifi sítí, a dalších možností. Obě dvě možnosti nastavení u Local Area Connection Properties, tedy Remember my credentials for this connection each time I m logged on a Fallback to unauthorized network access byly taktéž povoleny. Autentizační mód, jehož konfigurace je přístupná přes additional settings/advanced settings okno kde bylo nutné v 802.1x settings záložce nastavit volbu specifikace autentizace, neboli správně nakonfigurovat volbu Specify authentication mode. První možnost user or computer mode byl zavrhnut z důvodu neefektivního nastavení, kdy je vybrána první správná autentizace. Neboli je umožněna autentizace buď uživatele, nebo počítače a finální jednotlivý konkrétní výběr autentizace, ať už uživatele, nebo počítače je z části nahodilý. V případě autentizace počítače a následného jakéhokoliv vzniklého problému je obtížné dohledat, který uživatel byl na konkrétním autentizovaném počítači přihlášen. Tato možnost výběru módu s dvojí možností autentizace se všeobecně nedoporučuje. Bylo uvažováno o výběru módu v podobě autentizace pouze počítače, nebo jenom uživatele. Z důvodu přihlašování více uživatelů na jednom koncovém zařízení, který byl popsán výše, byla navržena konfigurace pro specifikaci autentizačního módu na autentizaci uživatele. Poslední případnou možností pro konfiguraci módu je také Quest autentizace, která se v praxi téměř nevyskytuje. Taktéž možnost konfigurace Enable single sign on for this network se v praxi nevyskytuje velmi často a ani v tomto firemním prostředí nebyla tato možnost konfigurována.

54 Implementace 54 Obr. 19 Vlastnosti připojení k místní síti Automatické zapnutí služby a konfigurace síťového rozhraní Pro účely testování jednotlivých zařízení ve firemním prostředí byla jak služba, tak konfigurace síťového rozhraní nastavována manuálně, předem popsaným způsobem. Pro účely hromadného zapnutí služby na všech klientech, tedy na všech dotčených počítačích by byla manuální konfigurace jednotlivých klientů velmi zdlouhavá, proto byl tento problém řešen nastavením přes group policy. Group policy není spravována kolálně, tudíž muselo být zažádáno o nastavení této služby a síťového rozhraní dotčených klientů. Služba pro automatické spouštění služby Wired autoconfig byla nastavena přes group policy pomocí následující politiky: Computer Configuration\Policies\Windows Settings\Security Settings\System Services\Wired AutoConfig. Taktéž konfigurace síťového rozhraní bylo nastaveno přes group policy pomocí politiky: Computer Configuration\Policies\Windows Settings\Security Settings\Wired Network Připojení k síti Klienti, tedy stolní počítače i laptopy, jsou propojeny v celém firemním prostředí přespřímý UTP kabel kategorie 5e do LAN zásuvek. Jednotlivé zásuvky jsou pomocí síťové infrastruktury vyvedeny do konkrétních racků, kde jsou dalšímy barevně odlišnými kabely propojeny z patch panelů do jednotlivých portů na switchi. Tyto switche jsou opět propojeny za pomocí síťové infrastruktury na centralizované místo do aktivních cisco zařízení umístěných v serverovně.

55 Implementace 55 Obr. 20 Rack osazený třemi cisco switchi Ostatní zařízení Ve firemní infrastruktuře se vyskytují také zařízení, které nedokáží odpovídat na standardní 802.1x požadavky switche, a proto muselo být řešeno adekvátní opatření, které by dané zařízení mohlo autentizovat a zůstala tím zachována bezpečnost, kterou s sebou implementace 802.1x přináší. Jedná se ve velké míře o síťové tiskárny, v menší míře pak muselo být toto opatření implementováno i pro UPS, IP kamery a PDU. Pro autentizaci těchto zařízení bylo zvoleno MAB, tedy Mac Authentication Bypass. Jedná se o metodu ověření zařízení podle jeho vlastní MAC a tím povolení přístupu přes port v případě správné autentizace. Mac Authentication Bypass je nakonfigurován na serveru, kde přes AD a MAC adresy konkrétních zařízení autentizuje server tato zařízení. 7.2 Konfigurace 802.1x na switchi V celém firemním prostředí jsou aktivní síťové prvky od jednoho výrobce a to společnosti Cisco. Jsou zde instalovány v jednotlivých racích switche typu Cisco WS-C2950, Cisco WS-C2960 a Cisco 3750G Umožnění autentizace 802.1x na switchi Nejprve bylo nutné na switchi nastavit AAA, tedy Authentication, Authorization a Accounting, jenž zajišťuje vlastní autentizaci, autorizaci a účtování, ať už zařízení nebo uživatele, za pomoci příkazu aaa new-model. Příkazem aaa authentication

56 Implementace 56 dot1x default group radius byl vytvořen defaultní seznam, který byl automaticky nastavený na všech portech switche. Klíčovým slovem group radius v tomto příkazu se umožnilo využití seznamu všech RADIUS serverů, které byly nastaveny pro autentizaci. Globálně na celém switchi bylo povoleno 802.1x, jenž se nastavilo příkazem dot1x systém-aut-control. Kvůli autorizaci klientů RADIUS serverem bylo nutné na switchi nastavit příkazem aaa authorization network group radius tuto možnost. Tedy umožnění autorizace a následného nastavování VLAN, RADIUS serverem. Následně byl vybrán konkrétní port switche, na kterém byly konfigurovány další příkazy nutné pro správnou autentizaci. Pro konfiguraci více portů byl tento nastavován pomocí příkazu range, kdy bylo nastavováno více portů souběžně. Zapnutí AAA bylo zadáváno v globálním konfiguračním režimu switche, do kterého se lze dostat přes privilegovaný uživatelský režim pomocí příkazu enable a configure terminal. Nastavení AAA metody pro 802.1x vypadá v přehledu příkazů na cisco switchi následovně: Switch>enable Switch#configure terminal Switch(config)#aaa new-model Switch(config)#aaa authentication dot1x default group radius Switch(config)#aaa authorization network group radius Switch(config)#aaa accounting dot1x default start-stop group radius Switch(config)#dot1x system-auth-control Switch(config)#interface fastethernet0/1 Pro správnou funkcionalitu a konektivitu bylo nutné nastavit VLANy, včetně IP adres, díky nimž je možná konektivita switche s RADIUS serverem. Na všech firemních switchích byly nastaveny IP adresy na VLAN 1, tedy na defaultních VLANách, přes které je také možné managovat tyto switche. Switche byly ovšem konfigurovány jednotlivě přes konzolový kabel. Nastavené switche, a tedy i jejich IP adresy na default VLAN 1, byly konfigurovány také na RADIUS serveru, jakožto RADIUS klienti. Tyto VLANy, nastavené pomocí příkazu interface vlan 1, ip adress byly již na switchi nastavené. Respektive nastavená byla pouze IP adresa switche na defaultní VLANě. První port switche byl na všech switchích nastavený na tuto VLANu, přes kterou probíhá komunikace, mimo jiné i s RADIUS serverem. Kromě toho lze přes tuto IP switche managovat. Tedy tento port již byl nastaven díky příkazům interface FastEthernet0/1, ustanoven pro koncové zařízení módem switchport mode access a zařazen do správné VLANy pomocí switchport access vlan 1. SWITCH(config)#interface vlan 1 SWITCH(config-if)#ip address SWITCH(config-if)#no shutdown SWITCH(config-if)#exit SWITCH(config)#interface fa0/1 SWITCH(config-if)#switchport mode access SWITCH(config-if)#switchport access vlan 1

57 Implementace 57 Jednotlivé porty každého switche byly nastaveny tak, aby 802.1x vyhovovaly potřebám firemní infrastruktury: authentication control-direction in Pomocí příkazu authentication control-direction in je port switche nastaven pouze pro jednosměrnou komunikaci v případě, pokud není port autentizován. Tzn., pokud se ve firemním prostředí připojí jakékoliv zařízení do sítě, bude na tomto portu umožněna (kromě defaultního nastavení) pouze komunikace směrem ke klientovi, nikoliv naopak od klienta směrem ke switchi. Tato konfigurace nastavení portu je také výhodná při využití možnosti vzdáleného zapnutí počítače přes síťovou kartu, tedy při využití Wake on LAN. authentication event fail action authorize vlan 660 Pokud ověření z jakéhokoliv důvodu selže, daný port je přepojen do konkrétní VLANy 660. V tomto případě je po dobu testovacího provozu port přepojen opět do datové VLANy a kontroluje se pouze v logu, jestli nedochází k přenastavení portu do datové VLANy z důvodu event fail action. Číslo datové VLANy 660 je v tomto případě smyšlené, v reálném firemním prostředí jsou číselné označení VLAN poněkud odlišná. authentication event server dead action authorize vlan 2 V případě, že by byl server nedostupný, je port switche přiřazen do VLAN 2. Tato možnost je konfigurována z důvodu, kdy by nebyl ani jeden RADIUS server dostupný. Jelikož jsou konfigurovány z důvodu redundance dva RADIUS servery a v případě výpadku jednoho, je využit ještě druhý server, neměla by (a v podstatě ani nesmí) tato situace nikdy nastat. Pokud by byly nedostupné oba dva servery, je port switche přenastaven z důvodu zajištění správné konektivity opět do jiné datové VLANy a toto přenastavení je kontrolováno v logu. Po konzultaci s externí firmou, která již má s implementací 802.1x zkušenosti v různých firemních prostředích, je konfigurace dvou RADIUS serverů dostačující a v praxi v různých prostředích, kde bylo 802.1x implementováno, se zatím nestalo, aby vypadly oba dva servery najednou. Při výpadku obou dvou serverů by musela být nedostupná část, nebo celá firemní ínfrastruktura. authentication event no-response action authorize vlan 660 Tento důležitý příkaz nastavený na portech switche ve firmě zajišťuje funkci přiřazení všech klientů, kteří ať už z jakéhokoliv důvodu neodpovídají switchi na Extensible Authentication Protocol over LAN request/identity, do speciální VLANy. V tomto případě je nakonfigurován port switche tak, aby pomocí tohoto příkazu přiřadil port opět do datové VLANy. Některé počítače, kde se neprovedlo zapnutí služby a konfigurace síťového rozhraní, nutného pro využívání 802.1x, by byly porty přiřazeny do omezené VLANy, což nemůže být v tomto reálném provozu dopuštěno. Switch si udržuje historii EAPoL paketů a pokud detekuje na portu jiný EAPoL paket, zakáže přepojení do speciální

58 Implementace 58 VLANy, tedy v tomto případě do datové VLANy, a port se nastaví do neautorizovaného stavu, kde začne opět probíhat autentizace. Pokud je na klientu již zapnutá služba apod., klient se autorizuje opět do datové VLANy, ale již standardní cestou. authentication event server alive action reinitialize Tento příkaz byl konfigurován na portech switche pro případ, pokud by nastala situace, kdy by byly oba dva servery nedostupné a alespoň jeden z nich by se stal opět dostupným. V takovém případě by nastala reinicializace klientů, kteří by se museli opět autentizovat. Jak bylo popsáno již dříve, k výpadku obou dvou RADIUS serverů by nemělo nikdy dojít a zatím se tak ani v praxi nestalo, proto by tento příkaz neměl být ani vykonáván. authentication port-control auto Příkaz authentication port-control auto nastavený na portech switchů umožňuje autentizaci firemních klientů a zároveň zapříčiní nastavení portu do neautorizovaného stavu, kdy jsou na těchto konkrétních portech propuštěny pouze EAPoL rámce. Tedy přes tento port mohou být odeslány nebo přijaty EAPoL rámce od koncových klientů, kteří se po připojení do sítě chtěji autentizovat. Díky tomuto příkazu je započata samotná autentizace, a to po odeslání EAPoL start rámce od klienta, nebo po tzv. změně portu na switchi ze stavu down na up. Po započetí autentizace již switch přeposílá komunikaci z klienta na RADIUS server. Pokud není klient správně nakonfigurován, v případě, že neběží korektně na klientu služba apod., port switche zůstane v neautorizovaném stavu a není mu umožněn plný přístup do sítě. Po odpojení klienta nebo po zaslání AEPoL logoff message se port dostane opět do neautorizovaného stavu. Při konfiguraci těchto portů na switchích byl u několika málo portů problém při umožnění 802.1x na portu pomocí příkazu authentication port-control auto, kdy bylo zobrazováno chybové hlášení a port nešel nakonfigurovat. Toto bylo způsobeno tím, že switch port byl ve stavu trunk mode, místo switch mode. Trunk mode byl na těchto portech nastaven z důvodu dřívějšího zapojení jiného testovacího switche, který již není v infrastruktuře zapojen. Po nastavení portů do switch port mode access již bylo možné 802.1x na portu povolit. dot1x pae authenticator Pro konfiguraci port access entity na portech jednotlivých switchů je využit tento příkaz. Díky němu je na firemních switchích nastavena řízená entita, využívající dot1x. dot1x timeout quiet-period 10 Dot1x tiemout quiet-period, tedy příkaz pro konfiguraci timeoutu daného portu, zapříčiní nastavení timeoutu, po který switch vyčkává při neúspěšné autentizaci. Tento příkaz je využit v případě, kdy je autentizace neúspěšná a switch zůstává po tuto nastavenou dobu nečinný, poté se pokusí o opětovnou autentizaci. Tento čas ohraničuje časový prostor mezi RADIUS

59 Implementace 59 access reject zprávou ze serveru, resp. EAP failure zprávou kterou přeposílá switch reprodukovaně ze serveru na koncového klienta a opětovnou žádostí EAP request identity přeposlanou též po uplinutí quiet-period ze switche na klienta. Defaultně je quiet-period nastaven na 60 sekund, tento čas byl ovšem pro zrychlení celé operace a snížení časových prodlev nastaven na všech portech switchů ve firemním prostředí na 10 sekund. dot1x timeout tx-period 10 Za pomoci příkazu timeout tx-period byl na portech firemních switchů nastaven další timeout. V případě, kdy switch zasílá EAP request identity rámce na klienta a nedostává od klienta na tyto žádosti žádnou odpověď, vyčkává právě stanovený tzv. retransmission time, po jehož uplynutí posílá znovu žádost na klienta v podobě EAP request-identity. Tento timeout nastavený defaultně na 20 sekund byl zkrácen pouze na 10 sekund na všech portech switchů. S tím související maximální počet opakování zasílání EAP request identity mezi jednotlivými timeouty, zapříčiněný příkazem maxreauth-req byl ponechán na defaultní hodnotě, tedy s počtem dvou reautentizací. dot1x timeout supp-timeout 10 Ve firemním prostředí na jednotlivých portech byl nastaven také timeout za pomoci příkazu dot1x timeout supp-timeout, který byl nastaven na 10 sekund. Defaultní hodnota tohoto timeoutu je přitom 30 sekund. Příkaz pro tento timeout má velmi podobnou funkcionalitu jako předešlý příkaz dot1x timeout tx-period, ovšem supp-timeout je nastaven a případně využit, pokud klient přestane odpovídat již v průběhu autentizace. Tedy pokud klient odpoví na požadavek ze switche pomocí EAP-response a dále již na ostatní požadavky EAP-request přeposlané ze serveru prostřednictvím switche neodpovídá. Po vypršení tohoto timeoutu switch opětovně odešle EAP-request a čeká na odezvu od klienta. Stejně jako max-reauth-req u dot1x timeout tx-period byl ponechán v defaultním nastavení také dot1x max-req, tedy v případě opětovného odesílání EAP-request ke klientovi se odešle pouze dvakrát. Příklad konfigurace jednoho portu switche: Switch(config-if)#dot1x control-direction in Switch(config-if)#authentication event fail action authorize vlan 660 Switch(config-if)#authentication event server dead action authorize vlan 2d Switch(config-if)#authentication event no-response action authorize vlan 660 Switch(config-if)#authentication event server alive action reinitialize Switch(config-if)#authentication port-control auto Switch(config-if)#dot1x pae authenticator

60 Implementace 60 Switch(config-if)#dot1x timeout quiet-period 10 Switch(config-if)#dot1x timeout tx-period 10 Switch(config-if)#dot1x timeout supp-timeout 10 Obr. 21 Konfigurace portu switche v průběhu testování Pro zvolení metody autentizace byl nakonfigurován switch tak, aby využíval pro autentizaci externí RADIUS server, běžící na Windows Serveru 2008 R2, tedy příkazem radius-server host ip, kde místo ip byla zadána konkrétní staticky nastavená ip adresa RADIUS serveru. Auth-port specifikuje číslo cílového UDP portu, které bylo defaultně ponecháno na hodnotě Klíčové slovo key, nezbytné při konfiguraci, uvádí tzv. secret key, jenž muselo být stejné i v nastavení RADIUS klienta na RADIUS serveru. Jedná se o alfanumerický řetězec sloužící k ověřování přístupu klienta. Během testování se vyskytnul problém v komunikaci mezi switchem a RADIUS serverem. Tento problém byl způsobem na serveru při vytváření RADIUS klienta během zadávání key s omylem nastavenou českou klávesnicí. Po smazání RADIUS klienta a konfiguraci nového byl tento problém odstraněn. Kvůli redundanci RADIUS serveru byly nastavené dva RADIUS servery, aby v případě výpadku jednoho probíhala autentizace s využitím druhého serveru. Switch(config)#radius-server host auth-port 1812 acct-port 1813 key Radius20 Switch(config)#radius-server host auth-port 1812 acct-port 1813 key Radius30

61 Implementace 61 Pro Mac Authentication bypass bylo uvažováno o konfiguraci přímo na portu switche. Kvůli starším IOS, které jsou na některých firemních switchích, tyto neumožňují příkaz dot1x mac-auth-bypass. Tento příkaz je dostupný na aktivních cisco prvcích pouze pod novějším IOS. Proto byla autentizace pomocí MAB konfigurována na serveru. Port switche požadavky na MAB propustí poté, co vyprší timeouty autentizace a není žádná odpověď na 802.1x ze strany klienta. Veškerá zařízení, která vyžadovala Mac Authentication Bypass, musela být zadána do AD na serveru do speciálně vytvořené organizační jednotky, kde název nově vytvořeného uživatele, jakožto zařízení, bylo nastaveno jako MAC adresa zařízení. Tedy User name = MAC zařízení stroje, kde každé přidávané zařízení byl nově vytvořený uživatel s názvem MAC adresy zařízení. Pro tyto zařízení jsou staticky nastaveny IP adresy, ovšem v celém firemním prostředí není udržovaný žádný seznam MAC adres těchto zařízení. Tyto MAC adresy musely být dohledávány z CAM tabulek, vygenerovaných na switchi a spárovány s IP adresami daných zařízení, pro přesné dohledání a přiřazení MAC adres ke konkrétním strojům. 7.3 Konfigurace 802.1x na RADIUS serveru Radius server běží pod operačním systémem Windows Server 2008 R2 od společnosti Microsoft. Oproti Windows Server 2008, je verze R2 odlišná a vychází spíše z prostředí Windows 7. Ve firemním prostředí byla jedna licence na Windows Server 2008 R2 volná, proto byla tato licence použita pro RADIUS server. Redundatní RADIUS server běží na jiném serveru, kde jsou souběžně nakonfigurované jiné služby a NPS server je zde pouze pro potřeby redundance. Tedy pokud by nastala situace, kdy se hlavní RADIUS server stane nedostupným a je potřeba využít druhý RADIUS server se stejnou konfigurací jako hlavní RADIUS Instalace a konfigurace NPS Na počátku implementace RADIUS bylo zvažováno, zda nakonfigurovat RADIUS server na Microsoft Windows Serveru 2003, tedy zda použít pro tuto implementaci IAS, nebo použít operační systém Microsoft Windows 2008 R2, kde je již novější obdoba IAS, a to NPS. Z důvodu velkého vytížení serverů běžících pod Windows Server 2003 ve firemním prostředí, byla zvolena možnost využití volné licence Windows Server 2008 R2, na nějž se později plánuje přidat několik dalších služeb. Využití instalace Windows Server pouze pro RADIUS by bylo už jen z ekonomického hlediska ceny licence neefektivní. Jako redundantní RADIUS server byl později využit jiný Windows Server 2008R2. NPS neboli Network Policy Server, který byl nainstalován a konfigurován, umožňuje centrálně vytvářet zásady při přístupu do sítě. Lze pomocí něj konfigurovat autentizaci a autorizaci při přístupu k síti. NPS ve Windows Server 2008 R2 je obdoba IAS (Internet Authentication Service), která je u starších verzí Windows Server, konkrétné u Windows Server 2003, 2003 R2 a 2003 se SP1 a SP2.

62 Implementace 62 Před samotnou instalací NPS bylo nutné zajistit, že byla instalace prováděna pod administrátorským účtem, bylo nastaveno síťové připojení se statickou IP adresou a v neposlední řadě také nutná kontrola nainstalovaných aktuálních updatů. V první řadě bylo nutné nainstalovat a nakonfigurovat NPS pro autentizaci uživatelů. V prostředí Windows Server 2008 R2 se přes Server Manager, dále přes Roles vybralo Add Roles. Z nabídky možných Rolí bylo nutné vybrat právě Network Policy and Access Services. Obr. 22 Instalace NPS výběr Role V průběhu instalace bylo nutné v nabídce Role Services vybrat NPS, který umožňuje vytvářet a vynucovat zásady pro přístup k síti napříč celou oragnizační strukturou. Obr. 23 Instalace NPS přes Server Manager Po výběru NPS a následné instalaci se zobrazila informativní zpráva o výsledku úspěšného nainstalování NPS. Pokud by nebyly splněny předešlé požadavky, jako instalace pod admin účtem, poslední updaty apod., instalace by skončila s chybovou hláškou a nebyla by správně nainstalována. Po úspěšné instalaci NPS

63 Implementace 63 bylo možné pro přístup k NPS využít buď Server Manager a odkaz Roles, nebo přes All programs/administrative Tools/Network Policy server. Poté bylo možné již NPS konfigurovat, tedy vytvořit nového klienta. Nový RADIUS klient sevytvořil v NPS pod záložkou RADIUS Clients and Servers. Pravým kliknutím bylo možné vytvořit nového klienta a nastavit nezbytné hodnoty. Tyto hodnoty jako Friendly name, IP address nebo Shared secret, se musely shodovat také s nastavenímna samotném RADIUS klientu tedy na switchi. Postupně byly nakonfigurovány a přidány jako RADIUS klienti všechny switche ve firemním prostředí. Několik desítech switchů bylo konfigurováno s vlastnostmi Friendly name v podobe Switch_pozice v racku_rack, ip adresa každého switche a shared secret bylo nastaveno pro všechny switche stejné. Po předchozím projednání s kolegy bylo rozhodnuto, že se jedná pouze o heslo pro ověření Radius klienta s RADIUS serverem, které bylo nakonfigurováno jen na switchi a RADIUS serveru, tedy na místech kam nemá nepověřená osoba přístup. Všechny racky jsou uzamčeny a přístup na RADIUS server je možný pouze pod speciálním serverovým administrátorským účtem, tudíž by nemělo být zneužitelné, přestože je například v exportovaném xml souboru NPS serveru v nešifrované podobě. Navíc konfigurace unikátního hesla pro každý switch zvlášť by zvýšilo nároky na administraci na straně IT oddělení. Obr. 24 Vytváření nového RADIUS klienta Konfigurace síťových zásad Dalším důležitým prvkem nastavení NPS bylo vytvoření síťových zásad, tzv. Network Policy. Network Policy v tomto případě obsahují kritéria RADIUS klienta a uživatele, které musí splňovat, aby byl koncový klient korektně autentizován. Síťové zásady se vytvářely přes záložku Policies/Network Policies/New. Při vytváření bylo nutné uvést jméno zásady a položku Type of network access server, v tomto případě ponechat na Unspecified, jelikož byla zásada nastavována pro autentizaci switche pomocí 802.1x. Dalším krokem bylo nastavení podmínek, tedy specifikování kritérií, která musí být splněna, aby mohlo dojít k úspěšnému splnění

64 Implementace 64 požadavku na autentizaci. Přidání podmínky bylo provedeno přes Add/Windows groups/add groups, kde byla vybrána konkrétní skupina uživatelů již vytvořená v Active Directory, jejíž všichni členové mají mít právo se autentizovat. U této skupiny byl nastaven Object type na Group, Location nastaveno na základní stromovou strukturu v AD a Object name je konkrétní skupina platných uživatelů, která již v AD existovala. Z bezpečnostního hlediska nelze uvést konkrétní název skupiny, ani adresářovou strukturu. Po přidání skupiny se tato následně zobrazila v dalším kroku konfigurace jako nastavená podmínka, včetně hodnoty, tedy doména\název skupiny. Po vytvoření podmínky bylo nutné specifikovat její povolení pro přístup do sítě, a to výběrem Acces Granted. Obr. 25 Specifikace povolení přístupu Následující krok konfigurace umožňoval stanovit autentikační metodu jenž je MS- CHAP-V2. Rozřiřující možnosti volby povolení, nebo zákazu autentizace, po předchozím projednání s odborníky zainteresovanými v daném oboru, nebyly nastaveny. Mezi rozšiřující možnosti omezení patří například konfigurace povolení nebo zakázání konkrétních IPv 4 adres apod. Po nastavení dané podmínky byl zobrazen finální soupis celé konfigurace této podmínky. Po potvrzení Finish se dokončila konfigurace podmínky a tato byla zobrazena mezi soupisem všech politik sítě. Pomocí příkazu Move up bylo nutné přetáhnout nově vytvořenou politiku na první místo, případně na některé z prvních míst, pokud se již sama po vytvoření nenastavila na horní pozici defaultně. Dané podmínky jsou vykonávány v pořadí, v jakém byly nastaveny na seznamu síťových politik na NPS, proto bylo nutné zvážit, která politika má přednost a kterou bylo nutné nastavit na první místo. Jednotlivé požadavky od RADIUS klienta jsou porovnávány s nastaveními jednotlivých politik. Na žádost RADIUS klienta jsou postupně vybírány jednotlivé síťové zásady podle jejich původních uspořádání. Jakmile je na žádost od RADIUS klienta vyhověno některou z předem nastavených síťových politik, přestanou se již

65 Implementace 65 další síťové zásady prohledávat a RADIUS server odpoví na tento požadavek právě vybranou síťovou zásadou. Mezi vytvořenými zásadami byla jako první nakonfigurována zásada MAB pro autentizaci ostatních zařízení pomocí jejich vlastní MAC adresy. Tato zásada je podrobněji popsána v následujícím odstavci MAB. Pro autentizaci dalších zařízení pomocí 802.1x byly nastaveny jiné zásady. Na druhém místě byla nakonfigurována zásada, která využívá jako autentizační metodu PAP, tedy jednoduchý ověřovací protokol, jenž není v šifrované podobě. Tato zásada byla konfigurována pro zařízení, která neumožňují autentizaci pomocí šifrovaného protokolu. Kromě protokolu pro autentizaci byla tato zásada také nakonfigurována tak, aby využívala všechny switche v síti pomocí nastavení Client Friendly Name, umožňuje autentizace po dobu 24 hodin denně, 7 dní v týdnu, jenž bylo nastaveno za pomocí podmínky Day and time restrictions. Další podmínkou bylo nastaveno využití autentizace uživatelů nastavených v AD. Hlavní síťovou zásadou pro autentizaci koncových klientů byla konfigurována zásada s několika nastavenými autentizačními metodami, kterými jsou Microsoft Encrypted Authentication version 2, Microsoft Encrypted Authentication, Encrypted Authentication. Jakožto EAP typ bylo nastaveno Protected EAP, Secured password (EAP-MSCHAP v2) a other certificates. Stejně jako u předešlých zásad byla nastavena zásada tak, aby bylo možné využití zásady u všech RADIUS klientů. Tedy pomocí podmínky Client Friendly Name s využitím parametru Switch*, jenž umožní využití zásady u všech Switchů, nakonfigurovaných na RADIUS serveru, jenž jsou označeny pod názvem Switch a konkrétním číselným označením. Podle doporučení jednotlivých recenzí zabývajících se touto problematikou, byla nastavena podmínka Day and time restrictions na neomezeno. Tato podmínka nemusí být nutně nastavena, ovšem v praxi se doporučuje její nastavení, z důvodu odstranění nahodilých situací, které díky nevymezení času autentizace mohou nastat. Důležitou podmínkou pro nastavení autentizace byla konfigurace podmínky User groups. Pomocí této podmínky byla vybrána skupina uživatelů v AD, jenž mají právo se autentizovat a mají povolený přístup do sítě.

66 Implementace 66 Obr. 26 Specifikace jednotlivých parametrů Redundantní RADIUS server Aby byla zajištěna redundance v případě výpadku hlavního RADIUS serveru, bylo nutné nastavit záložní RADIUS server, běžící opět pod Windows Server 2008 R2. Tento je schopen převzít úlohu hlavního RADIUS serveru, v případě jeho výpadku. Prvním požadavkem na zálohu bylo vyexportovat kopii NPS konfigurace na hlavním serveru. Tento export se zajistil pomocí příkazového řádku ve Windows Server 2008R2 přes skriptovací utilitu Network Shell, vytvořenou právě pro příkazovou řádku. V příkazové řádce byl zadán příkaz netsh a potvrzen enterem. Další příkaz, nutný pro export byl nps, který se opět potvrdil klávesou enter. Následující příkaz export filename= C:\Users\E428634\Desktop\nps_export.xml exportpsk=yes vyexportuje xml soubor obsahující konfiguraci NPS na plochu. Tento soubor obsahuje mimo jiné i nastavení registrů apod. Příkaz exportpsk=yes v sobě podmiňuje upozornění, že se vyexportují do xml souboru také hesla radius klientů v nezašifrované podobě. Z toho důvodu je nutné soubor chránit proti případnému zneužití. Na záložním serveru se tento soubor naimportuje obdobným příkazem netsh nps import filename= C:\Users\E428634\Desktop\nps_export.xml. Export a import NPS po pozdějším zjištění by bylo možné rovněž provést přes grafické rozhraní Windows Server 2008R2. Konkrétné přes Server Manager/Roles/NPS a pomocí pravého tlačítka výběrem export s udáním cílové cesty pro uložení, případně import na záložním serveru. Redundantní RADIUS server běží také pod operačním systémem Windows server 2008 R2, což je výhoda při konfiguraci redundantního NPS serveru. Tento

67 Implementace 67 server byl konfigurován až po průběžném testování a odladění hlavního RADIUS serveru, ze kterého byl vyexportován xml soubor s konfigurací, jenž byla použita a importována právě na tento záložní server. Na RADIUS klientech, tedy cisco switchích, byly nakonfigurovány oba dva RADIUS servery, kdy v případu nedostupnosti prvního z nich je možné využít právě záložní. Ohledně zálohy a redundance RADIUS serveru bylo vedeno několik dotazů a jednání s odborníky z daného oboru, zdali je pouze jeden redundantní RADIUS server dostačující. Nakonec bylo toto řešení uznáno jako dostačující a spolehlivé MAB Pro požadavky autentizace klientů pomocí MAC adresy, byla zvolena optimální cesta nastavení těchto klientů přes AD vytvořením nové organizační jednotky, jakožto podskupiny hlavní domény. AD není spravováno lokálním IT, tudíž musela být pro tuto operaci schválena výjimka, která umožnila vytvořit organizační jednotku a přidávat do ní jednotlivá zařízení v podobě doménových uživatelů. Do této organizační jednotky byly přidány všechny zařízení, které bylo nutné autentizovat pomocí MAB. Tato zařízení byla přídána do organizační jednotky jakožto uživatelé, kde uživatelské jméno bylo zadáno v podobě MAC adresy konkrétního zařízení. Každé zařízení bylo nastaveno s parametry Network access permission na Allow access, End a disconnected session na never, Account options přenastaveny na User cannot changed password and Password never expired. Pomocí záložky Member of byla jednotlivá zařízení přidána do organizační jednotky určenou pro Mac Authentication Bypass. Description jednotlivých vytvořených zařízení byl zadáván jednotně, stejně jako v databázi aktuálních hardwarových zařízení v celém firemním prostředí, aby byla umožněna jednodušší administrativa. V případě vyřazení starého zařízení z firemního prostředí, se spolu s manuálním mazáním zařízení v databázi veškerého hardwaru firmy provede i vymazání záznamu v OU, jenž bude jednoduše dohledatelný podle sjednoceného popisu, jako názvu. Bylo uvažováno o automatickém mazání zařízení, a to pomocí skriptu, který by bylo nutné naprogramovat tak, aby prohledával záznamy z ARP tabulek switchů a tyto MAC adresy z tabulek porovnával se záznamy v AD v organizační jednotce. K tomuto kroku nakonec nedošlo, z důvodu složitější implementace a malého množství zařízení, kterého by se tato implementace týkala. Pro správnou autentizaci bylo nutné také nastavení politiky pro zařízení autentizované přes MAB. Tyto politiky nastavené přes NPS/Network policies, byly definované, aby umožňovaly autentizaci zařízení. Za účelem nastavení politik byla přidána podmínka User groups, která odkazuje na OU v AD vytvořenou pro uživatele autentizující se přes MAC. Další nastavenou podmínkou je Client friendly name s parametrem Switch*, jenž odkazuje na veškeré switche, které byly nakonfigurovány jakožto RADIUS klienti na NPS. Tito RADIUS klienti jsou definováni na NPS pod specifickým číselným označením, jenž je odvozeno od IP adres jednotlivých switchů. Mezi další definovanou podmínku patří Day and time restrictions, umožňující zařízením autentizaci po neomezenou dobu, tedy od

68 Implementace 68 pondělí do neděle po dobu 24 hodin s parametrem Permitted. Tato zařízení ve většině případů nedisponují možností šifrované komunikace, proto byly nastavené jako autentizační metody kromě MS-CHAP-v2, MS-CHAP a CHAP, také nešifrované PAP. Při zadávání MAC adres a následném testování vznikal problém při ověřování určitých zařízení. Tento problém byl po určité době odstraněn po správném zadání MAC adres jednotlivých zařízení, kdy jméno uživatele musí být zadáno jako MAC adresa zařízení ve stejném formátu, jako je MAC adresa nastavena na konkrétním zařízení. Tedy v přesném formátu s oddělovačem MAC adresy v podobě dvojtečky, tečky nebo pomlčky, tato adresa byla původně v jednotném formátu Kontrola logů Pro požadavky kontroly logů autentizace a autorizace pomocí 802.1x, bylo nutné vybrat sofistikovaný nástroj, jenž by umožňoval efektivnější kontrolu logů a tím odhalení případných problémů během autentizace, či autorizace v průběhu testovacího provozu nasazení 802.1x. Pro tyto účely kontroly logů postačoval v jednoduché míře pouze defaultně implementovaný Events Viewer zobrazující NPS Events v prostředí Microsoft Windows Server 2008 R2, který zobrazuje všechny NPS chybové zprávy a ostatní události, které byly nakonfigurovány pro NPS záznamy. Tento NPS Event Viewer byl využit během testování jednotlivých zařízení, ve firemním prostředí pro odladění nahodilých událostí. Tento NPS Event Viewer zobrazuje kromě zpráv typu neznámý RADIUS klient (pokud není RADIUS klient nakonfigurován na NPS serveru), také zprávy v podobě neplatného bezpečnostního hesla pro komunikaci s RADIUS klientem, neplatnou zprávu od authenticatora nebo problémy spojené s nemožností vyhledání uživatelského doménového jména, či autentizaci doménového uživatele. Tyto záznamy v NPS event vieweru uchovávají informace obsahující Úroveň zprávy, tedy zdali se jedná o chybovou, informativní nebo kritickou zprávu apod, datum a čas zprávy, kdy byla zaznamenána do logu, zdroj, ID konkrétni události a kategorii, která je v tomto případě vždy Network Policy Server. Tyto jednotlivé záznamy lze v prostředí NPS přímo přes NPS Event viewer jednoduše filtrovat, což bylo užitečné při kontrole logů během testování. Při testování více zařízení už docházelo k menší přehlednosti logů a byla zvolena implementace jiného sofistikovanějšího softwaru, pro kontrolu logů.

69 Implementace 69 Obr. 27 NPS Event Viewer Pro tuto potřebu kontroly logů bylo uvažováno o několika různých monitorovacích nástrojích, které by vyhovovaly potřebám pro dlouhodobé kompletní testování dané implementace. Jednotlivé softwary byly testovány jako zkušební trial verze. Jedním z takových testovaných softwarů byl i Microsoft IAS/NPS log analyzer od společnosti Sawmill, který dokáže pracovat s platformou Microsoft 2008 R2. Tento umí spolupracovat s formátem NPS logu, analyzovat a reportovat události nebo generovat dynamické statistiky. Hlavní využitou funkcionalitou bylo filtrování logů. Nakonec došlo k výběru nástroje Log Viewer od Kiwi, jenž je součástí Solarwinds. Pomocí tohoto monitorovacího nástroje, který zobrazuje log soubory v přehlednějším a čitelnějším formátu, jsou kontrolovány jednotlivé logy a tím související nahodilé situace během autentizace, či autorizace. Pomocí nástroje Kiwi Log Viewer lze jednoduše zobrazovat logy, které odpovídají zadaným podmínkám, lze vyhledávat také pomocí klíčových slov, což bylo užitečné v prvotních fázích zkušebního provozu. Změny náhledu log souboru jsou za pomocí Kiwi Log Viewer zobrazovány v reálném čase, jakožto nově vytvořené položky.

70 Implementace 70 Obr. 28 Kiwi Log Viewer 7.4 Omezení výrobní haly Prvotním návrhem při utváření jednotlivých požadavků na využití 802.1x ve firemním prostředí bylo implementovat 802.1x autentizaci portů na všech switchích v celém firemním prostředí. Tedy jak na klientech jednotlivých uživatelů v kancelářích, tak ve výrobní hale, kde jsou umístěné nejen osobní počítače, menší síťové tiskárny, ale také zařízení nezbytné pro provoz výroby, jakožto semboxy. Po projednání s dodavatelem semboxů bylo navrženo, aby tyto byly autentizovány standardně pomocí Mac Authentication Bypass, spolu s ostatními síťovými tiskárnami. Výrobní hala má vlastní racky osazené cisco switchi a všechna zařízení ve výrobě jsou zapojena do těchto switchů, na kterých jsou konfigurovány speciální výrobní VLANy. Bezpečnost u těchto zařízení je řešena pomocí ACL, tedy za pomoci seznamu pravidel, jenž řídí přístup k jednotlivým objektům. U této infrastruktury, která byla původně zahrnuta do implementace s konfigurací dynamického přiřazování ACL pomocí RADIUS, bylo upuštěno kvůli rozhodnutí IT vedení z důvodu, že se jedná o omezenou síť, s omezeným přístupem do výrobní haly, kde by případná nekorektní autentizace mohla zpomalovat připojení zařízení do sítě. Na těchto několika switchích ve výrobní hale tedy nakonec k implementaci 802.1x z uvedených praktických důvodů nedošlo. 7.5 Rozšíření implementace do budoucna Firemním požadavkem bylo testování a implementace 802.1x na kabelové firemní síťové infrastruktuře. Pokud bude stávající konfigurace po finálním testování uvedena v reálném prostředí bez jakéhokoliv omezení, bude snaha o schválení požadavku na rozšíření autentizace pomocí 802.1x i na bezdrátovou infrastrukturu, tedy na wifi. Konfigurace 802.1x na wifi spočívá v nastavení koncových klientů, kde stejně jako pro kabelové připojení je nutné spuštění služby a konfigurace AP. Taktéž je nutné pro wifi připojení nakonfigurovat RADIUS server, se všemi potřebnými zásadami i RADIUS klienty, včetně propojení s AD. Dalším rozšířením této implementace bylo uvažováno o autentizaci některých novějších tiskáren za pomoci certifikátu. Tyto tiskárny by po vytvoření exportu certifikátu přímo do tiskárny bylo možné autentizovat za pomocí právě tohoto certifikátu, nikoliv pouze za pomocí MAC adresy s využitím MAC Authentication