Integrace autentizačních mechanismů

Mendelova zemědělská a lesnická univerzita v Brně Provozně ekonomická fakulta

Integrace autentizačních mechanismů pro bezdrátové sítě v prostředí malé a střední firmy Bakalářská práce

Vedoucí práce: Ing. Martin Pokorný, Ph.D.

Miroslav Daněk

Brno 2009

Děkuji vedoucímu bakalářské práce, Ing. Martinu Pokornému, Ph.D., za metodické vedení při zpracování závěrečné práce a za poskytnutí potřebných podkladů, cenných rad, připomínek a spolupráce v laboratoři UI PEF MZLU. Dále děkuji Bc. Petru Halamíčkovi a Ing. Patriku Serafinoviči za poskytnutí technického zázemí v laboratoři. V poslední řadě bych chtěl poděkovat spolužákům, kteří se mnou spolupracovali na experimentální síti v laboratoři UI PEF MZLU. V laboratoři spolupracovali Brázdil Jiří, Klein Richard, Kejda Jan, Láník Radek, Macka Ivo a Zelinka Michal.

Prohlašuji, že jsem tuto bakalářskou práci vyřešil samostatně s použitím literatury uvedené v závěru práce.

Brno 25.5.2009

....................................................

4

Abstract Daněk, M. Integration of authentication mechanisms for wireless networks in small and medium companies. Bachelor thesis. Brno, 2009 The bachelor thesis deals with construction of a wireless company network. The major part of the bachelor tehesis deals with integration of a directed access of users to a wireless network through the protocol 802.1x by open-source products and tools. This work surveys potentialities of the FreeRADIUS product, which deals with authentication and authorization of users in a wireless network. Key words RADIUS, SSL, EAP, WIFI, certifikáty, Cisco

Abstrakt Daněk, M. Integrace autentizačních mechanismů pro bezdrátové sítě v prostředí malé a střední firmy. Bakalářská práce. Brno, 2009 Bakalářská práce se zabývá vybudováním bezdrátové firemní sítě. Hlavní část práce řeší integraci řízeného přístupu uživatelů do bezdrátové sítě přes protokol 802.1x pomocí open-source produktů a nástrojů. Tato práce mapuje možnosti produktu Free radius, který se stará o autentizaci a autorizaci uživatelů v bezdrátové síti. Klíčová slova RADIUS, SSL, EAP, WIFI, certifikáty, Cisco

5

OBSAH

Obsah 1 Úvod a cíl práce 1.1 Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Cíl práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Analýza firemní sítě 2.1 Požadavky na firemní síť . . . 2.2 Návrh . . . . . . . . . . . . . 2.2.1 Zóny v síti a Adresace 2.2.2 Uzly na síti . . . . . . 2.3 Připojení k internetu . . . . . 2.4 Operační systémy . . . . . . . 2.5 Hardware . . . . . . . . . . . 2.5.1 Síťové prvky . . . . . . 2.5.2 Servery . . . . . . . . 2.5.3 Klientské počítače . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

8 8 8 9 9 9 10 11 12 13 13 13 14 14

3 Analýza bezdrátové sítě 15 3.1 FREE-WIFI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.2 PRIVATE-WIFI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.3 Návrh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4 Technologie 4.1 Bezdrátové lan . . . . . . . . . . . . . . . . . . 4.2 Topologie bezdrátových sítí . . . . . . . . . . . 4.3 SSID . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Šifrování WEP . . . . . . . . . . . . . . . . . . 4.5 Přístup přes standard IEEE 802.1x . . . . . . . 4.5.1 EAP-Transport Lyer Security . . . . . . 4.5.2 EAP-Tunneled TLS . . . . . . . . . . . . 4.5.3 EAP-LEAP . . . . . . . . . . . . . . . . 4.5.4 EAP-MD5 . . . . . . . . . . . . . . . . . 4.6 Postup autentizace 802.1x . . . . . . . . . . . . 4.7 RADIUS protokol . . . . . . . . . . . . . . . . . 4.7.1 Radius paket . . . . . . . . . . . . . . . 4.8 Šifrování WPA a WPA2 . . . . . . . . . . . . . 4.9 Transport Layer Security a Secure Sockets Layer 4.10 Certifikáty normy X.509 . . . . . . . . . . . . . 4.10.1 Obsah certifikátu podle X.509 v 3.0 . . . 4.10.2 Certifikační autorita . . . . . . . . . . . 4.11 Přístupové body v laboratoři . . . . . . . . . . . 4.12 MBSSID . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

17 17 18 20 20 20 21 22 22 22 22 22 23 24 25 26 27 27 28 29

6

OBSAH

5 Implementace 5.1 Získání produktů . . . . . . . . . . . . . . . . . . 5.2 Instalce OpenSSL . . . . . . . . . . . . . . . . . . 5.3 Instalce autentizačního serveru FreeRADIUS . . . 5.4 Konfigurace RADIUS serveru . . . . . . . . . . . 5.4.1 Terminologie v kontextu FreeRADIUS . . 5.4.2 Hlavní konfigurační soubor . . . . . . . . . 5.4.3 Konfigurace pro NAS . . . . . . . . . . . . 5.4.4 Nastavení EAP . . . . . . . . . . . . . . . 5.4.5 Vytváření uživatelů . . . . . . . . . . . . . 5.5 SSL certifikáty . . . . . . . . . . . . . . . . . . . 5.5.1 Vytvoření certifikační autority . . . . . . . 5.5.2 Vytvoření certifikátu pro server . . . . . . 5.5.3 Vytvoření uživatelských certifikátů . . . . 5.6 Konfigurace Access pointu . . . . . . . . . . . . . 5.6.1 Asus WL500GP . . . . . . . . . . . . . . . 5.6.2 Cisco 1230 series . . . . . . . . . . . . . . 5.7 Konfigurace koncového XP klienta . . . . . . . . . 5.7.1 Nastavení XP klienta pro PRIVATE-WIFI

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

30 30 30 31 31 32 32 33 34 35 35 35 36 36 38 38 41 43 43

6 Ladění implementace

48

7 Finanční nároky implementace

50

8 Diskuze 51 8.1 Nedostatky řešení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 9 Závěr

52

10 Literatura

53

Přílohy

54

A Příklad X.509 certifikátu

55

B radiusd.conf

57

C clients.conf

59

D eap.conf

60

E users

61

F ca.cnf

62

OBSAH

7

G server.cnf

64

H client.cnf

66

I

68

1230 AP conf

J Popis přiloženého CD

72

1

ÚVOD A CÍL PRÁCE

1 1.1

8

Úvod a cíl práce Úvod

V dnešní době je WIFI síť téměř nutností. Existence WIFI sítě v prostorách firmy umožňuje zaměstnancům rychlý a snadný přístup k firemním datům, aniž by byli omezeni délkou kabelů, pokud mají notebooky, laptopty, MDA, PDA a jiné zařízení, schopné připojit se na bezdrátovou síť. Pokud zaměstnanec vlastní notebook, nemusí mít dva desktopové počítače, mezi kterými by složitě přenášel pracovní data. Stačí mu pouze vlastnit jeden notebook, se kterým se připojí kdekoliv v dosahu WIFI sítě a mimo pracovní dobu k domácí síti. Existence bezdrátové sítě v prostředí firmy umožnuje pracovat kdekoliv, kde zaměstnanci stačí k práci jen notebook. Pokud firma investuje do IP wireless telefonů, bude zaměstnanec dostupný na svém telefoním čísle, ať se pohybuje kdekoliv po prostorách firmy, respektive kdekoliv, kam dosáhne firemní bezdrátová síť. Pro pochopení práce je potřeba, aby čtenář měl alespoň mírně pokročilé znalosti počítačových sítí a operačního systému Linux. Základní znalost Cisco IOS je také požadována pro správné pochopení práce.

1.2

Cíl práce

Cílem práce je navrhnout a vybudovat strukturu firemní bezdrátové sítě a do navržené struktury integrovat autentizační mechanismy. Při zadání práce nebyl žádný mechanismus explicitně určen. Autor se proto rozhodl vyzkoušet možnosti implementace pomocí open-source produktů. Pro implementaci autentizačního serveru byl zvolen program FreeRADIUS. Jako rámcová metoda pro komunikaci mezi uživatelem a autentizačním serverem byl zvolen EAP-TLS. Více informací v kapitole Technologie.

2

ANALÝZA FIREMNÍ SÍTĚ

2

9

Analýza firemní sítě

Tato kapitola byla společně sepsána těmito studenty: Brázdil Jiří, Daněk Miroslav, Klein Richard, Kejda Jan, Láník Radek, Macka Ivo a Zelinka Michal. Výše jmenovaní (dále jen autoři) vytvořili experimantální síť v laboratoři ÚI PEF MZLU v Brně (dále jen experimantální síť) jako podporu pro své bakalářské práce. Tato experimentální síť má za úkol simulovat prostředí fiktivní firmy Malafirma a v omezené míře i síťové okolí Internet. V rámci experimentální sítě se každý z autorů zaměřil na oblast zadanou svojí balalářskou prací: • Jiří Brázdil: základní serverové služby. • Miroslav Daněk: bezdrátové sítě. • Radek Láník: IPv6. • Ivo Macka: VoIP. Tato kapitola (Analýza firemní sítě) bude součástí těchto bakalářských prací: • Brázdil J. Implementace serverových služeb v prostředí malé a střední firmy. Bakalářská práce. Brno, 2009. • Daněk M. Integrace autentizačních mechanismů pro bezdrátové sítě v prostředí malé a střední firmy. Bakalářská práce. Brno, 2009. • Láník R. Počítačová síť malé a střední firmy na bázi IPv6. Bakalářská práce. Brno, 2009. • Macka I. Implementace IP telefonie v prostředí malé a střední firmy. Bakalářská práce. Brno, 2009.

2.1

Požadavky na firemní síť

Požadavky byly stanoveny takto: Jedná se o fiktivní firmu o 50 až 100 zaměstnancích (dále jen Malafirma). Není určeno žádné specifické zaměření Malefirmy. Malafirma má vlastního IT pracovníka. Je požadováno stálé připojení k internetu. Síť bude poskytovat následující služby DNS, webový server, e-mail, VoIP. Uživatelům je potřeba umožnit přístup do sítě i pomocí WiFi technologie. Dalším požadavkem je umožnit zaměstnancům, kteří se nenachází v budově firmy, přístup k firemním datovým zdrojům, pomocí technologie VPN. Zabezpečení firemních dat se provede kombinací firewallů a PKI certifikátů. Posledním požadavkem je zavedení IPv6 adresace v kombinaci s IPv4.

2.2

Návrh

K postupu při návrhu sítě Teare (2006) píše, že návrh sítě zahrnuje tyto úkoly: 1. stanovení požadavků, 2. analýza stávající sítě, pokud existuje, 3. příprava předběžného návrhu, 4. dokončení konečného návrhu,

2.2

Návrh

10

5. sestavení sítě, 6. monitorování a případně změna návrhu, 7. udržovnání dokumentace. 2.2.1

Zóny v síti a Adresace

Schauwers (2004) uvádí členění sítě do tzv. bezpečnostních zón: Nejvíce důvěryhodné jsou v organizaci její vnitřní servery, doménové řadiče a úložná zažízení připojená k síti. Méně důvěryhodné jsou vnitřní uživatelé a vnější autentizovaní uživatelé. Nedůvěryhodné jsou internetové servery a vnější neautentizovaní uživatelé. Pro implemetnaci těchto zón v experimentální síti jsou použity tzv. virtuální LAN. Tyto virtuální LAN jsou rozvrženy takto: • VLAN ID: 20, VLAN name: public. Slouží pro veřejné servery firmy. • VLAN ID: 30, VLAN name: private Trusted L1. Slouží pro vnitřní servery firmy. • VLAN ID: 40, VLAN name: clients users. Zóna pro obyčejné uživatele. • VLAN ID: 45, VLAN name: vip clients power users. Zóna pro privilegované uživatele. • VLAN ID: 55, VLAN name: wifi authenticated users. Zaměstnanecká WIFI síť. • VLAN ID: 66, VLAN name: wifi unauthenticated users. WIFI sít pro firemní hosty. • VLAN ID: 98, VLAN name: super private trusted L2. Zóna slouží pro monitoring sítě. • VLAN ID: 99, VLAN name: management. Zóna slouží pro management sítě. • VLAN ID: 150, VLAN name: VoIP. Zóna pro IP telefony. Každý prvek na síti je přiřazen do jedné ze zón. Pro adresaci zón je použit privátní adresní prostor IPv4 třídy A 10.0.0.0/8 a to následujícím způsobem: • první 2 oktety jsou vždy stejné 10.0.x.0, • následuje číslo VLAN 10.0.VLAN ID.0, • maska je /24 čili 255.255.255.0. Je také zavedeno následující pravidlo pro adresaci a to takové, že adresa výchozí brány bude končit vždy jedničkou. Viz obrázek číslo 1. Informace o zavádění IPv6 adres do firemní sítě jsou k dispozici v bakalářské práci Láník R., Počítačová síť malé a střední firmy na bázi IPv6. Seznam IPv6 adres vybraných uzlů: • Gandalf eth0 2001:470:1f08:bd3::2/64 • Gandalf vlan20 2001:470:92aa:14::1/64 • Gandalf vlan30 2001:470:92aa:1E::1/64 • Gandalf vlan40 2001:470:92aa:28::1/64 • Gandalf vlan45 2001:470:92aa:2D::1/64 • Gandalf vlan98 2001:470:92aa:62::1/64 • Gandalf vlan99 2001:470:92aa:63::1/64

2.2

• • • • • • •

Návrh

11

Merry eth0 2001:470:92aa:1E::3/64 Sam eth0 2001:470:92aa:1E::2/64 Glum eth0 2001:470:92aa:2D::2/64 Frodo eth0 2001:470:92aa:14::2/64 Arwen eth0 2001:470:92aa:28::2/64 Pipin eth0 2001:470:92aa:62::2/64 Sauron eth0 2001:470:92aa:63::2/64

2.2.2

Uzly na síti

Pro pojmenování uzlů ve firemní síti byla použita jména hlavních postav z trilogie J. R. R. Tolkiena Pán prstenů. Gandalf Tento uzel je implementován pomocí Sun serveru. Jedná se o hraniční router firemní sítě, který má za úkol směrování a filtrování paketů. Všechny VLAN, které se nacházejí ve firemní síti, jsou prodlouženy až na tento uzel. Na uzlu poběží operační systém GNU/Linux Debian 5.0. Frodo Uzel slouží jako veřejný server firemní sítě, na kterém běží služby WWW, DNS, e-mail a VoIP, přístupné z internetu. Uzel leží v demilitarizované zóně firemní sítě a je přiřazen do VLAN 20. Na uzlu poběží operační systém GNU/Linux Debian 5.0. Sam Tento uzel slouží jako interní WWW, e-mail, DNS a DHCP server. Na uzlu poběží operační systém GNU/Linux Debian 5.0. Merry Tento uzel slouží jako firemní autentizační server. Na uzlu běží RADIUS server, Samba, LDAP. Uzel je přiřazen do VLAN 30. Na uzlu poběží operační systém GNU/Linux Debian 5.0. Pippin Uzel slouží jako LOG server. Logy z celé sítě se posílají na tento uzel. Dále zde bude implementován monitorovací program Nagios. Uzel je přiřazen do VLAN 98. Na uzlu poběží operační systém GNU/Linux Debian 5.0. Gimly Uzel slouží jako přístupový bod do zón super private trusted L2 a private trusted L1. Jeho implementace je provedena pomocí Cisco Catalyst 2960/8. Aragorn Tento uzel je koncipován jako přístupový bod pro koncové klienty v síti pro zóny clients users 1 a vip clients power users. Jeho implementace je provedena pomocí Cisco catalyst 2960/24. Legolas Jedná se o přístupový bod do firemní sítě pro uživalete bezdrátových firemních sítí. Implementace je provedena pomocí acces pointů Asus WL500gP nebo pomocí Cisco 1230 AP series. Sauron Tento uzel je koncipován jako pracovní stanice administrátora sítě. Uzel je přiřazen do VLAN 99 a slouží ke správě celé sítě. Na uzlu poběží operační systém GNU/Linux Debian 5.0. Takto navržená síť (obrázek číslo 1) je schopna pojmout přibližně 20 uživatelů po ethernetu a 40 uživatelů přes wifi. Pro vybuduvání sítě schopné pojmout více uživatelů bude potřeba nahradit uzel Aragorn jiným přístupovým prvkem. Existují dvě možnosti. První je koupit přepínač s více porty. Druhá je nahradit uzel L2/L3

2.3

12

Připojení k internetu

ISP Vzdálený klient VPN tunelem propojen do firemní sítě

Linux public server Debian - Frodo 10.0.20.2/30 Pokuston 15 WWW, Email, FTP DNS-cache, DNS master, VoIP

Linux private server Debian - Pippin Pokuston 18 10.0.98.2/24 Syslog, integrita Nagios

VPN tunel ISP Micronet SP608A Switch

Linux private server Debian - Sam Pokuston 16 10.0.30.2/24 WWW, Email, FTP DNS - slave Linux private server Debian - Merry 10.0.30.3/24 LDAP,Radius, Samba, IM

INTERNET

Vlan 20 Public server 10.0.20.0/30 a public adresa 10.0.0.2/24

VLAN20 10.0.20.1/24 VLAN30 10.0.30.1/24 ETH1 10.0.98.1/24

Cisco Catalyst Gimli 10.0.98.150/24 2960/8

Linux Debian/Cisco 1841/Check Point Gandalf Firewall, IDS Dhcrealy, VPN-server

Trunk

Trunk Vlan 30 Private servers 10.0.30.0/24

Vlan 98 Private servers 10.0.98.0/24

VLAN40 10.0.40.1/24 VLAN45 10.0.45.1/24 VLAN55 10.0.50.1/24 VLAN66 10.0.66.1/24 VLAN77 10.0.77.1/24 VLAN150 10.0.150.1/24 ETH0 10.0.99.1/24

Cisco Catalyst Aragorn 10.0.99.150 2960/24

Legolas Wifi clients

Vlan 150 voice 10.0.150.0/24

Vlan 40 Windows client 10.0.40.0/24

Windows - Arwen 10.0.40.10/24 Pokuston 12

Vlan 99 Management 10.0.99.0/24 Vlan 45 Windows client 10.0.45.0/24 Windows - Glum 10.0.45.10/24 Pokuston 13

Linux Management stanice 10.0.99.10/24 Debian - Sauron VNC, Amanda

Obr. 1: Nákres firemní sítě zařízením, které zvládá inter VLAN routing. Poté by se do tohoto uzlu mohly zapojit přístupové přepínače pro jednotlivé zóny, tak jak je uvedeno na obrázku číslo 2. Toto řešení by mělo za následek rozložení směrovací zátěže mezi uzly Gandalf a Aragorn, což by vedlo k větší efektivnosti sítě.

2.3

Připojení k internetu

Kromě běžného provozu, jako jsou e-mail, prohlížení webových stránek, download malých objemů, přístup na firemní WWW z internetu, bude potřeba potřeba zajistit dostatečný objem linky pro služby VoIP a VPN. Jeden nekomprimovaný VoIP hovor potřebuje přibližně 64 Kb/s. VPN klientům stačí přibližně 100 Kb/s. Při předpokladu maximálního využívání jmenovaných služeb je potřeba firemní sít připojit rychlostí minimálně 10/5 Mb/s bez FUP (Fair user policy - omezení přenesených dat v obou směrech). Tato rychlost by se dala použít jako výchozí pro základní ná-

2.4

13

Operační systémy

Cisco 3750 Aragorn 10.0.99.150

Legolas

Wifi clients

Cisco 2960

Vlan 150 voice 10.0.150.0/24 Vlan 99 Management 10.0.99.0/24



Obr. 2: Nákres rozšíření sítě roky firemní sítě. To předpokládá, že firma nebude pracovat v oblasti poskytování služeb, jako je outsoursing. Pokud bude firma poskytovat různé služby pro širokou veřejnost, její nároky na připojení budou narůstat.

2.4

Operační systémy

Microsoft Windows Operační systémy firmy Microsoft budou nasazeny na klientské počítače v zónách pro uživatele. Debian Open - source operační systém GNU/Linux bude použit pro implementaci firemních serverů a uzlu Gandalf. Cisco IOS Jedná se o operační systém na uzlech implementovaných pomocí Cisco zařízení. Ostatní SW Služby na serverech budou implementovány pomocí open-source produktů.

2.5 2.5.1

Hardware Síťové prvky

Při vytváření infrastruktury podnikové sítě bylo k propojení jednotlivých počítačů a skupin počítačů použity tyto síťové prvky:

2.5

• • • • • •

Hardware

1× 1× 1× 1× 1× 1×

2.5.2

14

ASUS WL-500gP Cisco 1230 AP Cisco router 1841 Cisco switch 2960/24 Cisco switch 2960/8 R SP608A 10/100 Mbps Switch Micronet Servery

Jako servery byly vybrány výkonější počítače experimentální laboratoře. R Pentium R 4, 2.80 GHz, RAM-RWM 1 GB, HDD 120 GB, • 3× : CPU – Intel 1× network card. R Pentium R 4, 3 GHz, 2 core, RAM-RWM 1 GB, HDD • 1× : CPU – Intel 250 GB, 1× network card. • 1× : Sun server – AMD Opteron 2,2 GHz, RAM-RWM 1 GB, HDD 250 GB, 4× network card. 2.5.3

Klientské počítače

Pro simulaci klientských počítačů bylo použito stolních počítačů výukové části laboratoře Q15 ÚI PEF MEZLU v Brně. • CPU – Intel Core 2 duo 1,8 Mhz, RAM-RWM – 512 MB, HDD – 80GB, 1× network card. Jako klientů, připojených k bezdrátové síti, byly použity různorodě konfigurované notebooky tvůrců experimentální sítě.

3

ANALÝZA BEZDRÁTOVÉ SÍTĚ

3

15

Analýza bezdrátové sítě

U malé a střední firmy je potřeba zavést následujicí sítě FREE-WIFE, PRIVATEWIFI a PHONE-WIFI, pokud se firma rozhodne pro IP wireless telefony. Každá z těchto sítí bude mít svá specifika, jež jsou odlišná od ostatních. PRIVATE-WIFI síť se staví přibližně pro 30-40 hostů a dále je potřeba počítat s neznámým počtem hostů na FREE-WIFI.

3.1

FREE-WIFI

Síť bude fungovat jako informační kanál pro širokou veřejnost. Z tohoto důvodu nemůže být FREE-WIFI zabezpečená. Protože nevíme, kdo a s jakými úmysly se nachází na této síťi, bude jediný povolený přístup na firemní DNS a WWW servery, které se nacházejí na stroji Frodo. Přístup na DHCP server na stroji Sam bude taktéž odepřen a pro tuto síť bude z bezpečnostních důvodů realizovám DHCP server přímo na access pointu. Z této sítě se host může připojit do informačního systému firmy, kde bude mít možnoat vygenerovat si certifikáty pro následné připojení do zabezpečené WIFI. Klientům v této síti bude z bezpečnostních důvodů omezena doba a rychlost připojení.

3.2

PRIVATE-WIFI

Síť bude sloužit pro firemní zaměstnance. Bude poskytovat přístup na internet a k síťovým diskům, databázím atd. Autentizace a autorizace bude realizována pomocí Radius serveru, který je umístěn na stroji Merry, pomocí protokolu EAP a jeho metody EAP-TLS a šifrováním dat pomocí WPA-TKIP. Implementace RADIUS bude provedena pomocí open-source produktu FreeRADIUS. Server bude realizován ve verzi bez komunikace s databází. RADIUS server bude dohledávat informace o WIFI uživatelích v textovém soboru. Od Radius serveru se tedy požaduje, aby autentizoval a autorizoval uživatele do firemní sítě pomocí certifikátů a 802.1x autentizačních mechanizmů, a umožnil zaměstnanci přístup do firemní sítě a sítě Internet.

3.3

Návrh

Pro realizaci bezdrátových sítí pomocí Asus WL500gP bude implementována topologie, tak jak je uvedeno na obrázku 3. Při tomto řešení bude potřeba na každém AP nastavit jiný kanál, přes který se budou vysílat SSID, aby se předešlo problémům s rušením. Ideálním řešením bude nastavit kanály 1 pro první a 13 pro druhou síť. Pro realizaci bezdrátových sítí pomocí Cisco 1230 AP bude implementována topologie, tak jak je uvedeno na obrázku 4.

3.3

16

Návrh

Frodo WWW, Email, FTP DNS-cache, DNS master, VoIP

Vlan 20 INTERNET

Micronet

Sam DHCP

Gimli Merry LDAP, RADIUS

SSID PRIVATE-WIFI VLAN 55 10.0.55.0/24 Zabezpečení WPA-PKS, EAP-TLS Přístup - Internet, Frofo, Sam, Merry

Asus WL500GP 10.0.55.150/24

Aragorn Vlan 30 Vlan 150

Asus WL500GP 10.0.66.150/24 DHCP - pro free wifi

SSID FREE-WIFI VLAN 66 10.0.66.0/24 Zabezpečení žádné Přístup - Frodo - WWW

Pippin Vlan 98

Vlan 40

Vlan 45

Vlan 99

Obr. 3: WIFI sítě s Asus WL500gP

Frodo WWW, Email, FTP DNS-cache, DNS master, VoIP

Vlan 20 INTERNET

Micronet

Sam DHCP

Gimli Cisco 1230 AP series 10.0.99.151 DHCP - pro VLAN 66

Merry LDAP, RADIUS Aragorn

SSID PRIVATE-WIFI VLAN 55 10.0.55.0/24 Zabezpečení WPA-PKS, EAP-TLS Přístup - Internet, Frofo, Sam, Merry

Vlan 30 Vlan 150

Pippin Vlan 98

Vlan 40

Vlan 45

SSID FREE-WIFI VLAN 66 10.0.66.0/24 Zabezpečení žádné Přístup - Frodo - WWW Vlan 99

Obr. 4: WIFI sítě s Cisco 1230 AP

4

TECHNOLOGIE

4 4.1

17

Technologie Bezdrátové lan

První normou ustanovující pravidla pro WLAN (wireless LAN) byla IEEE 802.11. Norma pracuje v bezlicenčním frekvenčním pásmu od 2,4 do 2,4835 GHz. Metoda přenosu dat může být buď DSSS (Direct Sequence Spread Spectrum) nebo FHSS(Frequency Hopping Spread Spectrum). DSSS mění tok dat na symboly. Každý symbol zastupuje skupinu jednoho nebo více bitů. Při použití modulační techniky QPSK (Quadrature Phase Shift Keying) moduluje nebo násobí AP každý symbol šumovou frekvencí. Modulace se používá pro umělé rozšíření pásma. DSSS dělí pásmo na 14 kanálů, které se navzájem částečně ruší. Jednotlivá pásma jsou oddělena 22 Hz. Maximální možná rychlost je 2 Mbit/s. FHSS vysílá datové pakety po jednom kmitočtu. Celé pásmo se tedy dělí na 75 kanálů. Po ukončení vysílání v jednom kanálu začne vysílat na jiném kanálu. Následující kanál je znám pouze přijímači a vysílači. Maximání možná rychlost je 2 Mbit/s. Reakcí na malé rychlosti IEEE 802.11 byla norma 802.11b. Frekvenční pásmo je od 2,4 do 2,4835 GHz. Metodou pro přenost dat zůstal DSSS, ale změnila se modulační technika na CCK (Complementary Code Keying). 802.11b dosahuje rychlosti kolem 11 Mbit/s. To je ale maximální možná rychlost na fyzické vrstvě ISO OSI. Průměrná rychlost se pohypuje okolo 6 Mbit/s, to je částečně způsobeno režijí přenosu a také rušením z okolí. Podle síly rušení se zvyšuje nebo snižuje rychlost na 11Mbit/s, 5,5 Mbit/s, 2 Mbit/s až 1 Mbit/s. Dosah sítě je v ideálním případě kolem 100m. Norma IEEE 802.11a se začala specifikovat dříve, než 802.11b, ale schválena byla až v roce 1999. 802.11a pracuje v licenčním frekvenčním pásmu 5 GHz. Maximální teoretická rychlost přenosu dat je 54 Mbit/s, skutečná se pohybuje okolo 30 - 36 Mbit/s. Pro dosažení takovéto rychlosti se používá OFDM (Orthogonal Frequency-Division Multiplexing). Velkou výhodou 802.11a je frekvenční pásmo, ve kterém tato norma pracuje, protože není tak vytížené jako u 802.11b, ale hlavně se dá použít 8 navzájem se nerušících pásem. V Evropě je kmitočet 5 GHz vyhrazen normě HIPERLAN/2 a tudíž ji nejde použít. Norma IEEE 802.11g rozšiřuje 802.11b na teoretickou rychlost 54 Mbit/s ve frekvenčním pásmu 2.4 GHz. Tato norma používá OFDM stejně jako 802.11a. Další volitelnou technikou modulování je PBCC (Packet Binary Convolutional Coding). Zpětná kompatibilita s 802.11b je zajištěna implementací CCK. Modulační mechanizmy pracují simultálně, to znamená že AP, která pracuje v 802.11g, bude moci obsloužit nejenom klienty pracující s touto normou ,ale i s 802.11b. V teoretickém případě, že na jednom místě bude pracovat 802.11b CCK, 802.11b PBBC a 802.11g OFDM na totožném kmitočtu, může docházet k vzájemnému rušení. Norma IEEE 802.11n upravuje fyzickou vrstvu a část linkové vrstvy, takzvanou Media Access Control (MAC), podvrstvou. Oproti starším normám se 802.11n vy-

4.2

18

Topologie bezdrátových sítí

značuje vysokou rychlostí. Teoretická rychlost přenosu dat je až 300 Mbit/s. Reálná rychlost po odečtení provozních nákladů se pohybuje okolo 130 Mbit/s. Velmi důležitými vlastnostmi 802.11n je modulační technika MIMO (Multiple-Input MultipleOutput) a 40MHz kanál na fyzické vrstvě a funkce shlukování rámců na podvrstvě MAC. 802.11n používá jak 2,4 tak 5 GHz pásmo. Modulační technika MIMO používá více vysílacích a přijímacích antén. Ty se ale vejdou do jednoho pásma. Další zajímavou technologií použitou v 802.11n je schopnost využít vícecestných signálů. Vícecestné signály jsou odražané signály, které se dostanou na AP se spožděním. 802.11 a/b/g neumí z takovýchto signálů obnovit informaci a proto byly považovány za nežádoucí. Tab. 1: Nejpoužívanější normy IEEE 802.11

Norma 802.11a

Datum vydání 1999

Rychlost 54 Mbit/s

Pásmo 5.4 Ghz

Modulační technika OFDM

802.11b

1999

11 Mbit/s

2.4 GHz

DSSS

802.11g

2003

54 Mbit/s

2.4 GHz

OFDM

802.11n

2009

300 Mbit/s

2.4/5 GHz

MIMO

4.2


Bezdrátové sítě se dají provozovat v několika topologiích. První topologie je AD HOC. Jedná se o bezdrátovou síť mezi koncovými uzly bez síťové infrastruktury, jak je naznačeno na obrázku číslo 5. Typicky se jedná o síť mezi notebooky. Klient 1

Klient 2

Obr. 5: Schéma AD HOC sítě Pro další topologie je již potřeba použít síťový hardware. Jedná se o prvky, které zprostředkovávají komunikaci mezi koncovými klienty v síti, a pokud je to možné a žádoucí, tak i mimo síť. Takovýto prvek se nazývá acces point (přístupový bod) zkráceně AP. Ve většině implementací umí AP pracovat v různých režimech provozu. V režimu bridge (repeater) slouží pro zvětšení dosahu sítě a pro komunikaci mezi ostatnímy AP. AP nevysílá svoji síť, pouze předává dál síť AP, který je v režimu root. Bridge režim lze využít například k přemostění sítě z jedné budovy na druhou,

4.2

19


tak jak je zobrazeno na obrázku číslo 6. V režimu root slouží AP jako přístupový bod do LAN.

AP 1 v režimu root

AP 3 v režimu bridge

AP 2 v režimu root

LAN BUDOVA 1

LAN BUDOVA 2

Bezdrátová sít AP 1

Obr. 6: Schéma root a bridge režimu Zvláštní skupinou přístupových prvků jsou WIFI routery. Tyto zařízení v sobě kombinují několik síťových funkcí (viz obrázek číslo 7). Ve většině zařízení se jedná o následující funkce: přepínač, směrovač, přístupový bod, firewall, DHCP, NAT. Podle nastavení se mohou WIFI routery používat jako obyčejné acces pointy nebo hraniční routery. Pomocí funkcí firewall a access listů je možno zlepšit zabezpečení firemní sítě. WIFI router router

acces point

802.11b/g/n WLAN

LAN/WAN firewall

switch

LAN

Obr. 7: Schéma WIFI routeru Pro středně velké až velké organizace je vhodné použít tzv. bezdrátové switche. NEMETH a SNYDER (2004) popisují pojem bezdrátové switche takto: Teorie je taková, že ”inteligentní” switch umožní nasazení a správu spousty levných přístupových bodů. Tento switch spravuje konfiguraci přístupových bodů a snadno zajišťuje autentizaci a roaming.

4.3

4.3

SSID

20

SSID

SSID (Service Set ID) je jméno bezdrátové sítě. SSID je základním bezpečnostním prvkem bezdrátové sítě. Chce-li se uživatel připojit do WLAN, musí znát dané SSID. AP může, ale nemusí SSID vysílat.

4.4

Šifrování WEP

WEP (Wired Equivalent Privacy) je jednou z prvních metod zabezpečení bezdrátových sítí. Jedná se o zabezpečení bezdrátové sítě na úroveň sítí drátových, definované v IEEE 802.11b a později i v 802.11g. WEP používá proudovou šifrovací metodu RC4 pro šifrování informací a pro ověření jejich korektnosti používá metodu CRC32 kontrolního součtu. Tato metoda používá 40-bitový klíč, ke kterému je připojen 24-bitový inicializační vektor, což dohromady čítá 64-bitový RC4 klíč. WEP byl poprvé prolomen v roce 2000. Nejedná se tedy o bezpečnou metodu šifrování. Pomocí snadno dostupných programů lze toto šifrování prolomit přibližně do 5 minut. Platí, že s vyšší rychlostí a provozem se doba potřebná k prolomení WEP snižuje až na dobu v řádech sekund. Pužmanová (2007) uvádí následující nedostatky WEP: • Autentizace: – jednostranná autentizace - uživatel nemá jistotu, že se připojuje k autorizovanému přístupovému bodu (prostor pro falešné, rogue, AP); – klíč podporuje jen autentizaci zařízení, nikoli uživatele - krádež zařízení znamená krádež klíče; – autentizace sdíleným klíčem - možnost odchycení a zlomení klíče (výzva odpověď mezi klientem a AP se posílají v otevřené formě); • Šifrování: – stejný klíč na všech zařízeních v téže WIFI - sdílený klíč; – statický a krátký klíč - IV (Initialization Vector) o 24 bitech se sice mění s každým paketem, ale v reálném čase se opakuje; – slabý šifrovací mechanismus RC4; – problém s distribucí klíčů - manuální distribuce a změny WEP klíčů v rozsáhlých sítích jsou velice obtížné; • Integrita dat: – ICV (Integrity Check Value) nechrání data před útokem man-in-themiddle- nedostatečný lineární kód (CRC-32). Slabou ochranu WEP vylepšuje bezpečnostní rámec IEEE 802.1x, který byl přijat v roce 2001.

4.5

Přístup přes standard IEEE 802.1x

IEEE 802.1x (Port-Based Network Access Control) je bezpečnostní rámec pro řízení přístupu do sítí typu LAN a WLAN. Tento bezpečnostní rámec zahrnuje autentizaci uživatelů, distribuci klíčů a šifrování dat. Úkolem 802.1x je nepřipustit neoprávněné

4.5

21

Přístup přes standard IEEE 802.1x

uživatele do počítačové sítě. Rámec 802.1x je založený na protokolu EAP (Extensible Authentication Protocol), který se stará o autentizaci uživatelů. Autentizace uživatelů se provádí pomocí EAP metod a autentizačního serveru. Nejčastějiší metody jsou EAP-TTLS (Tunneled Transport Level Security), EAP-TLS (Transport Level Security) a PEAP (Protected EAP). 802.1x používá k šifrování dat pro autentizovanou stanici distribuované dynamické klíče. Každá stanice má svůj vlastní klíč, který zná pouze daná stanice. Klíče platí pouze pro daný port přístupového bodu a mají omezenou dobu platnosti. EAP protokol byl původně vyvinut pro PPP LCP (Point-to-Point Protocol Link Control Protocol). EAP definuje mechanismus přenosu paketů na spojové vrstvě LAN. Pakety EAP protokolu se zapouzdřují do paketů 802.1x. EAPOL (Extensible Authentication Protocol over LAN) je pouze jiné označení pro 802.1x. Protokol EAP obsahuje asi čtyřicet metod autentizace například EAP-MD5, EAP-TTLS, EAP-PSK, EAP-SIM. Komunikace přes EAP protokol probíhá bez IP adres. To umožnuje ověřit klienta dříve, než je povolem přístup do sítě. EAPoL EAP over LAN

RADIUS server

802.11 EAP over WIFI

Authenticator/NAS RADIUS klient Acces Point

Supplicant

Obr. 8: EAP obecný nákres Prvek který se chce připojit do sítě se obecně nazývá supplicant. Přístupový bod, přes který se klient chce přihlásit do sítě se nazývá NAS (Network acces server), authenticator nebo RADIUS klient. 4.5.1

EAP-Transport Lyer Security

Tato forma autentizačního mechanizmu EAP je dobře podporována výrobci WIFI zařízení. Používá PKI (Public key infrastructure) pro zabezpečení komunikace mezi autentizačním serverem například RADIUS serveru a koncovým uživatelem. EAPTLS je jednou z nejbezpečnějších metod EAP. Požadavek na uživatelské certifikáty je právě tím prvkem, který tuto metodu činí maximálně bezpečnou. Tyto certifikáty se dají uschovat na smart-card a tím se ještě zvýšuje bezpečnost. V metodě EAP-TLS se uživatel ověřuje oproti síti (serveru), ale i síť (server) se ověřuje na straně klienta. Metoda EAP-TLS používá protokol TLS. Podrobnosti o TLS v sekci Transport Layer Security a Secure Sockets Layer kapitoly Technologie.

4.6

Postup autentizace 802.1x

4.5.2

22

EAP-Tunneled TLS

EAP-TTLS je rozšíření EAP-TLS, používá TLS pro navázání spojení s ověřovacím serverem a vytvoření tunelu pro druhý ověřovací algoritmus. 4.5.3

EAP-LEAP

Lightweight Extensible Authentication Protocol je implementací metody EAP-TLS firmou Cisco. Používá TLS pro navázání spojení s uživatelem, ale narozdíl od EAPTLS nepoužívá pro autentizaci certifikáty. EAP-LEAP používá jméno a heslo. Taktéž zajištuje dynamické generování WEP klíčů. 4.5.4

EAP-MD5

Jedná se o jednu z prvních metod EAP. Autentizace je zde realizována pomocí uživatelského jména a hesla. Jména a hesla jsou hashována pomocí MD5.

4.6

Postup autentizace 802.1x

EAP zprávy jsou zapouzdřovány do rámce 802.1x (EAPOL) na straně klienta a na straně serveru jako RADIUS. • NAS odešle uživateli zprávu EAP REQUEST-ID. • Uživatel odešle na NAS EAP RESPONSE-ID. • NAS odešle na RADIUS server zprávu RADIUS ACCESS-REQUEST, která obsahuje EAP RESPONSE-ID od uživatele. • RADIUS server zapouzdří EAP SUCCESS/FAILURE do ACCESS ACCEPT/REJECT a odešle ji na NAS. • Uživatel a jeho přístupový port přes NAS se považuje za autentizovaný v případě, že RADIUS server odeslal zprávu ACCESS-ACCEPT obsahující EAP SUCCESS. V opačném případě NAS uzavře daný port.

4.7

RADIUS protokol

Autentizace se v bezdrátových sítich provádí pomocí RADIUS protokolu, který se stará o autentizaci, autorizaci a správu účtů. Jedná se o protokol typu klient/server. RADIUS server umožnuje dohledávat uživatele v textových souborech, LDAP a jiných databázích. RADIUS server používá pro autentizaci bezpečnostní stadard IEEE 802.1x, který se využívá u bezdátových sítí. Oficiální UDP port pro autentizaci je 1812 a 1813 pro accouting. Některé inplementace používají UDP port 1645 a 1646 typicky Cisco. Implementace protokolu: • FreeRADIUS • Cisco Secure Access Control • Radiator • OpenRADIUS

4.7

RADIUS protokol

23

Jako prostředník mezi supplicantem a RADIUS serverem slouží RADIUS klient (NAS). Jedná se o prvky na síti, které poskytují přístup do sítě koncovým uzlům. Fyzicky se jedná o AP nebo přepínače. RADIUS klient se stará o odesílání uživatelských informací RADIUS serveru a nese odpovědnost za zpracování odpovědí, které od serveru přijme. V konfiguraci klienta je uložena IP adresa RADIUS serveru a přístupové heslo pro komunikaci se serverem. Spojení mezi RADIUS serverem a jeho klienty jsou tedy realizována pomocí sdíleného tajemství. Pokud se chce uživatel připojit do bezdrátové sítě, asociuje se k virtuálnímu portu na AP. Tento port je uzavřen do doby, než server povolí přístup. Jediná povolená komunikace je EAP protokol. Klient požádá uživatele o zaslání identifikačních údajů. RADIUS server zpracovává požadavky od klienta ve dvou fázích. V první fázi zkontroluje pravost zaslaných uživatelských udajů. V druhé fázi autorizuje přístup do sítě (nastaví parametry uživatele). Každý uživatel, který se chce připojit do sítě, musí předat RADIUS klientovi autentizační údaje. V momentě kdy klient obdrží informace od uživalele, vygeneruje Access-Request (požadavek o přístup) a odešle ho přes RADIUS protokol na autentizační server. Access-Request obsahuje identifikační údaje uživatele a ID virtuálního portu, přes který se uživatel hlásí do sítě. Ještě než server přijme požadavek, ověří pravost klienta pomocí sdíleného hesla. Server přijme požadavek a ověří uživatelské údaje. V tento moment mohou nastat dvě možnosti. V první možnosti uživatelské údaje nesouhlasí s údaji v databázi a server vygeneruje Access-Reject. Tato zpráva může obsahovat pouze důvod zamítnutí autentizace. Když Access-Reject dorazí na RADIUS klienta, uzavře klient virtuální port, přes který je uživatel připojen. V druhé možnosti uživatelské údaje souhlasí a server vygeneruje Access-Accept. Access-Accept obsahuje parametry relace jako jsou IP adresy, maska sítě, rychlost připojení, dostupné služby atd. Prametry jsou uloženy v databázi uživatelů (textový soubor, LDAP, SQL databáze). 4.7.1

Radius paket

RADIUS paket je zabalen do datové části UDP segmentu, kde je cílový port nastaven na hodnotu 1812 nebo 1645 (Cisco). Kód Určuje typ paketu. Toto pole může obsahovat následující: 1. Access-Request 2. Access-Accept 3. Access-Reject 4. Accounting-Request 5. Accounting-Response 6. Access-Challenge Identifikátor Pořadové číslo paketu. Délka Celková délka paketu. Minimální délka je 20B maximální 4096B. Pokud velikost paketu neodpovídá poli délka, je paket zahozen.

4.8

24

Šifrování WPA a WPA2

RADIUS klient NAS Authenticator

RADIUS server

Uživatel Supplicant

1. Asociace k AP - EAP start 2. Požadavek identifikace Předání údajů

3. Odeslání údajů

Ověření serveru na straně uživatele

4. Server odešle certifikáty

5. Klienent odešle certifikáty

Ověření uživatele na straně serveru 6. Vygenerování WEP/WAP session

7. Boadcast klíč 8. Parametry relace

Obr. 9: Schéma komunikace RADIUS server - NAS - uživatel Kód 8 bitů

Identifikátor 8 bitů

Délka 8 bitů

Authenticator 128 bitů Atributy

Obr. 10: Schéma RADIUS paket Authenticator 4 řady po 32B. Hodnota je použita při autentizaci, dále je použita při šifrování posílaného hesla. Atributy Obsahuje parametry relace, konec této části paketu je určen polem délka paketu.

4.8

Šifrování WPA a WPA2

WPA (Wi-Fi Protected Access) je druh zabezpečení bezdrátových počítačových sítí. Šifrování WPA vzniklo v roce 2002 jako reakce na slabou ochranu WEP. WPA musel odstranit nedostatky WEP, jako je nulová autentizace a slabé šifrování statickým klíčem. Pro autentizaci uživatelů a distribuci klíčů se používá rámec 802.1x. WPA je vhodné pro podnikové sítě, které mají integrovaný autentizační server (RADIUS). Pro domácí použití je vhodná verze se sdíleným klíčem (WPA-PSK). Tento mecha-

4.9

Transport Layer Security a Secure Sockets Layer

25

nismus nejde použít v AD-HOC sítích. WPA z velké části inplementuje stadart IEEE 802.11i. Jedná se o skupinu bezpečnostních mechanizmů, které nepotřebovaly vylepšení přístupových bodů na fyzické úrovni. Jeho nevýhodou je nekompatibilita se staršími access pointy. Data jsou zašifrována pomocí proudové šifrovací metody RC4 se 128bitovým klíčem a 48bitovým inicializačním vektorem. TKIP (Temporal Key Integrity Protocol) je protokol dynamicky měnící klíče. WPA používá bezpečnější kontrolu integrity dat nazvanou MIC (Message Integrity Check), tento algoritmus je nazvaný Michael. MIC metoda použitá u WPA zahrnuje počítadlo rámců, které chrání před útoky snažícími se zopakovat předchozí zachycenou komunikaci. Norma IEEE 802.11i již byla plně implementována a je označována jako WPA2. Jedná se o bezpečnostní mechanismy pro sítě typu 802.11a/b/g/n. WAP2 používá pro autentizeci a distribuci klíčů 802.1x a silné šifrování AES volitelně RC4 pro kompatabilitu s WPA. Vhodné použití šifrovacích norem podle Pužmanové (2004): Tab. 2: Uplatnění WEP, WPA nebo WPA2

WEP WPA-PSK WPA2-PSK WPA WPA2

4.9

autentizace šifrování podnikové sítě domácí a malé sítě nulová WEP nic moc dobrá psk TKIP nic moc nejlepší psk AES-CCMP nic moc nejlepší 802.1x TKIP lepší dobrá 802.1x AES-CCMP nejlepší dobrá

Transport Layer Security a Secure Sockets Layer

Na serveru www.lupa.cz se ve slovníků pojmů nachází následující definice: ”SSL je zkratka Secure Sockets Layer. Je to protokol/vrstva, která běží mezi transportní a aplikační vrstvou a poskytuje zabezpečení komunikace pomocí šifrování a autentizace komunikujících stran.” TLS/SSL protokoly původně vznikly jako podpora pro HTTPS. Protokol zabraňuje odposlouchávání a falšování zpráv na síti. Šifrováním poskytuje TLS koncovým bodům autentizaci a bezpečí při komunikaci po síti. Vzájemná autentizace je pojem označující stav, kdy klient i server vědí s kým komunikují. Takováto autentizace požaduje implementaci PKI (Public key infrastructure). Protokol pracuje ve třech fázích. 1. Klient a server se musí dohodnout na podporovaných algoritmech. 2. Klient a server se autentizují na základě certifikátů. 3. Šifrování provozu symetrickou šifrou. SSL protokol pracuje na principu výměny záznamů. Záznamu je přiřazen typ obsahu – protokol vyšší úrovně. Navázání SSL spojení začíná pomocí Handshake protokolu. Následující postup podrobněji rozebírá žlutý rámeček na obrázku číslo 9.

4.10

Certifikáty normy X.509

26

1. Klient odešle zprávu Handshake typu CLIENT HELLO. Zpráva nese informaci o nejvyšší klientem podporované verzi TLS, náhodné číslo a návrh metod pro šifrování a komprimování dat. 2. Server odešle zprávu typu SERVER HELLO. Zpráva nese informace o serverem vybraných možnostech parametrů spojení nabízených klientem. 3. Server odešle zprávu typu CERTIFICATE, která obsahuje ceritikáty serveru. 4. V případě že server pracuje v režimu vzájemné autentizace, odešle zprávu typu CERTIFICATE REQUEST. V této zprávě je uložen požadavek na klientské certifikáty. Klient odpoví zprávou typu CERTIFICATE. 5. Server odešle zprávu typu SERVER HELLO DONE oznamující, že ukončuje počáteční dohodu o parametrech spojení. 6. Klient odešle zprávu typu CLIENT KEY EXCHANGE, která obsahuje šifrovací klíč dle zvoleného typu šifry. 7. Server a klient vygenerují hlavní šifrovací klíč pro relaci na základě vyměněných náhodných čísel a dílčích klíčů. 8. Klient odešle zprávu typu CHANGE CIPHER SPEC, která informuje server o tom, že klient bude veškerá následují data šifrovat. 9. Klient odešle zprávu typu FINISHED. Tato zpráva obsahuje hash a MAC (Message authentication code) předchozí komunikace. Server pomocí hlavního klíče relace dešifruje příchozí zprávu a ověří hash a MAC. V případě že dešifrování nebo ověření hodnot selže, server ukončí relaci. 10. V případě úspěšného dešifrování a ověření odešle server zprávu CHANGE CIPHER SPEC a FINISHED. Pokud je některý z kroků protokolu neúspěšný, celá relace se ukončí. Pří úspěchu se povolí protokol aplikační vrstvy.

4.10


Norma X.509 byla poprvé vydána roku 1988. Současná verze je 3.0. X.509 je standardem pro kryptografické systémy pracující s veřejnými klíči (PKI). Původně norma X.509 počítala jen s hierarchickým uspořádáním certifikačních autorit. Verze 3.0 obsahuje i jiné než hierarchické uspořádání definované v RFC 4158. Podle X.509 certifikační autority vydávají certifikáty, díky kterým se dá ověřit identita vlastníka veřejného klíče. Vlastník je zadán jménem, e-mail adresou nebo DNS jménem. Existuje několik formátů souborů, ve kterých se X.509 certifikáty vyskytují. DER - Binární zakódovaná podoba certifikátu použitelná pro MS Windows PEM - Osahuje certifikáty, veřejné klíče a soukromé klíče. KEY - Osahuje pouze klíče. P12 - Osahuje certifikáty, veřejné klíče a soukromé klíče. Tyto data jsou chráněna heslem. Vznikl na základě standardu PFX (Personal information exchange) a je používán k výměně veřejných i soukromých dat v jednom souboru. Tento formát se používá hlavně na MS Windows.

4.10


4.10.1 • • • • •

• •

• • • • • •

27

Obsah certifikátu podle X.509 v 3.0

Version - Verze certifikátu. Serial Number - Sériové číslo certifikátu. Signature Algorithm - Typ algoritmu (ID). Issuer - Certifikační autorita, která podepsala certifikát. Validity - Platnost. – Not Before - Platnost od. – Not After: Platnost do. Subject - Jméno vlastníka veřejného klíče. Subject Public Key Info - Informace o veřejném klíči vlastníka. – Public Key Algorithm - Algoritmus pro veřejný klíč. – Veřejný klíč (data) Issuer Unique Identifier - Unikátní identifikátor vydavatele. Subject Unique Identifier - Unikátní identifikátor vlastníka. X509v3 extensions Signature Algorithm - Algoritmus pro certifikát. Certifikát. Soukromý klíč.

4.10.2

Certifikační autorita

Certifikační autorita je v kryptografii subjekt, který vydává podepsané veřejné šifrovací klíče. Tím potvrzují pravdivost údajů, které jsou v klíči uvedeny. Certifikáty se ověřují pomocí podpisů od certifikační autority. To znamená, že se pro firmu vytvoří CA – certifikační autorita, kterou se budou podepisovat jednotlivé certifikáty. Tím se docílí toho, že připojit do PRIVATE-WIFI se budou moci jen ti klienti, kteří vlastní certifikáty podepsané firemní certifikační autoritou. Při importu certifikátů podepsaných certifikační autoritou se nejprve musí na klientský počítač importovat certifikát certifikační autority. Teprve poté je možno ověřit pravost uživatelských certifikátů. Certifikáty certifikační autority jsou podepsány buď soukromým klíčem certifikační autority (Self signed) nebo soukromým klíčem jiné důvěryhodné certifikační autority (Princip přenosu důvěry). Norna RFC 4158 definuje topologie certifikačních autorit. Toplogie mohou být podle normy například Hierarchical PKI, Multi-Rooted Hierarchical PKI atd. Hierarchical PKI topologie (viz obzrázek číslo refpki-h) definuje jednu hlavní ROOT CA, která podepisuje ostatní certifikační autority. CA druhé úrovně podepisují certifikáty koncových entit. Multi-Rooted Hierarchical PKI topologie (viz obzrázek číslo refpki-m) vychází z Hierarchical PKI s tím rozdílem, že umožňuje používat více CA první úrovně(ROOT), které podepisují a předávají důvěru na CA nižší úrovně.

4.11

28

Přístupové body v laboratoři

ROOT CA

EE - koncová entita CA - Certifikační autorita

CA

CA

CA

CA

CA

CA

CA

CA

CA

EE

EE

EE

EE

EE

EE

Obr. 11: Schéma topologie Hierarchical PKI List kořenových CA

ROOT CA

ROOT CA

ROOT CA

CA

EE

EE

EE - koncová entita CA - Certifikační autorita

CA

CA

EE

EE

CA

EE

EE

Obr. 12: Schéma topologie Multi-Rooted Hierarchical PKI

4.11

Přístupové body v laboratoři

Pro relalizaci firemní WIFI sítě jsou použity dva typy acces pointů. Prvním je Asus WL500gP, tento acces point je levná varianta pro vybudování WIFI sítě. Jeho cena se pohybuje okolo 1100 Kč. Správci sítě umožňuje upravovat směrovací tabulky, nastavovat firewall, filtrování URL a MAC adres. Obsahuje dva USB porty, do kterých se dá připojit hard disk, který bude sloužit jako lokální FTP server. Tento acces point podporuje i QOS, takže je například možné na něm upřednostňovat pakety IP telefonie. Jeho obrovskou nevýhodou je to, že nepodporuje práci s VLAN a neumí vysílat více jak jednu bezdrátovou síť. Pro realizaci ve firmě by tedy byly potřeba

4.12

MBSSID

29

alespoň dva respektive tři acces pointy. Druhým access pointem je Cisco 1230 AP. Tento přístroj zvládne nejenom to samé, jako výše popsaný, ale i mnohem více. Podporuje práci s VLAN. Přes anténu je možno vysílat až osm bezdrátových sítí. Každá tato síť může mít jiné parametry, jako jsou síla a kanál signálu, velikost na jakou se budou fragmentovat pakety, způsob zabezpečení atd. Jeho management lze provádět pomocí ethernetu nebo pomocí seriového kabelu. Pokud dojde k problémům na ethernetové síti, není nutno restartovat acces point do továrního nastavení. Jeho velkou nevýhodou je cena cca 7000 Kč, pomalé webové rozhraní a relativně složitá správa. Administrátor musí mít alespoň základní povědomí, jak ovládat Cisco IOS.

4.12

MBSSID

MBSSID (Multiple basic SSID) je technologie firmy Cisco, která umožňuje vysílat na jedné anténě více SSID neboli více bezdrátových sítí. Situace je taková, že na jedné MAC adrese je možno vysílat pouze jedno SSID. Proto levnější access pointy neumí vysílat více jak jednu bezdrátovou síť. Pomocí MBSSID je možno výsílat až osm sítí, znichž každá bude mít vlastní MAC adresu, které se liší pouze v posledních dvou bitech.

5

IMPLEMENTACE

5

30

Implementace

Kapitola Implementace se zabývá realizací kapitoly Analýza bezdrátové sítě. Radius server bude realizován na stroji MERRY. Na tomto stroji běží operační systém Debian 5.0. Pro implementaci RADIUS serveru bude použit open-source program FreeRADIUS 2.1.4, který má dobrou dokumentaci a relativně snadnou obsluhu. FreeRADIUS server s podporou EAP-TLS a EAP-TTLS potřebuje podporu protokolu SSL. Pro jiné rozšíření autentizačních metod, například EAP-MD5, není protokol SSL potřeba. SSL bude implementováno pomocí open-source programu OpenSSL 0.9.8. Kapitola dále řeší nastavní sítě pro připojení fiktivní osoby zamestnanec do PRIVATE-WIFI.

5.1

Získání produktů

Programy Freeradius a OpenSSL budou kompilovány ze zdrojových kódů. Instalační soubory pro FreeRADIUS jsou dostupné na adrese http://freeradius.org/download.html a OpenSSL na http://www.openssl.org/source/. Verze programů na těchto odkazech jsou stabilní a funkční, ale nejsou to ty nejaktuálnějiší možné verze. Z tohoto důvodu je dobré stáhnout takzvané snapshot verze, které jsou nejaktuálnějiší. Snapshot verze programů jsou dostupné na http://www.ticklers-org.lkams.kernel.org/ftp.freeradius.org/snapshots/ a http://ftp.fi.muni.cz/pub/openssl/snapshot/ pro OpenSSL. Příkazem wget se z příkazové řádky stáhnou instalační soubory z výše uvedených odkazů.

5.2

Instalce OpenSSL

Pro instalaci je potřeba superuživatelský režim. Příkaz apt-get install s parametrem build-essentil nainstaluje potřebné překladače zdrojových kódů jako jsou gcc, c++, python atd. Instalační sobory se nacházejí v archivovaném souboru openssl-0.9.8-stable-SNAP-20090506.tar.gz. Pro extrahování dat z archivu se použijí příkazy guzip a tar, kde cesta k souboru tvoří jejich parametr. V adresáři openssl-0.9.8-stable-SNAP-20090506, který se vytvoří po rozbalení stažaného souboru, jsou soubory potřebné k instalaci. Před zahájením samotné instalace je potřeba zkonfigurovat instalační soubory pomocí scriptu config s parametrem --prefix, který určí, kde se bude nacházet nainstalované OpenSSL. O instalaci programu se postarají příkazy make a poté make install. • ./config shared --prefix=/usr/local/openssl • make • make install Instalace programu OpenSSL je kompletní. Veškeré soubory spjaté s touto verzí programu se nacházejí v adresáři /usr/local/openssl. Tento adresář by měl obsahovat následující soubory a adresáře: bin - Obsahuje binární soubory pro OpenSSL.

5.3

Instalce autentizačního serveru FreeRADIUS

31

include - Obsahuje soubory nutné pro spolupráci s ostatními aplikacemi. lib - Obsahuje SSL knihovny. ssl - Obsahuje konfigurační soubory. Adresáře include a lib jsou využívány programem FreeRADIUS. Při instalaci serveru se na tyto dva adresáře přidává odkaz. FreeRADIUS tyto dva adresáře využívá při EAP-TLS komunikaci na vytvoření SSL tunelu a při vytváření a ověřování certifikátů.

5.3

Instalce autentizačního serveru FreeRADIUS

Soubor freeradius-server-snapshot-20080830.tar.bz2 obsahující instalační souboury se rozbalí pomocí programu tar s parametrem -jxvf. Pomocí scriptu configure se nastaví instalační soubory na daný systém. V tomto kroku je potřeba uvést cestu k OpenSSL adresářům lib a include. Cesty k adresářům se uvádí za parametry --with-openssl-includes a --with-openssl-libraries. Posledním parametrem je --prefix, který určí kam se nainstaluje program FreeRADIUS. Pro nápovědu ke konfiguraci slouží parametr --help. Instalace se dokončí dvojicí příkazů make a make install. • ./configure --with-openssl-includes=/usr/local/openssl/include/ --with-openssl-libraries=/usr/local/openssl/lib/ --prefix=/usr/local/radius • make • make install Instalace programu FreeRADIUS je kompletní. Pod adresářem /usr/local/radius jsou potřebné soubory, které bude server využívat.

5.4

Konfigurace RADIUS serveru

Konfigurační soubory se nacházejí pod adresářem /usr/local/radius/etc/radb/. Dokumentace k jednotlivým souborům je vepsána přímo v souborech1 . Další dokumentace se nachází na webových stránkách programu FreeRADIUS http://wiki.freeradius.org/Main Page. Každý konfigurační soubor je členěn do logických sekcí. Každá sekce se uvozuje jménem sekce a pokračuje obsahem sekce ve složených závorkách. Volby, které nemají svojí vlastní sekci, jsou ve většině případů na začátku konfiguračního souboru. Změna nastavení pro implementaci RADIUS serveru do firemní sítě se bude týkat následujících souborů: clients.conf - Obsahuje nastavení pro NAS (RADIUS klient). eap.conf - Obsahje nastavení pro EAP metody. radiusd.conf - Hlavní konfigurační soubor. 1

Dokumentace v konfiguračních souborech, jejichž kopie jsou přiloženy k této práci jako přílohy B až E, je z důvodu úspory místa vymazána.

5.4


32

users - Obsahuje seznam uživatelů a jejich parametrů autorizace. 5.4.1

Terminologie v kontextu FreeRADIUS

USER - Uživatel. client - Acces point neboli NAS. 5.4.2

Hlavní konfigurační soubor

Hlavní konfigurační soubor je radiusd.conf, do kterého se vkládají ostatní konfigurační soubory. Zde jsou uvedeny parametry jako uživatel pro spuštění, umístění logovacího souboru atd. Na začátku souboru je inicializace proměných. Jedná se o proměnné, do kterých se ukládají cesty k adresářům serveru. V těchto adresářích se nacházejí například konfigurační soubory, binární soubory, soubor s logy atd. Prametry bez sekce v souboru a jejich popis: user - Pod jakým uživatelem se bude server spouštět. group - Pod jakou skupinou se bude server spouštět. max request time - Maximální doba v sekundách na zpracování požadavku na server. Pokud čas vyprší, server vrátí REJECT message. cleanup delay - Čas v sekundách, po který se budou uchovávat v cache paměti serveru odeslané reply zprávy. Toto se hodí pro případ, že se paket s odeslanou zprávou pro NAS ztratí. NAS odešle nový požadavek a server může okamžitě odpovědět. max request - Maximální počet requestů, který bude server řadit do fronty na zpracování. Sekce listen nastavuje IP adresy a porty pro naslouchání autetizačních paketů, tato sekce se může opakovat vícekrát. Pro každou IP adresu a port je jedna sekce. Parametry každé sekce se uzavírají do složených závorek. Seznam možných parametrů v sekci listen: type - Typ paketů. Možnosti jsou: auth - autentizace, acct - accouting. ipaddr - IPv4 adresa. ipv6addr - IPv6 adresa. port - Číslo portu, na kterém se má naslouchat. interface - Pokud je na síťovém rozhraní více IP adres, začne server naslouchat na všech adresách. Poslední nutnou úpravou soboru je sekce log. V této sekci se nacházejí parametry pro syslog. Seznam možných parametrů v sekci log: destination - Určuje kam se budou ukládat logy programu. Existují čtyři možnosti. FILES - logy se budou ukládat do speciálního souboru. SYSLOG - log serveru se bude posílat do syslogu systému. STDOUT - logy se budou vypisovat na standardní výstup. STDERR - logy se budou vypisovat na standardní chybový výstup. Pro firmu je zvolem syslog, protože všechny logy ze serverů se přesměrovávají na server Pippin.

5.4


33

file - Uvádí cestu k souboru, do kterého se mají zapisovat logy. Použije se pouze v případě, že destination je nastaveno na files. syslog facility - Použije se v případě, že destination je nastaveno na syslog. auth - Loguje autentizační requesty. Nastavení souboru pro firemní síť user = radius group = radius max request time = 30 cleanup delay = 5 max request = 1024 • sekce listen listen { ipaddr = 10.0.30.3 port = 1812 type = auth } listen { ipaddr = 10.0.30.3 port = 1646 type = auth } • sekce log destination = syslog file syslog facility = deamon auth = yes Ostatní prametry v souboru je dobré ponechat ve výchozím nastavení. Celý soubor radiusd.conf je přiložen k této práci jako příloha B radiusd.conf 5.4.3

Konfigurace pro NAS

Soubor clients.conf obsahuje definice NAS, které se mohou přihlásit na RADIUS server. Definice začíná klíčovým slovem client následovaného IP addresou access pointu (NAS,RADIUS klient). Seznam parametrů se vkládá mezi složené závorky. Pokud je na firemní bezdrátové síti více AP je možnost za slovem client uvést IP adresu sítě místo hosta ve tvaru x.x.x.x/x. Definice client má pouze dva povinné parametry. secret - Toto je heslo pro komunikaci mezi NAS a radius serverem. shortname - Pojmenování NAS. Slouží pro přehlednost v LOG souboru serveru. nepovinné parametry

5.4


34

nastype - Určuje druh NAS respektive druh acces pointu. FreeRADIUS podporuje tyto NAS: cisco, computone, livingston, max40xx, multitech, etserver, pathras, patton, portslave, tc, usrhiper , other. Nastavení pro firemní síť, která bude využívat AP Asus WL500gP : client 10.0.55.150 { secret = asusAP shortname = Asus nastype = other } Nastavení pro firemní síť, která bude využívat AP Cisco 1230 : client 10.0.99.151 { secret = ciscoAP shortname = Cisco1230 nastype = cisco } Celý soubor clients.conf je přiložen k této práci jako příloha C clients.conf. 5.4.4

Nastavení EAP

Eap.conf je soubor obsahující nastavení EAP metod. Celý soubor je rozdělen do sekcí podle typu EAP. Pro firemní síť je potřeba konfigurovat sekci eap a tls. Seznam parametrů potřebných pro zprovoznění EAP-TLS: Parametry v sekci EAP: default eap type - Nastavuje, která metoda EAP se bude používat. timer expire - Maximální doba v sekundách mezi EAP-Response a EAP-Request. Parametry v sekci TLS: certdir - Umístění adresáře certifikátů. Pomocná proměnná. cadir - Umístení adresáře s certifikační autoritou. Pomocná proměnná. private key password - Heslo k certifikátům serveru. Toto heslo se musí shodovat s heslem, které je použito při vytváření serverových certifikátů. private key file - Umístění soukromého klíče serveru. certificate file - Umístění certifikátů serveru. CA file - Umístění certifikátů certifikační autority. dh file - Umístění souboru s časem pro práci s ceritikáty. random file - Umístění souboru s náhodnými čísly pro vytváření certifikátů. Nastavení souboru pro firemní síť: default eap type = tls certdir = ${confdir}/certs cadir = ${confdir}/certs private key password = server private key file = ${certdir}/server.pem certificate file = ${certdir}/server.pem CA file = ${cadir}/ca.pem

5.5

SSL certifikáty

35

dh file = ${certdir}/dh random file = ${certdir}/random To je vše potřebné pro nastavení EAP-TLS. Celý soubor je přiložen k této práci jako příloha D eap.conf. 5.4.5

Vytváření uživatelů

Seznam uživatelů, kteří se mohou připojit do sítě a jejich parametry jsou uloženy v soubor users. Definování uživatelů pod serverem je velice jednoduché. Jediný povinný parametr je jméno uživatele. Celý soubor tedy může být pouze seznam mnoha jmen. Nepoviný parametr Auth-Type zajistí, že uživatel nebude moci používat jinné metody než zde uvedné. Nastavení souboru pro firemní síť: zamestnanec Auth-Type := EAP

5.5

SSL certifikáty

FreeRadius od verze 2.0 obsahuje script, který do značné míry usnadňuje vytváření certifikátů z příkazové řádky. Script je uložen v adresáři /usr/local/radius/etc/radb/certs, který je zároveň úložištěm certifikátů a obsahuje i konfigurační soubory pro vytváření certifikátů. Script používá pro generování certifikátů program OpenSSL, který byl nainstalován před instalací serveru. Důležité soubory v adresáři certs: ca.cnf - Konfigurační soubor pro vytvoření certifikační autority. client.cnf - Konfigurační soubor pro vytvoření uživatelských certifikátů. Makefile - Script pro vytváření certifikátů. server.cnf - Konfigurační soubor pro vytvoření certifikátů serveru. xpextensions - Soubor pro podporu vytvoření certifikátu pro klienty s operačním systémem Windows XP. Ještě než se začnou vytvářet jednotlivé certifikáty, je potřeba vytvořit dva soubory. První soubor je dh, který bude obsahovat časové razítko, podle kterého se bude ověřovat doba platnosti ceritikátů. Druhý soubor je random, který bude obsahovat řetězec pro generování náhodných čísel. • date > dh • date > random 5.5.1

Vytvoření certifikační autority

Certifikační autoritu je potřeba vygenerovat jako první, protože tímto certifikátem, respektive klíčem certifikační autority se budou podepisovat certifikáty serveru a uživatelů. V souboru ca.cnf se upraví následující parametry : input password - Heslo pro manipulaci se soukromým klíčem. output password - Heslo pro manipulaci se soukromým klíčem. countryName - Zkratka státu.

5.5

SSL certifikáty

36

stateOrProvinceName - Upřesnění pozice. localityName - Lokalita například město. organizationName - Jméno organizace, která vydala certifikační autoritu. emailAddress - Adresa odpovědné osoby. commonName - Jméno certifikační autority. Nastavení souboru ca.cnf pro firemní síť: input password = certifikacniautorita output password = certifikacniautorita countryName = CZ stateOrProvinceName = Morava localityName = Brno organizationName = Malafirma emailAddress = [email protected] commonName = ”CA malafirma” Soubor ca.cnf je přiložen jako příloha F ca.cnf. Samotný certifikát certifikační autority se vytvoří příkazem make s parametrem ca.pem. Tímto krokem se vytvoří kořenový certifikát pro systémy typu Unix a klíč CA v souboru ca.key. Pro vytvoření kořenového certifikátu pro produkty společnosti Microsoft se použije příkaz make s parametrem ca.der. 5.5.2

Vytvoření certifikátu pro server

Těmito certifikáty se bude server ověřovat na straně klienta. Nastavení souboru server.cnf pro firemní síť: input password = server output password = server countryName = CZ stateOrProvinceName = Morava localityName = Brno organizationName = Malafirma emailAddress = [email protected] commonName = ”RADIUS server malafirma” Soubor server.cnf je přiložen jako příloha G server.cnf. Samotný certifikát se vytvoří příkazem make s parametrem server.pem. Toto vytvoří kořenový certifikát server.pem, který obsahuje i private key serveru. • make server.pem V souboru server.pem je v položce issuer zapsáno, kdo tento certifikát podepsal. V tomto případe Certifikační autorita malafirma. 5.5.3

Vytvoření uživatelských certifikátů

Při konfiguraci uživatelských certifikátů je potřeba u parametru commonName uvést jméno stejné jako je v souboru users pro daného uživatele. Prametr

5.5

SSL certifikáty

37

input password se používá při importu certifikátů do klientské stanice. Nastavení souboru client.cnf pro vygenerování certifikátů uživatele zamestnanec: input password = zamestnanec output password = zamestnanec countryName = CZ stateOrProvinceName = Morava localityName = Brno organizationName = Malafirma emailAddress = [email protected] commonName = zamestnanec Celý soubor je přiložen jako příloha H client.cnf. Script MakeFile je ve výchozím stavu nastaven tak, aby certifikáty serveru podepisoval firemní certifikační autoritou. V případě generování uživatelských certikátů tomu tak není. Script podepisuje certifikáty uživatelů pomocí certifikátů serveru. Takto se generují certifikáty ve firmě, kde existuje více autentizačních serverů. Podepsáním uživatelských certifikátů certifikátem serveru se docílí toho, že uživatel se bude moci ověřit jen proti tomuto serveru. V Maléfirmě toto není potřeba, proto se upraví script Makefile. V souboru Makefile se upraví příkazy, které podepisují uživatelské certifikáty certifikátem serveru. Jedná se o změny na následujících řádcích: Řádek 89 původní: • client.crt: client.csr server.crt server.key index.txt serial Řádek 89 nový • client.crt: client.csr ca.pem ca.key index.txt serial Řádek 90 původní: • openssl ca -batch -keyfile server.key -cert server.crt -in client.csr -key $(PASSWORD SERVER) -out client.crt -extensions xpclient ext -extfile xpextensions -config ./client.cnf Řádek 90 nový • openssl ca -batch -keyfile ca.key -cert ca.pem -in client.csr -key $(PASSWORD CA) -out client.crt -extensions xpclient ext -extfile xpextensions -config ./client.cnf Řádek 100 původní: • client.vrfy: server.pem client.pem Řádek 100 nový: • client.vrfy: ca.pem client.pem Příkazem make s parametrem client.pem se vytvoří uživatelský certifikát zamestnanecmalafirma.cz.pem. Tento certifikát je použitelný pro operační systémy typu UNIX. Pro vytvoření uživatelského certifikátu, který bude použitelný na produktech společnosti Microsoft, je potřeba převést certifikát z formátu pem na formát p12. Převedení formátu pem na formát p12:

5.6

Konfigurace Access pointu

38

• /usr/local/openssl/bin/openssl pkcs12 -export -in [email protected] -inkey [email protected] -out [email protected] Po prvním vytvoření certifikátů se v adresáři /urs/local/radius/etc/radb/certs vytvoří nové soubory ttfamily index a ttfamily serial, které obsahují indexovou databázi uživatelů, pro které byly vytvořeny certifikáty. Uživatelský certikát obsahuje certifikát uživatele a jeho RSA private klíč. Z tohoto důvodu se musí soubor ze serveru odstranit poté, co se certifikáty nahrají do klientské stanice. Serveru zůstanou pouze kopie certifikátu ve tvaru ¡pořadové číslo¿.pem, které obsahují certifikát uživatele a jeho RSA public klíč. Certifikáty typu .der a .p12 jsou v nečitelné podobě. Pro přeložení těchto certifikátů do čitelné podoby se použije příkaz ttfamily openssl. Parametry x.509 nebo rsa určují co se bude převádět, jestli certifikát nebo klíč. Parametr ttfamily -in uvádí cestu k souboru s certifikátem/klíčem. Parametr ttfamily -text určuje výpis v textové podobě. Příklad použití: • openssl x509 -in ca.der -text

5.6


V laboratoři UI PEF MZLU v Brně jsou k dispozici dva access pointy. Když se bude bezdrátová sít stavět pomocí Asus WL500gP tak bude potřeba koupit dva AP. Pro každou bezdrátovou sít jeden Asus, protože tento přístroj nenumí vysílat více SSID. Takovéto řešení není považováno za nejvhodnější, protože platí, že čím více prvků na síti, tím větší riziko výskytu chyb. Řešení za pomocí AP Cisco 1230 zmenší počet prvků na síti. Všechny potřebné bezdrátové sítě se můžou vysílat jen z jednoho AP. 5.6.1

Asus WL500GP

Ve výchozím nastavení má toto AP IP adresu 192.168.1.1 s maskou sítě 255.255.255.0. Při první konfiguraci je nutné router připojit napřímo kabelem UTP s koncovkou RJ45 k počítači administrátora. Na administrátorově počítači je potřeba nastavit IP adresu 192.168.1.x s maskou sítě 255.255.255.0. Pro připojení na webové rozhraní poslouží jakýkoliv internetový prohlížeč. Do pole pro adresy se vloží adresa 192.168.1.1. Zobrazí se tabulka s požadavkem na zadání jména a hesla. Tyto údaje jsou ve výchozím nastavení Admin a Admin. V prvním kroku je potřeba změnit přihlašovací heslo. Heslo se mění pod záložkou System Setup - Change Password. V dalším kroku je potřeba nastavit v jakém módu bude AP pracovat. Pro firemní sít bude AP v módu Access Point. V tomto režimu nejsou přístupné WAN funkce (firewall, NAT) routeru a v podstatě slouží pouze jako přístupový bod do sítě. Dále je potřeba nastavit IP adresu acces pointu, masku sítě a výchozí bránu. IP adresa AP pro PRIVATE-WIFI bude 10.0.55.150 maska sítě 255.255.255.0 a výchozí

5.6

39


Obr. 13: Změna hesla

Obr. 14: Změna operačního módu AP brána bude virtuální IP adresa stroje Gandalf, tedy 10.0.55.1 (viz obrázek 15). Na AP pro FREE-WIFI se nastaví IP adresa 10.0.66.150, maska sítě 255.255.255.0 a výchozí brána 10.0.66.1 (viz obrázek 16). IP konfigurce se nachází pod záložkou IP Config - LAN. V poslední fázi je potřeba nastavit SSID, které budou access pointy vysílat.

5.6

40


Obr. 15: IP konfigurace AP

Obr. 16: IP konfigurace AP Bezdrátová sít se nastavuje pod záložkou Wireless. Pro PRIVATE-WIFI se do pole SSID, určující jméno sítě, vpíše PRIVATE-WIFI. Kanál, na kterém bude síť vysílat se nastaví u položky channel z rolovací nabýdky na 1. Authentication Method se nastaví z rolovací nabídky na Radius with 802.1x. WEP Encription je potřeba změnit z 64 bitového klíče na 128 bitů (viz obrázek 17). Pod položkou RADIUS Setting se nastavuje adresa, port a přístupové heslo pro komunikaci s RADIUS serverem. IP adresa serveru je 10.0.30.3, port 1812 a heslo se nastaví na asusAP (viz obrázek 18). Toto heslo musí odpovídat parametru secret v konfiguračním souboru client.conf FreeRADIUS serveru pro NAS asus. Pro síť FREE-WIFI se do pole SSID vloží FREE-WIFI. Authentication Method se nastaví z rolovací nabídky na Open System. Kanál, na kterém bude síť vysílat, se nastaví u položky channel z rolovací nabídky na 13 (viz obrázek 19). Pod poloužkou Wireless - advance2 se dají nastavit parametry antény typu: kdy bude síť vysílat, vypnutí/zapnutí vysílání SSID atd. 2

Podrobnějiší informace o nastavení Asus WL500gP jsou obsaženy v autorově článku, který se zabývá nastavením tohoto WIFI routeru. Článek je dostupný na http://publicsitelan.wikidot.com/mala-firma

5.6


41

Obr. 17: Konfigurace WIFI PRIVATE-WIFI

Obr. 18: Konfigurace pripojení k RADIUS serveru

Obr. 19: Konfigurace WIFI FREE-WIFI 5.6.2

Cisco 1230 series

Pro implementaci bezdrátových sítí bude stačit pouze jedno AP. Díky technologii MBSSID, která umožnuje na jedné anténě AP vysílat více SSID. Ke konfiguraci se

5.6


42

dá použít program minicom, který umožní připojení na AP přes konzolový port. Po přihlášení se konsole nachází v uživatelském módu. Pro přepnutí do privilegovaného módu konfigurace slouží příkaz enable. Pro přepnutí do konfiguračního módu slouží příkaz configure terminal. V konfiguračním módu je možno nastavovat všechny parametry AP. V konfiguračním módu se jako první nastaví IP adresa RADIUS serveru, porty, na kterých server naslouchá, a klíč pro šifrování komunikace AP - server. Následně se musí definovat zbpůsob autentizace na EAP. • LEGOLAS(config)#aaa new model • LEGOLAS(config)#radius-server host 10.0.30.3 auth-port 1645 acct-port 1646 • LEGOLAS(config)#radius-server key 7 cisco • LEGOLAS(config)#aaa authentication login eap methods group rad eap V druhém kroku je potřeba nastavit virtuální rozhraní pro jednotlivé bezdrátové sítě. Virtuální rozhraní se musí nastavit jak na bezdrátovém rozhraní (Dot11Radio 0), tak i na ethernetovém portu (FastEthernet 0). Dále je potřeba tato rozhraní přiřadit do konkrétních VLAN a vytvořit přemostění mezi rádiovými a fastethernetovými virtuálními rozhraními. Implementace do firemní sítě také vyžaduje vytvoření a nastavení virtuálního interface pro nativní VLAN 99 jako subinterface na FastEthernet 0. IP adresa na tomto rozhraní se bude používat pro management AP. • LEGOLAS(config)#int dot11radio 0.55 • LEGOLAS(config-if)#encapsulation DOT1Q vlan 55 • LEGOLAS(config-if)#bridge-group 55 • SWITCH(config)#int dot11radio 0.66 • SWITCH(config-if)#encapsulation DOT1Q vlan 66 • SWITCH(config-if)#bridge-group 66 • LEGOLAS(config)#int fast 0.55 • LEGOLAS(config-if)#encapsulation DOT1Q vlan 55 • LEGOLAS(config-if)#bridge-group 55 • LEGOLAS(config)#int fast 0.66 • LEGOLAS(config-if)#encapsulation DOT1Q vlan 66 • LEGOLAS(config-if)#bridge-group 66 • LEGOLAS(config)#int fast 0.99 • LEGOLAS(config-if)#encapsulation DOT1Q vlan 99 native • LEGOLAS(config-if)#ip address 10.0.99.151 255.255.255.0 Ve třetím kroku je potřeba nastavit bezdrátové sítě, jejich parametry a tyto vzniklé sítě přiřadit na radio rozhraní. V tomto kroku se také musí zapnout MBSSID na rozhraní dot11radio 0. Na tomto rozhraní se taktéž nastavuje metoda šifrování dat pro VLAN 55, která bude přes toto rozhraní fyzicky vysílána. • LEGOLAS(config)#dot11 ssid PRIVATE-WIFI • LEGOLAS(config-ssid)#vlan 55

5.7

Konfigurace koncového XP klienta

• • • •

LEGOLAS(config-ssid)#authentication open eap eap methods LEGOLAS(config-ssid)#authentication network-eap eap methods LEGOLAS(config-ssid)#authentication key-management wpa LEGOLAS(config-ssid)#mbssid guest-mode

• • • •

LEGOLAS(config)#dot11 ssid FREE-WIFI LEGOLAS(config-ssid)#vlan 66 LEGOLAS(config-ssid)#uthentication open LEGOLAS(config-ssid)#mbssid guest-mode

43

• • • • •

LEGOLAS(config)#int dot11radio 0 LEGOLAS(config-if)#encryption vlan 55 mode ciphers tkip LEGOLAS(config-if)#ssid FREE-WIFI LEGOLAS(config-if)#ssid PRIVATE-WIFI LEGOLAS(config-if)#mbssid Příkaz mbssid guest-mode zapíná vysílání dané sítě. Kompletní konfigurační soubor je přiložen k této práci jako příloha I 1230 AP conf.

5.7


Pro obě dvě sítě musí mít klient zapnuto získávání IP adresy z DHCP serveru. Pro PRIVATE-WIFI je třeba, aby byl na klientském počítači nainstalován program obecně nazývaný supplicant. Tento program se stará o komunikaci s RADIUS serverem. Produkty společnosti Microsoft mají implementaci tohoto programu již zabudovanou. Pro připojení na síť FREE-WIFI není potřeba nastavovat nic víc. Klient se připojí výběrem bezdrátové sítě FREE-WIFI. 5.7.1

Nastavení XP klienta pro PRIVATE-WIFI

Certifikáty je potřebné nahrát na klientskou stanici jakýmkoliv bezpečným způsobem. Například generováním certifikátů v interním informačním systému firmy do kterého se přistupuje přes HTTPS. V prvním kroku je nutné importovat kořenový certifikát. Tento certifikát se nachází v souboru ca.der. Import certifikátu se provede dvouklikem levým tlačítkem myši. Zobrazí se průvodce importem certifikátu. V dalším kroku se průvodce ptá, kam má uložit certifikát. Nastavení se ponechá na automatický výběr podle typu certifikátu (viz obrázek 20). Posledním krokem je dokončení importu. Po dokončení se zobrazí zpráva o úspěchu/neúspěchu importu certifikátu. V následujícím kroku je potřebné importovat klientský certifikát. Ten se nachází v souboru [email protected]. Pro import tohoto certifikátu je požadováno heslo. Toto heslo je to, které se nastavilo u položky imput password v souboru client.cnf při generování uživatelských certifikátů. První dva kroky při importu uživatelského certifikátu jsou stejné, jako u importu kořenového certifikátu. Ve třetím

5.7


44

Obr. 20: Import kořenového certifikátu

Obr. 21: Import certifikátu zadání hesla kroku se průvodce dotazuje na heslo pro import (viz obrázek 21). Dokončení importu uživatelského certifikátu je stejné, jako u importu kořenového certifikátu. V posledním kroku konfigurace je nutné nastavit parametry bezdrátové sítě PRIVATE-WIFI. V ovládacích panelech se otevře položka síťová připojení. V nově načteném okně se vybere položka bezdrátové pripojení k síti a pravým tlačítkem myši se z rolovacího menu vybere položka vlastnosti. Na druhé záložce nově otevřeného okna vlastnosti (viz obrázek 22) je nutné opět zvolit vlastnosti a to pro síť PRIVATE-WIFI. Otevře se nové okno PRIVATE-WIFI vlastnosti, ve kterém se nastavuje ověřování a šifrování dat (viz obrázek 23). V záložce Ověřování v okně PRIVATE-WIFI vlastnosti je potřebné nastavit položku Typ protokolu EAP na Karta Smart Card nebo jiný certifikát (viz obrázek

5.7


45

Obr. 22: Síťová připojení - vlastnosti bezdrátové sítě

Obr. 23: Síťová připojení - vlastnosti PRIVATE-WIFI sítě 24). V tomto okně je dále nutné zvolit vlastnosti, což umožní výběr kořenového

5.7


certifikátu serveru (viz obrázek 25).

Obr. 24: Síťová připojení - vlastnosti PRIVATE-WIFI sítě

46

5.7


Obr. 25: Síťová připojení - vlastnosti PRIVATE-WIFI sítě

47

6

LADĚNÍ IMPLEMENTACE

6

48

Ladění implementace

FreeRADIUS se spouští souborem radiusd, který je uložen v adresáři/usr/local/radius/sbin/. V normálním módu se server spouští na pozadí a logy vypisuje podle nastavení do syslog, souboru nebo na stdout/stderr. Tyto logy nejsou dostatečně podrobné a pro ladění nejsou vhodné. Pro spuštění v debug módu je potřeba server spustit s parametrem -X, který zajistí podrobnější log s výstupem na stdout. Kompletní LOG serveru od spuštění až po přihlášení prvního klienta je na přibližně na 750 řádků textu, z tohoto důvodu autor nezařadil debug log serveru jako přílohu3 . Po korektním spuštění serveru v debug módu by LOG měl končit následujícími řádky, které udávají na kterých portech a adresách server naslouchá: • Listening on authentication address 10.0.30.3 port 1812 • Listening on authentication address 10.0.30.3 port 1645 • Listening on proxy address 10.0.30.3 port 1814 • Ready to process requests. Úspěšná autentizace klienta by měla končit odesláním paketu ACCESACCEPT tak, jak je vidět na následujících řádcích: • Sending Access-Accept of id 101 to 10.0.99.151 port 1645 • MS-MPPE-Recv-Key = 0x978e9411b42f0388ee63b27a8a8823ec4d36cb89d0f6779258298a8d0a2c01e3 • MS-MPPE-Send-Key = 0xaa8cb7899872f44697080646a19ba75caf24ab6f71f676d543e08f3a1632097b • EAP-Message = 0x03080004 • Message-Authenticator = 0x00000000000000000000000000000000 • User-Name = "zamestnanec" • Finished request 6. • Going to the next request • Waking up in 4.8 seconds. • Ready to process requests. Následující výpis obsahuje zachycenou komunikaci mezi RADIUS serverem a RADIUS klientem (Cisco 1230) na straně serveru, v době kdy se uživatel pokouší přistoupit do sítě. Pro odposlechnutí komunikace byl použit program Tshark. • 6.004661 10.0.99.151 -> 10.0.30.3 RADIUS Access-Request(1) (id=95, l=135) • 6.007556 10.0.30.3 -> 10.0.99.151 RADIUS Access-challenge(11) (id=95, l=64) • 6.014646 Cisco 8b:63:82 -> Spanning-tree-(for-bridges) 00 STP Conf. Root = 32798/00:1d:e6:8b:63:80 Cost = 0 Port = 0x8002 • 6.017873 10.0.99.151 -> 10.0.30.3 RADIUS Access-Request(1) (id=96, l=249) 3

Kompletní debug LOG serveru je na CD, které je přiloženo k tisknuté verzi bakalářské práce.

6

LADĚNÍ IMPLEMENTACE

49

• 6.018943 10.0.30.3 -> 10.0.99.151 RADIUS Access-challenge(11) (id=96, l=1090) • 6.024873 10.0.99.151 -> 10.0.30.3 RADIUS Access-Request(1) (id=97, l=143) • 6.025386 10.0.30.3 -> 10.0.99.151 RADIUS Access-challenge(11) (id=97, l=1090) • 6.032376 10.0.99.151 -> 10.0.30.3 RADIUS Access-Request(1) (id=98, l=143) • 6.032812 10.0.30.3 -> 10.0.99.151 RADIUS Access-challenge(11) (id=98, l=386) • 6.111376 10.0.99.151 -> 10.0.30.3 IP Fragmented IP protocol (proto=UDP 0x11, off=0) • 6.111384 10.0.99.151 -> 10.0.30.3 RADIUS Access-Request(1) (id=99, l=1637) • 6.111943 10.0.30.3 -> 10.0.99.151 RADIUS Access-challenge(11) (id=99, l=64) • 6.121443 10.0.99.151 -> 10.0.30.3 RADIUS Access-Request(1) (id=100, l=161) • 6.134438 10.0.30.3 -> 10.0.99.151 RADIUS Access-challenge(11) (id=100, l=111) • 6.143988 10.0.99.151 -> 10.0.30.3 RADIUS Access-Request(1) (id=101, l=143) • 6.144635 10.0.30.3 -> 10.0.99.151 RADIUS Access-Accept(2) (id=101, l=174) Na obrázku 26 je zachycenna komunikace protokolem EAP mezi uživatelem a RADIUS klientem (Cisco 1230), v okamžiku kdy se uživatel snaží připojit do sítě PRIVATE-WIFI. K odposlechnutí komunikace byl použit program Wireshark.

Obr. 26: EAP komunikace mezi NAS a uživatelem

7

7

FINANČNÍ NÁROKY IMPLEMENTACE

50

Finanční nároky implementace

Bakalářská práce se zabívá integrováním autentizačních mechanizmů pomocí opensource produktů. Z tohoto důvodu odpadají finančně velice nákladné položky za licence programů. V konečném součtu firma zaplatí pouze za nákup hardware a za práci IT odborníka na naistalování, zkonfigurování a odladění autentizačních mechamismů do bezdrátové sítě. Cena za hardware se bude lišit podle zvolené implementace. Asus WL500gP stojí v průměru 1 100 Kč a je nutné kalkulovat s tím, že do firemní sítě bude nutné koupit dva tyto acces pointy. Cena Cisco 1230 AP závisí na verzi IOS. V základní verzi, pro malou firmu dostačující, se cena pohybuje okolo 7 000 Kč. Cena práce IT odborníka, je uvažován vysokoškolsky vzdělaný člověk, se v průměru pohybuje okolo 500 Kč/hod. Konfigurace a ladění celé implenentace představuje přibližně 20 člověkohodin. Délka implementace se může lišit v závislosti na prováděných pracech (instalace OS, konfigurace velkého počtu klientů atd). Celková cena implementace se při délce práce 20 člověkohodin pohybuje v rozmezí 12 200 až 17 000 Kč v závislosti na použitém hardware. Údržba systému je relativně nenáročná. Tato činnost zahrnuje kontrolování logů serveru a acces pointů a vytváření nových uživatelů, a stávajícím uživatelům popřípadě generovat nové certifikáty. Těmto činnostem je potřeba se věnovat přibližně 2 člověkohodiny týdně. Pokud firma bude najímat externího pracovníka, budou náklady 1,000 Kč za týden. V případě že tato činnost bude svěřena firemnímu IT zaměstnanci, tak jsou náklady zohledněné v jeho platu.

8

DISKUZE

8

51

Diskuze

Při řešení bakalářské práce jsem se snažil využívat co možná nejdůvěryhodnějiší literární zdroje. Velkou nevýhodou open-source řešení je málo dostupná dokumentace, která občas svojí kvalitou velice zaostává za komerčními produkty. Z tohoto důvodu jsem také musel procházet diskuzní fóra, věnující se problematice autentizačních mechanismů a bezdrátových sítí. Většina dokumentace pro program FreeRADIUS je přímo vložena do konfiguračních souborů, což do jisté míry usnadňuje konfiguraci, ale zároveň se konfigurační soubory stávají nepřehledné.

8.1

Nedostatky řešení

Jedním z největších nedostatků implementovaného řešení je dohledávání uživatelů v textovém souboru. Tento způsob evidence uživatelů byl zvolen z důvodu jednodušší realizace v laboratoři UI PEF MZLU. Při realizaci ve skutečné firmě by bylo nutné provázat RADIUS server minimálně s LDAP nebo ještě lépe se SQL databází. Acces point Cisco 1230 nepodporuje normu IEEE 802.11i, která plně implementuje WPA2 se šifrováním AES. Z tohoto důvodu byl implementován slabší šifrovací mechanizmus WPA-TKIP. V laboratři nebyl dostatečný počet AP, které by zvládly technologii roaming. Tato technologie umožňuje ve větších prostorách, které by nezvládl pokrýt signálem jeden acces point, ponechat pracovat více acces pointů. Všechny acces pointy v síti si poté předávají klienty, aniž by klient ztratil připojení při přechodu z jednoho AP na druhé. Toto je velice potřebná vlastnost sítě v případě zavedení wireless IP telefonů. Předposledním návrhem na rozšíření je zavedení třetí bezdrátové sítě GUESTWIFI. Síť by sloužila pro firemní hosty, kteří by potřebovali během pobytu v prostorách firmy přístup na internet. Bezpečnost sítě by se řešila tehnologií WPA2 se sdíleným klíčem. Implementace, tak jak byla provedena v laboratoři, řeší pouze autentizaci koncové stanice, nikoliv uživatele. Tento nedostatek by bylo potřeba vyřešit pomocí smartcard a autentizovat jak stanici, tak i uživatele, který stanici využívá. Dané problematice se budu i nadále věnovat a pokusím se vyjmenované problémy vyřešit v laboratoři.

9

9

ZÁVĚR

52

Závěr

Cílem práce bylo integrovat autentizační mechanismy do bezdrátové sítě. Tento cíl byl dle mého názoru dostatečně splněn. Hlavní přínos práce vidím v tom, že na českém Internetu chybí dostatečný počet obdobných ucelených případových studií. Bakalářská práce se nezabývá pouze integrací autentizačních mechanismů, ale popisuje i kroky potřebné ke správnému zrealizování bezdrátových sítí tak, jak je uvedeno v kapitole Analýza bezdrátové sítě. Tato práce v základu vysvětluje princip fungování bezdrátových sítí a jejich bezpečnosti. Implementace tak, jak byla provedena, nebyla vystavena žádným zátěžovým testům, a to ze dvou důvodů. Prvním je absence potřebného technického vybavení v laboratoři k uskutečnění testů. Druhým důvodem byla časová náročnost implementace, jež autorovi trvala déle, než původně předpokládal. Bakalářská práce se nezabývá komplexním návrhem a realizací počítačové sítě pro malou a střední firmu, ale řeší pouze oblast bezdrátových sítí. Práce spolu s pracemi autorů uvedených v úvodu práce je součástí projektu realizovaného v laboratoři a interně nazvaného Malá firma s IT správcem. Teprve tato kolekce bakalářských prací řeší komplexní návrh a realizaci počítačové sítě pro potřeby malé a středně velké firmy. Postupem času budou základy jednotlivých prací přeneseny a vystaveny na veřejně přístupné části laboratorní wikipedie www.publicsitelan.wikidot.com. Tato bakalářská práce bude výchozí platformou pro další autorovu práci v oblasti řízeného přístupu do počítačové sítě. Rád bych se zaměřil i na jiné produkty implementující autentizační servery a jejich vzájemné srovnání. S tím také souvisí i integrace jiných autentizačních mechanismů, než EAP-TLS.

10

10

LITERATURA

53

Literatura

Teare, Diane, Paquet, Catherine. Campus Network Design Fundamentals : The all-in-one guide to modern routed and switched campus network design. Indianapolis : Cisco Press, c2006. 378 s. ISBN 1-58705-222-9. . Schauwers, Gert, DeLaet, Gert. Network Security Fundamentals : An introduction to the key tools abd technologies used to secure network access. Indianapolis : Cisco Press, 2004. 454 s. ISBN 1-587051672. . Pužmanová. Bezpečnost WiFi záleží jen na vás [online]. [cit. 15. května 2009]. Dostupné na Internetu: http://www.lupa.cz/clanky/bezpecnost-wifi-zalezi-jen-navas/. Pužmanová. WLAN konečně bezpečné [online]. [cit. 15. května 2009]. Dostupné na Internetu: http://www.lupa.cz/clanky/wlan-konecne-bezpecne/. Nmeth, Snyder. Linux : kompletní příručka administrátora. 1. vyd. Brno: Computer Press, 2004. 828 s. ISBN 80-7226-919-4. www.lupa.cz. Slovníček pojmů [online].[cit. 15. května 2009]. Dostupné na Internetu: http://www.lupa.cz/slovnicek/.

Přílohy

A

A

PŘÍKLAD X.509 CERTIFIKÁTU

Příklad X.509 certifikátu

Certificate: Data: Version: 3 (0x2) Serial Number: 2 (0x2) Signature Algorithm: md5WithRSAEncryption Issuer: C=CZ ST=Czech L=Brno O=Malafirma/[email protected] CN=Certifikacni autorita malefirmy Validity Not Before: May 20 13:54:43 2009 GMT Not After : May 20 13:54:43 2010 GMT Subject: C=CZ ST=Czech O=Malafirma [email protected] Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) Modulus (2048 bit): 00:b2:db:38:70:60:68:46:88:3c:06:66:14:22:a3: e7:6d:7a:54:97:18:91:6e:0d:a5:df:a6:d8:b2:1d: cb:1a:68:07:6a:c7:46:c9:49:0b:0b:88:4c:c1:77: 6b:eb:15:ca:89:c1:96:13:c0:65:6e:be:49:52:0e: 34:a5:b4:a3:d7:90:2b:22:ec:f8:c2:18:41:3c:7f: 31:15:09:41:e7:4d:a8:d4:77:a0:d9:3a:e9:78:c3: 42:19:da:e6:57:12:ce:91:8e:8e:25:99:fc:ab:71: 4d:85:be:b0:f0:83:3e:fe:65:a9:4d:c1:87:b2:b9: fa:1a:e0:b6:f3:76:0a:5c:ee:8e:90:75:5d:f3:bc: a3:d5:c1:04:b3:81:07:d0:62:4a:63:47:3c:03:99: c7:0f:53:f2:20:d8:91:33:57:0c:fd:9a:89:4b:c9: b8:15:c2:99:4e:c3:a9:ab:c3:5d:be:f6:9c:08:f6: 5c:d0:68:ce:b7:a8:15:ed:3b:ab:2d:12:00:10:5f: ff:ec:27:a3:4e:98:05:57:78:d3:00:d8:b9:a8:9b: 13:4a:cf:23:c8:b3:49:d8:09:c0:3b:1c:4e:2c:42: 3d:c3:d6:dc:1d:ef:d7:49:20:ed:c3:12:14:e4:4a: 7b:5d:15:44:b1:dd:13:c0:c4:9b:03:1c:e0:37:39: 30:bf

55

A

PŘÍKLAD X.509 CERTIFIKÁTU

Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Extended Key Usage: TLS Web Client Authentication Signature Algorithm: md5WithRSAEncryption aa:18:d0:a9:a4:c6:5a:7c:82:6f:0b:3d:e5:a8:59:2a:19:d3: 2c:18:56:d8:f1:3e:b9:3a:1f:81:06:35:8a:09:30:6b:6e:e1: d1:9a:13:74:17:61:ab:16:ee:06:c1:4f:fb:7b:1a:dd:ea:7b: 06:ae:22:be:45:b9:78:0e:ec:18:5c:35:91:9f:48:05:15:57: c9:7c:d3:c8:3b:03:ac:c5:22:fa:05:d2:44:70:ce:73:c9:00: 9f:88:83:62:ef:63:31:6a:bc:64:bd:61:9f:4b:90:3c:5f:93: 63:76:1e:9d:c9:b5:69:db:0c:85:1c:62:77:47:77:98:ef:3e: 0b:c2:2d:4c:b5:d4:bc:f2:43:75:cf:8f:df:a9:76:6a:f1:05: de:a5:4f:82:20:dc:7f:14:23:fa:d6:72:b0:4d:5f:47:67:aa: 3f:05:3d:d2:28:82:da:ad:cd:84:0f:f7:e4:49:52:32:85:fa: 1b:4e:e7:1e:1e:03:4b:06:1f:c1:23:89:e3:0e:bc:ef:e6:4c: 22:3e:6a:0e:c3:10:29:e9:d0:76:2f:a6:e1:92:f8:d9:76:69: b9:6c:11:ab:8d:fc:b0:97:48:c8:82:26:3f:e4:90:e3:1a:e0: 8b:28:8c:91:a7:42:81:d5:6e:81:10:fa:56:a1:a4:c6:33:eb: e3:61:a0:1a -----BEGIN CERTIFICATE----MIIDkDCCAnigAwIBAgIBAjANBgkqhkiG9w0BAQQFADCBjTELMAkGA1UEBhMCQ1ox DjAMBgNVBAgTBUN6ZWNoMQ0wCwYDVQQHEwRCcm5vMRIwEAYDVQQKEwlNYWxhZmly bWExITAfBgkqhkiG9w0BCQEWEmFkbWluQG1hbGFmaXJtYS5jejEoMCYGA1UEAxMf Q2VydGlmaWthY25pIGF1dG9yaXRhIG1hbGVmaXJteTAeFw0wOTA1MjAxMzU0NDNa Fw0xMDA1MjAxMzU0NDNaMHAxCzAJBgNVBAYTAkNaMQ4wDAYDVQQIEwVDemVjaDES MBAGA1UEChMJTWFsYWZpcm1hMRQwEgYDVQQDEwt6YW1lc3RuYW5lYzEnMCUGCSqG SIb3DQEJARYYemFtZXN0bmFuZWNAbWFsYWZpcm1hLmN6MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAsts4cGBoRog8BmYUIqPnbXpUlxiRbg2l36bYsh3L GmgHasdGyUkLC4hMwXdr6xXKicGWE8Blbr5JUg40pbSj15ArIuz4whhBPH8xFQlB 502o1Heg2TrpeMNCGdrmVxLOkY6OJZn8q3FNhb6w8IM+/mWpTcGHsrn6GuC283YK XO6OkHVd87yj1cEEs4EH0GJKY0c8A5nHD1PyINiRM1cM/ZqJS8m4FcKZTsOpq8Nd vvacCPZc0GjOt6gV7TurLRIAEF//7CejTpgFV3jTANi5qJsTSs8jyLNJ2AnAOxxO LEI9w9bcHe/XSSDtwxIU5Ep7XRVEsd0TwMSbAxzgNzkwvwIDAQABoxcwFTATBgNV HSUEDDAKBggrBgEFBQcDAjANBgkqhkiG9w0BAQQFAAOCAQEAqhjQqaTGWnyCbws9 5ahZKhnTLBhW2PE+uTofgQY1igkwa27h0ZoTdBdhqxbuBsFP+3sa3ep7Bq4ivkW5 eA7sGFw1kZ9IBRVXyXzTyDsDrMUi+gXSRHDOc8kAn4iDYu9jMWq8ZL1hn0uQPF+T Y3Yencm1adsMhRxid0d3mO8+C8ItTLXUvPJDdc+P36l2avEF3qVPgiDcfxQj+tZy sE1fR2eqPwU90iiC2q3NhA/35ElSMoX6G07nHh4DSwYfwSOJ4w687+ZMIj5qDsMQ KenQdi+m4ZL42XZpuWwRq438sJdIyIImP+SQ4xrgiyiMkadCgdVugRD6VqGkxjPr 42GgGg== -----END CERTIFICATE-----

56

B

B

RADIUSD.CONF

radiusd.conf

Obsah souboru radiusd.conf prefix = /usr/local/radius exec prefix = ${prefix} sysconfdir = ${prefix}/etc localstatedir = ${prefix}/var sbindir = ${exec prefix}/sbin logdir = ${localstatedir}/log/radius raddbdir = ${sysconfdir}/raddb radacctdir = ${logdir}/radacct confdir = ${raddbdir} run dir = ${localstatedir}/run/radiusd db dir = ${raddbdir} libdir = ${exec prefix}/lib pidfile = ${run dir}/radiusd.pid user = radius group = radius max request time = 30 cleanup delay = 5 max requests = 1024 listen { ipaddr = 10.0.30.3 port = 1812 type = auth } listen { ipaddr = 10.0.30.3 port = 1646 type = auth } hostname lookups = no allow core dumps = no regular expressions = yes extended expressions = yes log { destination = syslog file = ${logdir}/radius.log syslog facility = daemon stripped names = no auth = yes auth badpass = yes auth goodpass = yes }

57

B

RADIUSD.CONF

checkrad = ${sbindir}/checkrad security { max attributes = 200 reject delay = 1 status server = yes } proxy requests = yes $INCLUDE proxy.conf $INCLUDE clients.conf snmp = no thread pool { start servers = 5 max servers = 32 min spare servers = 3 max spare servers = 10 max requests per server = 0 } modules { $INCLUDE ${confdir}/modules/ $INCLUDE eap.conf $INCLUDE sql.conf $INCLUDE sql/mysql/counter.conf } instantiate { exec expr expiration logintime } $INCLUDE policy.conf $INCLUDE sites-enabled/

58

C

C

CLIENTS.CONF

clients.conf

Obsah souboru clietns.conf client localhost { ipaddr = 127.0.0.1 netmask = 32 secret = testing123 require message authenticator = no nastype = other } client 10.0.55.151 { secret = asusAP shortname = asus nastype = other } client 10.0.99.151 { secret = ciscoAP shortname = cisco nastype = cisco }

59

D

D

EAP.CONF

eap.conf

Obsah souboru eap.conf eap default eap type = tls timer expire = 60 ignore unknown eap types = no cisco accounting username bug = yes max sessions = 2048 md5 {} leap {} gtc { auth type = PAP } tls { certdir = ${confdir}/certs cadir = ${confdir}/certs private key password = server private key file = ${certdir}/server.pem certificate file = ${certdir}/server.pem CA file = ${cadir}/ca.pem dh file = ${certdir}/dh random file = ${certdir}/random fragment size = 1024 include length = yes CA path = /usr/local/radius/etc/raddb/certs/ } ttls { default eap type = md5 copy request to tunnel = no use tunneled reply = no virtual server = ”inner-tunnel” } peap { default eap type = mschapv2 copy request to tunnel = no use tunneled reply = no virtual server = ”inner-tunnel” } mschapv2 { } }

60

E

E

USERS

users

Obsah soubour users DEFAULT Framed-Protocol == PPP Framed-Protocol = PPP, Framed-Compression = Van-Jacobson-TCP-IP DEFAULT Hint == ”CSLIP” Framed-Protocol = SLIP, Framed-Compression = Van-Jacobson-TCP-IP DEFAULT Hint == ”SLIP” Framed-Protocol = SLIP user bob zamestnanec Auth-Type := EAP

61

F

F

CA.CNF

ca.cnf

[ ca ] default ca = CA default [ CA default ] dir = ./ certs = $dir crl dir = $dir/crl database = $dir/index.txt new certs dir = $dir certificate = $dir/ca.pem serial = $dir/serial crl = $dir/crl.pem private key = $dir/ca.key RANDFILE = $dir/.rand name opt = ca default cert opt = ca default default days = 365 default crl days = 30 default md = md5 preserve = no policy = policy match [ policy match ] countryName = match stateOrProvinceName = match organizationName = match organizationalUnitName = optional commonName = supplied emailAddress = optional [ policy anything ] countryName = optional stateOrProvinceName = optional localityName = optional organizationName = optional organizationalUnitName = optional commonName = supplied emailAddress = optional [ req ] prompt = no distinguished name = certificate authority default bits = 2048 input password = certifikacniautorita output password = certifikacniautorita x509 extensions = v3 ca [certificate authority]

62

F

CA.CNF

countryName = CZ stateOrProvinceName = Czech localityName = Brno organizationName = Malafirma emailAddress = adminmalafirma.cz commonName = ”Certifikacni autorita malefirmy” [v3 ca] subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer:always basicConstraints = CA:true

63

G

G

SERVER.CNF

server.cnf

[ ca ] default ca = CA default [ CA default ] dir = ./ certs = $dir crl dir = $dir/crl database = $dir/index.txt new certs dir = $dir certificate = $dir/ca.pem serial = $dir/serial crl = $dir/crl.pem private key = $dir/ca.key RANDFILE = $dir/.rand name opt = ca default cert opt = ca default default days = 365 default crl days = 30 default md = md5 preserve = no policy = policy match [ policy match ] countryName = match stateOrProvinceName = match organizationName = match organizationalUnitName = optional commonName = supplied emailAddress = optional [ policy anything ] countryName = optional stateOrProvinceName = optional localityName = optional organizationName = optional organizationalUnitName = optional commonName = supplied emailAddress = optional [ req ] prompt = no distinguished name = certificate authority default bits = 2048 input password = server output password = server x509 extensions = v3 ca [certificate authority]

64

G

SERVER.CNF

countryName = CZ stateOrProvinceName = Czech localityName = Brno organizationName = Malafirma emailAddress = adminmalafirma.cz commonName = ”server” [v3 ca] subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer:always basicConstraints = CA:true

65

H

H

CLIENT.CNF

client.cnf

[ ca ] default ca = CA default [ CA default ] dir = ./ certs = $dir crl dir = $dir/crl database = $dir/index.txt new certs dir = $dir certificate = $dir/ca.pem serial = $dir/serial crl = $dir/crl.pem private key = $dir/ca.key RANDFILE = $dir/.rand name opt = ca default cert opt = ca default default days = 365 default crl days = 30 default md = md5 preserve = no policy = policy match [ policy match ] countryName = match stateOrProvinceName = match organizationName = match organizationalUnitName = optional commonName = supplied emailAddress = optional [ policy anything ] countryName = optional stateOrProvinceName = optional localityName = optional organizationName = optional organizationalUnitName = optional commonName = supplied emailAddress = optional [ req ] prompt = no distinguished name = certificate authority default bits = 2048 input password = zamestnanec output password = zamestnanec x509 extensions = v3 ca [certificate authority]

66

H

CLIENT.CNF

countryName = CZ stateOrProvinceName = Czech localityName = Brno organizationName = Malafirma emailAddress = zamestnanecmalafirma.cz commonName = zamestnanec [v3 ca] subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer:always basicConstraints = CA:true

67

I

I

1230 AP CONF

1230 AP conf

! version 12.3 no service pad service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname Legolas ! ! ip subnet-zero ip dhcp excluded-address 10.0.66.0 10.0.66.10 ! ip dhcp pool vlana66 network 10.0.66.0 255.255.255.0 default-router 10.0.66.1 dns-server 10.0.20.2 ! ! aaa new-model ! aaa group server radius rad eap server 10.0.30.3 auth-port 1645 acct-port 1646 ! aaa group server radius rad mac ! aaa group server radius rad acct ! aaa group server radius rad admin ! aaa group server tacacs+ tac admin ! aaa group server radius rad pmip ! aaa group server radius dummy ! aaa authentication login eap methods group rad eap aaa authentication login mac methods local aaa authorization exec default local aaa accounting network acct methods start-stop group rad acct aaa session-id common

68

I

1230 AP CONF

69

! dot11 ssid FREE-WIFI vlan 66 authentication open mbssid guest-mode ! dot11 ssid PRIVATE-WIFI vlan 55 authentication open eap eap methods authentication network-eap eap methods authentication key-management wpa mbssid guest-mode ! ! ! ! ! ! interface Dot11Radio0 no ip address no ip route-cache ! encryption vlan 55 mode ciphers tkip ! ssid FREE-WIFI ! ssid PRIVATE-WIFI ! mbssid speed basic-1.0 basic-2.0 basic-5.5 6.0 9.0 basic-11.0 12.0 18.0 24.0 36.0 48.0 station-role root bridge-group 1 bridge-group 1 subscriber-loop-control bridge-group 1 block-unknown-source no bridge-group 1 source-learning no bridge-group 1 unicast-flooding bridge-group 1 spanning-disabled ! interface Dot11Radio0.55 encapsulation dot1Q 55 no ip route-cache bridge-group 55 bridge-group 55 spanning-disabled

I

1230 AP CONF

70

! interface Dot11Radio0.66 encapsulation dot1Q 66 ip address 10.0.66.2 255.255.255.0 no ip route-cache bridge-group 66 bridge-group 66 spanning-disabled ! interface FastEthernet0 no ip address no ip route-cache duplex auto speed auto hold-queue 160 in ! interface FastEthernet0.55 encapsulation dot1Q 55 no ip route-cache bridge-group 55 no bridge-group 55 source-learning bridge-group 55 spanning-disabled ! interface FastEthernet0.66 encapsulation dot1Q 66 no ip route-cache bridge-group 66 no bridge-group 66 source-learning bridge-group 66 spanning-disabled ! interface FastEthernet0.99 encapsulation dot1Q 99 native ip address 10.0.99.151 255.255.255.0 no ip route-cache bridge-group 1 no bridge-group 1 source-learning bridge-group 1 spanning-disabled ! ip default-gateway 10.0.99.1 ip http server no ip http secure-server ip http help-path http://www.cisco.com/warp/public/779/smbiz/prodconfig/help/eag! radius-server attribute 32 include-in-access-req format radius-server host 10.0.30.3 auth-port 1645 acct-port 1646 key cisco

I

1230 AP CONF

! control-plane ! ! ! ! line con 0 line vty 5 15 ! end

71

J

J

POPIS PŘILOŽENÉHO CD

72

Popis přiloženého CD

Toto CD je součástí těchto bakalářských prací: • Brázdil J. Implementace serverových služeb v prostředí malé a střední firmy. Bakalářská práce. Brno, 2009. • Daněk M. Integrace autentizačních mechanismů pro bezdrátové sítě v prostředí malé a střední firmy. Bakalářská práce. Brno, 2009. • Láník R. Počítačová síť malé a střední firmy na bázi IPv6. Bakalářská práce. Brno, 2009. • Macka I. Implementace IP telefonie v prostředí malé a střední firmy. Bakalářská práce. Brno, 2009. Struktura CD je následující: • servery/ – konfigurační soubory serverů, • servery/<jméno počítače>/etc.tar.gz – zabalené konfigurační soubory serverů , • servery/<jméno počítače>/balicky – seznam balíčků získaný příkazem dpkg -l, • servery/<jméno počítače>/ – může obsahovat i další položky, • internet/ – konfigurační soubory simulace internetu, • internet/<jméno počítače>/ – konfigurační soubory simulace internetu konkrétního počítače, • internet/vetinari/etc.tar.gz – zabalené konfigurační soubory počítače vetinari.

Integrace autentizačních mechanismů

Recommend Documents