Mendelova univerzita v BrněProvozně ekonomická fakulta

Návrh integrace IPv6 do počítačovésítě Mendelovy univerzity v Brně

v oblasti bezpečnostia síťových služeb

Diplomová práce

Vedoucí práce:Ing. Jiří Passinger

Bc. Michal Šturma

Brno 2017

2

Děkuji vedoucímu diplomové práce Ing. Jiřímu Passingerovi za poskytnutímnožství cenných rad, připomínek a nemálo stráveného času při zpracování tétozávěrečné práce. Dále děkuji Ing. Petru Zachovi, Ph.D. za poskytnuté odborné radya ochotu při konzultacích této práce.

Čestné prohlášení

Prohlašuji, že jsem tuto práci: Návrh integrace IPv6 do počítačové sítě Men-delovy univerzity v Brně v oblasti bezpečnosti a síťových služebvypracoval samostatně a veškeré použité prameny a informace jsou uvedenyv seznamu použité literatury. Souhlasím, aby moje práce byla zveřejněna v souladus § 47b zákona č. 111/1998 Sb., o vysokých školách ve znění pozdějších předpisů,a v souladu s platnou Směrnicí o zveřejňování vysokoškolských závěrečných prací.Jsem si vědom, že se na moji práci vztahuje zákon č. 121/2000 Sb., autorský zákon,a že Mendelova univerzita v Brně má právo na uzavření licenční smlouvy a užitítéto práce jako školního díla podle § 60 odst. 1 Autorského zákona.Dále se zavazuji, že před sepsáním licenční smlouvy o využití díla jinou osobou(subjektem) si vyžádám písemné stanovisko univerzity o tom, že předmětná licenčnísmlouva není v rozporu s oprávněnými zájmy univerzity, a zavazuji se uhradit pří-padný příspěvek na úhradu nákladů spojených se vznikem díla, a to až do jejichskutečné výše.

Brno 22. května 2017 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

Abstract

Šturma, M. Proposal of IPv6 Integration into computer network of Mendel Univer-sity in Brno in the field of security and network services. Brno, 2017.

This diploma thesis focuses on the complete analysis and design of securityand network services at Mendel university in Brno. The thesis contains analysisof current solution using the IPv4 protocol. Based on the analysis a new solutionis designed and implemented. The resolution is tested and evaluated in laboratoryconditions. Economic evaluation is part of this thesis as well.

Abstrakt

Šturma, M. Návrh integrace IPv6 do počítačové sítě Mendelovy univerzity v Brněv oblasti bezpečnosti a síťových služeb. Brno, 2017.

Diplomová práce se zabývá kompletní analýzou a návrhem oblasti bezpečnostia síťových služeb na Mendelově univerzitě v Brně. V práci je analyzováno stávajícířešení, které využívá protokol IPv4. Dále je vytvořen návrh řešení a implementace.Ta je následně verifikována v laboratorním prostředí. Součástí práce je také ekono-mické zhodnocení.

OBSAH 6

Obsah

1 Úvod a cíl práce 111.1 Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.2 Cíl práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2 Literární rešerše 122.1 Závěrečné práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2 Odborné monografie a internetové zdroje . . . . . . . . . . . . . . . . 142.3 Shrnutí . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3 Popis technologického aparátu 163.1 Adresní prostor a IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1.1 Internet protokol verze 6 . . . . . . . . . . . . . . . . . . . . . 163.1.2 Přechodové mechanismy . . . . . . . . . . . . . . . . . . . . . 16

3.2 Adresace koncových zařízení . . . . . . . . . . . . . . . . . . . . . . . 173.2.1 Bezstavová konfigurace . . . . . . . . . . . . . . . . . . . . . . 183.2.2 Stavová konfigurace . . . . . . . . . . . . . . . . . . . . . . . . 18

3.3 DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.4 Firewalling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.4.1 Paketový filtr . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.4.2 Aplikační proxy . . . . . . . . . . . . . . . . . . . . . . . . . . 203.4.3 Stavový filtr . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.5 IDS/IPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.6 ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.7 VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.7.1 Vzdálený přístup (remote access) . . . . . . . . . . . . . . . . 223.7.2 Propojení sítí (site to site) . . . . . . . . . . . . . . . . . . . . 23

3.8 Zabezpečení na úrovni ASW . . . . . . . . . . . . . . . . . . . . . . . 233.9 Sledování provozu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.10 Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.10.1 Dopředné proxy . . . . . . . . . . . . . . . . . . . . . . . . . . 253.10.2 Reverzní proxy . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.11 AAA služby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.12 Webové služby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.13 Poštovní služby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.14 Databázové služby . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.15 Časové služby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.16 Zálohovací služby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.17 VoIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.18 Virtualizace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.19 WiFi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.20 Správa koncových stanic . . . . . . . . . . . . . . . . . . . . . . . . . 31

OBSAH 7

3.21 Vícekriteriální hodnocení variant . . . . . . . . . . . . . . . . . . . . 32

4 Analýza současného stavu a požadavků 334.1 Metodika analýzy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.2 Obdobná řešení implementace IPv6 na jiných VŠ . . . . . . . . . . . 334.3 Geografické dělení univerzitní sítě . . . . . . . . . . . . . . . . . . . . 354.4 Adresní prostor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.5 Adresace koncových zařízení . . . . . . . . . . . . . . . . . . . . . . . 364.6 Služby a bezpečnostní funkce . . . . . . . . . . . . . . . . . . . . . . 37

4.6.1 DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.6.2 Firewalling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.6.3 IDS, IPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.6.4 ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.6.5 VPN (Virtuální privátní síť) . . . . . . . . . . . . . . . . . . . 414.6.6 Zabezpečení na úrovni ASW . . . . . . . . . . . . . . . . . . . 424.6.7 Sledování provozu . . . . . . . . . . . . . . . . . . . . . . . . . 434.6.8 Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.6.9 AAA služby . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.6.10 Webové služby . . . . . . . . . . . . . . . . . . . . . . . . . . 444.6.11 Poštovní služby . . . . . . . . . . . . . . . . . . . . . . . . . . 454.6.12 Databázové služby . . . . . . . . . . . . . . . . . . . . . . . . 474.6.13 Časové služby . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.6.14 Zálohovací služby . . . . . . . . . . . . . . . . . . . . . . . . . 484.6.15 VoIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.6.16 Virtualizace . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.6.17 WiFi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.7 Správa koncových stanic . . . . . . . . . . . . . . . . . . . . . . . . . 51

5 Návrh řešení 535.1 Adresní prostor a adresace koncových zařízení . . . . . . . . . . . . . 535.2 DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.2.1 Dva různé účely provozu dané služby . . . . . . . . . . . . . . 545.2.2 Malá škála dostupného DNS software . . . . . . . . . . . . . . 545.2.3 Nemožnost DNSSEC validace vlastních dat . . . . . . . . . . . 545.2.4 Špatná data z oddelegovaných, ale nezrušených zón . . . . . . 545.2.5 Dostupnost z internetu a útoky na DNS . . . . . . . . . . . . 555.2.6 DNS Cache Poisoning . . . . . . . . . . . . . . . . . . . . . . 555.2.7 Amplifikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565.2.8 Water tortue . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5.3 Firewalling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605.3.1 Vícekriteriální hodnocení variant . . . . . . . . . . . . . . . . 605.3.2 Návrh topologického diagramu . . . . . . . . . . . . . . . . . . 62

5.4 IDS, IPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

OBSAH 8

5.4.1 Vícekriteriální hodnocení variant . . . . . . . . . . . . . . . . 655.5 ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695.6 VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

5.6.1 Site-to-Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705.6.2 Remote Access . . . . . . . . . . . . . . . . . . . . . . . . . . 70

5.7 Zabezpečení na úrovni ASW . . . . . . . . . . . . . . . . . . . . . . . 705.7.1 Koncová stanice, univerzitní síť . . . . . . . . . . . . . . . . . 715.7.2 Koncová stanice, kolejní síť . . . . . . . . . . . . . . . . . . . 715.7.3 Datacentrum . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

5.8 Sledování provozu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725.9 Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725.10 AAA služby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725.11 Webové služby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735.12 Poštovní služby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735.13 Databázové služby . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745.14 Časové služby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745.15 Zálohovací služby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745.16 VoIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745.17 Virtualizace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745.18 WiFi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755.19 Správa koncových stanic . . . . . . . . . . . . . . . . . . . . . . . . . 75

6 Implementace návrhu 766.1 DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766.2 Firewalling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 776.3 IDS, IPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 806.4 ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 826.5 VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

6.5.1 Site to Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836.6 Zabezpečení na úrovni ASW . . . . . . . . . . . . . . . . . . . . . . . 83

6.6.1 Koncová stanice, univerzitní síť . . . . . . . . . . . . . . . . . 836.6.2 Koncová stanice, kolejní síť . . . . . . . . . . . . . . . . . . . 84

6.7 Sledování provozu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 856.8 Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 866.9 AAA služby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 886.10 Webové služby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 886.11 Poštovní služby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

6.11.1 IPv6 adresy na síťových rozhraních poštovních serverů . . . . 896.11.2 Vytvoření AAAA a PTR záznamů pro poštovní servery v DNS 896.11.3 Povolení protokolu IPv6 ve spuštěných službách . . . . . . . . 906.11.4 Vytvoření nových pravidel s IPv6 adresací pro firewall . . . . 90

6.12 Databázové služby . . . . . . . . . . . . . . . . . . . . . . . . . . . . 906.13 Časové služby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

OBSAH 9

6.14 Virtualizace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 916.15 WiFi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

6.15.1 Povýšení kontroléru na aktuální verzi . . . . . . . . . . . . . . 926.15.2 Konfigurace IPv6 na kontroléru . . . . . . . . . . . . . . . . . 93

6.16 Správa koncových stanic . . . . . . . . . . . . . . . . . . . . . . . . . 95

7 Verifikace navrženého řešení 967.1 DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

7.1.1 Simulace autoritativního požadavku . . . . . . . . . . . . . . . 967.1.2 Rekurzivní požadavek . . . . . . . . . . . . . . . . . . . . . . 977.1.3 Verifikace zabezpečení DNS . . . . . . . . . . . . . . . . . . . 97

7.2 Firewalling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 987.2.1 Přístup z PC1 k webovým službám PC2 . . . . . . . . . . . . 987.2.2 Ping zaslaný z klienta PC2 na IPv6 adresu klienta PC1 . . . . 997.2.3 Požadavek zaslaný z klienta PC2 na IPv6 adresu klienta PC1

se záměnou zdrojové adresy . . . . . . . . . . . . . . . . . . . 997.3 IDS, IPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1007.4 ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1017.5 VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1017.6 Zabezpečení na úrovni ASW . . . . . . . . . . . . . . . . . . . . . . . 103

7.6.1 Koncová stanice, univerzitní síť . . . . . . . . . . . . . . . . . 1037.6.2 Koncová stanice, kolejní síť . . . . . . . . . . . . . . . . . . . 104

7.7 Sledování provozu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1057.8 Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1077.9 AAA služby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1097.10 Webové služby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1117.11 Poštovní služby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

7.11.1 Server s nastavením provozu IPv4 . . . . . . . . . . . . . . . . 1127.11.2 Server s nastavením provozu IPv6 . . . . . . . . . . . . . . . . 1137.11.3 Server se zapnutou bezpečnostní aplikací Postgrey . . . . . . . 114

7.12 Databázové služby . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1157.13 Časové služby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1167.14 Virtualizace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1167.15 WiFi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

7.15.1 Tunelování CAPWAP pomocí protokolu IPv4 . . . . . . . . . 1177.15.2 Tunelování CAPWAP pomocí protokolu IPv6 . . . . . . . . . 1197.15.3 Zhodnocení verifikačních testů WiFi . . . . . . . . . . . . . . 121

7.16 Správa koncových stanic . . . . . . . . . . . . . . . . . . . . . . . . . 121

8 Ekonomické zhodnocení návrhu 1238.1 Nákladové položky . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1238.2 Výnosové položky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1248.3 Zhodnocení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

OBSAH 10

9 Závěr 127

10 Reference 128

1 ÚVOD A CíL PRÁCE 11

1 Úvod a cíl práce

1.1 Úvod

Počet adres protokolu IP verze 4 v současné době přestává stačit, protože jejichzdánlivě nepředstavitelné množství, více než 4 miliardy (RFC791), se již téměř vy-čerpalo. Přesto, že existují mechanismy, které se pokoušely nutnost přechodu nanový protokol IPv6 oddálit (NAT), i ony již dosahují svých limitů, protože jejichpoužití není možné ve všech případech nasazení. Běžným stavem je tak v současnostisituace, kdy je mnoho koncových stanic adresováno jednou veřejnou adresou spolus použitím metody překladu. Tento překlad často řeší problém nedostatku adres,avšak bez dodatečného nastavení neumožňuje přímo kontaktovat stanici, která jeza použití této metody adresována. Tento, ale i další problémy, nejen s nedostat-kem adres, je možné vyřešit nasazením protokolu IP verze 6. Ten nabízí nespočetněvíce adres, které lze použít, a umožňuje tak unikátní adresaci koncových stanic beznutnosti překladu.

Na Mendelově univerzitě v Brně byl před započetím zpracování této diplomovépráce využíván pouze protokol IPv4. Avšak vzhledem k tomu, že se rozvoj IPv6,především z důvodů docházejícího prostoru pro adresaci IPv4, velice zrychlil, začínábýt možnost použití protokolu IPv6 v podstatě nutností. Dále je tento krok zásadnípro servery, u kterých je velice pravděpodobné, že budou kontaktovány pomocí to-hoto protokolu z vnější sítě. S nasazením protokolu IPv6 však souvisí i nutnostnasazení odpovídajícího zabezpečení. IPv6 totiž spolu s benefity přináší také mnohoproblémů, z nichž významná část je z oblasti bezpečnosti.

Zadání diplomové práce vzešlo z potřeby implementace protokolu IPv6 na Men-delově univerzitě v Brně, jejímž důvodem je udržení kroku s okolními sítěmi, kteréIPv6 více či méně implementují.

1.2 Cíl práce

Cílem této diplomové práce je vytvořit návrh nasazení protokolu IPv6 na Mendelověuniverzitě v Brně. K naplnění cíle budou využity již zjištěné skutečnosti a návrhy,kterými se zabývali ve svých závěrečných pracích Ing. Tomáš Filip a Bc. BarboraChumlenová. Dále bude provedena analýza stávajícího řešení komunikace za pou-žití protokolu IPv4. Zjištěné skutečnosti budou využity pro tvorbu vlastního návrhuřešení, které se bude zabývat především oblastí bezpečnosti a síťových služeb. Smys-lem je vytvořit návrh řešení, jehož implementaci bude možné využít v produkční sítiMendelovy univerzity v Brně.

2 LITERÁRNí REŠERŠE 12

2 Literární rešerše

Analýza závěrečných prací, které mají souvislost se zpracováním tématu této di-plomové práce je provedena níže. Zdroje, které jsou uvedeny, mohou dodat hlubšíinformace o dané problematice a poskytnout tak sjednocený přehled informací, zekterých lze v této práci vycházet. Do analýzy byly vybrány práce, které se zabý-vají bezpečností protokolu IPv6 a aplikačními službami, které budou v rámci tétopráce pro integraci protokolu IPv6 navrhovány. Součástí analýzy jsou jak diplomovéa bakalářské práce, tak i monografie a internetové zdroje.

Vyhledávání zdrojů bylo prováděno pomocí vyhledávače odborných pracíthesis.cz, dále pak za užití fulltextového internetového vyhledávače Google. Pro vy-hledávání byla stanovena klíčová slova vyplývající z cíle této práce, a to: IPv6,firewall, DNS, DHCPv6.

2.1 Závěrečné práce

ČERMÁK, M. Bezpečnostní analýza provozu DNS [online]. Brno, 2014 [cit. 2017-05-14]. Dostupné z: <http://is.muni.cz/th/325314/fi_m/>. Diplomová práce.Masarykova univerzita, Fakulta informatiky. Vedoucí práce RNDr. Jan Vykopal,Ph.D.

Autor této diplomové práce přehledně popisuje způsob fungování DNS (DomainName Services) a jeho zranitelnosti. Zabývá se také monitoringem a analýzou jehoanomálií. Přesto, že se autor nedotýká protokolu IPv6, je jeho práce cenným zdro-jem informací o provozu DNS serveru.

FILIP, T. Návrh integrace IPv6 do počítačové sítě Mendelovy univerzity v Brněv oblasti směrování [online]. Brno, 2015 [cit. 2016-10-19]. Diplomová práce. Men-delova univerzita v Brně, Provozně ekonomická fakulta. Vedoucí práce Ing. MartinPokorný, Ph.D. Dostupné z: <http://theses.cz/id/4s6hgt/>.

Diplomová práce obsahuje logicky ucelený návrh adresního prostoru pro po-třeby Mendelovy univerzity v Brně. Tento návrh je velice kvalitně zpracován. Díkytomu je tak vhodný pro nasazení a umožní držet se navržených adresních blokůi v následujících obdobích, kdy je očekáván výrazný nárůst zařízení, které vyžadujíIP adresu pro komunikaci s internetem. Na tuto práci bude navázáno a v případětestovacích scénářů budou používány již navržené adresní bloky.

GEYER, Lukáš. ZABEZPEČENÍ SÍTÍ S PROTOKOLEM IPV6 [online]. Brno,2012 [cit. 2017-05-14]. Dostupné z: <https://www.vutbr.cz/www_base/zav_prace_soubor_verejne.php?file_id=53953>. Diplomová práce. Vysoké učenítechnické v Brně, Fakulta elektrotechniky a komunikačních technologií. Ústav te-lekomunikací. Vedoucí práce doc. Ing. Karel Burda, CSc.

Tato diplomová práce popisuje způsoby zabezpečení lokálních IPv6 sítí včetnědetailního popisu možných slabin způsobených chybným návrhem či konfigurací. Pro

2.1 Závěrečné práce 13

tuto práci je přínosná především kapitola popisující zranitelnosti aplikační službyDHCPv6 a IPv6 firewallu.

HLOUŠEK, Vladimír. Implementace DHCPv6 serveru [online]. Brno, 2008 [cit.2016-10-19]. Diplomová práce. Masarykova univerzita, Fakulta informatiky. Vedoucípráce RNDr. David Antoš, Ph.D. Dostupné z: <http://is.muni.cz/th/72599/fi_m/dp.pdf>.

Diplomová práce obsahující funkční a odladěnou implementaci programu apli-kační služby DHCPv6. Projekt je implementován v jazyce C++ a obsahuje stabilníprogram pro nasazení v běžném provozu. Program však není kontinuálně vyvíjena nejsou pro něj vydávány pravidelné aktualizace nových funkcí, oprav či zabez-pečení.

CHUMLENOVÁ, Barbora. Řešení dynamické konfigurace IPv6 klientů v počítačovésíti Mendelovy univerzity v Brně [online]. Brno, 2015 [cit. 2016-10-19]. Bakalářskápráce. Mendelova univerzita v Brně, Provozně ekonomická fakulta. Vedoucí práceIng. Martin Pokorný, Ph.D. Dostupné z: <http://theses.cz/id/m5l4g2/>.

V této práci se její autorka zabývá variantami dynamické konfigurace klientůvyužívajících protokol IPv6. Dále se zabývá mechanismem SLAAC v kombinacis bezstavovým a stavovým DHCPv6. Následně vybírá nejvhodnější variantu pronasazení v produkční síti Mendelovy univerzity v Brně. Práce obsahuje mnoho in-formací, které jsou podstatné pro zpracování této diplomové práce. Především pakstanovuje nejvhodnější způsob konfigurace klientů, již schválený vedením Odděleníinfrastruktury Ústavu informačních technologií Mendelovy univerzity v Brně, kte-rým je kombinace stavového DHCPv6 serveru a ohlášení směrovače.

JOUDAL, Jakub. Implementace IPv6 Na PřF JU [online]. České Budějovice, 2011[cit. 2016-10-19]. Bakalářská práce. Jihočeská univerzita v Českých Budějovicích,Přírodovědecká fakulta. Vedoucí práce Ing. Rudolf Vohnout Dostupné z: <http://theses.cz/id/rkiodq/>.

V této práci autor rozebírá možné způsoby nasazení protokolu IPv6 v síti Pří-rodovědecké fakulty Jihočeské univerzity. V této práci autor diskutuje předevšímmožné varianty nasazení. Výběr provádí pomocí multikriteriální analýzy.

VESELÝ, Jakub. IPv6 a bezpečnost [online]. Brno, 2014 [cit. 2017-05-14]. Dostupnéz: <http://theses.cz/id/pm0z8i/>. Diplomová práce. Masarykova univerzita,Fakulta informatiky. Vedoucí práce doc. RNDr. Eva Hladká, Ph.D.

Obsahem této práce je problematika bezpečnosti protokolu IPv6. Předevšímpak popisy možných útoků a s nimi souvisejícími způsoby obrany. Metody, kteréautor ve své práci zmiňuje, budou součástí této práce tak, aby bylo minimalizovánoriziko možných útoků a především jejich dopad na provoz navrhované infrastruktury.

VILÍMEK, Josef. Implementace protokolu IPv6 u ISP [online]. Praha, 2007

2.2 Odborné monografie a internetové zdroje 14

[cit. 2016-10-21]. Bakalářská práce. Vysoká škola ekonomická v Praze. Vedoucí práceLuboš Pavlíček Dostupné z: <http://theses.cz/id/7vqfzq/>.

V této práci autor popisuje fungování IPv6 a navrhuje možnou implementaciu společnosti UPC Česká republika, s.r.o. Autor se zabývá především návrhem imple-mentace pro kabelové a mobilní operátory. Podstatnou část však věnuje i konkrétnímdoporučením u DHCPv6 a DNS serverů, což by mohlo být přínosem i pro tuto práci.

ŽABENSKÝ, Filip. Návrh zavedení protokolu IP verze 6 do síťové infrastrukturyškoly [online]. Ostrava, 2015 [cit. 2016-10-19]. Bakalářská práce. Ostravská univer-zita, Přírodovědecká fakulta. Vedoucí práce RNDr. Tomáš Sochor, CSc. Dostupnéz: <http://theses.cz/id/dezk8s/>.

Práce autora Žabenského analyzuje stávající stav síťové infrastruktury středníškoly. Lehce se také dotýká témat nasazení síťových služeb (WWW, DHCP), avšaknezachází do hloubky a konfiguraci neuvádí. Autor dále analyzuje také softwarepoužívaný na serverech a koncových klientech.

2.2 Odborné monografie a internetové zdroje

IETF, Basic Transition Mechanisms for IPv6 Hosts and Routers [online]. 2005[cit. 2017-03-22]. Dostupné z <https://tools.ietf.org/html/rfc4213>

Dokument obsahující popis mechanismů přechodu z IPv4, které mohou býtimplementovány na síťových zařízeních. Popis zahrnuje jak tunelování, tak použitíDual-Stacku, jehož použití se v této práci předpokládá v návaznosti na již zmíněnépráce autora Filipa a Chumlenové.

IETF, Internet Protocol, Version 6 (IPv6) Specification [online]. 1998 [cit. 2016-12-03]. Dostupné z: <https://tools.ietf.org/html/rfc2460>

V tomto dokumentu je specifikován standard protokolu IPv6. Obsahuje pakpředevším formát hlavičky, rozšiřující hlavičky a voleb.

IETF, Privacy Extensions for Stateless Address Autoconfiguration in IPv6 [online].2007 [cit. 2016-08-20]. Dostupné z: <https://tools.ietf.org/html/rfc4941>

Dokument popisující rozšíření pro bezstavovou konfiguraci IPv6 adres. Přede-vším pak zahrnuje způsob generování adres globálního rozsahu pomocí identifikátorůrozhraní tak, že se průběžně mění v čase, čímž dochází k jejich obtížnějšímu sběruinformací o daném uzlu.

SANTOS, O., CCNA Security 210-260 Official Cert Guide, 2015, Cisco Press. ISBN9781587205668.

Tato odborná publikace obsahuje ucelený přehled možných způsobů zabez-pečení sítě. Obsahuje však také informace o útocích a způsobech, jakými se proti nimbránit. Zaměřuje se pak výhradně na zařízení od výrobce Cisco, což je uplatnitelnéi pro síť Mendelovy univerzity v Brně. Publikace obsahuje přehled hrozeb, které se

2.3 Shrnutí 15

vyskytují současně na protokolech IPv4 i IPv6, současně však zmiňuje i nová rizika,která se objevují s příchodem IPv6.

SATRAPA, P. IPv6 na TU v Liberci [online]. 2010 [cit. 2015-01-17]. Dostupnéz: <http://archiv.cesnet.cz/ipv6/wg/p/tul-ipv6.pdf>.

Tato knižní publikace zahrnuje velké množství informací, které je nutné znátpro práci s protokolem IPv6. Popisuje především funkce a možnosti tohoto proto-kolu. Zmiňuje se však také o konfiguraci DNS, stavového či bezstavového DHCPv6.Pro potřeby této práce bude přínosná kapitola popisující DNS server BIND (BarkleyInternet Name Domain) a to z toho důvodu, že obsahuje i bezpečnostní doporučení.

ŽORŽ, J., et al., Best Current Operational Practice for operators: IPv6 prefix as-signment for end-users - static (stable) or dynamic (non-stable) and what size tochoose. [online]. 2017 [cit. 2017-05-15]. Dostupné z: <http://internetsociety.org/deploy360/wp-content/uploads/2017/03/draft-IPv6pd-BCOP-v1.pdf>

Dokument popisující doporučený přístup k adresaci IPv6. Především se pak za-bývá adresací WAN spojů, přidělováním rozsahů pro koncové zákazníky ISP a způ-sobem jejich adresace. V rámci dokumentu je nejpodstatnější doporučení využívatminimálně bloky IPv6 adres o rozsahu /64 z důvodů kompatibility všech zařízení,a to i v případě point to point sítí.

2.3 Shrnutí

Na základě nalezených zdrojů lze konstatovat, že zpracování práce Návrh integraceIPv6 do počítačové sítě Mendelovy univerzity v Brně v oblasti bezpečnosti a síťovýchslužeb bude přínosné. Žádná z prací uvedených výše neobsahuje ucelený pohled nadanou problematiku, který by zahrnoval přechod sítě Mendelovy univerzity na pro-tokol IPv6 v oblasti bezpečnosti a síťových služeb. Naopak dvě z již publikovanýchprací, které jsou v rešerši uvedeny, poskytují základ pro zpracování této diplomovépráce Návrh a integrace IPv6 do počítačové sítě Mendelovy univerzity v Brně. Dalšízávěrečné práce taktéž poskytují pouze určitý náhled do způsobů implementace IPv6sítě, i proto je předpokládáno, že její zpracování bude přínosné.

3 POPIS TECHNOLOGICKÉHO APARÁTU 16

3 Popis technologického aparátu

3.1 Adresní prostor a IPv6

3.1.1 Internet protokol verze 6

Internet protokol verze 6, jakožto nástupce protokolu IPv4, byl představen již v roce1998, a to specifikací zveřejněnou v RFC2460 (1998) skupinou která začala praco-vat na novém protokolu, původně označovaným jako IPng (Hagen, 2014). Důvodemustanovení skupiny byl především omezený adresní protokol IPv4, který vedl k nut-nosti implementace mechanismů umožňující využití privátních adres, viz RFC1918(1996).

Postupem času většina organizací došla k závěru, že implementace protokoluIPv6 do jejich sítě bude nevyhnutelná. Vzhledem k tomu, že protokol IPv6 nenabízížádnou zpětnou kompatibilitu, bylo nutné stanovit způsob, jakým dojde k jeho im-plementaci tak, aby neomezil stávající funkční komunikaci pomocí protokolu IPv4.K tomuto účelu, který lze nazvat přechodovým mechanismem, patří několik metodpopsaných níže.

3.1.2 Přechodové mechanismy

Dual Stack Z pohledu přechodových mechanismů se jedná o poměrně snadno kon-figurovatelnou metodu pro koncová zařízení. Je však, na rozdíl od ostatních přecho-dových mechanismů, nutné vytvořit nový návrh celé adresace sítě tak, aby každástanice disponovala nejen IPv4, ale i IPv6 adresou.

Výhodou této metody však je, že pro použití nové adresace je možné využítstávající rozhraní, které je tak nakonfigurováno pro oba protokoly zároveň. Podrobněse tímto přechodovým mechanismem zabývá Graziani (2012).

Tunelování Tunelování vyžaduje, aby byl host na každém konci tunelu nakonfigu-rován tak, že umožní přebalovat IPv6 pakety do IPv4 a naopak. Výsledkem tak je,že paket, který je odeslán pomocí IPv4, ve své datové části obsahuje IPv6 paket, vizobr. 1. Dle Kaufmana (2004) tato technika vyžaduje, aby bylo spojení dvou koncůtunelu vždy předem nakonfigurováno.

Obrázek 1: IPv6 paket zabalený v IPv4

3.2 Adresace koncových zařízení 17

Router - Router – Jedná se o tunel, který využívá IPv4 síť a je nakonfigurovánna směrovačích IPv6 sítí. Výsledkem tedy je, že IPv6 sítě, spojené tímto tunelem,mohou komunikovat společně i přesto, že mezi nimi reálně neexistuje IPv6 cesta.Nevýhodou však je to, že ostatní IPv6 sítě pro ně zůstávají nedostupné.

Host - Router – Případ, kdy existuje tunel mezi koncovou stanicí a směrova-čem. Dle Amberga (2013) se tato metoda využívá především u vzdáleného přístupudo firemních sítí, které používají IPv6 protokol.

Host - Host – Obě koncové stanice v tomto případě komunikují přes IPv4 síť,využívají k tomu ale IPv6 pakety.

Detailně se tématikou tunelování zabývá Pavliš (2010), který ve své bakalářsképráci také popisuje technologie 6in4, 6to4, 6over4, ISATAP a Teredo.

Překladač NAT64 Přechodový mechanismus umožňující vytvoření komunikačníhokanálu mezi klienty užívající IPv6 a IPv4 pomocí překladu adres. Cisco (2016) uvádí,že tento mechanismus je překladačem mezi oběma protokoly a pro správnou funkcivyžaduje přidělení segmentu o rozsahu 32 bitů. Mapování IPv4 adres probíhá bezsta-vově a to tak, že IPv4 adresa je při překladu připojena za IPv6 prefix. Při překladuIPv6 adresy se pak využívá dynamický přístup využívající stavů, který se značně po-dobá překladu veřejných a privátních adres v IPv4. Dle specifikace RFC6146 (2011)existuje i možnost trvalých položek v mapovací tabulce. Díky té je možné, aby bylypomocí tohoto překladu dostupné síťové služby či aplikace v síti IPv4 i z IPv6 sítě.NAT64 je však navrhnut výhradně pro komunikaci iniciovanou IPv6 klientem. Speci-fické protokoly, například FTP (File Transfer Protocol), nebo SIP (Session InitiationProtocol), které využívají zapouzdřené IP adresy v uživatelských datech (payload),proto vyžadují bránu na aplikační vrstvě (ALG) pro podporu překladu.

Překladač DNS64 V případě, že klient disponuje pouze IPv6 rozhraním, pak jedle Linkové (2016) nucen komunikovat pouze s IPv6 servery. Liu (2011) uvádí, žeje-li tento server za bránou využívající NAT64, pak je nutné využití služby DNS64,která umožní překlad na IPv6 adresy tak, aby ji bylo možné pro tyto servery využít.DNS64 musí být spuštěn na zařízení, které využívá dual stack, protože stejně jakoslužba NAT64 komunikuje s okolními zařízeními za použití protokolu IPv4 i IPv6.Celý proces překladu pomocí DNS64 a NAT64 je znázorněn na obr. 2 a detailněpopsán v RFC6147 (2011).

3.2 Adresace koncových zařízení

Adresace klientů v případě protokolu IPv6 nabízí oproti původním zvyklostem IPv4nemálo změn, které je nutné uvážit při implementaci. Největší změnou je schop-nost bezstavové konfigurace, která je považována za součást systému pro objevovaní

3.2 Adresace koncových zařízení 18

Obrázek 2: Proces překladu pomocí DNS64 a NAT64

sousedů1. Způsob konfigurace je však nutné důsledně zvážit, a to především v kor-porátním prostředí, které požaduje zajištění bezpečnosti a zároveň určitý přehlednad provozem v síti.

3.2.1 Bezstavová konfigurace

Bezstavovou konfiguraci označujeme také jako SLAAC (Stateless Address Autocon-figuration). K automatické konfiguraci rozhraní klientského zařízení pak využívátoho, že v síti je přítomen směrovač se znalostí konfiguračních parametrů, kterérozesílá do sítí, ke kterým je připojen. Klient poté k těmto získaným údajům do-plní identifikátor rozhraní, který si vytvoří pomocí EUI-64 nebo Privacy Extensions(RFC2462, 1998).

3.2.2 Stavová konfigurace

Aplikační protokol DHCPv6, který nazýváme stavový, slouží pro přidělování IPv6adres a dalších síťových parametrů. Na rozdíl od IPv4 dle TCOFFENA (2015)probíhá identifikace klienta u DHCPv6 pomocí DUID. Dle RFC3315 je definiceDUID následující: „DHCP servery využívají DUID pro identifikaci klientů tak, abybyly schopny poskytnout jim odpovídající konfiguraci adresace. Klienti pak využí-vají DHCP, aby identifikovali server ve zprávách, kde je nutné jej identifikovat.ÿRFC3315 dále rozeznává několik typů DUID:

• adresa linkové vrstvy a čas vytvoření rozhraní,

• unikátní číslo přidělené výrobcem,

• adresa linkové vrstvy.

1Jedná se o obdobu ARP pro prostředí IPv6, avšak s dalšími funkcemi jako je například hledánísměrovačů, detekci duplicitních IP adres nebo zjišťování nezbytných parametrů pro automatickoukonfiguraci (Odom, 2010).

3.3 DNS 19

Hlavní výhodou DUID je jednoznačná identifikace operačního systému, tedy nepouze rozhraní. Vyčerpávajícím způsobem DUID popisuje Chumlenová (2015). Iden-tifikátor lze vidět v odchyceném paketu na obr. 3.

Obrázek 3: Ukázka odchyceného paketu při DHCPv6 Solicit

3.3 DNS

Služba sloužící pro překlad doménových jmen na IP adresy a naopak využívá hi-erarchický systém doménových jmen. Slouží především k tomu, aby bylo možnék serverům a službám přistupovat bez znalosti jejich IP adresy. V současnosti všakposkytuje i další funkce, jako je například obsluha MX, SPF záznamů, DKIM klíčůa dalších obdobných záznamů.

IP adresy a k nim přiřazená doménová jména jsou v rámci této služby spe-cifikovány uvnitř tzv. zónového souboru, kde jsou k IPv4 či IPv6 adresám přiřa-zeny doménová jména. Zpětný překlad doménových jmen na IP adresy pak zajišťujítzv. PTR záznamy.

Konfiguraci DNS serveru lze rozdělit na dvě samostatné části, které lze imple-mentovat dohromady, či samostatně.

Autoritativní DNS slouží pouze k poskytování odpovědí k dotazům na do-ménová jména a subdomény, které jsou pod jeho správou. V případě, že je dotázánna IP adresu domény, kterou nespravuje, pak není schopen zjistit její adresu. Běž-nou konfigurací pak je, že příchozí dotazy tento server odpovídá jak z lokální, takz vnější sítě.

3.4 Firewalling 20

Rekurzivní DNS je schopen se rekurzivně dotazovat dalších DNS serverůa umožňuje tak zajištění i překladu jiných než spravovaných doménových jmen čiIP adres. Požadavky tento server standardně přijímá pouze z lokální sítě a do vnějšísítě komunikuje pouze z důvodů výše zmíněné rekurze. V případě, že by byl tentoserver viditelný do internetu, pak by bylo jej možné zneužít, a to způsoby popsanýmiv kapitole 5.2.

Ačkoli se jedná o poměrně komplikovanou službu, její konfigurace pro protokolIPv6 se nijak zásadně nemění. Hlavní změnou je pouze dodání IPv6 záznamů, kterése označují textovou posloupností čtyř znaků A.

3.4 Firewalling

Firewall je zařízení, které umožňuje filtrovat provoz mezi dvěma sítěmi či jejichčástmi. Obvykle je umístěn mezi lokální a vnější sítí tak, aby umožnil filtraci ne-chtěného provozu, který je adresován na stroje v lokální síti. Firewall lze dělit doněkolika kategorií podle toho, jak s provozem, který je přes něj směrován, dokážepracovat.

3.4.1 Paketový filtr

Filtrace, která umožňuje konfigurace pouze základních pravidel. Tato pravidla ob-vykle postihují jen údaje, které jsou čitelné z hlavičky. Nejčastěji se pak k identifikacipaketů používá zdrojová či cílová IP adresa, port nebo protokol. Výhodou je po-měrně rychlé zpracování a snadná konfigurace, nevýhodou však nemožnost pracovats komunikačními relacemi.

3.4.2 Aplikační proxy

Jedná se o ochranu na aplikační vrstvě, kdy je klientský požadavek pomocí proxyserveru přeposlán cílovému zařízení. Z vnějšího pohledu se tento stroj vydává zaklienta a maskuje tak zdrojovou IP, případně i port. Výhodou je možnost kontrolyobsahu přenášených dat, cachování nebo možnost autentizovat uživatele přistupujícík této službě. Nevýhodou pak často pomalejší zpracování a hardwarová náročnost.

3.4.3 Stavový filtr

Tento typ filtrace je v současnosti nejrozšířenějším typem filtrace. Umožňuje totižhlídat stavy jednotlivých relací a na jejich základě definovat pravidla. Schopnostsledovat stav se pak neomezuje jen na spojovaný TCP protokol, ale také na protokolUDP.

3.5 IDS/IPS 21

3.5 IDS/IPS

IDS (Intrusion Detection System) a IPS (Intrusion Prevention System) jsou sys-témy zajišťující ochranu sítě pomocí monitoringu aktivity. IPS se většinou nasazujemezi síťové prvky a tvoří transparentní, tzv. inline, prvek, který provádí kontroluveškerého provozu mezi dvěma síťovými zařízeními. Detekce pak probíhá na základěpravidel, která definují vzor chování. V případě anomálie je prvek schopen zasáh-nout, a to prostřednictvím blokace určitého provozu.

Na trhu pak existuje několik řešení IDS/IPS. Placená, která poskytují napří-klad společnosti HPE, či Cisco Systems Inc., dosahují výborných výsledků (Wilkins,2015), avšak jejich cena je někdy až astronomicky vysoká. Dostupných je však tak-též mnoho řešení, která jsou poskytována zdarma či pod licencí open source. Jejichpopis je uveden níže.

Snort Společnost Sourcefire, která Snort poskytuje, je v současnosti vlastněna spo-lečností Cisco Systems (Snort, 2017). Tento produkt však lze využívat s menšímiomezeními zdarma po registraci. Nabízí také placenou verzi, která obsahuje prio-ritní podporu a především rychlejší dostupnost obrany proti novým hrozbám (Snort,2017). Pro správu aplikace je možné využít například front-end Snorby.

Suricata Software je vyvíjen společností OISF (Open Information Security Foun-dation) a je poskytován jako open source. Ke dni 20. 2. 2017 není nabízen žádnýprogram, který by umožňoval objednání placené podpory či jiných dodatkových slu-žeb. Suricata používá stejnou množinu pravidel jako Snort, je tedy možné použítstejná pravidla.

Bro Na rozdíl od předchozích dvou řešení, která využívají metodu detekce na zá-kladě podobností či pravidel, Bro se zaměřuje na analýzou řízený model, kdy analy-zuje data jako celek. První podpora IPv6 pak byla v dokumentaci zmíněna ve verzi0.17-8 (Bro, 2014).

Testování podpory IPv6 ve všech těchto aplikací prováděl Allen (2015). Výsled-kem jeho analýzy bylo, že všechny tyto aplikace jsou schopny pracovat s provozemIPv6. Veřejně dostupných je však velice málo pravidel, která by s tímto protokolempracovala. To na jedné straně může být dáno menším počtem známých útoků. Jeale možné, že některé z útoků pouze nejsou do databáze pravidel zapracovány.

Dle zjištění Allena (2015) zvládá Snort i Suricata pracovat s IPv6 bez problémů.Jejich úspěšnost detekce útoků je pak dle něj srovnatelná s detekcí podobných útokůna IPv4. Schopnost zpracovat výsledky však zatím na takové úrovni, jako v případěIPv4, není.

3.6 ACL 22

3.6 ACL

Seznamy pro řízení přístupu (access control listy), slouží k definici oprávnění propřístup k určitým zdrojům. V případě síťových služeb pak především ke službámposkytovanými, či využívanými klienty. V případě požadavku paketu na přístupk určitému rozhraní pak dojde nejprve ke kontrole oprávnění a až po poté je dodaného rozhraní vpuštěn či nikoli. V případě ACL nedochází s příchodem protokoluIPv6 k žádným výrazným změnám v logice jejich fungování. Konfigurace se provádíprakticky totožně s tím, jak tomu bylo u protokolu IPv4.

3.7 VPN

Virtuální privátní síť neboli VPN, se využívá pro vzdálený přístup k důvěryhodnésíti pomocí internetu. Po dokončení spojení spolu mohou stanice komunikovat stejně,jako kdyby byly propojeny v rámci jedné sítě. Inicializaci spojení provádí vždy jednaze stran a ověření totožnosti pak probíhá pomocí přístupových údajů či digitálníchcertifikátů. Veškerá komunikace je poté šifrována a spojení tak lze považovat zabezpečné. VPN dělíme na dva typy dle způsobu připojení.

3.7.1 Vzdálený přístup (remote access)

Vzdálený přístup se využívá v případě, že požadujeme zapojení koncové stanice dosítě, obvykle korporátní. Výhodou tohoto spojení je především přístup k lokálnímzdrojům a zajištění bezpečnosti pro takto komunikujícího klienta, viz obr. 4.

Obrázek 4: Topologický diagram remote access VPN

Obrázek 5: Topologický diagram site-to-site VPN

3.8 Zabezpečení na úrovni ASW 23

3.7.2 Propojení sítí (site to site)

Tento způsob konfigurace VPN se pak využívá především tam, kde je nutné kevzdálené síti zapojit více klientů umístěných v celé síti. Obvykle se jedná napříklado detašovaná pracoviště, která potřebují disponovat přístupem ke zdrojům v centrálea jedinou možností jejich propojení je využití sítě internet, viz obr. 5.

3.8 Zabezpečení na úrovni ASW

IPV6 RA Guard Funkce umožňující blokovat ohlášení routeru (router advertis-ment, RA), která jsou doručena na rozhraní nepatřící portu připojenému k výchozíbráně. Dle Cisca (2012) tato ohlášení slouží k nastavení výchozí brány koncovýchzařízení, jejich nastavení na jinou adresu by tak mohlo způsobit nedostupnost připo-jení, případně by mohlo dojít k odposlechu komunikace. Funkce RA Guard ohlášenírouteru analyzuje a filtruje dle nastavení tak, aby nebyla distribuována ta, kterájsou zasílána neautorizovanými zařízeními.

IPv6 Snooping Těžištěm v oblasti přístupové bezpečnosti IPv6 na zařízeních Ciscoje funkce IPv6 Snooping. Dle Wernyho (2011) se nejedná přímo o bezpečnostnífunkci, ale o prerekvizitu k jejich nasazení. Prvek se zapnutou funkcí IPv6 Snoopingvytváří tabulku IPv6 sousedů vytvořenou pomocí NDP (neighbor) či DHCPv6. Tatodatabáze je pak použita FHS (first hop security) funkcemi, které ověřují platnostpřipojených LLA (link layer address) a umožňují tak zamezit falšování adres (spoo-fing) či odposlouchávání (redirect). Příklad výpisu na síťových prvcích výrobce Ciscoje uveden níže.

Router# show ipv6 neighbor binding

address DB has 4 entriesCodes: L - Local, S - Static, ND - Neighbor DiscoveryPreflevel (prlvl) values:1:Not secure 2:MAC and LLA match 3:Cga authenticated4:Dhcp assigned 5:Cert authenticated 6:Cga and Cert auth7:Trusted port 8:Statically assigned

IPv6 address Link-Layer addr Interface vlan prlvl age state Time leftND FE80::A8BB:CCFF:FE01:F500 AABB.CC01.F500 Et0/0 100 0002 0 REACHABLE 8850L FE80::21D:71FF:FE99:4900 001D.7199.4900 Vl100 100 0080 7203 DOWN N/AND 2001:600::1 AABB.CC01.F500 Et0/0 100 0003 0 REACHABLE 3181ND 2001:300::1 AABB.CC01.F500 Et0/0 100 0007 0 REACHABLE 9559ND 2001:100::2 AABB.CC01.F600 Et1/0 200 0002 0 REACHABLE 9196L 2001:400::1 001D.7199.4900 Vl100 100 0080 7188 DOWN N/AS 2001:500::1 000A.000B.000C Fa4/13 300 0080 8676 STALE N/A

Funkce, které sdružuje, jsou uvedeny v následujícím seznamu a jejich popis tak,jak jej uvádí Cisco (2014), níže.

• IPv6 ND (Neighbor Discovery) Inspecion

• IPv6 Device Tracking

3.8 Zabezpečení na úrovni ASW 24

– IPv6 First-Hop Security Binding Table

– IPv6 Device Tracking

• IPv6 Address Glean

IPv6 ND (Neighbor Discovery) Inspection ND Inspection dle Cisca (2012)zjišťuje a udržuje tabulku vazeb pro bezstavovou konfiguraci tak, že analyzuje zprávyzaslané protokolem Neighbor discovery. Zdrojová adresa zprávy ND protokolu jepovažována za důvěryhodnou, pokud je možné v tabulce ověřit vazbu IPv6 a MACadresy. Zprávy, které neodpovídají jsou zahozeny. Výsledkem nasazení této funkcio-nality je zmírnění zranitelností protokolu ND, umožňuje nám totiž například útokyna detekci duplicitních adres, překlad adres či ND Cache.

IPv6 Device Tracking Funkcionalita zajišťující sledování IPv6 klienta tak,aby bylo možné v případě změn okamžitě změnit tabulku sousedů. K tomuto účeluslouží tabulka IPv6 First-Hop Security Binding Table a IPv6 Device Tracking.

IPv6 First-Hop Security Binding Table Tabulka a její režim zotaveníumožňuje tabulce vazeb obnovit záznam o zařízení v případě, že došlo k jeho re-startu. Není tak třeba žádat o nové přidělení adresace.

IPv6 Device Tracking Sledování zařízení je dle Cisca (2012) funkce, kteráumožní sledování, zda zařízení, které je připojené k přístupovému prvku, je stáleaktivní. V případě, že se jeho stav změní, pak dojde k okamžité změně tabulkyvazeb na daném prvku.

IPv6 Address Glean Address Glean je základem pro mnoho IPv6 funkcí,jejichž cílem je korektní udržování tabulky vazeb.

DHCPv6 Guard Další funkcionalitou, která má opodstatnění pro nasazení v rámcisítě MENDELU2, je funkce DHCPv6 Guard. Ta zajišťuje blokaci odpovědi DHCPv6serveru z portu, ke kterému je připojen neautorizovaný DHCP server či relay agent.

IPv6 Source Guard a Prefix Guard Obě tyto funkce zajišťují validaci zdroje IPv6provozu na vrstvě L2. IPv6 Source Guard zajišťuje blokaci provozu z neznáméhozdroje, tedy například zdroje, který dosud není naučen v binding tabulce prostřed-nictvím detekce sousedů (ND) či DHCP sběru (gleaningu). IPv6 Prefix Guard pakkontroluje použitý prefix u připojených klientů tak, aby nedocházelo k pokusůmo komunikaci mimo povolený rozsah.

IPv6 Destination Guard Tato funkce, společně s IPv6 ND, slouží k zajištěnípřekladu adres pouze pro ty adresy, které jsou aktivní na síťovém rozhraní. V kom-binaci s IPv6 Address Glean, která zajišťuje aktualizace v binding tabulce, se pakstará o blokaci překladu, jejichž cíl v této tabulce není uveden.

2MENDELU – Mendelova univerzita v Brně

3.9 Sledování provozu 25

3.9 Sledování provozu

Sledování provozu v rámci sítě lze provádět mnoha způsoby. Jedním ze způsobů jemonitoring pomocí tzv. NetFlow, kdy jsou do sítě nasazeny tzv. exportéry flow. Tyzpracovávají provoz tím způsobem, že z něj vyřezávají pouze hlavičky a zasílají jedo kolektoru. Ten je většinou jejich centrálním úložištěm a především nástrojem,kterým lze do zaznamenaného provozu nahlížet. Exportérem flow pak může býtserver, směrovač, L3 přepínač či jiný prvek, který umožňuje zasílat NetFlow dokolektoru. Ukázka topologie s NetFlow sondou a kolektorem je na obr. 6.

Obrázek 6: Topologický diagram zapojení NetFlow do sítě

Největší výhodou monitoringu pomocí NetFlow je možnost provádět nad po-sbíranými daty statistiky, výběry dat, ale i dohledávat síťový provoz jednotlivýchuživatelů. Jedná se tak o mocný nástroj, který by v žádné síti, ať už IPv4 neboIPv6, neměl chybět.

3.10 Proxy

Proxy server je zařízení, které se chová jako prostředník mezi klientem a cílovým ser-verem. V rámci jeho funkce požadavky překládá a oproti cílovému serveru vystupujesám jako klient. Proxy servery dělíme na dopředné a reverzní.

3.10.1 Dopředné proxy

Jedná se o proxy, která je přístupná pro zařízení z určité sítě a běžně slouží k tomu,aby klient byl schopen přistoupit ke službám, které z jeho vlastní sítě nejsou do-stupné. Proxy jsou také v některých případech využívány v případě, kdy klient ne-chce, aby byl zpětně dohledatelný. Ačkoli v mnoha případech tomu tak není, pokuddojde k řetězení proxy serverů, je šance na jeho dohledání minimální.

3.11 AAA služby 26

3.10.2 Reverzní proxy

Reverzní proxy je server, prostřednictvím něhož je možné poskytovat služby jinýchserverů bez toho, aby o tom klient věděl, viz obr. 7. Tento způsob konfigurace mánesporný počet výhod. Mezi ně patří především:

• Bezpečnost - Proxy server je další vrstvou mezi případným útočníkem a jeho cí-lem. Většina útoků je však prováděna přímo na službu jako takovou, a tak nelzeproxy server považovat za řešení, které by mohlo nahradit ostatní bezpečnostnímechanismy.

• SSL akcelerátor - Z pohledu hardwarové náročnosti je SSL šifrování poměrněnáročné. Pokud tak chceme tuto zátěž rozdělit mezi více serverů, je vhodnévyužít proxy server, který disponuje SSL akceleračním hardwarem.

• Load balancing - pomocí proxy serveru lze příchozí požadavky rozdělovat mezivíce strojů poskytujících stejnou službu. Klienti tak budou směrováni dle aktu-álních potřeb správců služby.

• Cache - využívání mezipaměti je výhodné především v případě, že klienti přistu-pují ke stále stejnému obsahu. Proxy server tak vytvoří jeho dočasnou kopii,kterou následně distribuuje klientům bez toho, aby o obsah žádal server, kterýjej poskytuje.

Obrázek 7: Ukázka nasazení reverzní proxy do sítě

Proxy server je v případě správného použití poměrně silným nástrojem, kterýlze v síti využít. Nic se pak na jeho využití nemění ani s příchodem IPv6 adres.

3.11 AAA služby

AAA označujeme služby, které obsluhují autentizační, autorizační a účtovací proto-kol. Ve zkratce se jedná o služby, které pro potřeby dalších aplikací zajišťují ověřeníuživatele, tzv. autentizaci, a na základě prokázání jeho identity pak udělují specifickýtyp služby (oprávnění) k této službě, což nazýváme autorizací. K AAA protokolůmpak řadíme například:

• TACACS,

3.12 Webové služby 27

• TACACS+,

• RADIUS,

• DIAMETER.

3.12 Webové služby

Webové služby představují skupinu technologií, které umožňují efektivní komunikacinapříč internetem. Mezi tyto technologie mohou patřit webové prohlížeče představu-jící uživatelské prostředí pro přístup k webu, webové servery reagující na požadavkyprohlížečů, značkovací a programovací jazyky pro tvorbu webového obsahu, FTPprotokol (File Transfer Protocol) určený pro přenos a sdílení souborů a předevšímHTTP protokol.

Klíčovým prvkem webových služeb je HTTP protokol (HyperText Transfer Pro-tocol). Jedná se o aplikační protokol pracující nad infrastrukturou TCP/IP. Protokoltypu klient/server - komunikace probíhá ve formě požadavků a následné odpovědi.Tato komunikace je realizována pomocí HTTP požadavků. Webový prohlížeč běžněvyužívá HTTP požadavky GET (dotazovací metoda) a POST (odesílání informacína server). Odpovědi získává ve tvaru třímístného kódu. Ty jsou dále rozděleny doněkolika skupin (informační - 1xx, úspěšné volání - 2xx, chyba serveru - 5xx, kli-enta - 4xx atd.). HTTP není vhodný pro přenášení citlivých informací, proto byltento protokol doplněn o SSL vrstvu (Secure Socket Layer), která zajišťuje šifrovánípřenášených dat. Takový protokol nazýváme jako HTTPS.

Všechny tyto protokoly HTTP, HTTPS, FTP jsou v IPv6 protokolu podporo-vány s drobnými odlišnostmi oproti IPv4 zapříčiněné především chybějícím masiv-ním využití IPv6.

3.13 Poštovní služby

Poštovní služby zajišťují přenos e-mailové komunikace mezi poštovními servery. Ač-koli pro koncového uživatele se jedná o velice jednoduchou službu k využívání, z po-hledu administrátora jde o poměrně komplikovaný proces.

Pro pochopení fungování služby je nutné nejprve popsat základní komponentycelého procesu zasílání e-mailů.

MUA (Mail User Agent) Poštovní program, pomocí něhož uživatel odesíláe-mailovou komunikaci. Tím může být například program Outlook, Thunderbird,ale také klient ve webovém rozhraní, např. RoudCube.

MTA (Mail Transfer Agent) Mailový server, který se stará o přeposlání e-mailovézprávy až k cíli. Komunikace mezi MTA servery probíhá pomocí protokolu SMTP,či SMTPS, tedy na port 25, 465 nebo 587 a ačkoli většina služeb implementujekomunikaci prostřednictvím protokolu TCP, dle RFC821, RFC2821 a RFC5321,

3.14 Databázové služby 28

je použitý komunikační kanál nezávislý. Komunikace tedy může probíhat i pomocíUDP.

MDA (Mail Delivery Agent) Jedná se o server obsahující poštovní schránky. Popřijetí e-mailové komunikace provede její uložení do poštovní schránky příjemce,který k ní poté může přistoupit pomocí MUA.

Komunikace probíhá z klientského zařízení obsahujícího MUA pomocí MTA ažk doručení e-mailu k MDA. Jakmile je zpráva doručena, klient k ní může přistoupitopět pomocí aplikace MUA. K tomuto účelu však již využívá protokol IMAP čiPOP3, viz obr. 8.

Obrázek 8: Ukázka přenosu mailové zprávy

K tomu, aby komunikace mezi mailovými servery probíhala korektně, je nutnékonfigurovat také DNS server, a to z důvodů správné identifikace serverů. Jednáse především o záznamy MX. Z důvodů bezpečnostních mechanismů je pak vhodnéimplementovat i PTR a SPF záznamy. Vyčerpávající popis implementace mailovýchserverů pak uvádí Dent (2004).

3.14 Databázové služby

Databázové služby zajišťují přístup k uloženým záznamům pro aplikace, které běžína rozdílných stanicích, avšak potřebují přistoupit k datům uloženým v databázina vzdáleném stroji. Z pohledu síťové infrastruktury se jedná o běžné aplikačnívybavení, které využívá síťové zdroje.

3.15 Časové služby

Časové služby zajišťují v synchronizaci času mezi stanicemi připojenými do inter-netu. Cílem je pak disponovat stejným časem na všech strojích, především serverech.Některé ze služeb totiž kontrolují čas mezi dvěma komunikujícími stroji a v případěvětšího časového rozdílu spolu odmítnou komunikovat. Tento problém se vyskytujepředevším u strojů s operačním systémem Windows, se kterými se, v případě špat-ného nastavení času, odmítá spojit doménový řadič.

3.16 Zálohovací služby 29

3.16 Zálohovací služby

Zálohovací služby by měly být základní komponentou každé sítě, která obsahuje doní připojené zařízení. Zálohování kritických služeb pro provoz infrastruktury je všaknaprosto zásadní. Z pohledu serverové infrastruktury lze zálohování dělit do dvouhlavních kategorií popsaných níže.

Zálohování stroje Zálohování celého stroje se provádí především ve virtualizova-ném prostředí, a to buď pomocí funkce snapshot, nebo pomocí zálohy celého strojejako celku. Výhodou je pak zálohování oběma způsoby, jelikož každý z nich je vý-hodnější použít v jiné situaci.

Zálohování konfigurace služby V případě, že je zálohována konfigurace, je možnéji v případě problémů přesunout na jiný stroj, který disponuje stejnou verzí danéslužby. Konfigurační soubory jsou v případě linuxových serverů uloženy v textovémformátu a lze je tak zálohovat poměrně snadno například pomocí programu rdiff-backup. Výhodou je pak, oproti zálohování celého stroje, nízká datová náročnost.Je tak možné provádět zálohy častěji a v případě nutnosti obnovy celého stroje pakdo dané služby obnovit aktuální verzi konfigurace.

3.17 VoIP

VoIP je komunikační protokol využívaný pro hlasovou komunikaci mezi dvěma tele-fonními zařízeními. Pro přenos komunikace se používá protokol UDP, kdy v každémz datagramů se pak přenáší malý úsek telefonního hovoru. Výhodou je implementaceQoS3, díky které nejsou telefonní hovory v rámci sítě omezovány jiným provozem.V současnosti se nejvíce používá protokol SIP, který popisuje RFC3216.

3.18 Virtualizace

Implementace virtualizace v rámci sítě přináší řadu výhod. Tou hlavní je pak přede-vším možnost použití HA4 funkcí. Ty zajišťují vysokou dostupnost díky schopnostiprovozovat virtualizované stroje na několika hypervizorech a případně i datovýchpolích současně.

Důležité je správně navrhnout infrastrukturu, která bude poskytovat dosta-tečný prostor pro implementaci HA. Základní komponentou je však redundance.Topologie musí obsahovat minimálně dva prvky sloužící stejnému účelu. Kompletněredundantní topologie, na které by bylo možné nasadit všechny funkce HA v plnémrozsahu by mohla vypadat například tak, jak je uvedeno na obr. 9.

Dalšími výhodami virtualizace pak jsou:

3Quality of Service – technologie umožňující prioritizovat určitý typ provozu v síti4HA – High Availability

3.19 WiFi 30

Obrázek 9: Ukázka redundatní topologie umožňující implementaci funkcí HA

• úspora hardwarového vybavení a energie,

• konsolidace diskového prostoru,

• zjednodušení správy.

Virtualizace je tak důležitou součástí serverové infrastruktury, může totiž nejenvýrazně pomoci v případě výpadků některého z fyzických zařízení, ale předevšímumožňuje správcům lépe efektivněji nakládat s přidělenými prostředky.

3.19 WiFi

Bezdrátové sítě jsou nedílnou součástí každé moderní sítě. Přenos dat je implemen-tován dle standardu 802.11, který se stále rozšiřuje. V současnosti je tak na většinězařízení implementován protokol 802.11ac, který nabízí teoretickou propustnost až1,3 Gbps (Aruba, 2015) díky podpoře MU-MIMO5. Dle topologie pak WiFi sítědělíme na:

Ad-hoc Topologie kdy spolu stanice komunikují bez použití centrálního prvku. Vevysílání řídícího rámce se střídají.

Basic Service Set (BSS) Jedná se o síť, kdy je řízení sítě zajišťováno přes centrálníprvek, tzv. přístupový bod, který také obsluhuje komunikaci do drátové sítě.

Extended Service Set (ESS) V rámci této topologie dochází ke spolupráci jednohoči více centrálních přístupových bodů sdílejících stejný název sítě (SSID). Pokud jsoupřístupové body dostatečně blízko, pak lze mezi nimi roamovat, tedy přecházet bezvýpadku spojení. V případě roamingu pak rozlišujeme tzv. L2 roaming, kdy docházík přechodu v rámci jedné IP sítě, a L3 roaming, kdy je klient nucen získat novou IPadresu.5MU-MIMO – Víceuživatelské využití více vstupů a více výstupů

3.20 Správa koncových stanic 31

Zabezpečení se u rozsáhlejších sítí obvykle implementuje pomocí autentizačníhoserveru, který ověřuje uživatele na základě EAP-TLS (certifikát) či PEAP (přístu-pové údaje). Ověření pak probíhá tak, jak je znázorněno na obr. 10.

Obrázek 10: Postup EAP autentizace bezdrátového klienta oproti autentizačnímuserveru

3.20 Správa koncových stanic

Provádění správy koncových stanic je z pohledu jejich správce poměrně kompliko-vaná činnost, která vyžaduje nejen dokonalou znalost problematiky, ale předevšímpřípravu a nekončící testování. Pro správu koncových stanic je však k dispozicimnoho softwaru, který tuto práci dokáže zjednodušit. Jedná se například o pro-dukty:

• System Center Configuration Manager,

• opsi.org,

• Kaspersky Endpoint Security 10 for Windows,

• Silveo Pulse.

Existuje však mnoho dalších produktů, které nabízí možnost kompletní správykoncových stanic. Obvykle pak zvládají minimálně níže uvedené funkce:

• vzdálené nasazení operačního systému,

• možnost vzdáleně instalovat nové aplikace a aktualizovat stávající,

• disponovat kontrolou nad aktualizacemi operačního systému,

• vzdálené spouštění skriptů na více stanicích v jednom čase,

• monitoring stavu koncových stanic.

3.21 Vícekriteriální hodnocení variant 32

V případě nasazení systému pro správu koncových stanic se tak značně ulehčíjejich správa. Jejich bezproblémový a především zabezpečený běh je však spojens nutností jejich kontinuální aktualizace, což vyžaduje nejen mnoho testování, alepředevším řešení problémů se stávajícím aplikačním vybavením.

3.21 Vícekriteriální hodnocení variant

Vícekriteriální hodnocení variant Šmerek (2014) definuje ve své práci takto:

p variant X1, X2, ..., Xp je hodnoceno podle k kritérií A1, A2, ..., Ak.

Následně tato hodnocení tvoří tzv. kriteriální matici:

Y = (Yij), kde prvek Yij značí ohodnocení varianty Xi, dle kritéria Aj,i = 1, 2, ..., p, j = 1, 2, ..., k.

Dalším krokem je vytvořit kriteriální matici v normalizovaném stavu pomocí vztahuR = (rij). Následně jsou kritéria maximalizační či minimalizační, převod minimali-začních na maximalizační se provádí vyjádřením úspor oproti nejhorší variantě.

y′ij = maxi(yij)− yij, i = 1, 2, ..., p, j = 1, 2, ...k.

Kriteriální maticeY ′ = (y′ij) poté obsahuje všechna kritéria maximalizačního typu.Sloupce obsahují hodnoty v různých jednotkách, a tedy neporovnatelné. Zavádí seproto tzv. normalizovaná kriteriální matice R s prvky:

rij =yij−djhj−dj , i = 1, 2, ..., p, j = 1, 2, ...k, kde dj = mini(yij) a hj = maxi(yij))

Matice R = (rij) již disponuje prvky, které jsou bezrozměrnými čísly z intervalu< 0, 1 >. To znamená, že hodnoty, které obsahuje, jsou navzájem porovnatelné a lzena jejich základě provést rozhodnutí o výběru dané varianty.

4 ANALÝZA SOUČASNÉHO STAVU A POŽADAVKŮ 33

4 Analýza současného stavu a požadavků

V rámci této kapitoly bylo analyzováno stávající řešení univerzitní sítě MENDELU.Informace, které jsou v této práci uvedeny, byly poskytnuty na základě ústní dohodyv rámci pracovního úvazku autora na Ústavu informačních technologii Mendelovyuniverzity v Brně. Informace, které jsou v této práci uvedeny odpovídají skutečnosti,některé z nich však mohou být záměrně zamlčeny či pozměněny tak, aby nedošlok jejich vyzrazení, avšak jejich vynechání nemá podstatný vliv na podstatu tétopráce.

4.1 Metodika analýzy

Metodika této práce sestává z dekompozice sítě na jednotlivé služby, které jsou projejí správnou funkci vyžadovány. Kapitola 4.6 pak zahrnuje přehled těchto služebvčetně rozboru podpory protokolu IPv6. Účelem tohoto přehledu je stanovit mož-nosti konfigurace, které budou prezentovány v kapitole Návrh řešení, viz kap. 5.V případě, že aplikace nebude kompatibilní s protokolem IPv6, či daná verze ne-bude splňovat požadavky na její podporu, pak bude navrženo řešení odpovídajícípožadavkům zadavatele.

Konfigurace v kapitole 5 bude tam, kde je to výhodné, v maximální možné mířekopírovat stávající funkcionalitu. Pokud se stávající řešení ukáže jako nevýhodné,pak bude nový návrh řešení vždy předem konzultován s vedením ÚIT6 MENDELU.

4.2 Obdobná řešení implementace IPv6 na jiných VŠ

Srovnání s jinými vysokými školami by mělo být přínosem především z pohleduinspirace metodikou přístupu, způsobem nasazení a hlavně konfigurací zabezpečení.Návrh implementace je pak nutné upravit přímo na míru síti MENDELU, jelikož sejedná o unikátní, poměrně rozsáhlou, topologii.

Přidělené globální směrovací IPv6 prefixy Vysoké školy, které jsou zapojeny dosítě sdružení CESNET, mají k dispozici poměrně velké množství IPv6 adres, kteréjim byly přiděleny od regionálního internetového registru RIPE. Přesné rozsahy jsoupak ověřitelné v databázi RIPE (2017). Z ní je například viditelné, že Masarykovauniverzita disponuje rozsahy 2a00:5800::/32, 2001:718:80a::/48, 2001:718:805::/48,2001:718:801::/48 a dalšími třemi rozsahy s prefixem /64. Vysoká škola báňská -Technická univerzita Ostrava pak dle databáze přidělených prefixů disponuje ad-resními bloky 2001:718:1003::/48, 2001:718:1001::/48, 2001:718:1007::/48 a čtyřmibloky s prefixem /64. Naopak Veterinární a farmaceutická univerzita Brno nedispo-nuje ani přiděleným prefixem, IPv6 tak velice pravděpodobně v rámci univerzitnísítě neimplementují vůbec.

6Ústav Informačních Technologií je ústavem spravující síťovou infrastrukturu MENDELU a jetaké zadavatelem tématu této práce.

4.2 Obdobná řešení implementace IPv6 na jiných VŠ 34

Lokality a adresace koncových sítí Každá univerzita přistoupila k adresaci sítíjinak. Některé ze zkoumaných univerzit využívají dělení na lokality, a to Vysokáškola báňská – Technická univerzita Ostrava (Pustka, 2010), Západočeská univer-zita v Plzni (Kostěnec, 2010), Vysoké učení technické v Brně (Lampa, 2009) a da-lší. Naopak Slezská univerzita v Opavě přiděluje jednotlivým koncovým sítí prefixyo délce 64 bitů (Macura, 2010). Univerzity, které adresují koncové sítě na základěrozdělaní lokalit pak nejčastěji využívají prefix /64, výjimkou je však České vysokéučení technické v Praze využívající prefixy o délce 56 bitů (Vaněk, 2010).

Konfigurace síťových služeb a bezpečnost Ve veřejně dostupných zdrojích lzenalézt informace, které mohou přiblížit stav IPv6 v rámci jednotlivých univerzit.

Pustka (2010) uváděl, že v rámci nasazení IPv6 na Vysoké škole báňské uva-žují do budoucna nad nasazením IPS, kterou v té době nepoužívali, dále uvádělže nedisponují pokročilým monitoringem na IPv6, ani přidělováním IPv6 adres po-mocí DHCP. V roce 2016 Pustka prezentoval aktuální informace o stavu sítě VŠB.Zde poskytl informaci, že pro adresaci klientů využívají automatickou konfiguraci,přidělování statických IPv6 adres klientů pak označil za problematické. Zpětnouidentifikaci uživatelů řeší pomocí automatizovaného sběru dat z NDP tabulek, kterépárují s lokální databází fyzických adres. Podobnou metodou dle Pustky provádíidentifikaci i Vysoké učení technické v Brně, kde taktéž mají IPv6 protokol na síťo-vých prvcích implementován. V případě sítí, kde nelze tímto způsobem kontroluprovádět z důvodů neznalosti zařízení, například v síti eduroam, využívají autenti-začního serveru, který po ověření dokáže párovat IPv6 adresu a přihlašovací údaje.

Vaněk (2016) z Českého vysokého učení technického v Praze pak informovalo aktuálním stavu v jednom z oddělených pracovišť. Uvádí, že některé služby pro-vozují v rámci budovy výhradně pomocí protokolu IPv6. Naopak zmiňuje některázařízení a služby, která IPv6 konfiguraci nepodporují. Pro monitoring používají ko-merční software Scrutinizer, který jej zajišťuje pomocí Netflow. Dle Vaňka takév minulosti neimplementovali firewall, nyní však již evidují poměrně vysoký podílIPv6 útoků (sto útoků na IPv4 odpovídá přibližně jednomu útoku na IPv6), imple-mentace IPv6 firewallu tak pro ně byla nutností.

Macura (2010), jehož publikace pojednává o IPv6 na Slezské univerzitě v Opavě,pak bezpečností funkce nezmiňuje a zaměřuje se pouze na snahu o základní imple-mentaci IPv6 tak, aby bylo možné poskytovat základní služby. Dle Kostěnce (2010)pak na ZČU v Plzni zbývá vyřešit pouze kompatibilitu monitoringu a firewallu, dleplánů by již k dnešnímu dni měla být tato IPv6 síť plně funkční.

Topologický návrh sítě či přehled bezpečnostních prvků jednotlivé vysoké školy,s ohledem na možnou zranitelnost, nezveřejňují. Všechny výše jmenované univerzityse myšlenkou IPv6, a především jejím nasazením, zabývaly již před několika lety. Tovšak ale neznamená, že by jejich implementace IPv6 byla v současnosti na úrovniprotokolu IPv4. Verifikace poskytovaných služeb proběhla pomocí služby chair6.net.Zde bylo otestováno několik vysokých škol v České republice. Výsledky testování jsoupak uvedeny v tab. 1.

4.3 Geografické dělení univerzitní sítě 35

Tabulka 1: Přehled spuštěných služeb na vybraných vysokých školách v České republice

VŠ AAAA záznam konektivita IPv6 MX záznamVŠB ANO ANO -MUNI ANO ANO -VFU - - ANOCVUT - - -MEDNELU - - -

Z testů uvedených v tab. 1 je viditelné, že ačkoli většina škol již s implementacíIPv6 začala, jejich současný stav není kompletní. Vysoká škola báňská a Masarykovauniverzita disponují webovou prezentací dostupnou pomocí IPv6. Jedinou univerzi-tou, která má dostupné MX záznamy pomocí IPv6, je pak Veterinární a farmaceu-tická univerzita Brno, a to z toho důvodu, že jejich poštovní služby jsou spravoványsdružením CESNET.

Na základě výše uvedených informací lze předpokládat, že většina českých uni-verzit je s nasazením protokolu IPv6 dále, než je v současnosti Mendelova univerzitav Brně. S ohledem na toto zjištění by bylo více než vhodné implementaci IPv6 urych-lit, a to minimálně na úrovni služeb poskytovaných do internetu.

4.3 Geografické dělení univerzitní sítě

V současnosti univerzita eviduje mnoho odloučených pracovišť. Ta jsou ke kampu-sové síti připojena pomocí L3 (GRE, IPsec) či L2 (MPLS) tunelů. V diplomovépráci Ing. Tomáše Filipa se s jejich přechodem na IPv6 nepočítalo, avšak vzhledemk tomu, že rozbor služeb bude tunely taktéž zahrnovat, je vhodné jejich existencizmínit.

Jediné odloučené pracoviště MENDELU, které nelze považovat z hlediska jehozapojení za součást kampusové sítě a jehož správa spadá pod ÚIT, jsou koleje JosefaTaufera.

Dalšími odloučenými pracovišti, jejichž správu si však zajišťují tyto samostatnécelky, které však spadají pod MENDELU, jsou zejména Zahradnická fakulta v Led-nici, Zlín, Žabčice, Křtiny, Útěchov a Karlov.

4.4 Adresní prostor

V současné síti jsou všechna zařízení adresována pomocí IPv4. Celkem je evidovánopřibližně 260 VLAN, z nichž je přibližně třetina adresována veřejnými adresami.Zbytek zařízení je pak za pomocí překladu adresován privátními adresami. S přícho-dem stále nových zařízení jsou některé bloky veřejných adres nahrazovány privátnímitak, aby došlo k uvolnění veřejných adres pro jejich nasazení na potřebných místech.

4.5 Adresace koncových zařízení 36

Rozvržení adresního prostoru včetně směrování navrhl pro účely nasazení IPv6na Mendelově univerzitě v Brně Ing. Tomáš Filip v rámci diplomové práce. Autorse rozhodl pro návrh pomocí přechodové metody dual stack, tedy řešení, kdy prvekv jednom čase disponuje adresami IPv4 i IPv6. Návrh adresace i směrování je takúzce provázán se stávajícím řešením. To umožňuje především beze změn vyžívatstávající služby Adresní plán Filipa (2015) je vytvořen tak, aby bylo možné adresyjednoduše sumarizovat a především snadně identifikovat VLAN. Základní principrozdělení globálního směrovacího prefixu IPv6 dle Filipa (2015) je znázorněn naobr. 11.

Obrázek 11: Adresní plán IPv6 univerzitní sítě MENDELU dle Filipa (2015)

4.5 Adresace koncových zařízení

Jak je uvedeno výše, současná síť, využívající protokol IP verze 4, adresuje většinuzařízení pomocí privátních adres. Zařízení ale nejsou přímo dostupná z internetu.Možnost adresovat všechna zařízení globálně unikátními adresami tak přinese zjed-nodušení nejen pro správce, ale i pro koncové uživatele. Spolu s výhodami ale tatomožnost přináší i zvýšené nároky na bezpečnost. Tu lze ve většině případů zajistitpomocí firewallu, konfigurace však bude oproti stávajícímu řešení rozsáhlejší.

Adresaci koncových zařízení ve své závěrečné práci navrhla Bc. Barbora Chumle-nová. Dle ní není možné, z důvodů chybějící implementace výrobců, využít standarddefinovaný v RFC6106 (2010) který by umožnil kompletní adresaci klientů tak, jakto umožňuje standardní DHCP. Navrhla proto kombinace řešení adresace, které za-jistí kompletní adresaci zajišťující klientům možnost komunikace s internetem včetněpřekladu doménových jmen (DNS).

4.6 Služby a bezpečnostní funkce 37

Microsoft implementaci RFC6106 (2010) dle Horleyho (2014) odmítl z důvodu,že adresace patří do jiné síťové vrstvy než překlad adres. Snaží se tak vyvarovatproblémům, které by případným mixováním těchto vrstev mohly vzniknout.

Bezstavový DHCPv6 Za problém tohoto řešení považuje Chumlenová vytvořeníidentifikátoru EUI-64, který navrhuje vynutit pomocí funkce IPv6 PACL. Výsled-kem jejího nasazení je pak vynucení identifikace klienta předem nakonfigurovanouadresou. Dále navrhla použití funkce IPv6 Source Guard na přístupových přepína-čích tak, aby zajistila požadavek Ústavu informačních technologií, který vyžadovalmožnost důvěryhodné identifikace zařízení dle jeho IP adresy. Za nevýhodu všakoznačuje to, že obě funkcionality jsou pro přístupové přepínače Cat2960 dostupnéaž od verze IOS 15.0(2) a pozdější (Cisco, 2015). Problémem jsou především dosudpoužívané přepínače Cat2950, které jsou dle Palucha (2015) již v režimu ukončenéhoprodeje a možnost update na IOS 15.0(2) není očekávaná.

Jako další způsob, který by zajišťoval vynucení EUI-64, označuje Chumlenovámožnost konfigurace na firewallu. Tato metoda se však nejeví jako příliš bezpečnáz důvodů chybějící kontroly zdrojových adres na přístupových portech. To by mohlovést k jejich podvržení v rámci jednotlivých adresních bloků.

Stavový DHCPv6 Zde navrhuje Chumlenová využít identifikátor DUID. Tentoidentifikátor je, jak již bylo zmíněno, unikátní nejen na úrovní hardwaru, ale i z po-hledu použitého operačního systému. Chumlenová tuto skutečnost označuje za ne-výhodu. V prostředí uživatelů, kteří nedisponují dostatečnými informatickými zna-lostmi, se však tato skutečnost může stát výhodou, protože méně zkušení uživateléjiž podvrhnutí tohoto údaje nebudou schopni. Sníží se tak pravděpodobnost zapojenícizího zařízení do sítě. V současnosti je externisty ÚIT vyvíjen systém, který budeschopen automatizovat konfiguraci parametru DUID pro stavový DHCPv6 spolus nastavením funkcí IPv6 Source Guard a PACL. V případě, že toto řešení nebudehotové, navrhuje Chumlenová využití serveru Dibbler (Klib.com.pl, 2015). Modelnávrhu je uveden na obr. 12.

4.6 Služby a bezpečnostní funkce

Univerzitní síť je tvořena mnoha službami, díky kterým se síť stává funkční a jeschopna uživatelům poskytnout podporu pro provozování síťových aplikací. Jedná seo služby jako je například překlad doménových jmen nebo firewall, ale i VPN, kteráposkytuje konektivitu mezi univerzitní sítí a oddělenými pracovišti. Pokud má býtpodpora IPv6 kompletní, všechny tyto aplikace musí protokol IPv6 podporovat a býtnakonfigurované tak, aby mohly uživatelům poskytovat potřebné služby. Aktuálněpoužívané služby v síti MENDELU jsou uvedeny v následujících podsekcích.

4.6 Služby a bezpečnostní funkce 38

Obrázek 12: Model sítě MENDELU se stavovým DHCPv6 dle Chumlenové (2015)

4.6.1 DNS

Překlad doménových jmen v prostředí MENDELU je zajišťován autoritativními ser-very na celkem třech IP adresách verze 4.

Primární služba pro překlad doménových jmen BIND (Berkley Internet NameDomain), kterou MENDELU využívá, je provozována na dvou strojích, z nichž pri-mární je provozován ve virtuálním prostředí VMware, sekundární pak jako fyzickýstroj. Primární server disponuje třemi rozhraními, z nichž jedno slouží pro pro-voz DNS. Toto rozhraní disponuje privátní adresou, která se však pomocí SourceNAT překládá na veřejnou adresu 195.178.72.150. Stejně tak probíhá překlad po-mocí DNAT, kdy paket, jehož cílová adresa je 195.178.72.150, a port vyhovuje na-staveným pravidlům, viz obr. 13. Následně je požadavek směrován na síťové rozhranístroje provozujícího nameserver BIND. Ke dni 17. 2. 2017 je na nasazen nameserverBIND ve verzi 9.9.

Existuje pak také sekundární (ns2.mendelu.cz) a terciální (ns.ces.net) DNS, kamjsou při změně v zónových souborech změny propagovány. Při případném výpadkuobou strojů zajišťujících primární server existují záložní autoritativní servery, kteréjsou schopny přebrat jejich funkci.

4.6 Služby a bezpečnostní funkce 39

Rekurzivní server je umístěn na stejné veřejné IPv4 adrese jako autoritativní,tedy 195.178.72.150. K tomuto serveru jsou směřovány veškeré požadavky z lokálnísítě. Konfigurace tohoto serveru pak využívá tzv. forwardery k tomu, aby pomocírekurze zajistila požadovanou adresu.

Obrázek 13: Topologický diagram zapojení DNS serveru v síti MENDELU

4.6.2 Firewalling

Firewall v současnosti zajišťuje služba iptables verze 1.4. Ta disponuje pravidly, kterájsou nastavována z většiny ručně. Metodika zabezpečení je v současnosti stanovenatak, že v prvním kroku byl veškerý provoz zablokován a poté byly povoleny pouzepakety s jasně definovaným účelem. V současnosti také stroj ukončuje několik sítía provádí kontrolu adres, které tyto sítě opouští.

4.6 Služby a bezpečnostní funkce 40

Prvek zajišťující službu firewall je připojen do VSS7, který je tvořen dvěmazařízeními řady Cisco Catalyst 6500. Prvky disponují oddělenými VRF8 a serverzajišťující firewall je zapojen mezi těmito softwarově oddělenými částmi zařízení.Topologie současného zapojení firewallu je uvedena na obr. 14.

Obrázek 14: Topologický diagram zapojení DNS serveru v síti MENDELU

4.6.3 IDS, IPS

IDS/IPS není v prostředí IPv4 nasazeno. Vzhledem k narůstajícímu počtu hrozeb,z nichž některé mohou být namířeny přímo na IPv6, by však bylo její nasazení prozvýšení úrovně zabezpečení zajisté přínosem.

Vytvořením IDS pro účely MENDELU se zabýval Bc. Aleš Lerch ve své baka-lářské práci Webová aplikace pro analýzu útoku na vybrané servery MENDELU.Tato práce se zabývala detekcí útoků na webové servery. V případě jejího dalšíhovývoje by mohla být vhodnou metodou obrany, která bude nasazena jednotlivýmiadministrátory.

Nasazení IDS/IPS by však mělo pokrývat útoky a hrozby směřující na jakýkoliprvek či službu. Bylo by tak více než vhodné nasadit komplexní řešení pokrýva-jící obranu před útoky na rozlišené služby. Hlavním požadavkem na tento systémpro použití v síťové infrastruktuře MENDELU bude jeho aktuálnost ve smyslu de-finice detekcí nových útoků a především cena, která musí být nastavena tak, abyodpovídala přínosům v síti MENDELU.

4.6.4 ACL

Access control list, tedy seznam pro řízení přístupu, je v síti MENDELU využívánpředevším na prvcích ukončujících sítě VLAN9. Na těchto prvcích je kontrolováno,že danou síť opouští pakety s IP adresami patřící do dané sítě. Konfigurace tohotoomezení je vždy povolována ručně při zřizování sítě, ukázka konfigurace je uvedenana výpisu níže.

7Virtualizační technologie umožňující propojit dva prvky řady Cisco Catalyst 6500 tak, abyvirtuálně tvořily jedeno síťové zařízení.8Technologie umožňující provozování více instancí směrovacích tabulek na jednom zařízení sou-

časně.9Virtuální LAN – logicky nezávislá síť vytvořená pomocí tagování na L2 prvcích

4.6 Služby a bezpečnostní funkce 41

Výjimkou však nejsou ani konfigurace, kde je pomocí ACL celý provoz VLANodříznut od okolních sítí. Tento stav je žádoucí u prvků, které se váží výhradně nalokální využití. Jedná se například o síť BMS (building management system), dokteré patří kamery, uzamykatelné skříňky či jiné prvky svázané s budovami. Dálenapříklad o síť určenou k podpoře zařízení určeného ke sdílení obrazu pro prezentacev aule budovy A. Tyto sítě, využívající pouze lokální komunikaci v současnosti IPv6nepotřebují, využívají totiž ke své komunikaci výhradně lokální síť a nedisponujípřístupem do internetu.

interface VlanXXip access-group SXX in

ip access-list extended SXXpermit ip 195.178.79.0 0.0.0.255 anydeny udp any any log-inputdeny tcp any any log-inputdeny ip any any log-input

Poslední dostupné obrazy pro přepínače Cisco podporují dle Cisca (2016) dvatypy IPv6 ACL.

IPv6 router ACL Tento typ seznamu pro řízení přístupu je dle Cisca (2016) apli-kován na směrovaný odchozí a příchozí provoz na rozhraních 3. vrstvy, což mohoubýt směrované porty, SVI (switch virtual interfaces) či EtherChannely na 3. vrstvě.

IPv6 port ACL Podpora tohoto seznamu je pouze pro příchozí provoz na rozhra-ních 2. vrstvy (Cisco, 2016).

4.6.5 VPN (Virtuální privátní síť)

Tento prostředek určený pro propojení koncových stanic se využívá tam, kde je nutnépropojit důvěryhodné počítačové sítě (site-to-site), či počítačovou síť a koncovoustanici (remote access), prostřednictvím sítě nedůvěryhodné.

V prostředí MENDELU se využívají oba typy VPN. U site-to-site se jedná o de-tašovaná pracoviště. Ta jsou ke kampusové síti připojena pomocí síťových připojení,které univerzita vlastní, případně si je pronajímá. K tomuto účelu se využívá tunelGRE (Generic Routing Encapsulation) vyvinutý společností Cisco Systems (Cisco,2015). Připojení pomocí VPN využívají tyto lokality:

• Koleje Josefa Taufera,

• Detašované pracoviště Lednice.

Přístupem k VPN typu remote access, tedy vzdálenému přístupu, disponujívšichni aktivní zaměstnanci univerzity. Ten se uskutečňuje pomocí tunelu L2TPover IPsec. Dle oprávnění se dále dělí na tři typy přístupu k univerzitním zdrojům.

4.6 Služby a bezpečnostní funkce 42

Plný přístup Tímto typem oprávnění disponují v současné chvíli všichni zaměst-nanci univerzity. Ačkoli je přístup aktuálně dělen na oprávnění vpn-admin a vpn-staff, v obou případech se jedná o přístup k veškerým univerzitním zdrojům, ať užk uživatelské či serverové části. Do budoucna se však plánuje rozdělení oprávněnítak, aby vpn-staff disponoval přístupem pouze k uživatelské části sítě.

Omezený přístup Přístup, který je přidělován studentům disponujícím oprávně-ním vpn-student, má oproti plnému přístupu výrazná omezení. Slouží především kepřipojení síťových úložišť využívaných ve výuce, případně ke přístupu k placenýmzdrojům publikací.

Speciální přístup Tento typ přístupu, vedený pod oprávněním vpn-contractor, bylvytvořen k přidělení oprávnění externím pracovníkům, kteří potřebují disponovatvzdáleným přístupem do univerzitní sítě, ale nedisponují ani jedním z oprávněnízmíněných výše. Tento přístup je přidělován výhradně pro určitý účel dle aktuálníchpotřeb.

K zajištění přístupu se využívá prvek Cisco ASA 5585, který má aktuálně insta-lován operační systém ve verzi 9. Vytvořený tunel pak využívá autentizační metodyMS-CHAP v2, kterou popisuje Microsoft (2017), a která se využívá pro ověřováníL2TP10.

4.6.6 Zabezpečení na úrovni ASW

Zabezpečení přístupové vrstvy je v současném stavu implementováno poměrně ne-systémově. Vzhledem k rozsáhlosti celé sítě a především jejímu postupnému rozšiřo-vání, vytvářeli konfiguraci různí administrátoři. Ti však neměli žádný doporučenýkonfigurační postup, či manuál, podle kterého by postupovali. Výsledkem tak je, žekonfigurace napříč univerzitou jsou velice rozdílné a nelze je jednoduše popsat.

Aktuálně jsou v IPv4 síti na MENDELU implementovány následující bezpeč-ností funkce:

• Port-Security,

• DHCP Snooping,

• Storm control,

• BPDU filter, guard.

Jedná se tak o nemálo funkcí, problémem je však to, že na některých místechnejsou aplikovány v plném rozsahu. S jistotou se tak nedá určit, kde jsou tyto funkceaplikovány.

10L2TP - Layer 2 Tunelling Protocol

4.6 Služby a bezpečnostní funkce 43

4.6.7 Sledování provozu

Sledování provozu, tzv. netflow, je v síti monitorováno za pomocí Flowmon Ko-lektoru. Ten provádí analýzu veškerého provozu odchyceného prostřednictvím sondumístěných v síti MENDELU. Využívá se především v případě potřeby dohledáníkoncového zařízení vykazujícího chybovou, podezřelou činnost, případně k řešeníbezpečnostních incidentů. Flowmon taktéž nabízí systém ADS (Anomaly DetectionSystem), který je řešením pro odhalování anomálií na základě chování v síti. Flow-mon totiž na rozdíl od IDS sleduje celkové chování zařízení v síti. Díky tomu dokážereagovat na poměrně specifické hrozby, které by jiné typy ochrany nebyly schopnédetekovat.

Flowmon v současnosti nabízí plnou podporu IPv6. V případě, že by byla sondanasazena v rámci některého z tunelových mechanismů IPv6, pak by bylo možnovyužít například IPv6 tunnel monitoring plug-in (Gregr, 2012).

Dalším nástrojem, který se v prostředí MENDELU využívá pro sledování pro-vozu je program The Dude. Ten pomocí protokolu SNMP vyčítá hodnoty z prvkův síti MENDELU a vytváří jejich ucelenou mapu, která slouží především k monito-ringu vytížení drátových linek v síti. Podpora IPv6, dle vyjádření podpory MikroTik(Janis, 2016), je plánována, ke dni vyjádření (11. 6. 2016) však nebyl znám termínpředpokládaného vydání verze, která by ji obsahovala.

4.6.8 Proxy

Proxy server, tedy prostředník v komunikaci dvou uzlů, se na MENDELU využívápro vzdálený přístup do interní sítě a přístup ke zdrojům, které jsou z této sítědostupné.

Univerzitní proxy Tuto proxy využívají uživatelé, nedisponující přístupem k uni-verzitní VPN. Jedná se především o studenty, kteří tento přístup využívají propřístup k dalším zdrojům dostupným v rámci univerzitní sítě, jako je napříkladdatabáze Scopus.

Webová proxy Webová stránka eduroam.mendelu.cz je zpřístupněna pomocí pro-gramu Squid. Využívá pro zpřístupnění této adresy v lokální VLAN, která nedispo-nuje přístupem do internetu.

Tunelování Další variantou proxy je tunelování pomocí přístupu ke zdroji (ser-veru), umístěném v interní síti, avšak dostupnému z internetu. Pomocí tohotopřístupu se dá následně spustit tunelování vlastního provozu a využít tak zmíně-ného přístupu ke směrování provozu přes prostředníka. Využití možnosti tunelováníje nezávislé na použitém protokolu. V případě přístupu k serveru pomocí IPv6 budetunel tvořen na tomto protokolu.

4.6 Služby a bezpečnostní funkce 44

4.6.9 AAA služby

Pod AAA služby se řadí veškeré služby ověřování identity uživatele na MENDELUa s tím související přidělení či odmítnutí práv přístupu k danému zařízení, služběči zdrojům. Uživatelské účty včetně všech informací k nim jsou uloženy v databáziuniverzitního informačního systému (UIS).

Z této databáze jsou veškeré informace distribuovány do generální repliky LDAPserveru, ze které jsou následně tvořeny sekundární repliky obsahující pouze podm-nožinu informací uvedených v replice generální. Informace zde uvedené jsou využí-vány pro ověřování uživatele napříč univerzitou. Ověřování zajišťuje služba FreeRA-DIUS instalovaná na linuxových serverech umístěných v lokalitě Černá Pole, aktu-álně pak provozovaná ve verzi 2.2 a 2.1. Pomocí této služby se zajišťuje autentizacea autorizace přístupu do:

• kolejní drátové sítě (EAP-TLS, PEAP),

• kolejní bezdrátové sítě (EAP-TLS, PEAP),

• univerzitní bezdrátové sítě (EAP-TLS, PEAP).

Podobně, jako LDAP databáze, tedy přímo z databáze aplikace UIS, je tvořenai databáze uživatelských účtů v Active Directory. Ta je využívána pro správu přihla-šování na studentských koncových stanicích a umožňuje tak správcům jejich jedno-dušší správu. Uživatelé v univerzitní databázi Active Directory se dále synchronizujíse službou Microsoft o365, která je na MENDELU v současnosti doporučovanýmřešením pro poštovní služby. Služba Active Directory je spuštěna na serveru Win-dows Server 2008, očekává se však brzký přechod na Windows server 2012 R2.

Dalšími službami, které se pro ověřování identit na MENDELU využívají, jsouMikroTik Hotspot a Shibboleth.

4.6.10 Webové služby

Webové služby jsou jedním z hlavních důvodů potřeby nasazení protokolu IPv6.Pokud by se totiž před nasazením IPv6 v síti MENDELU zařízení disponující pouzeIPv6 adresou pokoušelo přistoupit k webovým serverům Mendelovy univerzity, pakby bylo spojení neúspěšné. Z toho důvodu je kompletní nasazení webových a na tonavázaných služeb prioritou nasazení protokolu IPv6.

Webové servery, které jsou na MENDELU provozovány, spadají pod následujícípracoviště:

• Ústav informačních technologií,

• Ústav informatiky Provozně ekonomické fakulty.

Samozřejmě je pak provozován nespočet dalších serverů, a to ústavy či jednot-livými zaměstnanci, především k výzkumným účelům.

4.6 Služby a bezpečnostní funkce 45

4.6.11 Poštovní služby

Poštovní služby v síti MENDELU jsou obstarávány následujícími servery zjistitel-nými pomocí příkazu nslookup.

mendelu.cz MX preference = 0, mail exchanger = mlcoun1.mendelu.czmendelu.cz MX preference = 10, mail exchanger = mlcoun2.mendelu.cz

Oba servery disponují totožnou konfigurací, mlcoun1.mendelu.cz se však pou-žívá primárně pro příchozí komunikaci, naopak mlcoun2.mendelu.cz pro komunikaciodchozí. Oba servery jsou však navzájem zastupitelné, v případě problému je takprovoz na základě preference přesměrován na zastupující server.

Na každém ze serverů je spuštěna služba OpenLDAP, která je přenášena denně zgenerální repliky UIS. Lze předpokládat, že nasazení IPv6 nezpůsobí tomuto přenosužádné výrazné problémy. Jediným krokem, který bude nutné ze strany MENDELUna serveru provést, je povolení přístupu na firewallu obou strojů.

Důležitou součástí obou serverů jsou však kontrolní mechanismy. Jedná se o ná-sledující služby:

• SPF,

• DKIM,

• DMARC,

• AMaViS,

• Postgrey.

Každá z výše uvedených služeb má danou funkci, kterou vykonává v rámciprocesu zpracování příchozí či odchozí e-mailové komunikace. Vzhledem k tomu, žebude nutné ověřovat komunikaci, která bude přicházet na servery pomocí protokoluIPv6, pak bude vyžadována jejich rekonfigurace.

SPF Sender policy framework je program, který umožňuje serveru ověřit doménuodesílatele. Detailně je systém popsán v RFC7208. Proces lze popsat zjednodušeněpomocí obr. 15.

Obrázek 15: Diagram použití SPF při přijímání e-mailu

4.6 Služby a bezpečnostní funkce 46

Program SPF pomocí DNS dotazu, viz ukázka záznamu níže, zjistí u dané do-mény možné odesílatele mailu a porovná je s příchozím e-mailem. Pokud souhlasí,pak lze prohlásit, že e-mail byl s největší pravděpodobností odeslán ze serveru prá-voplatného odesílatele. V opačném případě SPF končí chybou.

mendelu.cz. 3600 IN TXT "v=spf1 ip4:195.178.72.112 ip4:195.178.72.113ip4:195.178.72.10 include:outlook.com ~all"

Výše uvedený záznam disponuje pouze IPv4 adresami, pro zprovoznění odesíláníe-mailů pomocí IPv6 jej bude nutné upravit na požadované adresy serverů. Stejnětak bude nutné upravit program, aby byl schopen kontrolovat IPv6 adresy příchozíche-mailů.

DKIM Program DKIM kontroluje, zda odeslaná zpráva nebyla mezi odesílatelema příjemcem pozměněna. Využívá asymetrické kryptografie, kdy pomocí privátníhoklíče na straně odesílatele jsou předem daná pole podepsána. Na straně příjemce jeporovnán výsledek hash funkce s veřejně dostupným klíčem odesílatele. Vzhledemk tomu, že tento program nepracuje s adresací jako takovou, nebudou nejspíš nutnéžádné změny v jeho konfiguraci.

DMARC Tento program využívá výsledky SPF a DKIM tak, že k úspěšnémuprůchodu e-mailu vyžaduje, aby alespoň jeden z těchto programů skončil úspěšnýmověřením. Pokud se tak nestane, je na tento e-mail aplikována politika, která jeurčována serverem odesílatelem pomocí DNS záznamu. Ta by mohla v prostředíMENDELU vypadat například tak, jak je uvedeno níže. Její implementace všakv prostředí MENDELU chybí, je tak na cílovém serveru, jak bude s e-maily, kterése nepodaří ověřit pomocí SPF ani DKIM, nakládat.

_dmarc.mendelu.cz TXT "v=DMARC1; p=none; pct=100; rua=mailto:postmaster@mendelu.cz"

Proces DMARC popisuje RFC7489. Způsob jeho fungování však lze naznačitdiagramem uvedeným na obr. 16.

Obrázek 16: Diagram použití DMARC

4.6 Služby a bezpečnostní funkce 47

AMaViS AMaViS-new (A Mail Virus Scanner) je rozhraní mezi mail serverema filtry obsahu Spamasassin a Clamav. Ty se využívají pro filtraci spamu, virůa malwaru. V tabulce 2 jsou uvedeny instalované verze. Dále také minimální verzepodporující IPv6.

Tabulka 2: Přehled instalovaných komponent mail filtrů a verzí s podporou IPv6

instalováno požadovánoAMaViS-new 2.10.1 2.0.0Spamassassin 3.4.0 3.4.0Clamav 0.99.2 0.98.3

Z tab. 2 lze vyčíst, že IPv6 podporují všechny komponenty mail filtrů. Při řešenínávrhu pro IPv6 tak nebude nutné měnit verzi, ale pouze konfiguraci.

Postgrey Nástroj, který umožňuje vložit nově příchozí komunikaci do tzv. gray-listu a upozornit odesílatele, aby se pokusil o odeslání mailu opětovně v časovémhorizontu minut. Tento způsob pozdržení komunikace zajistí, že případné spamovéútoky nebudou do sítě propuštěny, pokud v tomto časovém horizontu nebudou při-jaty znovu, což je v případě jejich plošného rozesílání nepravděpodobné. Postgreyumožňuje konfiguraci IPv6.

4.6.12 Databázové služby

Databázové služby jsou v prostředí MENDELU přidělovány pomocí systému žáda-nek v UIS. Vytváření databází pomocí IPv6 tak bude nutné řešit úpravou komuni-kace v informačním systému univerzity. V případě nasazení IPv6 v oblasti databá-zových služeb pak bude vhodné konzultovat změnu s vývojáři UIS.

Ačkoli jsou databáze využívány převážně v rámci lokální univerzitní sítě a je-jich zprovoznění na protokolu IPv6 nebude pro účely prvotního nasazení nikterakzásadní, je vhodné otestovat kompatibilitu s protokolem IPv6.

Aktuálně se pak využívá především databázová služba MySQL, kterou imple-mentuje program MariaDB. Práce se tedy bude zabývat výhradně touto službou.

4.6.13 Časové služby

Na stroji aleph.mendelu.cz je spuštěna služba ntpd ve verzi 4.2.6. Podporou IPv6tato služba disponuje již od verze 4.2.0 (Network Time Foundation, 2014), verzeaplikace instalovaná na serveru aleph.mendelu.cz je tak s IPv6 kompatibilní.

Vzhledem k tomu, že je plánováno nasazení serveru, který bude poskytovatodpovědi na dotazy směrem ke klientům pomocí IPv6, měl by k jeho synchronizaci

4.6 Služby a bezpečnostní funkce 48

být taktéž využíván protokol IPv6. NTP servery s podporou protokolu IPv6 uvádíYork (2014).

4.6.14 Zálohovací služby

Zálohování je podstatnou kapitolou, která však, na rozdíl od ostatních komunika-čních kanálů, probíhá výhradně v lokální síti. Z toho důvodu není nasazení IPv6v této oblasti prioritou, ale spíše podružnou záležitostí. V této kapitole pak budouanalyzovány výhradně služby zálohující serverovou infrastrukturu.

Analýzou bylo zjištěno, že Ústav informačních technologií disponuje servery,které jsou instalovány fyzicky, avšak převážná většina je nasazena ve virtualizovanémprostředí. Virtualizované servery pak lze dále dělit dle použitého hypervizoru, kekterému se dále váže řešení zálohování. Typy strojů a služby, které se na jejichzálohu váží, jsou uvedeny v tabulce 3.

Tabulka 3: Přehled řešení instalací serverů a k nim vázaných zálohovacích řešení

Instalace Hypervizor Zálohovací řešeníVirtuální VMware VeeamVirtuální oVirt oVirt BackupFyzický stroj - rdiff-backupFyzický stroj - Bacula

Celkem jsou v provozu 2 hypervizory VMware a 2 oVirt. Stroje jsou zálohoványpomocí výše uvedených prostředků tak, aby zálohy kompletně pokrývaly možnárizika. Na fyzických strojích, které dosud nebyly přesunuty do virtualizované podoby,se využívá především rdiff-backup, software Bacula pouze výjimečně.

4.6.15 VoIP

Telefonie, která využívá IP protokolu je nasazena pouze v kancelářích budovy X.Zde jsou použity VoIP telefony Aastra 7434ip.

4.6.16 Virtualizace

Pro virtualizaci se na MENDELU využívá více platforem. Tato diverzifikace exis-tuje především z důvodu, že virtualizace je provozována na více pracovištích a každýsprávce volí řešení, které je mu nejbližší. V současnosti jsou tak provozovány mini-málně tyto hypervizory:

• VMware vSphere,

4.6 Služby a bezpečnostní funkce 49

• Microsoft Windows Server 2012 Hyper-V,

• Xen,

• KVM.

Podpora IPv6 Všechny hypervizory v aktuální verzi poskytují podporu IPv6v režimu dual-stack. Nasazení IPv6 by tak v tomto ohledu nemělo znamenat nutnostvětších změn.

4.6.17 WiFi

V univerzitní síti jsou centrálně nasazeny a spravovány převážně prvky od výrobceCisco Systems. V květnu 2017 se však předpokládá instalace nového bezdrátovéhořešení značky Aruba od společnosti Hewlet-Packard Enterprise.

V kampusu MENDELU je nasazeno kontrolérové řešení od Cisco Systems. Totořešení zahrnuje celkem přibližně 190 LAP (Lightweight Access Point) a 4 fyzickékontroléry. Ty jsou uvedeny v následující tabulce.

Tabulka 4: Přehled použitých prvků a verzí jejich systému k 20. 2. 2017

prvek verze softwaruCisco 5508 Wireless Controller 8.2.141.0Cisco 5508 Wireless Controller 8.0.120.0Cisco 5508 Wireless Controller 8.0.120.0Cisco 4402 Wireless Controller 7.0.240.0

Cisco (2014) dělí podporu IPv6 do následujících dvou fází dle způsobu přenosupaketů mezi LAP a kontrolérem.

IPv6 pro klienty ve verzi 7.2 až 7.6 V těchto verzích je dle Cisca (2014) poskyt-nuta podpora pro adresaci klientů pomocí IPv4, IPv6 nebo dual-stacku ve stejnébezdrátové síti. Jedno zařízení může disponovat až 8 IPv6 adresami, což umožňujepřidělit jednomu rozhraní adresu link-local, SLAAC, DHCPv6, případně adresy s al-ternativními prefixy. Vyžadovány jsou adresy loopback a link-local.

Pro zajištění kompatibility s IPv6 musí síť podporovat IPv4 i IPv6, pro komu-nikaci mezi LAP a WLC je totiž použit standardní CAPWAP Tunel, který používáIPv4 adresaci, viz obr. 17.

4.6 Služby a bezpečnostní funkce 50

Obrázek 17: Podpora IPv6 pro WLC verze 7.2 a pozdější

IPv6 pro infrastrukturu ve verzi 8.0 Ve fázi dva je možné využít nativní konfigu-race, kdy veškerá komunikace již probíhá pouze na IPv6. Mezi LAP a WLC je pakvytvořen CAPWAP tunel provozovaný na protokolu IPv6, v případě potřeby všaklze nastavit i preferenci IPv4. Komunikace pomocí CAPWAP tunelu je znázorněnana obr. 18. Kompletní specifikaci CAPWAP specifikuje RFC5415.

Obrázek 18: Podpora IPv6 pro WLC verze 8.0

Dle tabulky 4 disponují tři z používaných kontrolérů verzí firmware s podporouIPv6 fáze dva. Konfigurace na IPv6 tedy s vysokou pravděpodobností nebude před-stavovat žádný problém. Ten může nastat pouze u kontroléru Cisco 4402, který mánasazen software 7.0.240.0, tedy verzi, která není kompatibilní s žádnou fází IPv6.Kontrolér Cisco 4402 je dle Cisco Wireless Solutions Software Compatibility Matrix(2017) kompatibilní nejvýše s verzí 7.x, což by znamenalo podporu alespoň fáze 1,tedy podporu klientských zařízení. Je však důležité zkontrolovat také kompatibilituAP. V současnosti kontrolér disponuje LAP uvedenými v tab. 5.

Tabulka 5: Přehled LAP asociovaných k WLC 4402 a nejvyšší kompatibilní verze

LAP verze softwaruAIR-LAP1131AG-E-K9 8.0.xAIR-LAP1142N-E-K9 -

Z tab. 5 lze vidět, že LAP asociovaná ke kontroléru Cisco 4402 Wireless Cont-roller lze povýšit až na verzi 8.0.x, tedy na verzi, která není podporovaná ani samot-

4.7 Správa koncových stanic 51

ným kontrolérem. Podpora IPv6 tak, minimálně pro klientskou část infrastruktury,bude možná.

4.7 Správa koncových stanic

Koncové stanice, které jsou na MENDELU využívány se dělí na uživatelské, kteréjsou využívány zaměstnanci, převážně akademickými pracovníky, a studentské, kterépoužívají vyučující a studenti při výuce. Každá skupina počítačů pak má nastavenjiný způsob jejich správy.

Uživatelské koncové stanice až na několik výjimek nejsou zapojeny do domény.Uživatelé používají lokální uživatelské účty a o jejich konfiguraci se stará osobaspravující výpočetní techniku na daném ústavu fakulty či pracovník Ústavu infor-mačních technologií. Na jejich správu se nepoužívá žádný specializovaný software,v tomto směru tedy bude nutné pouze vhodně navrhnout jejich konfiguraci tak, abybyla co nejjednodušší, jelikož ji bude nutné provést pro každý počítač zvlášť.

Studentské koncové stanice pod správou ÚIT a ÚI PEF MENDELU jsou za-pojeny do domény Microsoft Active Directory. K 21. 2. 2017 jsou hlavními dvěmadoménami na MENDELU následující domény:

• ad.mendelu.cz - provozována Ústavem informačních technologií,

• ad.pef.mendelu.cz - provozována Ústavem informatiky PEF.

Ostatní pracoviště, která spravují koncové stanice využívané pro výuku, vy-užívají doménu provozovanou na linuxovém serveru, případně doménu nevyužívajívůbec. S provozem domény na linuxovém serveru se pak do budoucna nepočítá a takjejí konfigurace nebude v této práci dále rozebírána.

System Center Configuration Manager Obě tato pracoviště používají pro správustudentských koncových stanic program System Center Configuration Manager(SCCM), což je produkt společnosti Microsoft umožňující správu počítačů s ope-račními systémy Windows, MacOS či Linux. Ačkoli SCCM nabízí obrovské množ-ství funkcí, oběma ústavy je do budoucna plánováno využívat především následujícífunkce.

• Nasazení operačního systému.

– Záznam obrazu operačního systému.

– Nasazení obrazu pomocí PXE.

– Nasazení obrazu pomocí agentské aplikace SCCM.

• Nasazení aplikačního vybavení.

4.7 Správa koncových stanic 52

• Hromadné operace na skupiny zařízení.

– Zjištění dostupnosti.

– Obnovení politik.

5 NÁVRH ŘEŠENí 53

5 Návrh řešení

Hlavním předmětem této kapitoly je návrh požadovaných služeb zajišťujících provozIPv6. Tento návrh musí být kompatibilní se stávajícím řešením popsaným v kapitoleAnalýza současného stavu a požadavků. Výstupem této kapitoly pak je stav, kterýbude odpovídat požadavkům vedení ÚIT na provoz protokolu IPv6 v síti MEN-DELU.

V následujících sekcích je proveden návrh řešení jednotlivých služeb. Kritickéjsou pak především ty, které jsou nutné pro obsluhu webových služeb. V současnostijsou totiž webové služby na protokolu IPv6 nedostupné. Dále jsou za kritické pova-žovány ty služby, bez kterých samostatný webový server není schopen poskytovatsvé služby do sítě internet. Jedná se například o bezpečnostní funkce, monitoring,či službu DNS zajišťující překlad doménových jmen.

5.1 Adresní prostor a adresace koncových zařízení

Důsledný návrh adresace a směrování je základním předpokladem bezproblémovésítě využívající protokol IPv6, která by měla být provozována na MENDELU pomnoho dalších let. Návrh totiž ovlivní konfigurace dalších aplikací a služeb, a jehozměna či úprava až po nasazení by byla velice komplikovaná.

Návrh adresace sítí pro Mendelovu univerzitu v Brně řešil Tomáš Filip (2015)ve své diplomové práci a jeho návrh se dá považovat za kompletní. Díky tomu nenítřeba se dále adresací zabývat.

Filip navrhuje použití IPv6 prefixů o délce 64 bitů. Tato délka je doporučo-vána i v rámci RFC5375 (2008), a to především kvůli funkcím mezi které patří ND(Neighbor Discovery), SEND (Secure Neighborship Discovery) či rozšíření soukromí(Privacy Extensions), vše popsáno v RFC3971 (2005) a RFC4941 (2007). Jedinýmtypem sítě, kde není dle RFC5375 (2008) využití delšího prefixu považováno za pro-blém, je využití /128 u sítí, kde lze předpokládat výskyt pouze jedné IPv6 adresy(loopback). Případně pak /126 u point-to-point sítí, podobně, jako /30 u IPv4.

5.2 DNS

Tato služba, zajišťující překlad doménových jmen je dle kapitoly Analýza součas-ného stavu a požadavků v současnosti nasazena ve verzi 9.9.4-14. Dle ICS KnowledgeBase (2017) je protokol IPv6 touto aplikací podporován od verze 9. Bieringer (2017)však doporučuje použití minimálně verze 9.1.3, která by již neměla obsahovat zneu-žitelné bezpečnostní mezery. Ve výchozím stavu však BIND (do verze 9.10) protokolIPv6 nevyužívá a je třeba jej povolit. To je možné pomocí nastavení následující volbyoptions:

listen-on-v6 { any; };

5.2 DNS 54

Minimem pro zprovoznění IPv6 na stávajícím DNS serveru je zavedení novýchzáznamů s IPv6 adresami pro servery provozované v síti MENDELU. Níže je uvedenpříklad konfigurace zónového souboru pro překlad IPv4 a IPv6.

;fragment zónového souboru pro mendelu.cz. na DNS serveru zajišťující překlad IPv4 a IPv6relay.mendelu.cz. 3600 IN A 195.178.72.150

IN AAAA 2001:718:803:f15::150sturma IN A 195.113.217.240

IN AAAA 2001:718:803:525::10

DNS server lze zprovoznit ve dvou režimech (autoritativní, rekurzivní), kdykaždý z nich slouží k jinému účelu. Oba tyto režimy jsou popsány v kap. 3.3.

V současnosti je dle kap. Analýza současného stavu a požadavků implemento-váno řešení, kdy rekurzivním DNS serverem, pro dotazy z vnitřní sítě, i autorita-tivním DNS serverem pro dotazy z internetu, je pouze jeden stroj, resp. dva stroje,z nichž aktivní je vždy jen jeden. Z pohledu bezpečnosti je toto řešení výraznýmrizikem a to z několika důvodů, které uvádí Caletka (2015) a Cisco (2017). Tytodůvody budou uvedeny v následujících podsekcích tak, aby bylo stanoveno, zda jsouněkteré z nich kritické pro infrastrukturu sítě MENDELU.

5.2.1 Dva různé účely provozu dané služby

Cisco (2017) uvádí, že na DNS server je třeba pohlížet jako na dvě oddělené funkce.Proto je vhodné je rozdělit, ať už z hlediska oddělené konfigurace, a tedy snadnějšísprávy, či z hlediska zvýšené bezpečnosti. V případě sjednocení služeb se totiž je-jich provozovatel vystavuje zvýšenému riziku napadení obou služeb při zranitelnostijedné z nich.

5.2.2 Malá škála dostupného DNS software

Malá škála dostupného DNS software, který by zvládal provozovat autoritativníi rekurzivní server v rámci jedné služby, není v infrastruktuře MENDELU problém.Provoz IPv6 totiž, aktuálně nasazený software BIND, zvládne bez problémů, a toi včetně funkce DNSSEC. Další službou, která IPv6 taktéž je pouze PowerDNS,avšak bez DNSSEC.

5.2.3 Nemožnost DNSSEC validace vlastních dat

Nemožnost DNSSEC validace vlastních dat znamená, že proces není schopen ověřitplatnost podpisu DNSSEC v rámci jedné služby. Tento jev je velice významný, můžetotiž způsobit problém v případě úspěšného napadení rekurzivního serveru tak, žebude poskytovat uživatelům v lokální síti podvržené adresy.

5.2.4 Špatná data z oddelegovaných, ale nezrušených zón

Chybná data z oddelegovaných, ale nezrušených zón nejsou v případě sítěMENDELU problém. V této chvíli je odděleně provozována pouze subdoména

5.2 DNS 55

zf.mendelu.cz. Do budoucna se však s ní již nepočítá a veškeré záznamy budouspravovány zónou mendelu.cz. Ačkoli si vlastní DNS servery tvoří i servery, na kte-rých je provozována doména Microsoft Active Directory (například ad.mendelu.cz),tyto nepředstavují potíže v případě změn v konfiguraci univerzitní DNS.

5.2.5 Dostupnost z internetu a útoky na DNS

Problémy související s dostupností z internetu jsou důvodem ohrožení předevšímproto, že autoritativní server, k tomu aby byl schopen odpovídat na rekurzivní do-tazy pro spravovanou zónu, musí být přímo dostupný z internetu, a to minimálněna portu 53/udp a 53/tcp. To znamená, že firewall, který jej chrání před potenci-álními útoky, musí příchozí pakety s tímto stavem propustit. Za napadení je pakpovažováno i přetížení. To je možné jednoduše vyvolat zvýšeným provozem (DNSrequest), tzv. Amplifikací. Teoreticky je taktéž možné, v případě zranitelnosti DNSserveru, jej napadnout tak, že mu jsou podstrčeny nesprávné údaje při dotazováníse autoritativního serveru, čímž jsou následně uživatelé směrováni na chybnou IPadresu.

Z útoků, jejichž cílem je DNS server, lze jmenovat tyto nejvíce rozšířené, jejichžpopis následuje:

• DNS Cache Poisoning (otrávení),

• Amplifikace,

• Water Torture.

5.2.6 DNS Cache Poisoning

Metod obrany proti otrávení DNS cache je více. Níže jsou uvedeny přístupy, které byměly být aplikovány na výslednou implementaci, tak aby bylo riziko minimalizovánov maximální možné míře.

Randomizace portu při odpovědi je technika, díky které lze dle CVE (2008)předejít riziko otrávení DNS cache. Ověření schopnosti serveru randomizovat portypři komunikaci lze ověřit pomocí níže uvedeného příkazu na unixových strojích.

# dig +short @10.6.0.253 porttest.dns-oarc.net txtporttest.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net."195.178.72.105 is GREAT: 26 queries in 3.9 seconds from 26 ports with std dev 15558"

Implementace DNS Security Extensions (DNSSEC) je další metodou vý-razně snižující riziko otrávení DNS cache. Specifikace, implementace a další infor-mace ohledně DNSSEC jsou popsány v následujících dokumentech RFC:

• RFC4033 (IETF, 2005) DNS Security Introduction and Requirements,

• RFC4034 (IETF, 2005) Resource Records for the DNS Security Extensions,

5.2 DNS 56

• RFC4035 (IETF, 2005) Protocol Modifications for the DNS Security Extensions,

• RFC5155 (IETF, 2008) DNS Security (DNSSEC) Hashed Authenticated Denialof Existence,

• RFC4310 (IETF, 2005) Domain Name System (DNS) Security Extensions Map-ping for the Extensible Provisioning Protocol (EPP),

• RFC4641 (IETF, 2006) DNSSEC Operational Practices.

Použitím DNSSEC jsou zónové soubory podepsány a publikovány standardnímzpůsobem na autoritativním DNS serveru. Rekurzivní servery implementující tutofunkci jsou pak díky principu elektronického podpisu schopny ověřit, že příchozíodpověď na jejich dotaz byla zaslána důvěryhodným autoritativním serverem a lzejí tak důvěřovat. Rekurzivní server tak s vysokou pravděpodobností obdrží odpověď,která nebyla podvržena.

Cisco (2017) pro zabezpečení DNS serveru doporučuje použití funkce DNS gu-ard, která je dostupná v jimi dodávaných prvcích ASA, PIX a FWSM. Ani jedenz těchto prvků se však pro Firewall v prostředí MENDELU aktuálně nevyužívá.Přesto, že návrh univerzitního firewallu na platformě Cisco zpracoval pro MEN-DELU Burian (2016).

5.2.7 Amplifikace

Útok primárně neohrožující DNS server, ale využívající jeho zdroje pro útok na jinázařízení. Server je nutné proti této možnosti zneužití zajistit.

Cesta, jakou lze tento problém řešit, je v limitování dotazů pomocí technikyRRL (Response Rate Limiting), kdy jsou omezeny velké počty dotazů, které bymohly být součástí amplifikačního útoku. Služba BIND podporuje RRL od verze9.9.4. Je ale nutné ověřit jeho podporu, protože jí nedisponují všechny balíčky. Na-stavení se pak provádí v konfiguračním souboru named.conf a může vypadat násle-dovně.

options { directory "/var/named"; rate-limit {responses-per-second 5; log-only yes; }; };

Ačkoli útok lze očekávat především z vnější sítě, tedy na autoritativní server, jenutné předpokládat i možnost jeho zdroje v interní síti. Útočník se může v nacházetpřímo v této síti, případně může být zdrojem napadené zařízení. Nasazení RRL jetak nutné i na rekurzivním DNS serveru.

5.2.8 Water tortue

Cílem tohoto útoku je přetížit autoritativní servery pro danou doménu. V případěMENDELU by to byla doména mendelu.cz. Útok probíhá tak, že se útočník pokouší

5.2 DNS 57

o překlad neexistujících doménových jmen, ke kterým připojí doménu, jíž auto-ritativní server obsluhuje. V případě DNS serveru MENDELU by se tak jednalonapříklad o překlad:

hello-0.mendelu.czhello-1.mendelu.czatd...

Útočník se ale na odpovědi neptá přímo serveru MENDELU, ale k jejich distri-buci využívá rekurzivní servery v internetu, které pak požadavky zahltí autoritativníserver. Caletka (2015) uvádí, že server BIND má pak výchozí limit nastaven na 1000současně probíhajících rekurzivních dotazů a v případě překročení jsou další dotazyodmítány s návratovým kódem SERVFAIL.

Dle Caletky (2015) neexistuje jednoduché protiopatření, které by umožniloobranu proti útokům tohoto typu, protože dotazy jsou často unikátní a RRL11 takv tomto případě není dostatečně efektivní. Jednou z možností předejití problémům jezvýšit limit současně probíhajících rekurzivních dotazů. Ten však dle Caletky (2015)není možné zvýšit na více něž 4500 dotazů z důvodů limitace počtu otevřených sou-borů na proces. Jako další možnost Caletka (2015) uvádí možnost blokace právěprobíhajících rekurzí, které se často opakují. Tento postup však znamená odstřiženíveškerých požadavků z daného rekurzivního serveru, což jeho uživatelům způsobínedostupnost překladu doménových jmen, které autoritativní sever obsluhuje.

Syntetizované RR Pro bezproblémové provozování některých služeb je nutné, abyIP adresa daného prvku obsahovala i reverzní záznam umožňující překlad IP adresyna konkrétní doménové jméno. Tento záznam je vyžadován v případě, že z danéhoprvku je například přímo odesílán mail. Může být také vyžadován některými da-lšími službami, či přístupy (v prostředí MENDELU reverzní záznam vyžaduje serverkiwi.mendelu.cz). U DNS pro IPv4 je způsob nastavení poměrně jednoduchý, stačíuvést reverzní záznamy pro všechny použité IP adresy, kterých většinou není nijakmnoho. U IPv6 však může nastat problém s adresací pomocí EUI-64, či SLAAC,kdy správce předem nezná používanou IP adresu síťového zařízení. Pokud bychomchtěli vytvořit reverzní záznam pro každý z použitých /64 IPv6 rozsahů, pak byjeden z nich, dle Caletky (2016), zabral stovky EiB. Toto řešení tak není možnéaplikovat. V současnosti lze problém řešit dvěma cestami:

• Zajistit přidělování IPv6 adresy, například pomocí stavového DHCPv6,

• Syntetizovat rekurzivní záznamy (recursice records).

První ze jmenovaných, tedy zajištění přidělení IPv6 adresy a k ní vygenerováníPTR záznamu, je způsob, který se využívá i v současnosti pro protokol IPv4. Pro-blém však může nastat u prvků, které například výše zmiňovaný způsob adresacenepodporují a umožní zvolit pouze adresu náhodně vygenerovanou pomocí SLAAC.

11RRL – Response Rate Limiting

5.2 DNS 58

K těmto zařízením by pak neexistoval reverzní záznam, což by mohlo způsobit ne-dostupnost některých služeb.

Vhodnější cestou pro vyřešení problému reverzních záznamů je tak syntetizovattyto záznamy a hromadně tak vytvořit PTR záznam pro celý rozsah daného bloku.Surý (2014) uvádí příklad konfigurace pro Knot DNS.

synth_record "(forward|reverse) <prefix> <ttl> \ <address>/<nn>";synth_record "forward gen- 400 2620:0:b61::/52";

V současnosti se v univerzitním prostředí používá pro DNS aplikace BIND. Tavšak výše zmíněné syntetizované rekurzivní záznamy, dle Lindqvista (2017), nepod-poruje. Jednou z možností, jak s jeho pomocí dosáhnout podobného výsledku, jevyužití směrnice $GENERATE, která vygeneruje záznam pro celý rozsah. Jak jižbylo ale zmíněno, tento přístup vyžaduje obrovské datové nároky a pro implemen-taci IPv6 je tak nevhodný. Využití jiné aplikace, která by syntetizované rekurzivnízáznamy umožňovala využít, je však z důvodů proprietární aplikace, která DNSspravuje, nemožné.

Řešení tohoto problému se bude držet stávajícího řešení, které přiděluje adresypomocí stavového DHCPv6. Všechny tyto záznamy budou spravovány univerzitníminformačním systémem, který vždy vytvoří i rekurzivní záznam. Tento způsob vy-tváření PTR záznamů vystačí pro většinu zařízení, která lze konfigurovat.

S příchodem IoT (Internet of Things) se však očekává, že stále více zařízeníbude využívat pouze IPv6 a především to, že neumožní manuálně konfigurovat IPv6adresu (a to ani pomocí DHCPv6 serveru). V případě, že se tato zařízení začnouobjevovat, pak je bude nutné zařadit do speciální VLAN určené k tomuto účelu,která bude disponovat významně menším rozsahem (například /118, 1024 adres),který při použití příkazu $GENERATE nebude představovat významnou zátěž navyužitou paměť serveru.

Návrh konektivity Výsledný návrh by měl v maximální možné míře pokrývat výšezmíněné metodiky zabezpečení tak, aby nedocházelo k problémům, které by mohlyomezit či ohrozit uživatele využívající poskytované služby.

V souvislosti se spuštěním služby je taktéž nutné zajistit, aby byl server do-stupný z internetu. Současné nastavení směrování je popsáno v kapitole Analýzasoučasného stavu a požadavků. Výsledkem by mělo být zapojení, které nebude vy-žadovat změny ve stávající topologii, ale rozšíří ji o možnost využití protokolu IPv6.Model toku provozu IPv6 lze vidět na obr. 20.

Návrh řešení Řešení bude na první pohled kopírovat stávající topologii, kdy k L3přepínači budou logicky zapojeny dva servery, v tomto případě již oba virtuální, vizobr. 19. Je však nutné zajistit především dvě podmínky:

• rozdělení Autoritativního a Rekurzivního serveru,

• zajištění redundance mezi oběma servery.

5.2 DNS 59

Obrázek 19: Topologický diagram návrhu řešení pro DNS

Navrhované řešení splňuje bez výhrad oba požadavky a to tak, že provozbude směrován na autoritativní či rekurzivní část DNS serveru MENDELU, vy-stupující pod IP adresou 195.178.72.150 serveru Firewallv4, případně IPv6 adresou2001:718:803:f15::1, kterou má nastavenu na síťovém rozhraní server Firewallv6. Natěchto serverech je nastaven překlad adres DNAT, viz obr. 19 tak, aby došlo kesměrování provozu na daný autoritativní či rekurzivní DNS server.

Toto nastavení je navrženo výhradně kvůli bezpečnosti a to z důvodů, že každýze serverů jedná samostatně a obsluhuje výhradně jednu ze služeb. Je tak splněnpožadavek na rozdělení autoritativního a rekurzivního serveru. Další výhodou, kterázvyšuje bezpečnost tohoto řešení je, že DNS servery nelze kontaktovat jiným způso-bem, než pomocí dotazu DNS. Zbytek provozu totiž nebude přesměrován, a tak sepřípadné útoky k DNS serveru vůbec nedostanou.

Oba servery však budou disponovat stejnou konfigurací. V případě výpadkujednoho z nich tak bude možné, ať už ručně či pomocí skriptu, přesměrovat veškerýprovoz pouze na jeden server, který by v té chvíli zajišťoval obsluhu obou částí

5.3 Firewalling 60

služby (autoritativní i rekurzivní). Tím by byla snížena úroveň zabezpečení, ovšempouze dočasně.

5.3 Firewalling

Konfiguraci stroje provozující firewall, který zajišťuje služba iptables, není možnézměnit tak, aby podporovala protokol IPv6. Pro její provoz je totiž nutné využítodlišnou službu a konfiguraci, která je schopna s protokolem IPv6 pracovat.

Jednou z nich je ip6tables, která více či méně kopíruje funkcionalitu původníhoiptables. Další aplikací, která je stejně jako ip6tables vydána pod licencí GPL12 a bybylo ji možné využít, je firewalld. Ten poskytuje stejnou funkcionalitu, avšak pronastavení využívá XML soubory. Dostupná jsou však i placená řešení, napříkladCisco ASA Firepower, nebo Juniper SRX.

Z důvodů nemožnosti využít stávající službu zajišťující firewall bylo navrženoprovozování firewallu na dvou strojích, kdy každý z nich by byl používán pro fil-trování jednoho z protokolů (IPv4, IPv6). Nasazení firewallu tímto způsobem bydisponovalo mnoha výhodami. Především by nebylo nutné přímo zasahovat do jižfunkčního řešení, dále by byl samostatný stroj výhodný z důvodů jednoduššího mo-nitoringu síťového provozu, bezpečnosti, oddělení konfigurace a správy. V případěproblémů by taktéž za předpokladu správné konfigurace bylo možné jeden ze strojůodstavit a zachovat tak konektivitu pomocí druhého z nich. Vhledem k tomu, žetento návrh byl odsouhlasen vedením Oddělení infrastruktury ÚIT, pak bude v da-lším textu uvažováno pouze toto řešení. Na základě tohoto rozhodnutí o diverzifikaciprovozu dle verze IP protokolu bylo stanoveno, že v síti bude vytvořen nový prvek.Tento způsob nasazení zachová stávající řešení firewallu, do kterého nebude nijakzasahováno a umožní postupné nasazení IPv6 v síti univerzity.

5.3.1 Vícekriteriální hodnocení variant

Vzhledem k tomu, že možností implementace firewallu je více, je vhodné jeho výběrprovést na základě vícekriteriálního hodnocení. Použitým řešením pak bude produkt,který bude výstupem tohoto hodnocení a bude tak nejvíce vyhovovat potřebámuniverzitní sítě. Hodnoceny budou následující produkty,

• Cisco ASA Firepower (appliance),

• Juniper SRX (appliance),

• pfSense (appliance),

• ip6tables (software),

• Firewalld (software),

• Windows Firewall (software).

12GPL - General Public License

5.3 Firewalling 61

Faktory analýzy pak budou kritéria specifikována níže.

• Cena řešení – Celková cena nového prvku je poměrně významným kritériem.Jedná se totiž o nový prvek, se kterým není počítáno z pohledu dlouhodobéhoplánu.

• Udržitelnost – Předpoklad dlouhodobé podpory z pohledu dostupných, přede-vším bezpečnostních, aktualizací je zásadní.

• Schopnost samostatné správy – Zařízení bude spravováno zaměstnanci univer-zity a bylo by přínosné, pokud by se jednalo o prvek, se kterým mají již zkuše-nosti

• Maximální propustnost rozhraní – Provoz sítě MENDELU v současnosti dosa-huje dle ÚIT až 1,5 až 2 Gbps, je tedy nutné, aby navržené řešení disponovalominimálně touto propustností.

• Kompatibilita s původní konfigurací – Stávající implementace firewallu je po-měrně rozvinutá a v případě nasazení řešení, které by disponovalo jinou logikoujeho konfigurace by bylo nutné ji kompletně přepracovat.

Výše uvedená kritéria poté byla ohodnocena tak, jak je uvedena v tab. 6.

Tabulka 6: Faktory analýzy

Pořadí Kritérium Hodnoty1. Cena řešení 1 - zdarma | 3 - střední | 5 - vysoká2. Udržitelnost 1 - krátkodobá | 3 - střednědobá | 5 - dlouhodobá3. Schopnost samostatné správy 1 - nízká | 3 - střední | 5 - vysoká4. Maximální propustnost rozhraní 1 - nízká | 3 - střední | 5 - vysoká5. Kompatibilita s původní konfigurací 0/1 [ne/ano]

Následně byly přiřazeny k daným kritérií jejich ohodnocení, viz tab. 7.

Tabulka 7: Ohodnocení variantPořadí Cisco ASA Juniper SRX pfSense ip6tables Firewalld Windows Firewall1 5 5 1 1 1 12 3 3 3 3 5 53 3 3 1 5 3 14 1 3 5 5 5 55 0 0 0 1 0 0

Z tab. 7 lze vyčíst, že placená řešení disponují poměrně malou propustností.V rámci této analýzy totiž nebyly z důvodu obrovské finanční náročnosti zahrnutyjejich nejvyšší modely, ale řešení, která by v případě jejich nákupu nebyla pro uni-verzitu likvidační. Ohodnocení po normalizaci dat je uvedeno v tab. 8

Po stanovení vah, které jsou uvedeny v tab. 9, bylo vypočteno hodnocení kritérií,viz tab. 10. Nejlepšího hodnocení dosáhla aplikace ip6tables.

Nově implementovaný prvek bude na základě vícekriteriálního rozhodnutí uve-deného v kap. 5.3.1 provozován službou ip6tables.

5.4 IDS, IPS 62

Tabulka 8: Ohodnocení variant po normalizaci dat

Pořadí Cisco ASA Juniper SRX pfSense ip6tables Firewalld Windows Firewall1 0 0 4 4 4 42 3 3 3 3 5 53 3 3 1 5 3 14 1 3 5 5 5 55 0 0 0 1 0 0

Tabulka 9: Hodnotící kritériaKritérium Váhový vektorCena řešení 0,15Udržitelnost 0,15Schopnost samostatné správy 0,25Maximální propustnost rozhraní 0,35Kompatibilita s původní konfigurací 0,10

5.3.2 Návrh topologického diagramu

Topologický diagram tohoto návrhu, včetně adresace, je uveden na obr. 20. Zahrnujeperimetr sítě včetně návrhu adresace. Na Firewalluv4 by pak měla být aktuálněspuštěná služba ponechána bez změny konfigurace. Veškerá implementace firewallubude probíhat na stroji Firewallv6.

Nasazený firewall musí implementovat veškerá pravidla, která jsou nutná prosměrování provozu IPv6 v rámci sítě MENDELU. Jedná se také o stávající pravidla,jejichž implementace v rámci firewallu bude pro protokol IPv6 velice podobná jakou IPv4. Z výchozích pravidel, která je nutné implementovat, lze zmínit napříkladRFC2827 (2000), označované jako BCP38, pojednávající o zvýšení bezpečnosti sítěpomocí blokace paketů s podvrženou IP adresou, která neodpovídá rozsahu sítě, zekteré je zasílán, ani žádné z ní podřízených.

Z pohledu bezpečnosti však firewall pro protokol IP verze 6 nepředstavuje vý-znamné zvýšení zranitelnosti. Tak, jako u ostatních služeb zde ale platí požadavekna nejnovější možnou verzi softwaru tak, aby byly zaplátovány známé zranitelnosti,které však jsou v posledních verzích opraveny.

5.4 IDS, IPS

Prvek, který by sloužil jako IDS či IPS není aktuálně v síti MENDELU nasazen.Vzhledem k tomu, že se jedná o výraznou bezpečností mezeru, pak by bylo vhodné

Tabulka 10: Vyhodnocení vícekriteriálního hodnocení

Produkt HodnoceníCisco ASA 0,125Juniper SRX 0,300pfSense 0,500ip6tables 0,850Firewalld 0,775Windows Firewall 0,650

5.4 IDS, IPS 63

Obrázek 20: Topologický diagram návrhu řešení směrování pro IPv6 Firewall

5.4 IDS, IPS 64

nasadit řešení, které by tuto úlohu zastávalo, čímž by mělo dojít k výraznému vy-lepšení zabezpečení sítě před útoky, které jsou stávajícími bezpečnostními prvky,například firewallem, nedetekovatelné.

Zařízení IDS/IPS by mělo být v ideálním případě nasazeno přímo za hraničnímfirewallem tak, aby mohlo v maximálně možné míře detekovat možné zranitelnosti,které jím nebyly blokovány. V případě sítě MENDELU by tak měl návrh vycházetz těchto požadavků.

Zásadní rozhodnutí, které je před započetím návrhu nutno udělat je to, zdalise bude týkat i vylepšení zabezpečení na protokolu IPv4. Pokud by tomu tak bylo,pak by bylo nutné, aby se návrh týkal i provozu IPv4. Diagram obou topologií, tedyzahrnující IPv4 či nikoli, je uveden na obr. 21. V případě varianty A je pomocíIPS/IDS sledován pouze provoz IPv6 bez ovlivnění IPv4 provozu. Tento návrh mávšak slabé místo nejen v absenci kontroly IPv4 provozu, přes který by bylo teoretickymožné určité typy útoků provádět, ale především v tom, že navrhované řešení neníredundantní.

Obrázek 21: Topologický diagram umístění IDS/IPS

Oba tyto problémy řeší návrh varianty B. K nasazení této topologie by však, nazákladě domluvy s vedením ÚIT, mělo dojít až po úspěšném testování varianty A.

Pro instalaci zařízení byla vybrána pozice ihned za firewallem. Firewall je totižprvkem, který je navržen k tomu, aby byl umístěn na perimetru sítě a blokoval

5.4 IDS, IPS 65

nelegitimní pakety a útoky, které se pokouší přistoupit do sítě MENDELU. Totoblokování je prováděno na základě informací uvedených v hlavičce paketu. Naopakstroj, který je IDS senzorem, provádí podrobnější inspekci těchto paketů. To jenáročnější na výkon stroje, proto je vhodné tuto inspekci provádět až poté, co ječást provozu odfiltrována firewallem na perimetru sítě.

Výsledná podoba topologického diagramu je tak uvedena na obr. 22.

Obrázek 22: Topologický diagram implementace IDS/IPS pro IPv6

5.4.1 Vícekriteriální hodnocení variant

Při výběru řešení, které bude nasazeno jako IDS/IPS do sítě MENDELU je nutnézvážit veškeré produkty, které jsou dostupné na trhu. Ačkoli nejdůležitějšími kritériijsou cena a schopnost detekce, je nutné do úvahy zahrnout i ostatní parametrynabízených aplikací či komplexních produktů nabízených jako hotová řešení.

Dle informací, které byly získány z Ústavu informačních technologií, se v sou-časnosti odchozí provoz ze sítě MENDELU, adresovaný protokolem IPv4, pohybujekolem hodnoty 1,5 Gbps. Ve špičce pak může dosahovat až 2 Gbps. V první řadě jetedy nutností vybrat řešení, které bude uvedenou kapacitou datového toku schopnoobsloužit. Ačkoli současný návrh řešení nepočítá s tím, že by veškerý provoz bylsměrován prostřednictvím stroje provozujícího IDS/IPS, do úvahy je nutné zahr-nout i fakt, že do budoucna se bude provoz protokolu IPv6 výrazně zvyšovat a můžetak v brzké době dosáhnout stejných hodnot, jako je provoz na protokolu IPv4. Vý-sledkem této úvahy je minimální hranice 2 Gbps, která bude minimem pro výběrsrovnávaných konkrétních produktů nabízených jako IDS. Výhodou pak je schop-nost obsloužit i vyšší datové toky, jelikož celková konektivita sítě MENDELU dointernetu je v současnosti 10 Gbps, a v nejbližší době by mohla být ještě zdvojná-sobena.

Faktory analýzy V analýze jsou porovnávány následující faktory, které budou zpra-covány dle metodiky uvedené v kap. 3.21. Prvním krokem bude specifikace kritériíanalýzy, která zahrnuje následující faktury.

• Cena za aktualizace – Aktualizace detekčních pravidel aplikace jsou důležitýmprvkem pro rozhodování, cílem je pak maximalizace aktualizací pravidel, avšakza cenu, která bude obhajitelná před vedením univerzity.

5.4 IDS, IPS 66

• Cena aplikace – Vzhledem k tomu, že se bude jednat o nový prvek v rámciinfrastruktury MENDELU, nejsou na jeho pořízení v současnosti vyhrazenyžádné zdroje, cena je tak významným kritériem.

• Možnost pořízení prioritních pravidel – Schopnost získat pravidla přímo oddodavatele aplikace je významnou výhodou. Schopnost reagovat na nové hrozbyje tak výrazně vylepšena.

• Dostupnost podpory pro aplikaci – V případě problémů s aplikací je nutné oka-mžitě reagovat a zajistit její opětovnou dostupnost. Podpora v tomto případěmůže být jediným východiskem.

• Náročnost instalace a správy – Instalace aplikace, potažmo její správa, můžebýt náročným úkolem, který bude vyžadovat specialistu. Aplikace, kterou bymohl spravovat i běžný správce by tak byla pro pořizovatele výhodnější.

• Nutnost pořízení specifického HW řešení – Využití stávajícího hardwarovéhovybavení, které je v majetku univerzity, by umožnilo dosáhnout výrazných úsporpři nasazování řešení IDS/IPS.

• Schopnost aplikace využívat vícevláknových procesů – Vícevláknovost procesuumožní využít zdroje přidělené aplikaci na maximum.

• Udržitelnost aplikace – Předpoklad, že aplikace bude vyvíjena a udržována podelší časové období, je dobrým předpokladem pro její nasazení v infrastruktuřeMENDELU.

• Přívětivost GUI aplikace pro správu – Správce, který bude obsluhovat dané za-řízení, potřebuje disponovat přehledem nalezených detekcí či hrozeb. PřehlednéGUI je tak výhodou.

• Maximální propustnosti rozhraní – Maximální propustnost rozhraní je požada-vek, který je nutné důsledně zvážit při rozhodování o řešení, které bude v sítinasazeno. Provoz, který univerzita obsluhuje, vytváří vysokou zátěž na síťovéprvky a je nutné vybrat řešení, které tuto zátěž zvládne obsloužit.

Tato kritéria byla následně ohodnocena, viz tab. 14.

Tabulka 11: Faktory analýzy

Pořadí Kritérium Hodnoty1. Cena za aktualizace 1 - nízká | 3 - střední | 5 - vysoká2. Cena aplikace 0/1 [ne/ano]3. Možnost pořízení prioritních pravidel 0/1 [ne/ano]4. Dostupnost podpory pro aplikaci 1 - nízká | 3 - střední | 5 - vysoká5. Náročnost instalace a správy 1 - nízká | 3 - střední | 5 - vysoká6. Nutnost pořízení specifického HW řešení 0/1 [ne/ano]7. Schopnost aplikace využívat vícevláknových procesů 0/1 [ne/ano]8. Udržitelnost aplikace 1 - nízká | 3 - střední | 5 - vysoká9. Přívětivost GUI aplikace pro správu 1 - nízká | 3 - střední | 5 - vysoká10. Maximální propustnosti rozhraní 1 - nízká | 3 - střední | 5 - vysoká

Dalším krokem vícekriteriální analýzy je její hodnocení, viz tab. 12.

5.4 IDS, IPS 67

Tabulka 12: Ohodnocení variantPořadí Bro Cisco HPE Snort Suricata1 1 5 5 1 12 1 0 0 1 13 0 1 1 1 04 1 5 5 5 35 3 1 1 3 56 0 1 1 0 07 0 1 1 1 18 1 5 5 5 39 3 5 5 3 310 1 5 5 3 3

Po ohodnocení variant je třeba získat normalizovanou kriteriální matici, viztab. 13. Minimalizační kritéria se převádí na maximalizační vyjádřením úspor vůčinejhorší variantě tak, jak je řečeno v kap. 3.21.

Tabulka 13: Ohodnocení variant po normalizaci dat

Pořadí Bro Cisco HPE Snort Suricata1 4 0 0 4 42 1 0 0 1 13 0 1 1 1 04 1 5 5 5 35 2 4 4 2 06 1 0 0 1 17 0 1 1 1 18 1 5 5 5 39 3 5 5 3 310 1 5 5 3 3

Tabulka 14: Hodnotící kritériaKritérium Váhový vektorCena za aktualizace 0,05Cena aplikace 0,15Možnost pořízení prioritních pravidel 0,05Dostupnost podpory pro aplikaci 0,1Náročnost instalace a správy 0,05Nutnost pořízení specifického HW řešení 0,05Schopnost aplikace využívat vícevláknových procesů 0,05Udržitelnost aplikace 0,2Přívětivost GUI aplikace pro správu 0,1Maximální propustnosti rozhraní 0,2

Na základě vah, které jsou uvedeny v tab. 14, bylo dle vzorce uvedenéhokap. 3.21 vypočteno výsledné hodnocení kritérií, viz tab. 15. V tomto hodnocenínejlepších hodnot dosáhl program Snort. Ani placená řešení od společností HPEa Cisco však nebyla hodnocena špatně.

Vzhledem k tomu, že byl vybrán program, který vyžaduje použití vlastníhohardwaru, je nutné vybrat operační systém, na které bude software Snort nasazen.Pro tento účel nejlépe poslouží systém CentOS verze 7. A to především z důvodů, žetento systém je použit na většině strojů provozovaných ÚIT, unifikace tak přineseúspory v oblasti školení správců. Systém by měl být nasazen jako virtualizovaný,

5.4 IDS, IPS 68

Tabulka 15: Vyhodnocení vícekriteriálního hodnocení

Produkt HodnoceníBro 0,275Cisco 0,750HPE 0,750Snort 0,775Suricata 0,550

a to v prostředí VMware, či oVirt. Diagram nasazení operačního systému v rámcivirtualizovaného prostředí bude vypadat tak, jak je uvedeno na obr. 23.

Obrázek 23: Diagram nasazení OS pro IDS/IPS

Na základě vícekriteriální analýzy uvedené výše byla pro zajištění IDS/IPS naMENDELU vybrána aplikace Snort, která je IPS systémem vlastněným společnostíCisco, avšak pod licencí open-source. Její hlavní výhodou je pak možnost využitíveřejné i komerční databáze umožňující detekovat útoky v reálném čase. V souvis-losti s touto aplikací lze využívat podpůrných aplikací třetích stran, které umožňujíjejí jednodušší správu. Jednou z nich je aplikace PulledPork for Snort and Suri-cata rule management, která umožňuje provádět automatické aktualizace a importynových pravidel. Spolu se systémovým démonem Cron tak automaticky udržuje pro-gram Snort v nejaktuálnější podobě.

Nasazení programu Snort pak z důvodů zvýšení bezpečnosti musí být prove-deno v bridge módu, tedy tak, že stroj nebude pro přeposílání využívat IP adresace.Pakety budou přeposílány mezi přímo připojenými rozhraními, přičemž bude prová-děna jejich kontrola v reálném čase. Stroj však nebude možné prostřednictvím těchtorozhraní kontaktovat přímo a případný útočník tak bude mít obtížné na tento strojútok cílit. Tento mód je v programu Snort nazýván jako ”inline” a jeho konfiguracese provádí následovně:

• na obou rozhraních, které budou využívány je odstraněna IP adresa,

• na stroji je povolen promiskuitní režim,

5.5 ACL 69

• do konfigurace programu Snort je zavedena konfigurace DAQ knihoven, (configdaq: afpacket a config daq mode: inline),

• program Snort je spuštěn v režimu inline pomocí parametru -Q.

Topologický diagram zapojení stroje provozujícího program Snort je uveden naobr. 23.

Poté, co bude nasazen program Snort, je nutné nahlížet do jeho výstupů (de-tekcí). Ty jsou ve výchozím stavu ukládány v textové podobě, která neumožňujezískat přehled nad možnými riziky, či narušení bezpečnosti. Proto je vhodné nasaditnadstavbu, která umožní přehled nad těmito výstupy. K tomu lze využít některý zespecializovaných programů, které byly vytvořeny k tomuto účelu. Jedná se o apli-kace Snorby, BASE či Sguil. Výstupy lze také směrovat pro komplexní programy proanalýzu systémových záznamů, jako je například Kibana, GrayLog, Splunk nebo Ali-enVault OSSIM. Tato řešení budou pro správu vhodnější než jednoúčelové aplikace.Pro účely této práce však Snort generuje výstupy pouze v textové podobě.

Topologický diagram nezahrnuje redundanci, v případě výpadku stroje provo-zujícího IDS/IPS by tak byla celá síť nedostupná. Tento nedostatek lze řešit vícezpůsoby. Jedním z nich je nasazení dvou identických strojů, které by zajišťovalyredundanci a pomocí dělení zátěže (load balancing) by mohly také obsloužit většídatový tok. Jednodušším řešením by pak mohl být záložní spoj, který by byl spuštěnv případě výpadku stroje zajišťujícího IDS/IPS. Obě tato řešení jsou však určitounadstavbou, která v této práci není dále rozebírána.

5.5 ACL

Pravidla pro protokol IPv4, jejichž současný stav je popsán v kapitole Analýzasoučasného stavu a požadavků, je nutné analogicky transformovat i do konfiguraceACL pro IPv6. Jedná se především o kontrolu zdrojových IPv6 adres na prvcíchukončující sítě VLAN. Jde tedy o BCP38 (Ashworth, 2016) již zmíněný v kapitoleFirewall.

Funkce IPv6 ACL podporuje pouze named ACL, což není z pohledu konfiguraceproblém. Zásadní je však podpora pouze sítí s prefixem /0 až /64, je tudíž nutnékonfigurovat sítě výhradně s prefixy z tohoto rozsahu.

Vzhledem k tomu, že IPv6 ACL umožňují jejich aplikaci na směrované (L3)rozhraní i linkové (L2) rozhraní, bylo by příhodné aplikovat oba typy. Pro nejčet-něji použité prvky Catalyst2960 je však IPv6 port ACL dostupný až od IOS verze15.0(1) a pozdější (Cisco, 2015). Nelze je tak v současnosti nasadit. Pokud by sevšak v budoucnu uvažovalo o povýšení verze, či nákupu nových zařízení, IPv6 portACL by měly být na L2 porty konfigurovány.

5.6 VPN 70

5.6 VPN

5.6.1 Site-to-Site

V rámci analýzy VPN, viz kap. 4.6.5, bylo zjištěno, že pro připojení odloučenýchlokalit je využíván GRE tunel. Ten je v současnosti konfigurován pro tunelováníIPv4 provozu baleného do IPv4 paketů.

Vzhledem k tomu, že se i nadále předpokládá využívání IPv4 sítí, a navíc sedo budoucna dle informací ÚIT s tunelováním pomocí GRE příliš nepočítá, nemásmysl nasazovat tunel, který by byl adresovaný IPv6 adresami. Je však nutné, abystávající GRE tunel byl schopen s IPv6 pakety pracovat a vzájemně je přenášet mezilokalitami. Pro site-to-site VPN tak návrh bude zahrnovat pouze výše zmíněnoufunkcionalitu.

5.6.2 Remote Access

Vzdálený přístup, který se používá pro virtuální přistoupení k lokální síti, dlekap. 4.6.5 využívá k zajištění připojení prvek Cisco ASA 5585 ve verzi 9. Návrhkonfigurace tak musí být v souladu s tímto prvkem a především verzí operačníhosystému.

Konfigurace prvku ASA bude sestávat z následujících změn:

• IPv6 adresace služeb DNS, NTP a AAA,

• IPv6 adresace potřebných síťových rozhraní,

• IPv6 směrování (výchozí brána, výchozí brána tunelu),

• definice a přiřazení IPv6 adresních rozsahů pro jednotlivé skupiny VPN klientů.

Výše uvedené změny zajistí, že klient disponující pouze IPv6 adresou budeschopen vytvořit tunel výhradně pomocí tohoto protokolu.

Návrh implementace a jeho verifikace nejsou dále v této práci uvedeny, a toz důvodu chybějící licence pro stávající prvky v síťové laboratoři. Tyto prvky dis-ponují operačním systémem ASA ve verzi 7.0, jehož podpora společností Cisco bylaukončena ke dni 31. října 2015, a který neobsahuje podporu pro IPv6 remote accessVPN. Konfigurační příkazy návrhu implementace by tedy nebylo možné verifikovat.

Dle Cisca (2017) je podpora IPv6 pro Remote-Access VPN přidána ve verzi9.0(1) ze dne 29. 11. 2012. Verze, která je aktuálně nasazena v produkční síti MEN-DELU je vyšší a disponuje tak plnou kompatibilitou pro implementaci protokoluIPv6.

5.7 Zabezpečení na úrovni ASW

Zabezpečení na úrovni přístupového přepínače musí být řešeno systematicky tak, abybyla výsledná konfigurace totožná napříč univerzitou. Výsledkem implementace bytak měly být konfigurační šablony, které by byly k dipozici pro každý typ připojení

5.7 Zabezpečení na úrovni ASW 71

a do budoucna by tak nevznikaly rozdílné konfigurace. Šablony by měly být dostupnépro následující typy prvků:

• koncová stanice, univerzitní síť,

• koncová stanice, kolejní síť,

• datacentrum.

Výjimkou jsou zařízení, která vyžadují statickou konfiguraci. Konfigurace síťo-vého připojení těchto prvků, bude proto záviset na uvážení správce, který budenastavení provádět.

Návrh funkcí, které by měly implementační šablony obsahovat, pak vypadánásledovně.

5.7.1 Koncová stanice, univerzitní síť

Bezpečnost zařízení umístěných v rámci univerzitní sítě je maximální prioritoua hlavním důvodem implementace těchto pravidel na přepínače, které zajišťujípřístupovou vrstvu sítě. Návrh proto zahrnuje celou řadu bezpečnostních funkcí:

• RA Guard,

• IPv6 Snooping,

• DHCPv6 Guard,

• IPv6 Source Guard,

• IPv6 Prefix Guard,

• IPv6 Destination Guard.

5.7.2 Koncová stanice, kolejní síť

V rámci kolejní sítě se jedná většinou o studentské počítače. Nejedná se o kritickéstroje, avšak pokusy o napadení okolních počítačů zde nemusí být výjimkou, je-likož klienti, připojení do přístupových switchů, mohou být často jinak neověřenéosoby. Není zde však takové riziko úniku citlivých dat, jako u počítačů umístěnýchv univerzitní síti:

• RA Guard,

• DHCPv6 Guard,

• IPv6 Source Guard.

5.8 Sledování provozu 72

5.7.3 Datacentrum

Datacentrum je specifická část sítě, u které se nepředpokládá, že by v ní dochá-zelo k přístupům neautorizovaných zařízení či osob. Konfigurace pravidel, která byprováděla blokaci rámců na přístupové vrstvě, tak v této části sítě nelze doporučit,a to především z toho důvodu, že by jejich implementace mohla, spíše než přínos,způsobit potíže.

5.8 Sledování provozu

Sledování provozu pomocí flow na IPv6 bude znamenat zavedení IPv6 kompatibilityna stávajícím řešení FlowMon kolektoru spolu se změnou konfigurace stávajícíchsond. Změna se bude týkat prvků uvedených v následujícím seznamu:

• FlowMon kolektor,

• 3x FlowMon sonda.

5.9 Proxy

Z pohledu nasazení proxy je nutné, aby se nezměnila konfigurace pro uživatele.Nastavení je totiž pro většinu uživatelů, kteří nedisponují potřebnými IT znalostmi,poměrně náročný úkon a nutnost využít jiné řešení pro IPv6 by mohlo způsobitněkterým uživatelům komplikace.

V případě univerzitní proxy se konfigurace týká doménového jménaproxy.mendelu.cz a konfigurace programu squid, který ji obsluhuje. Předpoklademje, aby univerzitní DNS server obsahoval AAAA záznam pro doménové jméno, kterélze přeložit na IPv6 adresu proxy serveru. Obsluhující server pak musí disponovatpodporou pro IPv6 provoz a umožňovat připojení klientům.

Pro obsluhu webové proxy se používá, stejně jako pro univerzitní proxy, pro-gram squid. Konfigurace tedy bude velice podobná jako stávající, pouze se změně-nými rozsahy povolených IP adres z důvodu korektní identifikace zdrojové VLAN.

5.10 AAA služby

Hlavním prvkem AAA služeb v síti MENDELU je server se službou RADIUS, kterýv současnosti obstarává ověřování uživatelů například při pokusu o přístup do sítěWiFi. Používá se ale i na dalších místech a je tak centrálním prvkem pro ověřování.Aktuálně je nejnovější instance tohoto serveru provozována službou FreeRADIUSve verzi 2.2. Té však již v současnosti byla ukončena podpora, a je tak příhodnádoba pro její povýšení na již stabilní verzi 3.0.x.

Pokud by upgrade nebyl proveden, pak by nebylo možné zajistit podporu IPv6.Verze 2.2 totiž neumožňuje obsluhovat autentizace IPv4 a IPv6 klientů zároveň,a v rámci konfigurace je tak nutné vybrat pouze jeden protokol, který bude stroj

5.11 Webové služby 73

obsluhovat. Součástí konfigurace verze 3.0.x, souboru clients.conf, je pak konfigura-ční manuál, který stanovuje nutnost vytvoření klientského záznamu pro IPv4 a IPv6protokol zvlášť. Služba jako taková však již umí naslouchat zároveň na obou proto-kolech. Je proto nutné navrhnout pro ověřování klientů nový server.

Ideálním stavem, který lze v této práci navrhnout, je implementace nového ser-veru, který bude nahrazovat původní Radius server provozovaný v síti MENDELU.Nová verze se pokouší o zachování maximální kompatibility a ačkoli konfiguračnísoubor nelze zachovat celý, nemělo by se jednat o velké změny.

5.11 Webové služby

Aplikace pro provoz webových služeb je třeba nakonfigurovat tak, aby naslouchalyna rozhraní, které je pro příchozí požadavky nakonfigurováno.

Webserver Apache podporuje IPv6 od verze 2.0.14. Bieringer (2017) všakzmiňuje, že pro korektní fungování virtuálních hostů je nutná minimálně verze 2.0.28,a doporučuje použití vždy poslední verze z důvodů bezpečnostních záplat. Z pohledubezpečnosti pak stejně tak, jako u ostatních služeb, platí požadavek na nejaktuálnějšístabilní a odladěnou verzi.

5.12 Poštovní služby

Návrh řešení poštovních serverů byl navržen tak, aby bylo možné zachovat stávajícítopologii i nastavení. Navrženy budou pouze změny přímo vedoucí k podpoře IPv6protokolu. Stávající implementace byla popsána v kap. 4.6.11.

Pro nasazení IPv6 na poštovní služby bude vyžadováno minimálně následujícínastavení:

• IPv6 adresy na síťových rozhraních poštovních serverů,

• vytvoření AAAA a PTR záznamů pro poštovní servery v DNS,

• povolení protokolu IPv6 ve spuštěných službách,

• vytvoření nových pravidel s IPv6 adresací pro firewall.

V případě příchozích mailů bude stroj schopen přijímat zprávy prostřednictvímprotokolu IPv4 i IPv6, je však nutné stanovit protokol, který bude v případě po-třebného rozhodnutí prioritní. Vzhledem k tomu, že protokol IPv4 je v současnostina většině mailových serverů podporován, bude výhodnější jej v případě komuni-kace prioritizovat. Pokud by server nedisponoval IPv4 rozhraním, případně by totorozhraní bylo nedostupné, pak se pokusí o zaslání zprávy pomocí IPv6.

Server by měl být nastaven tak, aby v případě požadavku na odeslání e-mailunejprve zjistil, zdali cílový server podporuje IPv4, v případě, že by tomu tak ne-bylo, tak použil IPv6. V opačném případě by vždy využil IPv4. Tento postup, ačkolise může zdát zpátečnický, má své opodstatnění. Ne všechny mailové servery totiž

5.13 Databázové služby 74

mohou mít protokol IPv6 implementován správně a rychlý přechod by mohl způ-sobit neočekávané problémy. Do budoucna je však ale cílem, aby došlo k přepnutíprioritizace na IPv6 a komunikace probíhala výhradně tímto protokolem.

5.13 Databázové služby

V rámci návrhu řešení databázových služeb je nutné zachovat stávající implementaciprotokolu IPv4 a zajistit, aby byla služba dostupná i pomocí protokolu IPv6.

Implementace MariaDB podporuje IPv6 již verze MariaDB 5.5. Poslední do-stupná verze instalace MariaDB ve výchozím repozitáři programu yum v systémuCentOS 7 je pak verze 5.5.52. Ta bude využita pro návrh, implementace i verifikaci.

5.14 Časové služby

Aby bylo možné synchronizovat čas na zařízeních, která budou v budoucnu pro-vozována pouze na IPv6, je nutné disponovat NTP serverem podporujícím IPv6.Tento protokol podporuje program ntpd ve 4.0 nativně, jeho konfigurace je automa-ticky generovaná v případě detekce podpory rozhraní pro protokol IPv6, viz definicev RFC2553 (1999).

5.15 Zálohovací služby

V analýze uvedené v kap. 4.6.14 byly uvedeny metody zálohování a k nim využívanýsoftware. Na základě zjištěných informací však lze konstatovat, že případná konfi-gurace těchto služeb tak, aby byly provozovány pomocí protokolu IPv6, by jejichsprávcům nepřinesla žádné hmatatelné výhody. Naopak nevýhodou by byla nadby-tečná konfigurace protokolu, který by se k přenášení záloh nevyužíval a mohl by takzpůsobovat komplikace při provozování stávajícího funkčního řešení.

5.16 VoIP

Zařízení, která jsou v současnosti využívána pro VoIP telefonii, nedisponují možnostíkonfigurace IPv6. V případě, že by v budoucnu byl požadavek na schopnost komu-nikace pomocí tohoto protokolu, byla by nutná jejich výměna. V dalších kapitoláchtéto práce tak již VoIP telefonie není dále diskutována.

5.17 Virtualizace

Pro virtualizaci jako takovou nový protokol nepřináší žádné zásadní změny. Vzhle-dem k tomu, že pro komunikaci mezi hypervizory a okolními síťovými zařízeními,mimo provoz managementu, se rozhraní konfigurují přímo ve virtuálních strojích,bude nutné pouze ověřit, že stávající verze aplikací pro virtualizaci podporují pro-tokol IPv6.

5.18 WiFi 75

5.18 WiFi

Návrh řešení pro WiFi musí vycházet z informací popsaných v kapitole Analýzasoučasného stavu a požadavků. Zde bylo uvedeno, že jsou využívána zařízení, kteránení možné povýšit na nejaktuálnější verzi nabízeného softwaru pro WLC. Nebudetak možné využít veškeré funkce pro IPv6, které společnost Cisco nabízí.

Controller Cisco 4402 Wireless Controller, který má v současnosti nasazen soft-ware verze 7.0.240.0 bohužel nelze povýšit na verzi podporující protokol IPv6. Pokudbude řešení uvedené v této práci nasazeno, pak je více než vhodné jej vyměnit za no-vější model, který bude jeho podporou disponovat. Pokud by se tak nestalo, uvedenéřešení bude funkční. Avšak v případě výpadku jednoho z kontrolérů podporujícíchIPv6 a nutnosti přesunu AP na kontrolér Cisco 4402, klienti přijdou o podporuIPv6, kterou mohli na stejném AP disponovat, což jim způsobí ztrátu konektivityse zařízeními IPv6 only.

5.19 Správa koncových stanic

V rámci analýzy využívaných řešení bylo zjištěno, že pro správu se používá přede-vším program Microsoft SCCM. Tento komplexní nástroj disponuje plnou podporoupro IPv6. Prerekvizitou jeho nasazení je řešení Microsoft Active Directory, které tak-též poskytuje plnou podporu pro IPv6 již od verze Windows Server 2008.

Do budoucna je plánováno nastavení, kdy koncové stanice budou adresoványprivátními IPv4 adresami. Ty by byly směrovatelné v rámci celé sítě MENDELUa překládány na perimetru sítě. Toto řešení by zajistilo zachování konektivity k těmtostrojům i za předpokladu, že budou všechny stroje disponovat IPv6 adresou. Není tovšak důvod proč IPv6 na SCCM neimplementovat. V síti se totiž mohou vyskytnoutstroje, které z nějakého důvodu nebudou síť IPv4 využívat a pak by jejich vzdálenáspráva nebyla možná.

Výsledná implementace SCCM by tak měla umožňovat připojit koncovou sta-nici pomocí protokolu IPv6 a pracovat s ní stejným způsobem, jako tomu je u IPv4klientů.

6 IMPLEMENTACE NÁVRHU 76

6 Implementace návrhu

Tato kapitola zahrnuje konfigurace daných služeb včetně implementačních detailů.Výsledná konfigurace přidává funkce, či nahrazuje původní řešení popsaná v kapitoleAnalýza současného stavu a požadavků. Tato implementace je, pokud není řečenojinak, v souladu s kapitolou Návrh řešení.

6.1 DNS

Implementace DNS serveru bude navržena podle návrhu, který je uveden v kapitoleNávrh řešení. Požadovaný stav je existence jedné IPv6 adresy, která bude dostupnáz interní sítě i internetu. Příchozí provoz pak bude směrujícím prvkem přesměrovándle tazatele, který může být lokalizován v interní síti MENDELU či v síti internet,na předdefinovaný DNS server.

K dosažení tohoto stavu je nutné na směrujícím prvku nastavit přesměrovánípaketů pomocí překladu IP adres. Nejvhodnějším řešením je využití služby ip6tables,která na směrujícím prvku označovaném níže jako Firewall bude instalována a spu-štěna, viz kap. 6.2. Není tak třeba instalovat žádný další software. Pro správnoufunkci je nutné, aby server disponoval verzí kernelu 3.9.0 a ip6tables verze 1.4.18(Beringer, 2017). V opačném případě by nebyla dostupná tabulka NAT a nebylo bymožné níže uvedené nastavení aplikovat. Vzhledem k tomu, že směrující prvek budeinstalován nově, pak toto omezení nepředstavuje pro implementaci a nasazení žádnýproblém.

Konfiguraci je nutno provést pomocí překladu adres (NAT). Ačkoli se tatofunkce u IPv4 používala především pro překlad mezi privátními a veřejnými ad-resami, lze ji aplikovat i pro překlad adres veřejných. Výsledkem tak bude ukrytípoužitých adres cílového prvku. To povede k tomu, že dotazující prvek nebude znátadresu zařízení, které mu odpovídá. Ani v případě, že by ji znal, jej z důvodů blo-kování firewallem nebude moci přímo kontaktovat.

Prvním krokem pro aplikaci požadovaného nastavení je konfigurace přesměro-vání paketu na správný prvek. To lze provést pomocí níže uvedených příkazů,jejichž cílem je vždy daný (autoritativní, či rekurzivní) DNS server. Pravidlo jenutné aplikovat ihned po jeho přijmutí daným prvkem, proto je konfigurována volba-A PREROUTING, pravidlo tak bude v případě shody ihned provedeno a dalšíoperace s tímto paketem budou prováděny až po jeho aplikaci. Následně je nutnéprovést identifikaci paketu, který má být přesměrován. Identifikaci paketu DNS lzeprovést parametrem -p udp - -destination-port 53, případně -p tcp - -destination-port53, kdy je testováno, že daný paket využívá protokol UDP, případně TCP, a cílovýport daného paketu je 53, tedy DNS. Po úspěšně provedené identifikaci DNS paketuje nutné rozhodnout, na jaký DNS server bude probíhat směrování. Toto rozhodnutíbude provedeno dle zdrojového rozhraní směrujícího prvku. V případě, že je paketpřijat ze směru vnější sítě, pak je směrován na autoritativní server, pokud ze sítěvnitřní, pak na server rekurzivní, viz níže uvedená konfigurace DNAT.

6.2 Firewalling 77

# KONFIGURACE DNATip6tables -t nat -A PREROUTING -d 2001:718:803:f15::150 -p udp --destination-port 53 -i eth0.22-j DNAT --to-destination 2001:718:803:f15::10ip6tables -t nat -A PREROUTING -d 2001:718:803:f15::150 -p udp --destination-port 53 -i eth0.21-j DNAT --to-destination 2001:718:803:f15::11ip6tables -t nat -A PREROUTING -d 2001:718:803:f15::150 -p tcp --destination-port 53 -i eth0.22-j DNAT --to-destination 2001:718:803:f15::10ip6tables -t nat -A PREROUTING -d 2001:718:803:f15::150 -p tcp --destination-port 53 -i eth0.21-j DNAT --to-destination 2001:718:803:f15::11

Druhým krokem pro kompletní zprovoznění překladu je skrytí IP adresy ser-verů DNS konfigurací překladu zdrojové adresy (SNAT). Ten zajišťuje, že odchozípakety serverů DNS, které mají ve výchozím stavu uvedenou ve zdrojové adrese pa-ketu pravé adresy serverů, budou přeloženy zpět na maskovanou IPv6 adresu. Tentokrok lze provést pomocí funkce SNAT, která se provádí až těsně před odesláním pa-ketu z rozhraní směrujícího prvku v řetězci POSTROUTING. Identifikace paketů,u nichž je nutné provést tuto změnu, se provede pomocí rozsahu zdrojových adres,který pokryje oba DNS servery, použitím příkazu -s. Celá konfigurace je uvedenaníže. Jejím výsledkem, spolu s výše uvedenou konfigurací DNAT, je maskování ad-res DNS serverů a možnost cíleného přesměrování příchozího provozu dle potřebnéfunkcionality.

# KONFIGURACE SNATip6tables -t nat -A POSTROUTING -s 2001:718:803:d209::/64 -j SNAT --to-source 2001:718:803:f15::150

Výše uvedené konfigurace pak společně zajistí požadavek na maskování adresa umožní oba typy DNS serveru (autoritativní, rekurzivní) adresovat pomocí jednéIPv6 adresy.

6.2 Firewalling

Úspěšné nasazení prvku, který bude zajišťovat firewalling pro protokol IPv6 je zá-kladním prvkem implementace celého návrhu.

Vzhledem k tomu, že se jedná o nový prvek, je v první řadě nutné nejprveinstalovat operační systém, na kterém bude služba ip6tables provozována. K tomutoúčelu byl vybrán operační systém CentOS ve verzi 7. Po jeho instalaci bude jednímz kroků nahrazení služby firewalld, která je po instalaci tohoto systému nasazena,viz kap. 4.6.2. Nahrazení lze provést následujícími příkazy.

# Maskování původní služby firewalldsystemctl stop firewalldsystemctl mask firewalld

# Instalace balíčků iptablesyum install iptables-services -y

# Spuštění instalované služby po startusystemctl enable ip6tables

# Spuštění instalované službysystemctl start ip6tables

6.2 Firewalling 78

Logickým krokem bude totožný postup i v případě standardních iptables proprotokol IPv4. Zde je vhodné zablokovat v rámci konfigurace veškerý provoz násle-dujícími příkazy.

iptables -P INPUT DROPiptables -P OUTPUT DROPiptables -P FORWARD DROP

Po úspěšné konfiguraci a spuštění služby ip6tables je následujícím krokem konfi-gurace pravidel, která budou zajišťovat základ celého zabezpečení sítě MENDELU.Tato pravidla je v první řadě vhodné rozdělit do bloků, které umožní jednoduššísprávu a snadnější přehled nad jejich konfigurací. Ačkoli v první fázi nebude kon-figurace firewallu nijak rozsáhlá, předpokládá se její významné rozšíření, jakmilezačne být protokol IPv6 v rámci MENDELU více využíván. Cílem je vytvoření ře-tězců, které budou odpovídat stávající konfiguraci služby iptables. I z toho důvoduzde nebudou všechny zveřejněny.

Základní struktura řetězce forward služby ip6tables pak bude vypadat tak, jakje uvedeno na obr. 24.

Obrázek 24: Diagram pravidel firewallu MENDELU pro protokol IPv6

Jedná se však například o tyto řetězce sloužící k popsaným účelům.

6.2 Firewalling 79

INET DO CP V rámci tohoto řetězce bude docházet ke kontrole vstupních IPv6adres tak, aby pakety s IPv6 adresou z rozsahu 2001:718:803::/48 byly zahozeny. Dálepak ke kontrole, zdali do sítě nemíří pakety, které se v rámci sítě internet nemajívyskytovat, tzv. bogon (Campbell, 2009). Jedná se například o adresy z rozsahufe80::/10, nebo ::1 /128.

CP DO INET Analogicky s předchozím řetězcem je zde kontrolována výstupníIPv6 adresa tak, aby byla z rozsahu 2001:718:803::/48. Odchozí pakety s jinou ad-resou budou zahozeny, viz BCP38 zmíněné v kap. 5.3.

WWW-SERVER V rámci tohoto řetězce, přiřazeného specifickému webovému ser-veru, jsou povolena specifická pravidla pro přístup k jeho zdrojům. V případě, žepaket směrovaný na tento server těmto pravidlům nevyhoví, pak je zahozen.

Řetězce, které jsou uvedeny výše, jsou pouze příkladem. Nejedná se o reálnénázvy, které budou použity v rámci produkčních serverů. Výsledný firewall taktéžbude disponovat výrazně více pravidly, která pokryjí veškeré požadavky sítě IPv6.Výše uvedený řetězec by však v rámci konfigurace ip6tables vypadal následovně.

*filter:FORWARD DENY [0:0]:CP_DO_INET - [0:0]:INET_DO_CP - [0:0]:WWW-SERVER - [0:0]

-A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT-A FORWARD -m state --state INVALID -j DROP

-A FORWARD -i vlan22 -m conntrack --ctstate NEW -j CP_DO_INET-A FORWARD -i vlan21 -m conntrack --ctstate NEW -j INET_DO_CP

-A CP_DO_INET -s 2001:718:803::/48 -j ACCEPT-A CP_DO_INET -j DROP

-A INET_DO_CP -s 2001:718:803::/48 -j DROP-A INET_DO_CP -s [BOGON ADRESY] -j DROP-A INET_DO_CP -d [WWW-SERVER_IPv6] -j WWW-SERVER-A INET_DO_CP -j DROP

-A WWW-SERVER -p tcp -m tcp --dport 80 -j ACCEPT-A WWW-SERVER -p tcp -m tcp --dport 443 -j ACCEPT-A WWW-SERVER -j DROP

COMMIT

Výsledkem výše uvedené implementace bude povolení odchozího provozupouze se zdrojovými adresami z přiděleného rozsahu (2001:718:803::/48) a nao-pak příchozího provozu mimo těchto adres a adres bogon (viz obr. 24). ŘetězecWWW-SERVER pak povoluje pouze provoz směřující na IPv6 adresu serveru po-skytujícího webové služby.

6.3 IDS, IPS 80

6.3 IDS, IPS

Implementace systému pro detekci průniku je zásadním krokem pro zvýšení bezpeč-nosti v síti MENDELU. Vzhledem k tomu, že detekce těchto útoků v současnostinení na protokolu IPv4 vůbec nasazena, je možné navrhnout řešení, které se ne-musí vázat na stávající implementaci. Toto řešení musí vycházet z důkladné analýzya zvážení všech možných řešení.

Pro implementaci serveru jako takového byl vybrán systém CentOS verze 7.K instalaci programu Snort pak vedly následující kroky.

Na systému byly po jeho instalaci kompletní aktualizace všech, již předinsta-lovaných, balíčků. Poté je aplikací Snort vyžadována přítomnost dalších balíčků,jejichž instalaci lze provést pomocí programu yum následujícím příkazem.

#INSTALACE ZÁVISLOSTÍ SNORTyum install gcc flex bison zlib libpcap pcre libdnet libdnet-devel tcpdump epel-release

Po tomto kroku, kdy jsou instalovány všechny závislosti, lze provést instalaciDAQ. To je balík nahrazující přímé dotazy na libcap funkce abstraktní vrstvouusnadňující tuto operaci na rozdílném hardwarovém či softwarovém vybavení bezpotřeby změn přímo v aplikaci Snort. Jeho instalace se provede před instalací sa-motné aplikace Snort, tedy v následujícím pořadí.

#INSTALACE DAQyum install https://www.snort.org/downloads/snort/daq-2.0.6-1.centos7.x86_64.rpm

#INSTALACE Snort 2.9.9.0yum install https://www.snort.org/downloads/snort/snort-2.9.9.0-1.centos7.x86_64.rpm

Aby nově instalovaná aplikace pracovala bez problémů, je vhodné po jejímnasazení provést obnovení pomocí příkazu ldconfig. V rámci instalace pomocí yumje již také vytvořena skupina ”snort” a uživatel ”snort”, což lze ověřit nahlédnutímdo /etc/passwd a /etc/group. Stejně tak tato instalace zajistí většinu potřebnýchzměn v souborovém systému. V rámci testovací instalace nedošlo k vytvoření složkysnort dynamicrules, proto bylo nutné zavolat její vytvoření, stejně tak jako vytvořeníprázdných seznamů pravidel.

mkdir /usr/local/lib/snort_dynamicruleschmod -R 5775 /usr/local/lib/snort_dynamicruleschown -R snort:snort /usr/local/lib/snort_dynamicrulestouch /etc/snort/rules/white_list.rulestouch /etc/snort/rules/black_list.rulestouch /etc/snort/rules/local.rules

Po tomto kroku je aplikace Snort, která bude použita pro detekci hrozeb v sítiMENDELU, kompletně nainstalována. Nyní je však nutné ji nakonfigurovat tak,aby dokázala v první řadě hrozby rozpoznat. Tento krok je přímo závislý na rozhod-nutí vedení ÚIT, zdali se rozhodne využít placenou podporu, která umožní prioritnípřístup k novým pravidlům umožňující okamžitou detekci nových hrozeb. Pokud bytomu tak nebylo, pak by bylo možné disponovat těmito pravidly až po 30 denníochranné lhůtě, což může být dostatečný čas pro útočníka nově objevenou hrozbu

6.3 IDS, IPS 81

využít pro průnik do sítě. V každém případě je k získání pravidel nutné provéstregistraci, která umožní stáhnout pravidla, alespoň s 30 denním zpožděním. Po tétoregistraci lze vygenerován Oink kód, který umožní stažení výše zmíněných pravidel.

Stažení pravidel a jejich nasazení pak lze provést následujícími příkazy.

wget https://www.snort.org/rules/community -O ~/community.tar.gzwget https://www.snort.org/rules/snortrules-snapshot-2990.tar.gz?oinkcode=<vygenerovany_oinkcode> -O~/registered.tar.gz

tar -xvf ~/community.tar.gz -C ~/cp ~/community-rules/* /etc/snort/rules

tar -xvf ~/registered.tar.gz -C /etc/snort

# ZAKOMENTOVÁNÍ VŠECH INCLUDŮ PRAVIDELsed -i ’s/include $RULE_PATH/#include $RULE_PATH/’ /etc/snort/snort.conf

V této chvíli Snort obsahuje pravidla, díky kterým je schopen detekovat pří-padné hrozby. Nyní však nedisponuje žádnou konfigurací, která je pro jeho úspěšnéspuštění potřebná. Tato konfigurace již musí být na míru topologii uvedené naobr. 21, musí totiž obsahovat rozhraní, která budou systémem kontrolována.

#/etc/snort/snort.conf

# Konfigurace domácí sítěipvar HOME_NET 2001:718:803::/48

# Konfigurace externí sítě (NOT domácí)ipvat EXTERNAL_NET !$HOME_NET

Spuštění programu lze provést pomocí následujícího příkazu. Vzhledem k tomu,že však na něj budou navázány další komponenty, není dobré jej v této chvíli pro-vádět.

#SPUŠTĚNÍ PROGRAMU SNORT (NASLOUCHÁ NA <INTERFACE>)sudo snort -A console -q:<quiet> -i <interface> -u snort -g snort -c /etc/snort/snort.conf

Poté, co je kompletně nainstalována služba Snort je nutné rozhodnout, jakýmzpůsobem bude docházet ke stahování pravidel. Ta můžou být pro program Snortaktualizována ručně, či automaticky.

Volba ruční aktualizace by byla výhodná za předpokladu, že změny, které tatoaktualizace provede, by mohly ovlivnit příchozí provoz natolik, že by se některékritické služby mohly stát nedostupnými. Naopak automatická aktualizace pravidelpřináší výhodu v okamžité ochraně před novými hrozbami. Aktuálnost pravidel sebude samozřejmě odvíjet od dostupných zdrojů, pokud nebudou využita placenápravidla, pak budou do serveru doručována s odpovídajícím zpožděním.

Ačkoli nelze předpokládat, že by okamžitá ochrana byla kritickou součástí navr-hovaného řešení zabezpečení, je její nasazení výhodnější už jen z důvodů odlehčeníopakujícího se úkonu případnému správci stroje.

Pro automatické stahování pravidel Snort je určený program Pulled Pork. Tenje možné spouštět pomocí cronu v nastavených intervalech a automaticky tak obno-vovat aktuální pravidla.

6.4 ACL 82

Spuštění programu se poté provede následujícím příkazem obsahujícím vytvoře-nou konfiguraci.

#SPUŠTĚNÍ PROGRAMU PulledPork)/usr/local/pp/bin/pulledpork.pl -c /usr/local/pp/etc/pulledpork.conf -l

Pokud vše proběhne korektně a program Snort lze po provedení výše uvede-ného příkazu spustit, pak lze nastavit tento úkol do cronu tak, aby došlo k jehoautomatickému spuštění v předem nastavených intervalech.

* */1 * * * /usr/local/bin/pulledpork.pl -c /usr/local/etc/snort/pulledpork.conf -T -l>/dev/null 2>&1

Jakmile je dokončena instalace, program je plně funkční a lze jej otestovatnásledujícím příkazem.

snort -q -d -A console -u snort -g snort -c /usr/local/etc/snort/snort.conf -i eth1:eth2 -Q

V této chvíli je aplikace funkční. Přeposílá pakety dle návrhu topologie a chránítak lokální síť před útoky z vnější sítě. Politika nastavení je taková, že v případědetekce problémového paketu je zavolán příkaz ALERT a paket je propuštěn. V tutochvíli je tak program spuštěn pouze v monitorovacím režimu, tedy tzv. IDS (Intru-sion Detection System). Jakmile bude systém po jeho nasazení v univerzitní topologiidostatečně otestován, pak bude možné přepnout detekce na akci DROP a problé-mové pakety nebudou do univerzitní sítě vpuštěny.

Jak již bylo zmíněno výše, aplikace ukládá výstup ve formátu, který neumožňujesprávci rychlý přehled nad zjištěnými riziky. Proto je vhodné ke zobrazení výstupůz aplikace Snort využít program třetí strany, díky kterému bude administrátor dis-ponovat okamžitým přehledem.

Všechna řešení, která jsou volně dostupná a byla vytvořena přímo na míru pro-gramu Snort spolupracují s nadstavbou Barnyard. Databáze této aplikace však vevýchozím stavu neumí pracovat s IPv6 adresami a byly by nutné nemalé úpravy.Mnohem výhodnější tak bude vyčítat výstup detekcí programu Snort pomocí něk-teré z komplexních monitorovacích aplikací, jako je například Graylog, Kibana čiLogstash (všechny Open Source).

6.4 ACL

Konfigurace ACL, které slouží ke kontrole zdrojových adres při opouštění sítě lzekonfigurovat na IPv6 podobně jako u protokolu IPv4. Při implementaci jsou pouzezměněna klíčová slova v rámci konfigurace. Vzhledem k tomu, že v síti MENDELUjsou prakticky bez výjimek prvky značky Cisco Systems, bude uvedena konfiguracepouze pro prvky tohoto výrobce.

interface XXip access-group SXX inipv6 traffic-filter SXX in

ip access-list extended SXX

6.5 VPN 83

permit ip 195.178.79.0 0.0.0.255 anydeny udp any any log-inputdeny tcp any any log-inputdeny ip any any log-input

ipv6 access-list SXXpermit ipv6 2001:718:803:d79::/64 anydeny udp any any log-inputdeny tcp any any log-inputdeny ipv6 any any log-input

Výše uvedenou konfiguraci IPv6 ACL lze v současnosti z důvodů zmíněnýchv kap. 5.5 nasadit pouze na prvcích, které disponují podporou IPv6 port ACL.V případě přepínačů, které tuto volbu nepodporují je vhodné nasadit IPv6 ACL narozhraní, do kterého jsou zapojeny.

6.5 VPN

6.5.1 Site to Site

Implementace návrhu řešení, které bylo navrženo v kap. 5.6.1, sestává z návrhukonfiguračních parametrů GRE tunelu v rámci zařízení Cisco tak, aby bylo možnépomocí IPv4 GRE tunelu přenášet mimo jiné IPv6 provoz.

Úpravu, kterou bude nutné v rámci tunelu zavést, je zavedení příkazu tunnelmode ipv6ip do konfigurace rozhraní tunelu spolu s konfigurací IPv6 adresy.

Výsledná konfigurace rozhraní tunelu by pak mohla vypadat například takto.

interface Tunnel1ip address 192.168.1.2 255.255.255.0mtu 1476ipv6 address 2001:718:803:D::2/64tunnel source GigabitEthernet0/0tunnel destination 192.168.0.1tunnel mode ipv6ip!

6.6 Zabezpečení na úrovni ASW

Na základě návrhu řešení, viz kap. 5.7, zde budou uvedeny konfigurační šablony pronásledující typy zapojení koncových prvků. Výsledné konfigurace jsou pak uvedenyuvedeny níže v této kapitole:

• koncová stanice, univerzitní síť,

• koncová stanice, kolejní síť.

6.6.1 Koncová stanice, univerzitní síťipv6 access-list <nazev listu ACL alc1>

permit host <ipv6 adresa DHCPv6 serveru> any

ipv6 access-list <nazev listu ACL acl2>permit host <ipv6 adresa klienta> any

6.6 Zabezpečení na úrovni ASW 84

ipv6 prefix-list <nazev listu ipv6_prefix_list_1> permit <adresa site ipv6>/<delka prefixu> ge 128ipv6 prefix-list <nazev listu ipv6_prefix_list_2> permit <adresa site ipv6>/<delka prefixu> le 128

ipv6 dhcp guard policy <nazev politiky dhcp_guard_policy>device-role servermatch server access-list <nazev listu ACL acl1>match reply prefix-list <nazev listu ipv6_prefix_list_2>preference min 0preference max 255trusted-port !aplikujeme pouze u politiky, kterou přiřazujeme k důvěryhodnému rozhraní

ipv6 snooping policy <nazev politiky ipv6_snooping_policy>destination-glean recovery dhcpdata-glean recovery ndpprotocol dhcp prefix-list <nazev listu ipv6_prefix_list_1>prefix-glean

ipv6 destination-guard policy <nazev politiky ipv6_destination_guard_policy>enforcement stressed

ipv6 source-guard policy <nazev politiky ipv6_source_guard_policy>permit link-localdeny global-autoconftrusted !aplikujeme pouze u politiky, kterou přiřazujeme k důvěryhodnému rozhraníno validate addressvalidate prefix

ipv6 nd inspection policy <nazev politiky ipv6_nd_inspection_policy>drop-unsecuresec-level minimum 2tracking disable stale-lifetime infinitetrusted-port !aplikujeme pouze u politiky, kterou přiřazujeme k důvěryhodnému rozhraní

ipv6 nd raguard policy <nazev politiky ipv6_ra_guard_policy>device-role host|router !vyber dle typu portumanaged-config-flag onmatch ipv6 access-list <nazev listu ACL acl2>

ipv6 neighbor tracking

ipv6 neighbor binding <ipv6_adresa klienta> interface <rozhrani> <cislo rozhrani>ipv6 neighbor binding max-entries 100ipv6 neighbor binding logging

interface <rozhrani> <cislo rozhrani>ipv6 snooping attach-policy <nazev politiky ipv6_snooping_policy>ipv6 nd inspection attach-policy <nazev politiky ipv6_nd_inspection_policy>ipv6 destination-guard attach-policy <nazev politiky ipv6_detination_guard_policy>ipv6 source-guard attach-policy <nazev politiky ipv6_source_guard_policy>ipv6 nd raguard attach-policy <nazev politiky ipv6_ra_guard_policy>

6.6.2 Koncová stanice, kolejní síťipv6 access-list <nazev listu ACL alc1>

permit host <ipv6 adresa DHCPv6 serveru> any

ipv6 access-list <nazev listu ACL acl2>permit host <ipv6 adresa klienta> any

6.7 Sledování provozu 85

ipv6 prefix-list <nazev listu ipv6_prefix_list_2> permit <adresa site ipv6>/<delka prefixu> le 128

ipv6 nd raguard policy <nazev politiky ipv6_ra_guard_policy>device-role host|router !vyber dle typu portumanaged-config-flag onmatch ipv6 access-list <nazev listu ACL acl2>

ipv6 dhcp guard policy <nazev politiky dhcp_guard_policy>device-role servermatch server access-list <nazev listu ACL acl1>match reply prefix-list <nazev listu ipv6_prefix_list_2>preference min 0preference max 255trusted-port !aplikujeme pouze u politiky, kterou přiřazujeme k důvěryhodnému rozhraní

ipv6 source-guard policy <nazev politiky ipv6_source_guard_policy>permit link-localdeny global-autoconftrusted !aplikujeme pouze u politiky, kterou přiřazujeme k důvěryhodnému rozhranívalidate address

ipv6 snooping policy <nazev politiky ipv6_snooping_policy> !Snooping je třeba implementovatv základním tvaru, aby bylo možné korektně provozovat funkci IPv6 Source Guard.

interface <rozhrani> <cislo rozhrani>ipv6 snooping attach-policy <nazev politiky ipv6_snooping_policy>ipv6 nd raguard attach-policy <nazev politiky ipv6_ra_guard_policy>ipv6 source-guard attach-policy <nazev politiky ipv6_source_guard_policy>

Výše uvedené konfigurační šablony pokrývají bezpečnostní funkce, které by bylovhodné implementovat v rámci přístupové vrstvy, jak je uvedeno v kap. 5.7.

6.7 Sledování provozu

Implementace serveru, provozujícího monitoring sítě pomocí flow, znamená změnukonfigurace v rámci GUI. Pokud by byl server instalován od počátku, pak po jehoinstalaci, v rámci prvotní konfigurace, lze použít pouze IPv4 adresaci, viz obr. 25,použití IPv6 adresy zde není dovoleno.

Obrázek 25: Úvodní konfigurace Flowmon Virtual Appliance

6.8 Proxy 86

Nastavení IPv6 adresy lze provést až v rámci grafického uživatelského rozhranív záložce System sekce Configuration Center, viz obr. 26, kde je možná její změnau obou management rozhraní. Poté, co je nastavení uloženo, je webové rozhraní do-stupné i za pomocí IPv6 adresy, avšak pouze pomocí protokolu HTTPS (443/tcp),a to i přesto, že dle nastavení pravidel firewallu prvku je povolen přístup i prostřed-nictvím protokolu HTTP (80/tcp). Jedná se tak nejspíše o předimplementovanýbezpečnostní mechanismus daného zařízení.

Obrázek 26: Konfigurace IPv6 adresy Flowmon Virtual Appliance

Schopnost provádět záznam IPv6 paketů pak není nutné v nastavení povolovat.Flowmon Virtual Appliance tyto pakety zpracovává ve výchozím stavu a je schopennad nimi provádět standardní výběry či analýzy, stejně jako tomu je u protokoluIPv4.

6.8 Proxy

Pro uživatelskou i webovou proxy se v současnosti využívá program squid. Vzhledemk tomu, že v současnosti je již v síti MENDELU squid instalován, implementace sebude zabývat pouze úpravou jeho konfigurace tak, aby byla kompatibilní s IPv6.Squid disponuje plnou podporou tohoto protokolu a očekávané změny tak nejsouvelké.

Změna konfigurace uživatelské proxy sestává z přidání a aplikace přístupovýchpravidel. Jejich přidání pro povolení komunikace IPv6 v rámci konfiguračního sou-boru programu, umístěného v /etc/squid/squid.conf bude nutné upravit o následu-jící konfiguraci.

Definovat IPv6 adresu klienta13, ze které má být proxy server přístupný v rámcisquid.conf.

13V případě této konfigurace bude pro ukázku použita jedna z IPv6 adres přiděleného /48 bloku.

6.8 Proxy 87

acl allowed_networks src 2001:718:803:a::10/128

Následně je nutné aplikovat toto přístupové pravidlo v rámci konfigurace tak,aby klient získal přístup k serveru.

http_access allow allowed_networks

V rámci konfigurace je možné definovat do jednoho ACL více klientských adresči sítí. Je však vždy nutné myslet na to, že jejich povolení je nutné provést i v konfi-guraci lokálního a univerzitního firewallu. Současně je však tato konfigurace svázánas univerzitním informačním systémem, který klienta žádajícího o přístup ověří a jehoIP adrese přidělí přístup. Tento informační systém tak bude nutné upravit tak, abybyl schopen pracovat i s IPv6 adresami.

Návrh řešení pro webovou proxy pak bude velice podobný, jako tomu bylo u uži-vatelské proxy. I v tomto případě je potřeba v konfiguraci programu squid povolitrozsahy IPv6 adres, které mají povoleno proxy využívat. V tomto případě se všakjedná o celý adresní blok, který je přidělen VLAN síti, v níž jsou umístěni klienti,jimž je umožněno tuto proxy využívat. Konfigurace webové proxy pak obsahujejistá omezení dostupných doménových jmen, která však pro testování IPv6 nejsoudůležitá. Zásadní změnou oproti konfiguraci uživatelské proxy je její transparent-nost, kdy uživatelské požadavky jsou na ni automaticky směrovány bez jakékolivjejich součinnosti. Toho lze standardně dosáhnout pomocí jejich přesměrování, pro-vedeného například pomocí služby ip6tables na výchozí bráně, kam jsou směřoványklientské požadavky. V případě ip6tables pak konfigurace vypadá následovně:

<vstupni interface> - Název rozhraní, prostřednictvím kterého bude paket doručen.

<rozsah zdrojové VLAN> - Rozsah zdrojových adres, které jsou přidělovány klientským zařízením v danéVLAN ve formátu <IPv6/prefix>

<cílová adresa> - Definice adresy serveru. Požadavky jemu adresované budou směrovány do služby squid.Využití doménového jména je možné, ale nedoporučuje se z důvodu, že jeho překlad je proveden pouzejednou při uložení pravidla.

ip6tables -t nat -A PREROUTING -i <vstupni interface> -s <rozsah zdrojové VLAN> -d <cílová adresa>-p tcp --dport 80 -j REDIRECT --to-port 8080ip6tables -t nat -A PREROUTING -i <vstupni interface> -s <rozsah zdrojové VLAN> -d <cílová adresa>-p tcp --dport 443 -j REDIRECT --to-port 8080

Výše uvedená konfigurace směruje pakety klientských zařízení na port 8080daného serveru, aktuálně provozujícího proxy squid. Tyto pakety je nutné zpracovata v rámci transparentního módu zajistit směrování ke správnému serveru a naopak.V rámci konfigurace squid.conf vypadá konfigurace následovně.

http_port 8080 transparent # Pro squid ve verzi 2.6 nebo 2.7http_port 8080 intercept # Pro squid ve verzi 3.0 a vyšší

acl allowed_networks src <rozsah zdrojové VLAN>

6.9 AAA služby 88

Výše uvedeným nastavení se proxy stává transparentní, uživatelé tedy o jejíexistenci nemusí být nijak informování a pakety, které mají být jejím prostřednictvímsměrovány, jsou přeposílány.

6.9 AAA služby

Implementace AAA služeb bude uvádět implementaci serveru FreeRADIUS tak,jak bylo navrženo v kap. 5.10. V rámci této kapitoly se bude jednat o implemen-taci výchozí instalace serveru, a to především z důvodu otestování její funkčnostia schopnosti pracovat s IPv6 adresací tak, jak je na webu FreeRadius projektu uvá-děno.

Implementace pak bude zahrnovat konfiguraci IPv4 a IPv6 klienta, a to z dů-vodů, aby bylo možné verifikovat současný běh v rámci jedné služby při verifikačnímtestu.

client hostv4{ipv4addr = <ipv4_adresa sítě>/<prefix> # anysecret = <heslo_plaintext_v4>

}

client localhostv6{ipv6addr = <ipv6_adresa sítě>/<prefix> # localhostsecret = <heslo_plaintext_v4>

}

Další změny v konfiguraci nejsou nutné.

6.10 Webové služby

Jak již bylo zmíněno v kap. 5.11, webový server Apache, který má být přístupnýpomocí protokolu IPv6, musí být instalován minimálně ve verzi 2.0.28, která podpo-ruje IPv6 a neobsahuje žádné zásadní bezpečností mezery. Následně je nutné v rámciaplikace Apache provést změnu konfigurace v souboru httpd.conf.

Níže uvedený návrh řešení předpokládá využití dual stacku, tedy současnéhoprovozu IPv6 i IPv4 na jednom rozhraní.

Listen 195.178.72.2:80Listen [2001:718:803:d222::2]:80NameVirtualHost 195.178.72.2:80NameVirtualHost [2001:718:803:d222::2]:80

<VirtualHost 195.178.72.2:80 [2001:718:803:d222::2]:80>ServerName www.mendelu.czServerAlias mendelu.cz</VirtualHost>

Samozřejmě také bude nutné povolit přístup k těmto zdrojům ve firewallu da-ného webového serveru. V případě služby ip6tables by k povolení přístupu postačo-valo pravidlo.

-A INPUT -m tcp -p tcp --dport 80,443 -j ACCEPT

6.11 Poštovní služby 89

6.11 Poštovní služby

Implementace poštovních serverů vychází ze skutečnosti, že aktuálně provozovanéservery disponují softwarovým vybavením podporujícím protokol IPv6. Implemen-tační část pak zahrnuje změny, popsané v kap. 5.12, jejichž konfigurace je uvedenaníže:

• IPv6 adresy na síťových rozhraních poštovních serverů,

• vytvoření AAAA a PTR záznamů pro poštovní servery v DNS,

• povolení protokolu IPv6 ve spuštěných službách,

• vytvoření nových pravidel s IPv6 adresací pro firewall.

6.11.1 IPv6 adresy na síťových rozhraních poštovních serverů

Konfigurace adresace bude vycházet z návrhu adresace použité v síti MENDELU.Adresy pak mohou být ve stejné, či odlišné síti. Doporučený prefix pro tyto sítě je/64.

6.11.2 Vytvoření AAAA a PTR záznamů pro poštovní servery v DNS

Editace DNS bude vyžadovat změnu záznamů v rekurzivním DNS serveru. Za před-pokladu, že je povoleno dotazování pomocí IPv6, je nutné zavést IPv6 (AAAA)záznamy do DNS. V případě DNS serveru s názvem mail.mendelu.cz, IPv4 adre-sou 195.178.72.10 a IPv6 adresou 2001:718:803:a::101 se bude jednat o následujícíkonfiguraci.

mail IN A 195.178.72.10IN AAAA 2001:718:803:a::101

Aby bylo možné přeložit konkrétní adresu na DNS záznam a ověřit tak existencidomény, z důvodů zapnutého bezpečnostního mechanismu reject unknown client, jenutné konfigurovat PTR záznam a s ním související konfiguraci zónového souboru.

#/etc/named.confzone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.a.0.0.0.3.0.8.0.8.1.7.0.1.0.0.2.ipv6.arpa"IN{type master;file "db.reverz.6";

};

#/var/named/db.reverz.6$TTL 86400$ORIGIN 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.a.0.0.0.3.0.8.0.8.1.7.0.1.0.0.2.ipv6.arpa.@ IN SOA 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.a.0.0.0.3.0.8.0.8.1.7.0.1.0.0.2.ipv6.arpa.mail.mendelu.cz. (

0 ; serial1D ; refresh1H ; retry1W ; expire3H) ; minimum

IN NS relay.mendelu.cz.

6.12 Databázové služby 90

101 IN PTR mail.mendelu.cz.

Výše uvedenou konfiguraci je pak vhodné ověřit pomocí příkazu dig, či nslookup.

6.11.3 Povolení protokolu IPv6 ve spuštěných službách

Protokol IPv6 je potřeba povolit v rámci konfigurace programu postfix. Ta je uloženav konfiguračním souboru /etc/postfix/main.cf. V rámci stávající konfigurace jdeo následující změny.

# Nastavení rozsahu vlastní sítě, která je považována za důvěryhodnoumynetworks = <puvodni IPv4 rozsahy>

[2001:718:803::]/48

# Povolení komunikace prostřednictvím protokolu IPv4 i IPv6, lzekonfigurovat i příkazem inet_protocols = ipv4, ipv6inet_protocols = all

# Povolení lokální adresy k tomu, aby pomocí ní bylo možné odesílat e-mailové zprávysmtp_bind_address6 = 2001:718:803:a::101

# Konfigurace preference, v současnosti doporučováno ipv4, lze však použít i ipv6smtp_address_preference = ipv4

Jakmile je toto nastavení hotové, je konfigurace mailových serverů, samozřejměpo restartu služby postfix, kompletní.

6.11.4 Vytvoření nových pravidel s IPv6 adresací pro firewall

Konfigurace firewallu odpovídá standardním pravidlům pro provoz mailů s tím roz-dílem, že v konfiguraci budou použity IPv6 adresy. Pravidla by poté mohla vypadattakto.

-A INET_DO_CP -d [IPv6 adresa MAIL serveru] -j MAIL-A MAIL -p tcp -m tcp --dport 25 -j ACCEPT # SMTP-A MAIL -p tcp -m tcp --dport 465 -j ACCEPT # SMTPS-A MAIL -p tcp -m tcp --dport 993 -j ACCEPT # IMAPS-A MAIL -p tcp -m tcp --dport 995 -j ACCEPT # POP3S

V této chvíli je implementace hotová a je možné prostřednictvím tohoto serverupřijímat a odesílat e-mailové zprávy.

6.12 Databázové služby

Implementace databázových služeb bude navržena pro program MariaDB 5.5.52.Změna konfigurace tak, aby byla služba kompatibilní s protokolem IPv6, bude se-stávat z těchto kroků:

• konfigurace IPv6 adres na rozhraní,

• povolení přístupu pro IPv6 adresy.

6.13 Časové služby 91

Povolení přístupu k databázi lze provést pomocí CLI, a to přiřazením práv propřihlášení z univerzitní sítě pro daného uživatele. Konfigurace přístupových právprostřednictvím CLI14 bude vypadat následovně.

GRANT ALL PRIVILEGES ON *.* TO ’<uzivatel>’@’<IPv6 adresa>’ IDENTIFIED BY ’<heslo>’WITH GRANT OPTION;

Poté je nutné v rámci konfigurace MariaDB (my.cnf) povolit naslouchání narozhraní IPv6, a to následující konfigurací.

bind-address=::

Ověřit, že služba naslouchá lze pomocí příkazu netstat.

#netstat -anp | grep 3306tcp6 0 0 :::3306 :::* LISTEN 6631/mysqld

Služba naslouchá na výchozím portu na portu 3306. Nastavení je korektní.

6.13 Časové služby

Implementace časových služeb je totožná s implementací této služby pro IPv4,jakmile je přítomné rozhraní disponující IPv6 adresou a platná konfigurace, slu-žba na této adrese začne odpovídat a tím poskytovat službu NTP. Pokud by tomutak nebylo, je nutné zkontrolovat konfigurační soubor /etc/default/ntp, který musíobsahovat následující konfiguraci.

NTPD_OPTS=’-g’

Dále je nutné povolit rozsah lokální sítě v nastavení /etc/ntpd.conf tak, abyserver akceptoval požadavek na synchronizaci, a to násedující konfigurací.

restrict 2001:718:803:: mask ffff:ffff:ffff:: nomodify notrap

Úspěšnou konfiguraci, tedy to že server naslouchá na portu 123/udp, lze ověřitpomocí příkazu.

netstat -anp | grep :123

6.14 Virtualizace

Implementace hypervizorů, které zajišťují provoz nativně virtualizovaných strojů, jev současnosti poměrně náročně implementované řešení, které navíc vyžaduje drahélicence. Zdroje, které do jejich zakoupení byly investovány, jsou však náležitě vy-váženy robustností řešení a funkcionalitou. VMWare ESXi podporou IPv6 disponujíjiž od verze 4.1.

Povolení komunikace prostřednictvím IPv6 pak na VMWare ESXi ve verzi 5.xa 6.0 probíhá následujícím způsobem:14CLI – Command Line Interface

6.15 WiFi 92

• ve Webovém klientu vSphere přejít na hostitele,

• v záložce Manage vybrat Networking a poté Advanced,

• vybrat volbu IPv6 support, vybrat požadované nastavení, viz obr. 27,

• v případě změny nastavení restartovat hostitele, aby došlo k jejich aplikaci.

Obrázek 27: Povolení komunikace prostřednictvím IPv6 pomocí Webového klientavSphere

Poté hostitelé disponují plnou podporou protokolu IPv6 a je možné adresovathostitele a především provozovat virtuální stroje i pomocí IPv6 adres.

6.15 WiFi

Implementace návrhu kopíruje návrh řešení, popsaný v předchozí kapitole.Prvním krokem, který doporučuje Cisco (2017) provést před nasazením IPv6,

je povýšení softwaru na kontrolérech na nejnovější možnou verzi. Vzhledem k tomu,že stávající verze, které jsou na kontrolérech nasazeny, nejsou nejnovější dostupnoustabilní verzí, pak bude prvním krokem jejich povýšení.

6.15.1 Povýšení kontroléru na aktuální verzi

Update kontroléru na verzi podporující IPv6 lze provést v následujících krocích:

• nahrát novou verzi firmware na úložiště přístupné pomocí TFTP,

• v záložce COMMANDS vybrat položku Download file to Controller,

• vybrat typ souboru Code a mód přenosu TFTP,

• nastavit zdroj souboru umístěného na TFTP úložišti,

• spustit stahování.

Nový firmware se stáhne do zařízení a nastaví se jako záložní obraz. To lze ověřitzadáním následujícího příkazu do konzole.

(Cisco Controller) >show bootPrimary Boot Image............................... Code 7.0.240.0 <active>Backup Boot Image................................ Code 7.2.100.0

6.15 WiFi 93

Aktivaci nového firmawru lze provést zadáním následujícího příkazu.

(Cisco Controller) >config boot backup

Pokud by byl stroj v této chvíli restartován, pak by došlo k bootu nově staženéhoobrazu. Připojená AP by však disponovala starým obrazem a výpadek konektivityby se prodloužil na dobu potřebnou ke stažení nové verze. Tomu se dá předejítpomocí funkce predownload, která se vyvolá následujícím příkazem, a která provedepředstažení nového firmwaru do záložního oddílu tak, aby po restartu mohl být tentooddíl jednoduše vybrán a AP nastartovalo v co nejkratším možném čase.

(Cisco Controller) >config ap image predownload backup all

6.15.2 Konfigurace IPv6 na kontroléru

Prerekvizitou pro úspěšné nasazení IPv6 na WLC je připravená konfigurace adresaceklientů v rámci sítě VLAN, do které budou asociovaní klienti připojováni. Bez tétokonfigurace by níže uvedené nastavení nebylo nic platné.

Na kontroléru je nejdříve nutné nastavit parametry IPv6. Prvním krokem je takkonfigurace IPv6 adresy na rozhraní, které slouží pro management a pro správu AP,tedy se zapnutým parametrem Dynamic AP Management. Jakmile je tato konfigu-race nastavena, pak lze z počítače, zapojeného do stejné sítě a disponujícího IPv6adresou, přistoupit do GUI kontroléru pomocí IPv6 adresy, viz obr. 28.

Výše uvedenou konfiguraci IPv6 na rozhraní určeného pro správu (management)je možné provést pouze tehdy, pokud v síti není používán Cisco Prime Infrastructureve verzi 2.1 a starší, pak by totiž došlo k jeho ztrátě konektivity s WLC a nebylo bytak možné kontrolér pomocí Cisco Prime Infrastructure spravovat.

Dalším krokem je nastavení multicastové adresy v rámci sítě, jehož nastaveníje vyžadováno. Adresa pak musí vyhovovat požadavkům uvedených v RFC7346(2014), tedy být z rozsahu FFXX::/16. Multicast v rámci sítě není nutné využívat,jeho použití je však doporučováno, a to z důvodů snížení zátěže sítě a předevšímkontroléru. Jeho konfiguraci lze provést v CLI pomocí následujících příkazů.

# Zapnutí multicast na WLCconfig network multicast mode multicast

# Vypnutí multicast na WLCconfig network multicast unicast

Nelze také opomenout nastavení minimálně základních funkcí pro zabezpečení,které jsou pro implementaci IPv6 v rámci kontroléru připraveny.

IPv6 RA Guard je funkce zamezující bezdrátovým klientům možnost posílat RAzprávy určené koncovým stanicím na stejné síti. Její zapnutí se provede v menuCONTROLLER>IPv6>RA Guard tak, že v dropdownu IPv6 RA Guard on AP sevybere volba Enable.

6.15 WiFi 94

Obrázek 28: Ukázka GUI kontroléru přístupného pomocí protokolu IPv6

IPv6 RA Throttling je First-Hop security funkcionalita, která limituje počet mul-ticastových RA kolujících na bezdrátové síti. IPv6 RA throttler sleduje RS (žádostirouteru - router solicitaions) a provádí konverzi těch, které jsou zaslány jako multi-cast na unicast. Zapnutí této funkce se provede v menu CONTROLLER>IPv6>RAThrottle Policy zaškrtnutím checkboxu Enable RA Throttle Policy check box. Pronasazení v rámci sítě MENDELU je vhodné nechat ostatní volby tohoto konfigura-čního okna ve výchozím nastavení.

Tento návrh řešení zahrnuje konfiguraci IPv6 na WLC kontroléru spolu s plnoupodporou provozu IPv4. Provoz, který je tunelovaný mezi WLC a LAP, pak můžebýt adresován IPv4 či IPv6 adresou. Z webu Cisco Systems pak neplynou žádnádoporučení, která by preferovala IPv6 tunel, oproti stávajícímu řešení používajícímuprotokol IPv4.

Závěrem tak lze konstatovat, že přechod na adresaci tunelování pomocí IPv6by nepřineslo žádné výhody, naopak by vyžadovalo změnu v konfiguraci provozu,který je zasílán z LAP k WLC. V současnosti tak bude výhodnější zachovat tu-nelování pomocí protokolu IPv4 a přidat možnost využívat i IPv6 protokol. Budevšak příhodné ověřit i funkcionalitu řešení IPv6 tunelování tak, aby jej bylo možnév případě potřeby nasadit v nejkratším možném termínu.

6.16 Správa koncových stanic 95

6.16 Správa koncových stanic

Implementace IPv6 pro účely správy koncových stanic se bude skládat předevšímz úpravy konfigurace serverů provozující službu Active Directory (AD). Služba Sys-tem Center Configuration Manager totiž pracuje pouze s doménovými jmény a adre-saci si zjišťuje na základě informací z lokálního DNS serveru umístěného na serveruse službou AD.

Implementace doménového serveru musí zahrnovat konfiguraci jeho síťovýchrozhraní tak, aby disponovaly IPv6 adresou. Ideální v tomto případě bude využítdual-stack, kdy jedno rozhraní disponuje IPv4 i IPv6 adresou a nebude tak nutnéprovádět žádné zásadní změny v rámci topologie sítě.

Dále je pak nutné zajistit, aby služba DNS tohoto serveru obsahovala IPv6(AAAA) záznamy. Toho lze docílit pomocí ruční konfigurace, vhodnější ale budenastavení serveru relay.mendelu.cz do volby forwarder. Server provozující ActiveDirectory tak v případě příslušného požadavku pomocí rekurzivního dotazu zjistípožadovanou adresu a je schopen ji použít či poskytnout. Posledním krokem ve-doucím ke zprovoznění DNS serveru je povolení IPv6 adresy, na které daný servernaslouchá, a z níž obsluhuje požadavky.

Samozřejmě je pak nutné, aby doménový klient, který má být v kontaktu seserverem, disponoval IPv6 adresou a byl serverem kontaktovatelný.

Doména Active Directory již dále pracuje pouze s doménovými jmény. V pří-padě, že je dostupná IPv6 konektivita, ji navíc preferuje oproti IPv4. Veškerá komu-nikace se zařízeními v rámci domény pak bude probíhat výhradně pomocí protokoluIPv6.

7 VERIFIKACE NAVRŽENÉHO ŘEŠENí 96

7 Verifikace navrženého řešení

K verifikaci implementační části této práce byly využity prvky umístěné v labora-toři počítačových sítí Ústavu informatiky PEF. Verifikace probíhala dle jednotlivýchsekcí, jejichž implementace pokrývá součásti potřebné pro kompletní nasazení pro-tokolu IPv6 v infrastruktuře MENDELU.

7.1 DNS

Verifikace řešení DNS, které bylo navrženo v předchozí kapitole, byla prováděnapomocí dvou klientských zařízení. Jedno z těchto zařízení bylo umístěno v síti VLANzapojené do VRF CernaPole, simulující lokální síť, druhé pak v síti VLAN, kterábyla přímo připojena k VRF Internet. Topologický diagram implementované sítě, nakteré byla verifikace prováděna, kopíroval mimo výše zmíněné klienty návrh řešení,viz obr. 19.

Testovaným cílem tohoto verifikačního testu byla v obou případech virtuálníIPv6 adresa DNS serveru 2001:718:803:f15::150. Ta je jedinou možnou adresou, kteráslouží pro kontakt DNS serverem, a to z lokální i vnější sítě. Tato adresa byla naklientském zařízení nastavena jako výchozí pro zasílání DNS dotazů. Požadavek bylzaslán pomocí nástroje příkazového řádku nslookup.

Předmětem verifikace pak bylo ověření skutečnosti, že zasílané požadavky jsoukorektně směrovány na autoritativní či rekurzivní DNS server dle jejich zdroje.

7.1.1 Simulace autoritativního požadavku

Cílem tohoto testu bylo ověřit, že požadavek zaslaný ze sítě internet, jehož cílem jevirtuální IPv6 adresa 2001:718:803:f15::150, bude doručen na požadovaný, autorita-tivní, DNS server. IPv6 adresa autoritativního serveru je 2001:718:803:f15::10, vizobr. 19.

Pro účely simulace vnější sítě byla vytvořena VLAN 10, přímo připojenádo VRF Internet. Klient, z něhož byl požadavek zasílán, pak disponoval adresou2001:718:803:d20::10/64. Na tomto klientovi byla konfigurována IPv6 adresa DNSserveru v souboru /etc/resolv.conf následovně.

search firma.cznameserver 2001:718:803:f15::150

Testovaný požadavek překladu doménového jména na IPv6 adresu, jehož cílembylo virtuální rozhraní, pak spolu s jeho výstupem vypadal následovně.

> nslookup -query=AAAA pc.firma.czServer: 2001:718:803:f15::150Address: 2001:718:803:f15::150#53

pc.firma.cz has AAAA address 2001:718:803:123::123

Z výstupu požadavku lze vyvodit, že byl úspěšně směrován na stroj poskytujícíslužbu DNS. Potvrzení, že byl opravdu doručen k rozhraní autoritativního DNS

7.1 DNS 97

serveru a IPv6 adresou 2001:718:803:f15::10, lze získat náhledem do odchycenýchpaketů na zmíněném stroji, kde byl paket s DNS požadavkem zaznamenán, vizobr. 29, s uvedenou adresa autoritativního DNS serveru.

Obrázek 29: Odchyt DNS požadavku na PC simulujícím autoritativní DNS server

Požadavek z vnější sítě tak byl korektně doručen k rozhraní správného DNSserveru.

7.1.2 Rekurzivní požadavek

Cílem bylo ověření skutečnosti, že stejný požadavek na překlad, jako byl zaslánv sekci 7.1.1, bude přijat a doručen na rekurzivní DNS server, jehož IPv6 adresabyla 2001:718:803:f15::11.

Stejně tak jako v předchozí sekci byl odeslán DNS požadavek na virtuální adresuDNS serveru, kterou překládá stroj Firewallv6, 2001:718:803:f15::150, avšak s tímrozdílem, že tento požadavek byl zaslán z lokální sítě. Simulován tedy byl rekurzivnípožadavek klienta v síti MENDELU. Příkaz nslookup a jeho výstup na klientovi pakvypadal následovně.

> nslookup -query=AAAA pc.firma.czServer: 2001:718:803:f15::150Address: 2001:718:803:f15::150#53

pc.firma.cz has AAAA address 2001:718:803:123::123

DNS požadavek pak byl viditelný v odchycených paketech na stroji simulujícírekurzivní DNS server.

I v tomto případě byl paket doručen ke správnému DNS serveru. Verifikační testsměrování k autoritativnímu i rekurzivnímu serveru tak lze označit jako úspěšný.

7.1.3 Verifikace zabezpečení DNS

Pokud by uživatel ve vnější síti jakýmkoli způsobem zjistil IPv6 adresu autorita-tivního serveru, pak by, především z bezpečnostních důvodů, měl být přesto nucenvyužívat virtuální rozhraní pro DNS 2001:718:803:f15::150. Toho lze docílit tak, ževeškerá komunikace směrovaná z vnější sítě, jejíž cílem budou adresy autoritativníhoči rekurzivního serveru, bude zahazována. Pro ukázku zde bude uveden pouze veri-fikační test zahození požadavku na rekurzivní server z vnější sítě. Všechny ostatníkombinace požadavků dopadly se stejným výsledkem.

Testování komunikace bylo provedeno pomocí příkazu nslookup, tedy stejnějako v předchozí podsekci. V tomto případě však s tím rozdílem, že cílovou ad-resou DNS požadavku byla přímo IPv6 adresa rekurzivního DNS serveru, tedy2001:718:803:f15::11.

7.2 Firewalling 98

> nslookup -query=AAAA pc.firma.cz;; connection timed out; trying next origin;; connection timed out; no server could be reached

Jak lze vidět z výstupu uvedeného výše, požadavek, jehož cílem byl přímo DNSserver, nebyl k serveru doručen. Verifikační test byl tedy úspěšný.

7.2 Firewalling

Implementace firewallu byla testována v síti, ve které byl přítomen prvek simulujícíFirewall spolu s dvěma klienty, viz obr. 30. Na PC2 pak byla navíc nasazena službaApache tak, aby bylo možné verifikovat korektní nastavení pravidla pro přístupk webovým službám.

Obrázek 30: Topologie pro verifikační test Firewallu

Cílem verifikace bylo otestovat funkčnost návrhu řešení uvedeném v kap. 6.2. Pospuštění navržené topologie byla importována pravidla uvedená v kap. 6.2 a následněbylo otestováno několik případů, na kterých byla verifikována správná funkčnostfirewallu:

• přístup z PC1 k webovým službám PC2,

• ping zaslaný z klienta PC2 na IPv6 adresu klienta PC1,

• požadavek zaslaný z klienta PC2 na IPv6 adresu klienta PC1 se záměnou zdro-jové adresy.

7.2.1 Přístup z PC1 k webovým službám PC2

Přístup byl proveden pomocí webového prohlížeče Firefox na PC1. Cílem bylo, abydošlo ke korektnímu zobrazení webové stránky, což bylo úspěšně ověřeno, viz obr. 31.

7.2 Firewalling 99

Obrázek 31: Verifikační test přístupu z PC1 k webovým službám PC2

7.2.2 Ping zaslaný z klienta PC2 na IPv6 adresu klienta PC1

Následně byl proveden verifikační test přístupu z lokální do vnější sítě po-mocí příkazu ping. Cílem tohoto příkazu byla IPv6 adresa stroje PC1, tedy2001:718:802:a::10/64.

Reply from 2001:718:802:a::10: bytes=32 time=2ms TTL=254Reply from 2001:718:802:a::10: bytes=32 time=2ms TTL=254Reply from 2001:718:802:a::10: bytes=32 time=3ms TTL=254Reply from 2001:718:802:a::10: bytes=32 time=2ms TTL=254

Ping statistics for 2001:718:802:a::10:Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:Minimum = 0ms, Maximum = 0ms, Average = 0ms

7.2.3 Požadavek zaslaný z klienta PC2 na IPv6 adresu klienta PC1 se zámě-nou zdrojové adresy

Posledním verifikačním testem byl test, který byl podobný jako v podsekci 7.2.2,avšak s tím rozdílem, že požadavek byl zaslán z adresy nepatřící do rozsahu2001:718:803::/48. Pro tento účel bylo nejvhodnější využít program nping, kterýumožňuje zaslat pakety s podvrženou zdrojovou adresou. Jeho využití je však li-mitováno tím, že neumí pracovat s protokolem ICMPv6. Verifikační test tak bylproveden požadavkem SYN zaslaným na port 80/tcp. Příkaz pro jeho zaslání mělnásledující podobu.

nping -6 2001:718:802:a::10 -e enp0s3 --source-mac 08:00:27:f8:bc:71 --dest-mac 08:00:27:5f:9d:ab-S 2001:718:802:a::11

Následně byly na prvku simulující firewall odchyceny pakety na příchozím i od-chozím rozhraní. Výstup je uveden na obr. č. 32. K prvku, kterému byly paketyadresovány nebyl doručen žádný z uvedených.

7.3 IDS, IPS 100

Obrázek 32: Odchycený provoz na prvku R1

Z výše uvedeného výstupu je zřetelné, že požadavek byl zaslán z adresy, kteráneodpovídá rozsahu 2001:718:803::/48, přičemž byl zahozen.

Všechny výše uvedené verifikační testy služby Firewall proběhly korektně. Ná-vrh lze proto považovat za správný.

7.3 IDS, IPS

Pro verifikaci řešení, jehož implementace byla popsána v kapitole 6.3, byla využitanová instalace systému CentOS 7. Na tomto stroji byly instalovány veškeré kom-ponenty, které výše uvedená kapitola zmiňovala tak, aby bylo možné otestovat je-jich funkčnost. Následně byl testován scénář zahrnující především detekci a obsluhuvlastního pravidla. Součástí tohoto testu bylo i ověření funkcionality routingu, kterýje zásadní komponentou pro funkci celého řešení IDS/IPS. V případě, že by systémnebyl funkční, provoz směrovaný do lokální sítě by nebyl doručen a výsledkem bybyla kompletní ztráta konektivity IPv6 z lokální sítě do internetu.

Pro tento scénář byla vytvořena testovací topologie. Ta sestávala ze dvou strojůs operačním systémem Linux, kdy jeden z nich simuloval útočníka v síti internet,druhý pak klientské zařízení v lokální síti MENDELU.

V rámci programu Snort, bylo do souboru local.rules, importovaného do nasta-vení programu v souboru snort.conf, vloženo následující pravidlo.

alert icmp any any -> $HOME_NET any (msg:"dp xsturma"; sid:1000005; rev:002;)

Výše uvedené pravidlo umístěné v souboru s pravidly vyvolá reakci, pokud je dodomácí sítě ($HOME NET) doručen paket protokolu ICMP. Testování funkčnostipak bylo provedeno zasláním požadavku programu ping ze stroje simulujícího útoč-níka na IPv6 adresu rozhraní klienta v lokální síti. S tímto nastavením byly všechnypožadavky úspěšně doručeny na cílový stroj. Programem Snort byl však na základětohoto chování vyvolán alert tak, jak tomu mělo být dle konfigurace uvedené výše.Ten bylo možné prohlédnout v souboru snort.log, případně přímo nahlédnout dozáznamu paketů ve formátu pcap. Alert v textovém formátu je uveden níže.

[**] [1:1000005:2] detected dp xsturma [**][Priority: 0]05/15-04:26:22.077076 2001:718:803:d209::11 -> ff02::1:ff00:12IPV6-ICMP TTL:255 TOS:0x0 ID:0 IpLen:40 DgmLen:72

7.4 ACL 101

Bylo tedy úspěšně verifikováno, že pravidla aplikovaná do programu Snort jsoukorektně detekována, a že v případě narušení bezpečnosti dojde k úspěšnému za-znamenání tohoto pokusu. Verifikační test tak proběhl korektně.

7.4 ACL

Pro verifikaci ACL byl využit přepínač Cisco WS-C2960X-48TD-L, na němž bylonakonfigurován IPv6 ACL, viz níže.

interface GigabitEthernet1/0/11ipv6 traffic-filter S01 in

interface GigabitEthernet1/0/12ipv6 traffic-filter S01 in

ipv6 access-list S01permit ipv6 2001:718:803:a::/64 anydeny udp any any log-inputdeny tcp any any log-inputdeny ipv6 any any log-input

Toto ACL mělo za cíl blokovat příchozí rámce, jejichž zdrojová IPv6 adresaneodpovídá rozsahu 2001:718:803:a::/64. Nastavení bylo verifikováno příkazem showipv6 access-lists.

#show ipv6 access-listsIPv6 access list S01

permit ipv6 2001:718:803:A::/64 any sequence 10deny udp any any log-input sequence 20deny tcp any any log-input sequence 30deny ipv6 any any log-input sequence 40

Toto ACL bylo aplikováno na rozhraní Gi1/0/11 a Gi1/0/12 (viz výše), k nimžbyly připojeny dvě stanice s IPv6 adresou z rozsahu 2001:718:803:b::/64. Tyto sta-nice se pokoušely navzájem kontaktovat pomocí programu ping6. Výsledek jednohoz pokusů je uveden níže.

ping6 2001:718:803:b::11PING6(56=40+8+8 bytes) 2001:718:803:b::10 --> 2001:718:803:b::1116 bytes from 2001:718:803:b::11, icmp_seq=0 Destination unreachable: Address unreachable16 bytes from 2001:718:803:b::11, icmp_seq=1 Destination unreachable: Address unreachable16 bytes from 2001:718:803:b::11, icmp_seq=2 Destination unreachable: Address unreachable--- 2001:718:803:b::11 ping6 staticics ---3 packets transmitted, 0 received, +3 errors, 100.0% packet loss, time 3455ms

Všechny rámce, které byly z dané adresy doručeny byly zahozeny. Verifikačnítest byl úspěšný.

7.5 VPN

V rámci verifikačních testů bylo provedeno testování implementace site-to-site VPN,navržené v kap. 6.5. Tento návrh byl transformován do laboratorní topologie, kde

7.5 VPN 102

byla otestována jeho funkčnost. Topologie, na které byl proveden verifikační test jeuvedena na obr. 33.

Obrázek 33: Topologie pro verifikační test VPN

Konfigurace na routerech, na kterých byl vytvořen tunel pak vypadaly násle-dovně.

! Konfigurace rozhraní Tunnel1 prvku R1interface Tunnel1ip address 192.168.1.1 255.255.255.0 !IPv4 adresa tunelu pro směrovánímtu 1476 !Maximální velikost MTUipv6 address 2001:718:803:D::1/64 !IPv6 adresa tunelu pro směrovánítunnel source GigabitEthernet0/0 !Odchozí rozhraní tunelutunnel destination 192.168.0.2 !IP adresa druhé strany GRE tunelutunnel mode ipv6ip !Mód tunelu!

! Konfigurace rozhraní Tunnel1 prvku R2interface Tunnel1ip address 192.168.1.2 255.255.255.0 !IPv4 adresa tunelu pro směrovánímtu 1476 !Maximální velikost MTUipv6 address 2001:718:803:D::2/64 !IPv6 adresa tunelu pro směrovánítunnel source GigabitEthernet0/0 !Odchozí rozhraní tunelutunnel destination 192.168.0.1 !IP adresa druhé strany GRE tunelutunnel mode ipv6ip !Mód tunelu!

Výpis informací o vytvořeném rozhraní Tunnel1 na prvku R1 je pak uvedenníže. Je z něho jasně patrné, že tunel byl adresován pomocí IPv4 adres.

Router#show interfaces tunnel 1Tunnel1 is up, line protocol is up (connected)Hardware is TunnelInternet address is 192.168.1.1/24MTU 17916 bytes, BW 100 Kbit/sec, DLY 50000 usec,reliability 255/255, txload 1/255, rxload 1/255

Encapsulation TUNNEL, loopback not setKeepalive not setTunnel source 192.168.0.1 (GigabitEthernet0/0), destination 192.168.0.2Tunnel protocol/transport IPv6/IPKey disabled, sequencing disabledChecksumming of packets disabled

# Zkráceno

Pro verifikační test byl použit příkaz ping zaslaný z PC1 na PC2, viz obr. 33.Cílem bylo, aby tento příkaz proběhl bez problémů mezi oběma vybranými stani-cemi.

7.6 Zabezpečení na úrovni ASW 103

Reply from 2001:718:803:B::1: bytes=32 time=0ms TTL=254Reply from 2001:718:803:B::1: bytes=32 time=0ms TTL=254Reply from 2001:718:803:B::1: bytes=32 time=0ms TTL=254Reply from 2001:718:803:B::1: bytes=32 time=0ms TTL=254

Ping statistics for 2001:718:803:B::1:Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:Minimum = 0ms, Maximum = 0ms, Average = 0ms

Jak lze vidět na výpisu uvedeném výše, příkaz proběhl bez problémů. Uvedenéspojení je tak schopné přenosu IPv6 paketů.

7.6 Zabezpečení na úrovni ASW

Verifikace nastavení byla prováděna na prvku Cisco WS-C2960X-48TD-L, s opera-čním systémem IOS ve verzi 15.2(2)E5. Verifikační test byl proveden v návaznostina návrh řešení uvedený v kap. 6.6.

7.6.1 Koncová stanice, univerzitní síť

Nastavení, které bylo na prvku nasazeno, přesně odpovídá návrhu uvedenémuv kap. 6.6.1. Správnost návrhu pak byla ověřena pomocí verifikačních příkazů show.

! Zobrazení IPv6 ND capture politik, které jsou aktivní na rozhraní gi 1/0/1Switch#show ipv6 snooping capture-policy interface gigabitEthernet 1/0/1

HW Target Gi1/0/1 HW policy signature 0000039F policies#:5 rules 8 sig 0000039FSW policy ipv6_ra_guard_policy feature RA guardSW policy ipv6_snooping_policy feature SnoopingSW policy ipv6_destination_guard_policy feature Destination GuardSW policy ipv6_source_guard_policy feature Source guardSW policy ipv6_nd_inspection_policy feature NDP inspection

# Zkráceno...

! Zobrazení informací o snooping politikách na zařízeníSwitch#show ipv6 snooping featuresFeature name priority stateDHCP Guard 200 READYNDP inspection 160 READYSnooping 128 READYSource guard 32 READYDestination Gua 16 READY

! Zobrazení IPv6 snooping politik, které jsou aktivní na rozhraní gi 1/0/1Switch#show ipv6 snooping policies interface gigabitEthernet 1/0/1Target Type Policy Feature Target rangeGi1/0/1 PORT ipv6_snooping_policy Snooping vlan allGi1/0/1 PORT ipv6_destination_gua Destination Gu vlan allGi1/0/1 PORT ipv6_source_guard_po Source guard vlan allGi1/0/1 PORT ipv6_nd_inspection_p NDP inspection vlan all

! Zobrazení detailních informací o specifických paketech detekovaných na rozhraní gi 1/0/1Switch#show ipv6 snooping counter interface gigabitEthernet 1/0/1Received messages on Gi1/0/1:Protocol Protocol messageNDP RS[9] NS[5] NA[1]DHCPv6 SOL[26]

Bridged messages from Gi1/0/1:Protocol Protocol message

7.6 Zabezpečení na úrovni ASW 104

NDP RS[9] NS[6]DHCPv6 SOL[26]

Dropped messages on Gi1/0/1:Feature Protocol Msg [Total dropped]RA guard NDP RA [8]

reason: Message unauthorized on port [8]

! Zobrazí konfiguraci politiky DHCPv6 guard politikySwitch#show ipv6 dhcp guard policy dhcp_guard_policyDhcp guard policy: dhcp_guard_policy

Device Role: dhcp serverTarget: Gi1/0/1 # Politika aplikovaná na rozhraníMax Preference: 255Min Preference: 0Source Address Match Access List: acl1Prefix List Match Prefix List: ipv6_prefix_list_2

! Konfigurace source guard politiky na rozhraní gi 1/0/1Switch#show ipv6 source-guard policy ipv6_source_guard_policyPolicy ipv6_source_guard_policy configuration:validate prefixpermit link-localdeny global-autoconf

Policy ipv6_source_guard_policy is applied on the following targets:Target Type Policy Feature Target rangeGi1/0/1 PORT ipv6_source_guard_po Source guard vlan all

! Zjištění stavu politiky destination guard na zařízeníSwitch#show ipv6 destination-guard policy ipv6_destination_guard_policyDestination guard policy ipv6_destination_guard_policy:enforcement stressed

Target: Gi1/0/1

Z výše uvedených výpisů konfigurace přístupového přepínače lze vidět, ževšechny požadované funkce byly aktivní. Verifikační test jejich nastavení tak proběhlkorektně.

7.6.2 Koncová stanice, kolejní síť

Nastavení, které je na prvku nasazeno, přesně odpovídá návrhu uvedenémuv kap. 6.6.2. Správnost návrhu pak byla ověřena pomocí verifikačních příkazů show.

! Zobrazení IPv6 ND capture politik, které jsou aktivní na rozhraní gi 1/0/1Switch#show ipv6 snooping capture-policy interface gigabitEthernet 1/0/1

HW Target Gi1/0/1 HW policy signature 0000039F policies#:3 rules 8 sig 0000039FSW policy ipv6_ra_guard_policy feature RA guardSW policy ipv6_source_guard_policy feature Source guardSW policy ipv6_snooping_policy feature Snooping

# Zkráceno...

! Zobrazení informací o snooping politikách na zařízeníSwitch#show ipv6 snooping featuresFeature name priority stateDHCP Guard 200 READYRA guard 192 READYSnooping 128 READYSource guard 32 READY

! Zobrazení informací o snooping politikách na rozhraní gi 1/0/1Switch#show ipv6 snooping policies interface gigabitEthernet 1/0/1Target Type Policy Feature Target range

7.7 Sledování provozu 105

Gi1/0/1 PORT ipv6_ra_guard_policy RA guard vlan allGi1/0/1 PORT ipv6_source_guard_po Source guard vlan allGi1/0/1 PORT ipv6_snooping_policy Snooping vlan all

! Zobrazí konfiguraci politiky DHCPv6 guard politikySwitch#show ipv6 dhcp guard policy dhcp_guard_policyDhcp guard policy: dhcp_guard_policy

Device Role: dhcp serverTarget: Gi1/0/1 # Politika aplikovaná na rozhraníMax Preference: 255Min Preference: 0Source Address Match Access List: acl1Prefix List Match Prefix List: ipv6_pefix_list_2

! Konfigurace source guard politiky na rozhraní gi 1/0/1Switch#show ipv6 source-guard policy ipv6_source_guard_policyPolicy ipv6_source_guard_policy configuration:validate addresspermit link-localdeny global-autoconf

Policy ipv6_source_guard_policy is applied on the following targets:Target Type Policy Feature Target rangeGi1/0/1 PORT ipv6_source_guard_po Source guard vlan all

! Zjištění stavu politiky destination guard na zařízeníSwitch#show ipv6 destination-guard policy ipv6_destination_guard_policyDestination guard feature not active

Výsledky, které byly získány pomocí verifikace příkazy show odpovídají návrhu,který byl uveden v kap. 6.6.

Konfigurace zabezpečení přístupové vrstvy byla úspěšně verifikována. Nasta-vení, které bylo uvedeno v kap. 6.6, lze na přístupový přepínač nasadit a je funkční.

7.7 Sledování provozu

Verifikace návrhu proběhla v serverovně X, a to na trial verzi Flowmon Collectoru,který je společností Flowmon Network poskytován v rámci testovací verze po ome-zenou dobu zdarma. Do stejné sítě VLAN pak byla umístěna fyzická sonda, kteroumá ÚIT MENDELU zakoupenou. Inicializaci zařízení bylo nutné provést pomocíprotokolu IPv4, následně byla sondě i kolektoru přiřazena IPv6 adresa z rozsahu2001:718:803:d::/64.

Poté co byla úspěšně ověřena funkčnost IPv6 adresace pomocí přístupu ke GUItěchto prvků, byla na FlowMon sondě nakonfigurována cílová IPv6 adresa exportéru,a to na adresu kolektoru, viz obr. 34.

Poté, co byl nastaven cíl exportéru, byl do monitorovacího rozhraní nakonfigu-rován SPAN15 port, který zrcadlil provoz rozhraní, do kterého byla zapojena koncovástanice s konektivitou na server ve stejné síti. Následně byl z této klientské stanicespuštěn ping na server pomocí protokolu IPv6 tak, aby prostřednictvím monitoro-vaného rozhraní byly přeposílány IPv6 pakety. Tento provoz byl následně odchycen

15SPAN (Switched Port Analyzer) – Metoda monitoringu, kdy je na přepínači provoz zdrojovéhoportu zrcadlen na cílový port.

7.7 Sledování provozu 106

Obrázek 34: Nastavení cíle exportéru v kolektoru

pomocí FlowMon sondy, která jej pomocí exportéru zaslala do FlowMon Collectoru.Ping proběhl korektně a jeho výpis vypadal následovně.

ping6 2001:718:803:d::11PING6(56=40+8+8 bytes) 2001:718:803:d::5 --> 2001:718:803:d::1116 bytes from 2001:718:803:d::11, icmp_seq=0 hlim=64 time=0.627 ms16 bytes from 2001:718:803:d::11, icmp_seq=1 hlim=64 time=0.623 ms16 bytes from 2001:718:803:d::11, icmp_seq=2 hlim=64 time=0.820 ms16 bytes from 2001:718:803:d::11, icmp_seq=3 hlim=64 time=0.769 ms16 bytes from 2001:718:803:d::11, icmp_seq=4 hlim=64 time=0.685 ms16 bytes from 2001:718:803:d::11, icmp_seq=5 hlim=64 time=0.906 ms16 bytes from 2001:718:803:d::11, icmp_seq=6 hlim=64 time=0.652 ms16 bytes from 2001:718:803:d::11, icmp_seq=7 hlim=64 time=0.616 ms16 bytes from 2001:718:803:d::11, icmp_seq=8 hlim=64 time=0.670 ms--- 2001:718:803:d::11 ping6 staticics ---9 packets transmitted, 9 packets received, 0.0% packet lossround-trip min/avg/max/std-dev = 0.616/0.708/0.906/0.096 ms

Ve Flowmon Collectoru byl následně vyfiltrován tento provoz pomocí filtrucílové adresy, viz obr. 35.

Obrázek 35: Přehled filtrovaných paketů ve Flowmon Collectoru

Zaslané IPv6 pakety, které byly prostřednictvím sondy odchyceny, byly v kolek-toru viditelné. Verifikační test aplikace pro sledování provozu tak skončil úspěšně.

7.8 Proxy 107

7.8 Proxy

Verifikační testy proxy byly prováděny v laboratorní topologii. Program squid, kterýbyl pro implementaci vybrán však disponuje prakticky totožnou konfigurací, jakoprodukční služba. Topologie je uvedena na obr. 36.

Obrázek 36: Verifikační topologie proxy

Pro verifikační test uživatelské proxy pak na serveru squid byla nasazena kon-figurace navržená v kap. 6.8. Server s IPv6 adresou 2001:718:803:d::10, viz obr. 36,měl spuštěn webový server, na který se bude klient pokoušet spojit s webovou proxynastavenou na server squid s IPv6 adresou 2001:718:803:a::1, viz obr. 37.

Obrázek 37: Nastavení proxy serveru na klientovi

Následně se klient pokusil přistoupit přímo na IPv6 adresu webového serveru,tedy 2001:718:803:d::10. Webová stránka umístěná na webovém serveru se korektněnačetla, proxy server tedy s IPv6 adresami korektně pracuje a je schopen obsloužitklienty, které je používají.

7.8 Proxy 108

Z důvodů ověření této skutečnosti navíc byly na serveru obsluhující proxyodchyceny pakety, které obsahují GET požadavek, viz obr. 38 a 39. Na prvnímz těchto odchytů lze spatřit požadavek, který, ačkoli patří serveru s IPv6 adresou2001:718:803:d::10, je směrován na adresu proxy serveru 2001:718:803:a::1. Na dru-hém odchytu pak požadavek, který již směřuje k webovému serveru přímo z adresy2001:718:803:d::1 patřící proxy serveru. Odpověď z tohoto serveru byla následnězaslaná proxy serveru, který ji přeposlal prohlížeči klienta.

Obrázek 38: GET požadavek odchycený na rozhraní proxy serveru přímopřipojeném ke klientovi

Obrázek 39: GET požadavek odchycený na rozhraní proxy serveru přímopřipojeném k webovému serveru

Verifikace webové proxy probíhala na stejné topologii. Klient však v tomto pří-padě nedisponoval žádným nastavení proxy, která byla ve výchozím stavu prohlížeče,viz obr. 40. Další změnou pak bylo, že v konfiguraci squid.conf byly zahrnuty změnyzmíněné v kap. 6.8, a to následující konfigurace.

Obrázek 40: Konfigurace proxy serveru při verifikačním testu webové proxy

7.9 AAA služby 109

http_port 8080 interceptacl allowed_networks src 2001:718:803:a::/64

Dále byla upravena konfigurace služby ip6tables následovně.

ip6tables -t nat -A PREROUTING -i eth0 -s 2001:718:803:a::/64 -d 2001:718:803:d::10-p tcp --dport 80 -j REDIRECT --to-port 8080

Poté byla otestována komunikace mezi těmito stroji pomocí zaslaného HTTPpožadavku. Ten byl úspěšně přeposlán a doručen k cílovému serveru, který na nějzaslal odpověď. Ta poté byla z proxy serveru směrována zpět na klientské zařízení.

Bylo tak úspěšně verifikováno, že proxy server squid korektně pracuje s IPv6adresami a je schopen obsloužit klientské požadavky, tak jak je navrženo v kap. 6.8.

7.9 AAA služby

Na základě implementace uvedené v kap. 6.9, byl nasazen server s operačním systé-mem CentOS7 a instalována služba FreeRadius 3.0.4. Následně byly implementoványkonfigurační změny dle kap. 6.9.

Služba poté byla spuštěna pomocí příkazu ”radiusd -X”, jejíž výstup byl násle-dující.

#ZkrácenoListening on auth address * port 1813 as server defaultListening on acct address * port 1813 as server defaultListening on auth address :: port 1813 as server defaultListening on acct address :: port 1813 as server defaultListening on auth address127.0.0.1 port 18120 as server inner-tunnelOpening new proxy socket ’proxy address * port 0’Listening on proxy address * port 36798Ready to process requests

Ověření, že služba korektně běží na požadovaných rozhraních, pak bylo ověřenoi pomocí výpisu netstat.

# netstat -antup | grep 1812udp 0 0 0.0.0.0:1812 0.0.0.0:* 7244/radiusdudp 0 0 127:0.0.1:18120 0.0.0.0:* 7244/radiusdudp6 0 0 :::1812 :::* 7244/radiusd

Nyní bylo možné provést verifikační test ověření uživatelského účtu. Ten bylproveden pomocí utility radtest, která je rozhraním k příkazu radclient, testujícímfunkčnost služby radiusd.

Nejprve byl otestován přístup v rámci localhostu, a to pomocí protokolu IPv6i IPv4. Výstupy vypadaly následovně.

#Zaslany pozadavek IPv4[root@localhost ~]# radtest -4 bob hello 127.0.0.1 0 testing123Sending Access-Request Id 196 from 0.0.0.0:35217 to 127.0.0.1:1812User-Name = ’bob’User-Password = ’hello’NAS-IP-Address = 127.0.0.1NAS-Port = 0Message-Authenticator = 0x00

7.9 AAA služby 110

Received Access-Accept Id 196 from 127.0.0.1:1812 to 127.0.0.1:35217 length 32Reply-Message = ’Hello, bob’

#Vystup radiusd serveruSending Access-Accept Id 196 from 127.0.0.1:1812 to 127.0.0.1:35217Reply-Message = ’Hello, bob’(0) Finished request

#Zaslany pozadavek IPv6[root@localhost ~]# radtest -6 bob hello ::1 0 testing123Sending Access-Request Id 18 from :::47887 to ::1:1812User-Name = ’bob’User-Password = ’hello’NAS-IPv6-Address = ::1NAS-Port = 0Message-Authenticator = 0x00Received Access-Accept Id 18 from ::1:1812 to ::1:47887 length 32Reply-Message = ’Hello, bob’

#Vystup radiusd serveruSending Access-Accept Id 18 from ::1:1812 to ::1:47887Reply-Message = ’Hello, bob’

Následně byl do stejné sítě zapojen klient s instalovanými freeradius-utils a tes-tování proběhlo stejným způsobem.

#Zaslany pozadavek IPv4# radtest -4 bob hello 10.0.0.10 0 testing123Sending Access-Request Id 5 from 0.0.0.0:44887 to 10.0.0.10:1812User-Name = ’bob’User-Password = ’hello’NAS-IP-Address = 127.0.0.1NAS-Port = 0Message-Authenticator = 0x00Received Access-Accept Id 5 from 10.0.0.10:1812 to 10.0.0.11:44887 length 32Reply-Message = ’Hello, bob’

#Vystup radiusd serveruSending Access-Accept Id 5 from 10.0.0.10:1812 to 10.0.0.11:44887

Reply-Message = ’Hello, bob’

#Zaslany pozadavek IPv6# radtest -6 bob hello 2001:718:803:a::10 0 testing123Sending Access-Request Id 246 from :::44095 to 2001:718:803:a::10:1812User-Name = ’bob’User-Password = ’hello’NAS-IPv6-Address = ::1NAS-Port = 0Message-Authenticator = 0x00Received Access-Accept Id 246 from 2001:718:803:a::10:1812 to 2001:718:803:a::11:44095 length 32Reply-Message = ’Hello, bob’

#Vystup radiusd serveruSending Access-Accept Id 246 from 2001:718:803:a::10:1812 to 2001:718:803:a::11:44095Reply-Message = ’Hello, bob’

Z výše uvedených výstupů lze vyvodit, že ověření mezi IPv4/IPv6 klientema IPv4/IPv6 serverem proběhlo korektně. Verzi 3.0.4 služby FreeRadius tak lze do-poručit pro použití IPv6 síti MENDELU pro ověřování zařízení.

7.10 Webové služby 111

7.10 Webové služby

Implementace, která byla navržená v kap. 6.10, byla otestována na webovém serveru,na kterém je instalována služba apache ve verzi 2.4.6.

Konfigurace serveru pak byla upravena tak, aby obsluhovala dva virtuální hosty.To v praxi znamená obsluhu dvou domén. Běžně webový server obsluhuje těchtodomén desítky, avšak pro účely verifikačního testu je toto nastavení dostatečné.

Konfigurace těchto virtuálních hostů byla totožná, jako by tomu bylo u IPv4.Jejich konfigurace je uvedena níže.

#/etc/httpd/sites-available/netlab.local.conf<VirtualHost *:5000>

ServerAdmin mail@netlab.localServerName netlab.localServerAlias www.netlab.localDocumentRoot /var/www/netlab.local/public_htmlErrorLog /var/www/netlab.local/error.logCustomLog /var/www/netlab.local/requests.log combined

</VirtualHost>

#/etc/httpd/sites-available/netlab2.local.conf<VirtualHost *:5001>

ServerAdmin mail@netlab2.localServerName netlab2.localServerAlias www.netlab2.localDocumentRoot /var/www/netlab2.local/public_htmlErrorLog /var/www/netlab2.local/error.logCustomLog /var/www/netlab2.local/requests.log combined

</VirtualHost>

V rámci této konfigurace byl pouze změněn port, pomocí kterého s k těmtovirtuálním hostům přistupuje, aby bylo možno verifikační test provést i bez DNSserveru. Následně byly tyto porty povoleny přímo v konfiguraci přístupu apache,souboru httpd.conf. Žádné další změny oproti výchozí konfiguraci nebyly prováděny.

Obrázek 41: GET požadavek odchycený na webovém serveru

Verifikační test se skládal z přístupu klienta na síťové rozhraní webového ser-veru. Klient disponoval IPv6 i IPv4 adresou, přistupoval však k serveru pomocíIPv6, a to zadáním adresy [2001:718:803:a::1]:5000 do adresního řádku webového

7.11 Poštovní služby 112

prohlížeče. Požadovaná stránka se bez problémů načetla. Pro ověření skutečnosti,že pro přenos dat byl použit protokol IPv6, byly odchyceny pakety přenesené meziklientem a webovým serverem, viz obr. 41

Na požadavku, který je uveden na obr. 41, je vidět, že přístup k webovém serveruproběhl bez problémů pomocí protokolu IPv6. Stejně proběhl i požadavek zaslanýna adresu [2001:718:803:a::1]:5001. Webový server je tak v případě konfigurace dlenávrhu funkční.

7.11 Poštovní služby

Verifikace poštovních služeb vychází z návrhu řešení a především implementace uve-dené v kap. 6.11.

Topologie, na které byl návrh verifikován, pak vypadala tak, jak je uvedeno naobr. 42

Obrázek 42: Verifikační topologie pro poštovní služby

Cílem verifikace je otestovat následující konfigurace serveru:

• server s nastavením provozu IPv4,

• server s nastavením provozu IPv6,

• server se zapnutou bezpečnostní aplikací Postgrey.

7.11.1 Server s nastavením provozu IPv4

Implementace serveru odpovídala verifikační topologii dle návrhu, viz kap. 6.11.Testování probíhalo pomocí zprávy zaslané ze stroje server.outside.local na e-mailmichal@inside.local, k čemuž byl použit níže uvedený příkaz.

mail -s \DP TEST" michal@inside.local

Následně byl sledován výstup aplikace postfix. Na relay-server.outside.local bylvýstup následující.

7.11 Poštovní služby 113

Apr 18 07:17:35 relay-server postfix/smtpd[3770]: connect from server.outside.local[172.16.0.200]Apr 18 07:17:35 relay-server postfix/smtpd[3770]: A532A409BBFE:client=server.outside.local[172.16.0.200]Apr 18 07:17:35 relay-server postfix/cleanup[3773]: A532A409BBFE:message-id=<20170516084213.A6C9A22D63EB@server.outside.local>Apr 18 07:17:35 relay-server postfix/qmgr[3768]: A532A409BBFE: from=<root@server.outside.local>,size=657, nrcpt=1 (queue active)Apr 18 07:17:35 relay-server postfix/smtpd[3770]: disconnect from server.outside.local[172.16.0.200]Apr 18 07:17:35 relay-server postfix/smtp[3774]: A532A409BBFE: to=<michal@inside.local>,relay=mail.inside.local[172.16.0.101]:25, delay=0.12, delays=0.03/0.02/0.03/0.04, dsn=2.0.0,status=sent (250 2.0.0 Ok: queued as 64774412AE8D)Apr 18 07:17:35 relay-server postfix/qmgr[3768]: A532A409BBFE: removed

Z výše uvedeného výpisu lze vidět, že komunikace mezi oběma servery pro-běhla pomocí protokolu IPv4. Komunikace mezi servery relay-server.inside.locala mail.inside.local pak vypadala takto.

Apr 18 07:18:34 mail postfix/smtpd[3219]: connect from relay-server.inside.local[172.16.0.100]Apr 18 07:18:34 mail postfix/smtpd[3219]: 64774412AE8D:client=relay-server.inside.local[172.16.0.100]Apr 18 07:18:34 mail postfix/cleanup[3222]: 64774412AE8D:message-id=<20170516084213.A6C9A22D63EB@server.outside.local>Apr 18 07:18:34 mail postfix/qmgr[1368]: 64774412AE8D: from=<root@server.outside.local>,size=870, nrcpt=1 (queue active)Apr 18 07:18:34 mail postfix/smtpd[3219]: disconnect fromrelay-server.inside.local[172.16.0.100]Apr 18 07:18:34 mail postfix/virtual[3223]: 64774412AE8D: to=<michal@inside.local>,relay=virtual, delay=0.04, delays=0.02/0.02/0/0, dsn=2.0.0, status=sent (delivered to maildir)Apr 18 07:18:34 mail postfix/qmgr[1368]: 64774412AE8D: removed

Stejně tak jako v předchozím kroku pak komunikace proběhla pomocí protokoluIPv4. Verifikační test tedy proběhl korektně.

7.11.2 Server s nastavením provozu IPv6

Konfigurace se v rámci tohoto verifikačního testu oproti předchozí konfiguraci měnilapouze v konfiguraci prioritizace. Nastavení souboru /etc/postfix/main.cf obsahovalonásledující konfiguraci.

smtp_address_preference = ipv6

Následně byl proveden stejný test, jako v předchozím kroku. Výstup ze serverurelay-server.outside.local je uveden níže.

Apr 18 07:20:34 relay-server postfix/smtpd[3879]:connect from server.outside.local[2001:718:803:a::200]Apr 18 07:20:34 relay-server postfix/smtpd[3879]: 3A0DA409BBFE:client=server.outside.local[2001:718:803:a::200]Apr 18 07:20:34 relay-server postfix/cleanup[3882]: 3A0DA409BBFE:message-id=<20170516084512.1B33723543A2@server.outside.local>Apr 18 07:20:34 relay-server postfix/qmgr[3877]: 3A0DA409BBFE: from=<root@server.outside.local>,size=655, nrcpt=1 (queue active)Apr 18 07:20:34 relay-server postfix/smtpd[3879]:disconnect from server.outside.local[2001:718:803:a::200]Apr 18 07:20:34 relay-server postfix/smtp[3883]: 3A0DA409BBFE: to=<michal@inside.local>,relay=mail.inside.local[2001:718:803:a::101]:25, delay=0.17, delays=0.03/0.02/0.08/0.04,dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 065B7412AE8D)Apr 18 07:20:34 relay-server postfix/qmgr[3877]: 3A0DA409BBFE: removed

7.11 Poštovní služby 114

Komunikace tudíž proběhla výhradně pomocí protokolu IPv6. Komunikace meziservery relay-server.inside.local a mail.inside.local pak taktéž proběhla pomocí IPv6.

Apr 18 07:21:32 mail postfix/smtpd[3230]: connect fromrelay-server.inside.local[2001:718:803:a::100]Apr 18 07:21:33 mail postfix/smtpd[3230]: 065B7412AE8D:client=relay-server.inside.local[2001:718:803:a::100]Apr 18 07:21:33 mail postfix/cleanup[3234]: 065B7412AE8D:message-id=<20170516084512.1B33723543A2@server.outside.local>Apr 18 07:21:33 mail postfix/qmgr[1368]: 065B7412AE8D: from=<root@server.outside.local>,size=862, nrcpt=1 (queue active)Apr 18 07:21:33 mail postfix/smtpd[3230]: disconnect fromrelay-server.inside.local[2001:718:803:a::100]Apr 18 07:21:33 mail postfix/virtual[3235]: 065B7412AE8D: to=<michal@inside.local>,relay=virtual, delay=0.04, delays=0.02/0.02/0/0, dsn=2.0.0, status=sent (delivered to maildir)Apr 18 07:21:33 mail postfix/qmgr[1368]: 065B7412AE8D: removed

Z výše uvedených výpisů je tak jasně zřetelné, že komunikace pomocí IPv6proběhla totožně, jako tomu bylo u IPv4.

7.11.3 Server se zapnutou bezpečnostní aplikací Postgrey

Dále byla testována stejná konfigurace, jako tomu bylo v sekci 7.11.2, avšak s tímrozdílem, že pomocí příkazu smtpd recipient restrictions byla v konfiguračním sou-boru /etc/postfix/main.cf serveru relay-server.inside.local povolena aplikace Post-grey. Server tak měl při prvním pokusu o komunikaci odmítnout požadavek serverua vynutit si jeho opětovné zaslání po předem definovaném časovém intervalu. Kon-figurace funkce v rámci souboru /etc/postfix/main.cf tedy vypadala následovně.

smtpd_recipient_restrictions = check_policy_service unix:/var/spool/postfix/postgrey/socket,permit_mynetworks

Poté bylo opět iniciováno zaslání e-mailu ze serveru server.outside.local namail.inside.local. Výstup aplikace postfix na serveru relay-server.inside.local pak vy-padal takto.

Apr 18 07:30:35 relay-server postfix/smtpd[3987]:connect from server.outside.local[2001:718:803:a::200]Apr 18 07:30:35 relay-server postgrey[736]: action=greylist, reason=new,client_name=server.outside.local, client_address=2001:718:803:a::200,sender=root@server.outside.local, recipient=michal@inside.localApr 18 07:30:35 relay-server postgrey[736]: cleaning up old logs...Apr 18 07:30:35 relay-server postfix/smtpd[3987]: NOQUEUE: reject: RCPT fromserver.outside.local[2001:718:803:a::200]: 450 4.2.0 <michal@inside.local>:Recipient address rejected: Greylisted for 60 seconds; from=<root@server.outside.local>to=<michal@inside.local> proto=ESMTP helo=<server.outside.local>Apr 18 07:30:35 relay-server postfix/smtpd[3987]:disconnect from server.outside.local[2001:718:803:a::200]Apr 18 07:30:35 relay-server postfix/smtpd[3987]:connect from server.outside.local[172.16.0.200]Apr 18 07:30:35 relay-server postgrey[736]: action=greylist, reason=new,client_name=server.outside.local, client_address=172.16.0.200, sender=root@server.outside.local,recipient=michal@inside.localApr 18 07:30:35 relay-server postfix/smtpd[3987]: NOQUEUE:reject: RCPT from server.outside.local[172.16.0.200]: 450 4.2.0 <michal@inside.local>:Recipient address rejected: Greylisted for 60 seconds;from=<root@server.outside.local> to=<michal@inside.local> proto=ESMTP helo=<server.outside.local>Apr 18 07:30:36 relay-server postfix/smtpd[3987]:

7.12 Databázové služby 115

disconnect from server.outside.local[172.16.0.200]

Z výše uvedeného logu je pak vidět, že ve chvíli, kdy server nebyl úspěšný připokusu o odeslání mailu pomocí IPv6, ihned se pokusil odeslat stejný e-mail pomocíprotokolu IPv4. Serverem relay-server.inside.local byl ale korektně zablokován a bylnucen vyčkat minimálně 60 sekund, než mu bylo umožněno zprávu doručit. V serveruserver.outside.local pak byla zpráva ve frontě, kterou lze vypsat příkazem mailq,viz následující výstup.

-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------E072323543A2 453 Tue May 16 10:55:13 root@server.outside.local(host relay-server.inside.local[172.16.0.100] said: 450 4.2.0 <michal@inside.local>:Recipient address rejected: Greylisted for 60 seconds (in reply to RCPT TO command))

michal@inside.local

Poté co stanovená lhůta uplynula, byl mail úspěšně doručen pomocí protokoluIPv6 tak, jak již bylo uvedeno výše.

Všechny verifikační testy návrhu poštovního serveru proběhly korektně. Apli-kace, jejíž implementace je uvedena v kap. 6.11, se chová tak, jak bylo očekáváno,a s protokolem IPv6 pracuje korektně.

7.12 Databázové služby

Verifikace návrhu implementace databázových služeb byla otestována pomocí vzdá-leného připojení do databáze. Topologie tohoto verifikačního testu je uvedena naobr. 43.

Obrázek 43: Topologie pro verifikaci návrhu databázových služeb

V rámci MariaDB serveru byla upravena konfigurace dle kap. 6.12. Následněbylo provedeno vzdálené připojení k databázovému serveru, jehož výstup vypadaltakto.

#mysql -u root -p -h 2001:718:803:a::10Enter password:Welcome to the MariaDB monitor. Commands end with ; or \g.Your MariaDB connection id is 9Server version: 5.5.52-MariaDB MariaDB Server# zkráceno

7.13 Časové služby 116

MariaDB [(none)]>\end{list}

Proběhlo tak úspěšné připojení pomocí protokolu IPv6, čímž byl verifikovánnávrh řešení uvedený v kap. 6.12.

7.13 Časové služby

Verifikace časových služeb proběhla pomocí dvou přímo připojených strojů, kdy je-den z nich disponoval instalovanou službou ntpd. Oba stroje pak měly konfiguroványIPv6 adresy síťových rozhraní enp0s3.

Instalace proběhla běžným způsobem za přítomnosti rozhraní disponujícíhoIPv6 adresou. Následně byl povolen rozsah lokálních adres dle návrhu implemen-tace uvedeného v kap. č. 6.13.

Z důvodů implementace v lokální síti bez přístupu do internetu však server seslužbou ntpd nedisponoval připojením k jinému ntpd serveru. Automaticky si taknastavil vzdálenost od referenčních hodin na maximální hodnotu, se kterou je pakostatními servery považován za nepřesný. Synchronizaci tak bylo nutné testovat po-mocí příkazu ntpdate, kterým dojde k manuálnímu vynucení synchronizace. Výstupz něj vypadal následovně.

ntpdate 4.2.6p5@1.2349-o Wed Apr 12 21:24:06 UTC 2017 (1)Looking for host 2001:718:803:a::11 and service ntphost found : 2001:718:803:a::11transmit(2001:718:803:a::11)receive(2001:718:803:a::11)# zkráceno2001:718:803:a::11, port 123stratum 16, precision -24, leap 11, trust 000refid [2001:718:803:a::11], delay 0.02596, dispersion 0.00037# zkráceno

Z výše uvedeného výstupu je zřetelné, že synchronizace se serverem pomocíprotokolu IPv6 proběhla korektně. Verifikační test byl úspěšný.

7.14 Virtualizace

Řešení, které bylo uvedeno v kap. 6.14 bylo implementováno a otestováno na pro-dukční instalaci Ústavu Informatiky. Z toho důvodu bylo třeba maximální opatr-nosti při změnách v konfiguraci. Nejprve došlo k povolení protokolu IPv6 tak, jakje uvedeno v návrhu, viz kap. 6.14. Poté bylo nutné přesunout všechny provozovanévirtuální stroje na jiný hypervizor tak, aby nedošlo k výpadku jimi poskytovanýchslužeb. Po tomto úkonu bylo nutné restartovat hypervizor. Jakmile restart korektněproběhl, bylo možné všechny tyto stroje zmigrovat zpět na původní stroj. V tétochvíli bylo proběhla kontrola skutečnosti, že oproti stavu před migrací na migrova-ných strojích nedošlo k žádným změnám, které by mohly negativně ovlivnit jejichchod. To se u verifikačního testu neprokázalo. Jakmile bylo ověřeno správné nasta-vení povolení protokolu IPv6, bylo možné přejít k samotnému verifikačnímu testu.

7.15 WiFi 117

Ten byl proveden tak, že na dvou různých hypervizorech byly vytvořeny virtuálnístroje, které disponovaly pouze IPv6 adresou, dále pak byl v téže síti VLAN vy-tvořen fyzický stroj. Všechny tyto tři stoje se pak navzájem kontaktovaly, aby byloověřeno, že provoz protokolu IPv6 je funkční mezi:

• dvěma virtuálními stroji provozovaných na různých hypervizorech v rámci jednéinstance ESXi,

• virtuálním strojem provozovaných v rámci ESXi a fyzickým strojem v téžeVLAN.

Ověření komunikace pak proběhlo pomocí příkazu ping, který byl spuštěn vždymezi dvěma testovanými stroji. Výstup obou testování byl totožný, proto je nížeuveden pouze výstup verifikačního testu mezi virtuálním strojem provozovanýmv rámci ESXi a fyzickým strojem umístěným v téže síti VLAN.

Pinging 2001:718:803:d::10 with 32 bytes of data:Reply from 2001:718:803:d::10: bytes=32 time=4ms TTL=56Reply from 2001:718:803:d::10: bytes=32 time=4ms TTL=56Reply from 2001:718:803:d::10: bytes=32 time=4ms TTL=56Reply from 2001:718:803:d::10: bytes=32 time=4ms TTL=56

Ping statistics for 2001:718:803:d::10:Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:Minimum = 4ms, Maximum = 4ms, Average = 4ms

Na základě tohoto verifikačního testu lze považovat návrh implementace uve-dený v kap. 6.14 za funkční, jelikož byl ověřen dvěma verifikačními testy uvedenýmivýše v této kapitole.

7.15 WiFi

V této kapitole byla testována implementace kontroléru v testovací topologii. Tatotopologie odrážela nastavení prvků v produkční síti, ačkoli je do určité míry zjedno-dušená.

Kontrolér v testované topologii měl instalovaný firmware 8.0.140.0. Ten pod-poruje provoz IPv6 v plném rozsahu, tedy je schopen nejen adresovat a provozovatkoncové klienty na protokolu IPv6, ale také tento protokol využívat pro tunelováníprovozu mezi AP a kontrolérem.

Verifikace zahrnovala konfiguraci IPv6 protokolu na kontroléru a následně tes-tování provozu pomocí tunelu adresovaného IPv4 a IPv6 adresami. Hlavním bodemtestu bylo otestování a náhled do tunelovaného provozu při užití IPv4 a IPv6 pro-tokolu pro komunikaci mezi bezdrátovým klientem a rozhraním routeru.

7.15.1 Tunelování CAPWAP pomocí protokolu IPv4

Při nastavení prioritizace IPv4 CAPWAP tunelu, viz obr. 45, se výsledný způsobpřeposílání příliš neliší od původního stavu konfigurace bez IPv6. Jedná se také

7.15 WiFi 118

Obrázek 44: Testovací topologie pro verifikaci návrhu řešení

o prakticky totožnou konfiguraci, které lze dosáhnout nasazením systému ve verzi7.2 až 7.6, jejíž způsob komunikace je popsán v kapitole 4.6.17.

Obrázek 45: Nastavení preference tunelování na IPv4

Dle topologie uvedené na obr. 44 byl klient adresován adresou IPv4 i IPv6 tak,aby bylo možné otestovat konektivitu na obou protokolech. Testování probíhalotím způsobem, že klient zasílal zprávy ICMP echo Request na rozhraní VLAN 10vytvořené na prvku L3 Switch (viz topologie).

Cílem verifikace byl stav, kdy na veškeré požadavky byly doručeny z cílovéhoprvku odpovědi.

IPv4 Echo Request Tato komunikace přesně odpovídala původnímu provozu, kdybyl IPv4 paket zabalen do protokolu CAPWAP adresovaného na adresy IP verze 4.Aktuální adresa klienta byla přidělena pomocí DHCP serveru. Cílem požadavkůbyla adresa 10.0.0.5 a výpis v příkazovém řádku klienta vypadal následovně.

Pinging 10.0.0.5 with 32 bytes of data:Reply from 10.0.0.5: bytes=32 time=10ms TTL=56Reply from 10.0.0.5: bytes=32 time=10ms TTL=56Reply from 10.0.0.5: bytes=32 time=10ms TTL=56Reply from 10.0.0.5: bytes=32 time=10ms TTL=56

Ping statistics for 10.0.0.5:Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:Minimum = 10ms, Maximum = 10ms, Average = 10ms

Z tohoto výpisu lze vyvodit, že na všechny požadavky byla doručena i odpo-věď. Vzhledem k tomu, že všechny pakety byly na lokální síti odposlechnuty, lze jedohledat na stroji označeném v diagramu jako pcap. Ten obsahoval zabalený paketzasílaný na adresy IPv4 a adresován IPv4 adresami.

7.15 WiFi 119

Obrázek 46: Odchycený IPv4 paket tunelovaný pomocí CAPWAPv4 tunelu

Jak lze vidět na obr. 46, tunelovaný ICMP Echo Request byl zasílán z IPv4adresy klienta (10.0.0.54) na IPv4 adresu cíle (10.0.0.5). Celý tento paket byl zabalendo CAPWAP a adresován IPv4 adresami LAP a WLC.

IPv6 Echo Request Požadavek na ICMP Echo Request byl zaslán na stejné za-řízení s tím rozdílem, že k jeho zacílení byla využita adresa IPv6. To znamená, žecílem programu ping byla adresa 2001:718:803:10::5, která byla staticky nastavenana rozhraní VLAN 10 prvku L3 Switch. Výpis pak vypadal následovně.

Pinging 2001:718:803:10::5 with 32 bytes of data:Reply from 2001:718:803:10::5: bytes=32 time=10ms TTL=56Reply from 2001:718:803:10::5: bytes=32 time=10ms TTL=56Reply from 2001:718:803:10::5: bytes=32 time=10ms TTL=56Reply from 2001:718:803:10::5: bytes=32 time=10ms TTL=56

Ping statistics for 2001:718:803:10::5:Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:Minimum = 10ms, Maximum = 10ms, Average = 10ms

Z výše uvedeného výpisu lze stejně jako u požadavků zasílaných na IPv4 adresuvyvodit, že všechny požadavky byly doručeny a bylo na ně i odpovězeno v čase 10 ms.Pro úplnost byl odchycen paket přenášející tuto informaci, viz obr. 47, na kterém lzevidět, že IPv6 paket je zabalen a tunelován pomocí CAPWAP tunelu adresovanémIPv4 adresami.

Obrázek 47: Odchycený IPv6 paket tunelovaný pomocí CAPWAPv4 tunelu

Na základě těchto výsledků, kterými se potvrdilo očekávané chování, lze tutočást testu návrhu WiFi hodnotit jako úspěšnou a využívat ji pro tunelování IPv4i IPv6 paketů.

7.15.2 Tunelování CAPWAP pomocí protokolu IPv6

Prioritizace IPv6 tunelování, viz obr. 48, zajistí, že veškerý provoz bude přenášenpomocí tunelu adresovaného protokolem IPv6 tak, jak je popsáno v kap. 4.6.17.

7.15 WiFi 120

Obrázek 48: Nastavení preference tunelování na IPv6

Verifikační test pak testoval provoz IPv6 i IPv4 stejně, jak tomu bylo u CA-PWAP tunelu adresovaného IPv4 adresami.

IPv4 Echo Request Požadavek byl zaslán z klientského zařízení na IPv4 adresuprvku L3 switch, tedy 10.0.0.5. Výsledkem měla být odpověď na všechny zaslanépožadavky.

Pinging 10.0.0.5 with 32 bytes of data:Reply from 10.0.0.5: bytes=32 time=10ms TTL=56Reply from 10.0.0.5: bytes=32 time=10ms TTL=56Reply from 10.0.0.5: bytes=32 time=10ms TTL=56Reply from 10.0.0.5: bytes=32 time=10ms TTL=56

Ping statistics for 10.0.0.5:Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:Minimum = 10ms, Maximum = 10ms, Average = 10ms

Jak lze vidět z výpisu uvedeného výše, test komunikace byl úspěšný. Bylo všaknutné ověřit, že tunel, který byl vytvořen mezi LAP a WLC, opravdu využíval IPv6adresaci. Že tomu tak opravdu bylo, se lze ujistit na obr. 49, kde lze ověřit CAPWAPtunel adresovaný adresami IPv6, který obsahuje zabalený paket IPv4.

Obrázek 49: Odchycený IPv4 paket tunelovaný pomocí CAPWAPv6 tunelu

IPv6 Echo Request Stejně, jak tomu je u předchozích verifikačních testů WiFi,i zde byl zasílán paket ICMP Echo request. V tomto případě však byla jeho cílemIPv6 adresa prvku L3 Switch. Zasílán byl opět z klientského zařízení připojenéhoprostřednictvím WiFi.

Pinging 2001:718:803:10::5 with 32 bytes of data:Reply from 2001:718:803:10::5: bytes=32 time=10ms TTL=56Reply from 2001:718:803:10::5: bytes=32 time=10ms TTL=56Reply from 2001:718:803:10::5: bytes=32 time=10ms TTL=56Reply from 2001:718:803:10::5: bytes=32 time=10ms TTL=56

Ping statistics for 2001:718:803:10::5:Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:Minimum = 10ms, Maximum = 10ms, Average = 10ms

7.16 Správa koncových stanic 121

Z výpisu lze ověřit, že verifikační test proběhl v pořádku. V odchytu uvedenémna obr. 50 pak lze ověřit, že IPv6 paket je zabalen v CAPWAP tunelu adresovanémadresami IPv6.

Obrázek 50: Odchycený IPv6 paket tunelovaný pomocí CAPWAPv6 tunelu

Stejně jako tomu bylo u IPv4 tunelu, i zde lze prohlásit verifikační test zaúspěšný. Všechny odeslané pakety byly doručeny k cíli prostřednictvím tunelu ad-resovaného IPv6 adresami tak, jak bylo v prvcích nastaveno.

7.15.3 Zhodnocení verifikačních testů WiFi

Vzhledem k tomu, že všechny verifikační testy dopadly tak, jak bylo očekáváno, lzejejich test hodnotit jako úspěšný. Díky tomu lze v první fázi nasadit řešení provozupomocí IPv4 tunelování, které bylo navrženo v kapitole Návrh řešení, a v případěpotřeby kdykoli přepnout nastavení způsob využívající IPv6 tunelování.

7.16 Správa koncových stanic

Verifikace návrhu pro správu koncových stanic byla provedena na instalaci aktuálnístabilní a otestované verzi Microsoft Windows Server 2012R2. Klientské zařízení pakdisponovalo operačním systémem Windows 8.1.

Testovaný scénář zahrnoval kompletní vyřazení protokolu IPv4 ihned po insta-laci tak, aby veškerá komunikace probíhala pouze pomocí protokolu IPv6. Po tomtoúkonu byla provedena instalace doménových služeb v plném rozsahu, pomocí volbyAdd Roles and Features. Následně byly staticky nakonfigurovány IPv6 adresy narozhraní. Vzhledem k tomu, že ve verifikační topologii byly oba stroje umístěny vestejné síti, byly k tomuto účelu použity IPv6 adresy ze stejného rozsahu o délceprefixu /64, viz obr. 51.

Stejným způsobem byla nakonfigurována i IPv6 adresa na klientském stroji.Poté bylo ověřeno funkční spojení mezi oběma stanicemi a schopnost klienta vyu-žít DNS server na stroji s instalovanou službou Active Directory Domain Servicespomocí příkazu nslookup.

C:\textbackslash Users\textbackslash user>nslookup adv6.netlab.localServer: UnknownAddress: 2001:718:803:d::1

Name: adv6.netlab.localAddress: 2001:718:803:d::1

7.16 Správa koncových stanic 122

Obrázek 51: Konfigurace rozhraní na testovacím doménovém řadiči

Obrázek 52: Inicializace a připojení klienta do domény pomocí IPv6

Po ověření konektivity bylo možné připojit klientské zařízení k doménové slu-žbě provozované na serveru pod doménovým jménem adv6.netlab.local. Toto připo-jení bylo iniciováno v nastavení systémových parametrů klienta, viz obr. 52. Potébyl uživatel na klientovi vyzván k zadání přístupových údajů, s administrátorskýmoprávněním.

Po ověření přístupu byl klient korektně zapojen do domény, viz obr. 52, čímžbyla verifikována schopnost serveru komunikovat s klienty. Verifikační test tedy do-padl korektně a návrh lze považovat za ověřený.

8 EKONOMICKÉ ZHODNOCENí NÁVRHU 123

8 Ekonomické zhodnocení návrhu

Tato část práce zahrnuje zhodnocení ekonomické stránky nasazení IPv6 protokoluv rámci MENDELU. Ačkoli v této práci bylo jedním z požadavků maximálně využítstávající infrastrukturu, ne vždy to bylo možné.

8.1 Nákladové položky

Nákladové položky, které je nutné do ekonomického zhodnocení zahrnout jsou uve-deny v následujícím přehledu a poté jsou detailně popsány níže:

• nákup nových přepínačů na přístupové vrstvě,

• náklady na mzdu technického pracovníka, který provede a verifikuje změnukonfigurace dle návrhu,

• roční platba za bezpečností řešení Snort IDS/IPS.

Nákup nových přepínačů na přístupové vrstvě Pro nasazení IPv6 protokolu nasíťové služby a zajištění bezpečnosti v rámci sítě MENDELU bylo navrženo převážněvyužití stávající infrastruktury. Tato infrastruktura však, především na přístupovévrstvě, není pravidelně aktualizována a nedisponuje tak některými, především bez-pečnostními, funkcemi. Jejich absence je však zásadním nedostatkem z pohledu bez-pečnosti a implementaci IPv6 protokolu do sítě MENDELU bez těchto funkcí lzejen stěží doporučit.

Současně je na univerzitě nasazeno přibližně 270 kusů přepínačů, které je nutnépovýšit na verzi, která podporuje ASW funkce popsané v kap. 5.7. Z tohoto počtuse jedná přibližně 100 kusů přepínačů Cisco Catalyst 2950, které již novou verzinepodporují a je nutné je nahradit novějšími zařízeními. V současnosti univerzitanakupuje prvky Cisco Catalyst 2960. Ačkoli jejich cenu nelze z důvodů soutěže určitpřesně, dle historických nákupů je přibližně 65 000 Kč. V případě nákupu 100 kusůse tak jedná o částku převyšující 6 milionů.

Náklady na mzdu technického pracovníka, který zajistí změnu a verifikaci kon-figurace dle návrhu Techničtí pracovníci, kteří jsou na univerzitě zaměstnáni a je-jichž pracovní náplní jsou i rozvojové úkoly v rámci sítě MENDELU, by zajisté byliv dlouhodobém výhledu schopni upravit konfigurace prvků dle návrhu zpracovanéhov této práci. Zvýšení nákladů na jejich práci tak lze očekávat ve výrazně menšímrozsahu, než by tomu bylo v případě, že by rozvojové úkoly nebyly součástí jejichpracovní náplně. Přesto je vhodné náklady na práci vypočíst. Na základě mzdovéhopředpisu Mendelovy univerzity v Brně (Havel, 2015) je hrubá mzda technickéhopracovníka 18 000 Kč. Celkové náklady zaměstnavatele pak přibližně 24 000 Kč.Po odečtení nákladů na dovolenou zaměstnance jsou pak náklady na odpracovanouhodinu při úvazku 40 hodin týdně přibližně 152 Kč.

8.2 Výnosové položky 124

Na základě kvalifikovaného odhadu pak byla stanovena předpokládaná odpra-covaná doba nutná k nasazení protokolu IPv6. Jednotlivé položky jsou uvedenyv tab. 16.

Tabulka 16: Předpokládaná doba práce technického pracovníka vedoucí k nasazení danéslužby

Služba Testování Implementace Monitoring CelkemDNS 40 h 10 h 50 h 100 hFirewalling 80 h 30 h 40 h 150 hIDS, IPS 80 h 40 h 40 h 160 hACL 10 h 25 h 10 h 45 hVPN 60 h 10 h 20 h 90 hZabezpečení na úrovni ASW 45 h 35 h 8 h 88 hSledování provozu 10 h 2 h 5 h 17 hProxy 20 h 10 h 10 h 40 hAAA služby 80 h 40 h 30 h 150 hWebové služby 20 h 20 h 20 h 60 hPoštovní služby 40 h 15 h 20 h 75 hDatabázové služby 20 h 10 h 5 h 35 hČasové služby 5 h 1 h 2 h 8 hZálohovací služby 20 h 20 h 10 h 50 hVoIP - - - -Virtualizace 20 h 20 h 20 h 60 hWiFi 35 h 20 h 20 h 75 hCelkem 585 h 308 h 310 h 1203 h

Předpokládaná doba práce technického pracovníka je 1 203 hodin. Vyjádřenov nákladech zaměstnavatele se jedná o částku 182 856 Kč.

Roční platba za bezpečností řešení Snort IDS/IPS V kapitole č. 5.4 bylo na-vrženo použití aplikace Snort. Ta je vyvíjena pod licencí open source, avšak ak-tualizovaná databáze detekčních pravidel je placená. Celková roční částka za jejípředplacení je 399$, což je ke dni 13. 5. 2017 přibližně 9 693 Kč. Tato částka neníve srovnání s celkovými náklady na správu sítě MENDELU velká, dá předpokládat,že její úhrada nebude pro ÚIT problémem.

Celkové náklady, které je nutné na zprovoznění protokolu IPv6 v síti MENDELUvynaložit, jsou vysoké, a to především z důvodu, že na přístupové vrstvě jsou použitypřepínače s neaktuální verzí operačního systému.

8.2 Výnosové položky

Položky, které by univerzitě přinesly přímý zisk plynoucí z nasazení protokolu IPv6v rámci její sítě, nelze jednoznačně určit. Pro zachování konkurenceschopnosti uni-

8.3 Zhodnocení 125

verzity se však, minimálně v omezeném rozsahu, stane nasazení IPv6 protokolu nut-ností. Výpočet, který by se pokoušel odhadnout úbytek studentů, či jiných zdrojůfinancí, na základě nedostupnosti IPv6 protokolu by byl pouhým odhadem.

Dle Googlu (2017) je ke dni 10. 5. 2017 celkem 14,67 % uživatelů, kteří k tomu,aby přistoupili ke službám Google, využívají protokol IPv6, viz obr. 53. Počet těchtouživatelů se pak každým rokem zvyšuje. V případě, že by se potenciální zájemceo studium či spolupráci s MENDELU pokoušel využít IPv6 protokol, v současnostiby nebyl úspěšný. Na tuto skutečnost je nutné reagovat v první řadě.

Obrázek 53: Statistika uživatelů přistupující ke službám Google pomocí protokoluIPv6 (Google, 2017)

8.3 Zhodnocení

Náklady, které by vyžadovalo kompletní nasazení IPv6 včetně zabezpečení jsouv současné chvíli příliš vysoké na to, aby vyvážily celkový přínos v případě jejichvydání. Přesto je protokol IPv6 nutné nasadit minimálně v takové míře, aby službypomocí něj poskytované byly dostupné především v síti internet. To by zahrnovaloimplementaci následujících částí této práce:

• adresní prostor, adresace a směrování koncových zařízení, která se budou týkatpředevším serverové části sítě (viz Filip, 2015),

• firewall,

8.3 Zhodnocení 126

• IDS/IPS,

• autoritativní DNS,

• rekurzivní DNS,

• webové servery vč. univerzitního informačního systému,

• poštovní servery.

Výše uvedený seznam zahrnuje položky, na jejichž implementaci nebude vyža-dován nákup nových operačních systémů, licencí či hardwaru. Náklady se tak ztenčío jejich nejvýraznější část a přínos, který nasazení IPv6 protokolu přináší, je pakzajisté větší, než vložené prostředky.

9 ZÁVĚR 127

9 Závěr

Cílem této diplomové práce bylo navrhnout řešení pro bezpečnost a implementacisíťových služeb pro protokol IPv6 na Mendelově univerzitě v Brně. V této prácibyla nejprve provedena analýza stávajícího řešení síťových služeb a popsána je-jich konfigurace. Následně bylo ke každé službě navrhnuto řešení pro protokol IPv6a především byl pro každou z těchto služeb vytvořen návrh implementace tohotoprotokolu do stávající sítě MENDELU. Závěrem pak byly všechny implementačnínávrhy otestovány a slovně popsány v rámci kapitoly Verifikace navrženého řešení.Součástí je taktéž ekonomické zhodnocení návrhu přechodu na protokol IPv6.

Na základě ekonomického hodnocení navrhovaných změn lze konstatovat, žez hlediska síťových služeb nebude implementace protokolu nijak nákladná. Pokudby však mělo v současnosti dojít k plošnému nasazení IPv6 včetně všech souvisejí-cích bezpečnostních funkcí na přístupové vrstvě, pak by celková cena neodpovídalapřínosu celé instalace.

Hlavním přínosem této práce je přehled konfiguračních změn, které, v případěkonfigurace, zajistí kompatibilitu stávajících služeb s protokolem IPv6. V případěpožadavku na jeho implementaci do sítě MENDELU bude případný IT správce dis-ponovat informacemi, které povedou ke spolehlivému nasazení konfiguračních úprav.Na základě informací uvedených v této diplomové práci pak také lze rozhodnouto postupu nasazení protokolu IPv6 do sítě tak, aby tato implementace nezpůsobilaproblémy ve stávající síti.

10 REFERENCE 128

10 Reference

CAMPBELL, D., IPv6 Martian and Bogon Filters — 6session [online]. 2009 [cit.2016-11-09]. Dostupné z: <https://6session.wordpress.com/2009/04/08/ipv6-martian-and-bogon-filters/>

ALLEN, J., IPv6 and Open Source IDS [online]. 2015 [cit. 2016-10-23]. Dostupnéz: <https://www.sans.org/reading-room/whitepapers/detection/ipv6-open-source-ids-35957>

ARUBA, 802.11ac In-Depth [online]. 2015 [cit. 2017-03-23]. Dostupné z:<http://www.arubanetworks.com/assets/wp/WP_80211acInDepth.pdf>

ASHWORTH, J., BCP38 [online]. 2016 [cit. 2016-12-10]. Dostupné z:<http://www.bcp38.info/index.php/Mai_Page>

BIERINGER, P., Linux IPv6 HOWTO (en) [online]. 2017 [cit. 2017-03-11].Dostupné z:<https://mirrors.bieringer.de/Linux+IPv6-HOWTO/index.html>

BIERINGER, P., Network Address Translation (NAT) using netfilter6 [online].2016 [cit. 2017-02-21]. Dostupné z: <http://mirrors.bieringer.de/Linux+IPv6-HOWTO/nat-netfilter6..html>

BREEN, K., Home IDS with Snort And Snorby [online]. 2015 [cit. 2016-06-05].Dostupné z: <https://techanarchy.net/2015/01/home-ids-with-snort-and-snorby/>

BRO, The Bro Network Security Monitor [online]. 2014 [cit. 2016-10-05]. Dostupnéz: <https://www.bro.org/>

BURIAN, J., Návrh univerzitního firewallu na platformě Cisco [online]. 2016 [cit.2016-11-10]. Vedoucí práce Ing. Jiří Balej Dostupné z:<https://theses.cz/id/yvdjql/zaverecna_prace.pdf>

CALETKA, O., Útok na DNS náhodnými dotazy [online]. 2015 [cit. 2016-09-11].Dostupné z:<https://www.root.cz/clanky/utok-na-dns-nahodnymi-dotazy/>

CISCO, Catalyst 2960 and 2960-S Switches Software Configuration Guide, Release15.0(1)SE - Configuring IPv6 ACLs - Cisco [online]. 2016 [cit. 2016-10-05].Dostupné z: <http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst2960/software/release/15-0_1_se/configuration/guide/scg2960/swv6acl.html>

CISCO, Catalyst 3750 Switch Software Configuration Guide, Release 12.2(58)SE[online]. 2016 [cit. 2017-01-23]. Dostupné z: <http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750/software/release/12-2_58_se/configuration/guide/3750scg/swv6acl.html>

10 REFERENCE 129

CISCO, Cisco ASA New Features by Release [online]. 2017 [cit. 2017-05-20].Dostupné z: <http://www.cisco.com/c/en/us/td/docs/security/asa/roadmap/asa_new_features.html>

CISCO, Cisco Wireless LAN Controller IPv6 Deployment Guide, CUWN Release8.0 [online]. 2014 [cit. 2016-10-29]. Dostupné z:<http://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-0/IPV6_DG.html#pgfId-76691>

CISCO, Cisco Wireless Solutions Software Compatibility Matrix [online]. 2017 [cit.2017-04-20]. Dostupné z: <http://www.cisco.com/c/en/us/td/docs/wireless/compatibility/matrix/compatibility-matrix.html>

CISCO, DNS Best Practices, Network Protections, and Attack Identification[online]. 2017 [cit. 2017-03-10]. Dostupné z: <http://www.cisco.com/c/en/us/about/security-center/dns-best-practices.html>

CISCO, Chapter: Configuring IPv6 ACLs [online]. 2016 [cit. 2017-01-23]. Dostupnéz: <http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750/software/release/15-0_2_se/configuration/guide/scg3750/swv6acl.html#98396>

CISCO, IPv6 Configuration Guide, Cisco IOS Release 15.2S [online]. 2012 [cit.2016-12-05]. Dostupné z:<http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipv6/configuration/15-2s/ip6-15-2s-book/ip6-nd-cache.html>

CISCO, IPv6 Configuration Guide, Cisco IOS Release 15.2S [online]. 2012 [cit.2017-03-17]. Dostupné z:<http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipv6/configuration/15-2s/ip6-15-2s-book/ip6-ra-guard.html>

CISCO, IPv6 Device Tracking [online]. 2012 [cit. 2017-01-29]. Dostupné z:<http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipv6_fhsec/configuration/15-sy/ip6-dev-track.html>

CISCO, IPv6 snooping [online]. 2016 [cit. 2017-02-10]. Dostupné z:<http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipv6_fhsec/configuration/15-s/ip6f-15-s-book/ip6-snooping.>

CISCO, NAT64 Technology: Connecting IPv6 and IPv4 Networks [online]. 2012[cit. 2017-02-10]. Dostupné z: <http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/white_paper_c11-676278.html>

CISCO, Release Notes for the Catalyst 3750, 3560, 3560-C, 2960, 2960-S, 2960-C,and 2960-Plus Switches, Cisco IOS Release 15.0(2)SE and Later [online].2016 [cit. 2017-01-03]. Dostupné z:

10 REFERENCE 130

<http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750/software/release/15-0_2_se/release/notes/OL25301.html>

CLOUDSHARK, CloudShark on cloudshark.org [online]. 2013 [cit. 2017-02-01].Dostupné z: <https://www.cloudshark.org/captures/8eb7d881565c>

COFFEEN, T., DHCPv6 and the Trouble with MAC Addresses [online]. 2015 [cit.2016-12-09]. Dostupné z:<https://community.infoblox.com/t5/IPv6-Center-of-Excellence/DHCPv6-and-the-Trouble-with-MAC-Addresses-Part-1-of-2/ba-p/3474>

CVE, CVE - CVE-2008-1447 [online]. 201x [cit. ]. Dostupné z:<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1447>

ČERMÁK, M. Bezpečnostní analýza provozu DNS [online]. Brno, 2014 [cit.2017-05-14]. Dostupné z: <http://is.muni.cz/th/325314/fi_m/>.Diplomová práce. Masarykova univerzita, Fakulta informatiky. Vedoucí práceRNDr. Jan Vykopal, Ph.D.

DENT, K., Postfix: the definitive guide, 2004, O’Reilly Media. ISBN978-0596002121.

ELATOV, K., Snort On Debian [online]. 2014 [cit. 2016-08-20]. Dostupné z:<http://elatov.github.io/2014/04/snort-debian/>

FILIP, T. Návrh integrace IPv6 do počítačové sítě Mendelovy univerzity v Brně voblasti směrování [online]. Brno, 2015 [cit. 2016-10-19]. Diplomová práce.Mendelova univerzita v Brně, Provozně ekonomická fakulta. Vedoucí práceIng. Martin Pokorný, Ph.D. Dostupné z: <http://theses.cz/id/4s6hgt/>.

FRIEDL, S.,An Illustrated Guide to IPsec [online]. 2005 [cit. 2016-09-10].Dostupné z: <http://unixwiz.net/techtips/iguide-ipsec.html>

GEYER, L. ZABEZPEČENÍ SÍTÍ S PROTOKOLEM IPV6 [online]. Brno, 2012[cit. 2017-05-14]. Dostupné z: <https://www.vutbr.cz/www_base/zav_prace_soubor_verejne.php?file_id=53953>. Diplomová práce. Vysokéučení technické v Brně, Fakulta elektrotechniky a komunikačních technologií.Ústav telekomunikací. Vedoucí práce doc. Ing. Karel Burda, CSc.

GOOGLE, Google IPv6 [online]. 2017 [cit. 2017-03-18]. Dostupné z:<https://www.google.com/intl/en/ipv6/statistics.html>

GRAZIANI, R., IPv6 fundamentals: a straightforward approach to understandingIPv6, 2012, Cisco Press. ISBN 1-58714-313-5.

GREGR, M., IPv6 TUNNEL MONITORING PLUG-IN [online]. 2012 [cit.2016-10-17]. Dostupné z: <https://github.com/VUTBR/nf-tools/tree/master/flowmon-ipv6-tunnel>

10 REFERENCE 131

HAGEN, S., Ipv6 essentials, 2014, O’Reilly Media. ISBN 1449319211.

HAVEL, L., MZDOVÝ PŘEDPIS MENDELOVY UNIVERZITY V BRNĚ[online]. 2015 [cit. 2017-04-20]. Dostupné z: <https://is.mendelu.cz/auth/dok_server/vyhledavani.pl?id=5;download=150627;ve_slozce=67225>

HLOUŠEK, V. Implementace DHCPv6 serveru [online]. Brno, 2008 [cit.2016-10-19]. Diplomová práce. Masarykova univerzita, Fakulta informatiky.Vedoucí práce RNDr. David Antoš, Ph.D. Dostupné z:<http://is.muni.cz/th/72599/fi_m/dp.pdf>.

HORLEY, E., Practical IPv6 for Windows Administrators, 2013, Apress. ISBN978-1430263708.

CHARLTON, T., What are the differences between an IPSec VPN and a GREtunnel? [online]. 2013 [cit. 2016-11-14]. Dostupné z:<http://blog.boson.com/bid/92815/What-are-the-differences-between-an-IPSec-VPN-and-a-GRE-tunnel>

CHUMLENOVÁ, B. Řešení dynamické konfigurace IPv6 klientů v počítačové sítiMendelovy univerzity v Brně [online]. Brno, 2015 [cit. 2016-10-19]. Bakalářskápráce. Mendelova univerzita v Brně, Provozně ekonomická fakulta. Vedoucípráce Ing. Martin Pokorný, Ph.D. Dostupné z:<http://theses.cz/id/m5l4g2/>.

IETF Resource Records for the DNS Security Extensions [online]. 2005 [cit.2016-07-14]. Dostupné z: <https://www.ietf.org/rfc/rfc4034.txt>

IETF, Domain Name System (DNS) Security Extensions Mapping for theExtensible Provisioning Protocol (EPP) [online]. 2005 [cit. 2016-07-20].Dostupné z: <https://tools.ietf.org/html/rfc4310>

IETF, DNS64: DNS Extensions for Network Address Translation from IPv6Clients to IPv4 Servers [online]. 2011 [cit. 2016-12-05]. Dostupné z:<https://tools.ietf.org/html/rfc6147>

IETF, Address Allocation for Private Internets [online]. 1996 [cit. 2016-12-04].Dostupné z: <https://tools.ietf.org/html/rfc1918>

IETF, Basic Socket Interface Extensions for IPv6 [online]. 1999 [cit. 2016-08-24].Dostupné z: <https://tools.ietf.org/html/rfc2553>

IETF, Basic Transition Mechanisms for IPv6 Hosts and Routers [online]. 2005 [cit.2017-03-22]. Dostupné z <https://tools.ietf.org/html/rfc4213>

IETF, Control And Provisioning of Wireless Access Points (CAPWAP) ProtocolSpecification [online]. 2009 [cit. 2016-08-01]. Dostupné z:<https://tools.ietf.org/html/rfc5415>

10 REFERENCE 132

IETF, DNS Security (DNSSEC) Hashed Authenticated Denial of Existence[online]. 2008 [cit. 2016-07-18]. Dostupné z:<https://tools.ietf.org/html/rfc5155>

IETF, DNS Security Introduction and Requirements [online]. 2005 [cit. 2016-07-12].Dostupné z: <https://tools.ietf.org/html/rfc4033>

IETF, DNS Security Introduction and Requirements [online]. 2005 [cit. 2016-07-12].Dostupné z: <https://tools.ietf.org/html/rfc4033>.

IETF, DNSSEC Operational Practices [online]. 2006 [cit. 2016-07-23]. Dostupné z:<https://www.ietf.org/rfc/rfc4641.txt>

IETF, Domain-based Message Authentication, Reporting, and Conformance(DMARC) [online]. 2015 [cit. 2017-01-19]. Dostupné z:<https://tools.ietf.org/html/rfc7489>

IETF, Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [online]. 2003[cit. 2016-11-12]. Dostupné z: <http://tools.ietf.org/html/rfc3315>

IETF, Generic AAA Architecture [online]. 2000 [cit. 2017-01-19]. Dostupné z:<https://tools.ietf.org/html/rfc2903>

IETF, Internet Protocol, Version 6 (IPv6) Specification [online]. 1998 [cit.2016-12-03]. Dostupné z: <https://tools.ietf.org/html/rfc2460>

IETF, IPv6 Multicast Address Scopes [online]. 2014 [cit. 2016-07-25]. Dostupné z:<https://tools.ietf.org/html/rfc7346>

IETF, IPv6 Router Advertisement Options for DNS Configuration [online]. 2010[cit. 2017-01-19]. Dostupné z: <https://tools.ietf.org/html/rfc6106>

IETF, IPv6 Stateless Address Autoconfiguration [online]. 1998 [cit. 2016-08-01].Dostupné z: <https://www.ietf.org/rfc/rfc2827.txt>

IETF, IPv6 Unicast Address Assignment Considerations [online]. 2008 [cit.2016-08-15]. Dostupné z: <https://tools.ietf.org/html/rfc5375>

IETF, Network Ingress Filtering [online]. 2000 [cit. 2016-08-01]. Dostupné z:<https://www.ietf.org/rfc/rfc2827.txt>

IETF, Privacy Extensions for Stateless Address Autoconfiguration in IPv6 [online].2007 [cit. 2016-08-20]. Dostupné z:<https://tools.ietf.org/html/rfc4941>

IETF, Protocol Modifications for the DNS Security Extensions [online]. 2005 [cit.2016-07-16]. Dostupné z: <https://www.ietf.org/rfc/rfc4035.txt>

IETF, Secure Neighbor Discovery (SEND) [online]. 2005 [cit. 2016-08-18].Dostupné z: <https://tools.ietf.org/html/rfc3971>

10 REFERENCE 133

IETF, Sender Policy Framework (SPF) for Authorizing Use of Domains in Email,Version 1 [online]. 2014 [cit. 2017-01-19]. Dostupné z:<https://tools.ietf.org/html/rfc7208>

IETF, SIP: Session Initiation Protocol [online]. 2002 [cit. 2016-12-01]. Dostupné z:<https://tools.ietf.org/html/rfc3261>

IETF, Stateful NAT64: Network Address and Protocol Translation from IPv6Clients to IPv4 Servers [online]. 2011 [cit. 2016-12-02]. Dostupné z:<https://tools.ietf.org/html/rfc6146>

ISC, ISC Knowledge Base [online]. 2016 [cit. 2016-11-20 ]. Dostupné z:<https://kb.isc.org/category/77/0/10/Software-Products/BIND9/>

JANIS, K., Ipv6 support in Dude [online]. 2016 [cit. 2016-10-07]. Dostupné z:<https://forum.mikrotik.com/viewtopic.php?t=110118>

JOUDAL, J. Implementace IPv6 Na PřF JU [online]. České Budějovice, 2011 [cit.2016-10-19]. Bakalářská práce. Jihočeská univerzita v Českých Budějovicích,Přírodovědecká fakulta. Vedoucí práce Ing. Rudolf Vohnout Dostupné z:<http://theses.cz/id/rkiodq/>.

JUNIPER, Understanding IPv6 Neighbor Discovery Inspection [online]. 2016 [cit.2017-02-03]. Dostupné z: <https://www.juniper.net/documentation/en_US/junos/topics/concept/port-security-nd-inspection.html>

KAUSHIK, D., IPSec IPv6 - Securing the NextGen Internet [online]. 2008 [cit.2016-08-20]. Dostupné z:<http://ipv6.com/articles/security/IPsec.htm>

KOSTĚNEC, M., IPv6 na ZČU v Plzni – aktuální stav [online]. 2010 [cit.2015-01-17]. Dostupné z:<http://archiv.cesnet.cz/ipv6/wg/p/zcu-ipv6.pdf>

KOYCHEV, V., Build IPS Virtual Appliance Based on Vmware ESXi, Snort andDebian Linux [online]. 2015 [cit. 2016-06-20]. Dostupné z:<https://s3.amazonaws.com/snort-org-site/production/document_files/files/000/000/069/original/Snort-IPS-Tutorial.pdf>

LAMPA, P., Pravidla přidělování IPv6 adres na VUT [online]. 2009 [cit.2015-01-17]. Dostupné z:<http://www.fit.vutbr.cz/CVT/ipv6/lib/exe/fetch.php?media=intro:pravidlaipv6doc.pdf>

LERCH, A., Webová aplikace pro analýzu útoku na vybrané servery MENDELU[online]. 2016 [cit. 2016-12-03]. Dostupné z:<https://is.mendelu.cz/auth/lide/clovek.pl?zalozka=7;id=57379;studium=69780;zp=56824;download_prace=1>

10 REFERENCE 134

LINDQVIST, H., domain name system - Possibility to synthesise resource recordsin BIND? - Server Fault [online]. 201x [cit. ]. Dostupné z:<http://serverfault.com/questions/839041/possibility-to-synthesise-resource-records-in-bind?noredirect=1#comment1073306_839041>

LINKOVA, J., Let’s talk about IPv6 DNS64 DNSSEC [online]. 2016 [cit.2017-02-10]. Dostupné z:<https://blog.apnic.net/2016/06/09/lets-talk-ipv6-dns64-dnssec/>

LIU, C., DNS and Bind on IPv6, 2011, O’Reilly Media. ISBN 978-1449305192.

LOSHIN, P., IPv6: Theory, Protocol, and Practice (The Morgan Kaufmann Seriesin Networking. 2004 [cit. 2017-02-16]. ISBN:9781558608108

MACURA, L., Implementace IPV6 na OPF SU [online]. 2010 [cit. 2015-01-17].Dostupné z:<http://archiv.cesnet.cz/ipv6/wg/p/su-ipv6.pdf>

MARIADB, What is MariaDB 5.5? - MariaDB Knowledge Base [online]. 2017 [cit.2017-05-17]. Dostupnéz:<https://mariadb.com/kb/en/mariadb/what-is-mariadb-55/>

MICROSOFT, MS-CHAP v2 [online]. 2017 [cit. 2017-05-17]. Dostupnéz:<https://technet.microsoft.com/en-us/library/cc957983.aspx>

MRUGALSKI, T.,Dibbler – a portable DHCPv6 User’s guide [online]. 2015 [cit.2016-11-21]. Dostupné z:<http://klub.com.pl/dhcpv6/doc/dibbler-user.pdf>

NETWORK TIME FOUNDATION, NTP Version 4 Release Notes [online]. 2003[cit. 2016-09-29]. Dostupné z: <http://doc.ntp.org/4.2.0/release.html>

NIXCRAFT, Apache IPv6 Configuration: Dual Stacked IPv4 & IPv6 Virtual Hosts[online]. 2009 [cit. 2016-11-02]. Dostupné z: <https://www.cyberciti.biz/faq/ipv6-apache-configuration-tutorial/>

ODOM, W., CCNP Route 642-902 official certification guide, 2010, Cisco Press.ISBN 978-1-58720-253-7.

PALUCH, P., Cisco 2950 V.12.1 IOS Upgrade to 15.0 or Higher [online]. 2015 [cit.2017-02-25]. Dostupné z: <https://supportforums.cisco.com/discussion/12389456/cisco-2950-v121-ios-upgrade-150-or-higher>

PAVLIŠ, M., Možnosti tunelování protokolu IPv6 přes protokol IPv4 [online]. 2010[cit. 2017-02-23]. Vedoucí práce Agáta Bodnárová Dostupné z:<http://theses.cz/id/66yw36/>

PILIHANTO, A., A Complete Guide on IPv6 Attack and Defense [online]. 2011[cit. 2017-02-16]. Dostupné z: <https://www.sans.org/reading-room/

10 REFERENCE 135

whitepapers/detection/complete-guide-ipv6-attack-defense-33904>

POWERSHELLSERVER, PowerShell Server — Secure Remote Access toPowerShell Over SSH [online]. 2016 [cit. 2016-10-24]. Dostupné z:<http://www.powershellserver.com/>

PUSTKA, Martin Pustka - Slasti a strasti IPv6 v univerzitní síti [online]. 2016[cit. 2017-01-20]. Dostupné z:<https://www.youtube.com/watch?v=YvF7alLJPDg>

PUSTKA, M., Přehled stavu IPv6 v síti VŠB TUO [online]. 2010 [cit. 2015-01-17].Dostupné z: <http://archiv.cesnet.cz/ipv6/wg/p/vsb-ipv6.pdf>

RIPE, RIPE Database Query [online]. 2017 [cit. 2017-04-10]. Dostupné z:<https://apps.db.ripe.net/search>

SANTOS, O., CCNA Security 210-260 Official Cert Guide, 2015, Cisco Press.ISBN 9781587205668.

SATRAPA, P. IPv6 na TU v Liberci [online]. 2010 [cit. 2015-01-17]. Dostupnéz:<http://archiv.cesnet.cz/ipv6/wg/p/tul-ipv6.pdf>.

SNORT, Snort - Network Intrusion Detection [online]. 2016 [cit. 2016-10-10].Dostupné z: <https://www.snort.org>

SURÝ, O., Knot DNS krátký pohled do budoucnosti [online]. 2014 [cit. 2016-11-05].Dostupné z: <https://www.nic.cz/public_media/IT14/prezentace/Ondrej_Sury_2.pdf>

ŠMEREK, M., Vícekriteriální hodnocení variant [online]. 2014 [cit. 2015-10-12].Dostupné z: <https://moodle.unob.cz/pluginfile.php/35526/mod_resource/content/2/OV_T13.pdf>

VANĚK, František Vaněk - Nasazení IPv6 na UCEEB ČVUT [online]. 2016 [cit.2017-01-25]. Dostupné z:<https://www.youtube.com/watch?v=zP7a2AGVyfU>

VANĚK, F., IPv6 – Areál Karlova náměstí (FEL ČVUT) [online]. 2010 [cit.2015-01-17]. Dostupné z:<http://archiv.cesnet.cz/ipv6/wg/p/fel-ipv6.pdf>

VESELÝ, J. IPv6 a bezpečnost [online]. Brno, 2014 [cit. 2017-05-14]. Dostupné z:<http://theses.cz/id/pm0z8i/>. Diplomová práce. Masarykova univerzita,Fakulta informatiky. Vedoucí práce doc. RNDr. Eva Hladká, Ph.D. .

VESELÝ, J. IPv6 a bezpečnost [online]. Brno, 2014 [cit. 2017-05-14]. Dostupné z:<http://theses.cz/id/pm0z8i/>. Diplomová práce. Masarykovauniverzita, Fakulta informatiky. Vedoucí práce doc. RNDr. Eva Hladká, Ph.D.

10 REFERENCE 136

VILÍMEK, J. Implementace protokolu IPv6 u ISP [online]. Praha, 2007 [cit.2016-10-21]. Bakalářská práce. Vysoká škola ekonomická v Praze. Vedoucípráce Luboš Pavlíček Dostupné z: <http://theses.cz/id/7vqfzq/>.

WENRY, Ch.,Configuring IPv6 Snooping and DHCPv6 Guard on Cisco IOS[online]. 2014 [cit. 2016-10-18]. Dostupné z:<https://insinuator.net/2014/01/configuring-ipv6-snooping-and-dhcpv6-guard-on-cisco-ios/>

WILKINS, S., A Guide To Intrusion Detection And Intrusion Prevention Systems(IDS/IPS) [online]. 2015 [cit. 2016-08-01]. Dostupné z:<http://www.tomsitpro.com/articles/intrusion-detection-intrusion-prevention-systems-ids-ips,2-959-2.html>

YORK, D., IPv6 Time Servers (NTP) [online]. 2014 [cit. 2016-11-03]. Dostupné z:<http://www.internetsociety.org/deploy360/resources/ipv6-time-servers-ntp/>

ŽABENSKÝ, F. Návrh zavedení protokolu IP verze 6 do síťové infrastruktury školy[online]. Ostrava, 2015 [cit. 2016-10-19]. Bakalářská práce. Ostravskáuniverzita, Přírodovědecká fakulta. Vedoucí práce RNDr. Tomáš Sochor, CSc.Dostupné z: <http://theses.cz/id/dezk8s/>.

ŽORŽ, J., et al., Best Current Operational Practice for operators:IPv6 prefixassignment for end-users - static (stable)or dynamic (non-stable) and whatsize to choose. [online]. 2017 [cit. 2017-05-15]. Dostupné z:<http://internetsociety.org/deploy360/wp-content/uploads/2017/03/draft-IPv6pd-BCOP-v1.pdf>