Development and Deployment of Software Tools for Analyzing of Network Access at VŠB-TU Ostrava

Katedra automatizaˇcn´ı techniky a ˇr´ızen´ı

V´

yvoj a nasazen´ı SW prostˇ

redk˚

u

pro anal´

yzu pˇ

r´ıstup˚

u do s´ıtˇ

e

Vˇ

SB-TU Ostrava

Development and Deployment of Software Tools for

Analyzing of Network Access at Vˇ

SB-TU Ostrava

Vedouc´ı b.p.: Ing. Fojt´ık David, Ph.D.

Konzultant: Ing. Martin Pustka, Ph.D.

ˇ

Reˇsitel: Jakub Kalnik

Kalnik, J. V´yvoj a nasazen´ı SW prostˇredk˚u pro anal´yzu pˇr´ıstup˚u do s´ıtˇe VˇSB-TU Os-trava: bakal´aˇrsk´a pr´ace. Ostrava: VˇSB – Technick´a univerzita Ostrava, Fakulta strojn´ı, Katedra automatizaˇcn´ı techniky a ˇr´ızen´ı, 2017, 40 s. Vedouc´ı pr´ace: Fojt´ık, D.

Tato bakal´aˇrsk´a pr´ace se zab´yv´a anal´yzou pˇr´ıstup˚u na s´ıt’ VˇSB-TU, coˇz je rozs´ahl´a poˇc´ıtaˇcov´a s´ıt’ poskytuj´ıc´ı sluˇzby tis´ıc˚um uˇzivatel˚u, stanic a mobiln´ıch zaˇr´ızen´ı. Do anal´yzy spad´a identifikace kl´ıˇcov´ych ´udaj˚u, jejich z´ısk´an´ı, ukl´ad´an´ı a prezentace kon-cov´emu uˇzivateli. V pr´aci je pops´an princip autentizace uˇzivatel˚u v t´eto s´ıti a problema-tika z´ısk´an´ı poˇzadovan´ych informac´ı. D´ale je v pr´aci provedena anal´yza rozˇsiˇritelnosti jiˇz nasazen´ych softwarov´ych prostˇredk˚u. Praktick´a ˇc´ast se zamˇeˇruje na konfiguraci pro-dukˇcn´ıch server˚u a v´yvoj nov´ych softwarov´ych prostˇredk˚u, kter´e budou zajiˇst’ovat poˇzado-van´e funkcionality.

Kl´ıˇcov´a slova:RADIUS, s´ıt’, pˇr´ıstup, IPv6, EDUROAM Annotation

Kalnik, J. Development and Deployment of Software Tools for Analyzing of Network Access at VˇSB-TU Ostrava: Bachelor Thesis. Ostrava: VˇSB – Technical University of Ostrava, Faculty of Mechanical Engineering, Department of Control Systems and In-strumentation, 2017, 40 p. Head: Fojt´ık, D.

This thesis deals with analysis of accesses into VˇSB-TU network which provides ser-vices to thousands of users, workstations and mobile deser-vices. Analysis includes identifi-cation, acquisition, storage and presentation of valuable data. The thesis explains how the users authenticate and how to collect the data. There is also analysis of extensibility of currently used software. The practical part mainly focuses on production servers con-figuration and development of new software which will provide requested functionalities. Keywords:RADIUS, network, access, IPv6, EDUROAM

Obsah

Seznam pouˇzit´ych zkratek 6

1 Uvod´ 8

2 Ovˇeˇrov´an´ı pˇr´ıstup˚u do s´ıtˇe 9

2.1 Architektura . . . 9 RADIUS server . . . 9 EDUROAM . . . 9 2.2 AAA model . . . 12 Autentizace . . . 12 Autorizace . . . 13 ´ Uˇctov´an´ı . . . 13 2.3 Protokol IPv6 . . . 15 Bezstavov´a konfigurace . . . 15

3 Volba programov´ych prostˇredk˚u a konfigurace server˚u 17 3.1 Konfigurace serveru Radiator . . . 18

Rychlostn´ı optimalizace . . . 19

3.2 Konfigurace serveru FreeRadius . . . 20

3.3 SQL datab´aze a obsluhuj´ıc´ı skripty . . . 21

´ Uˇctov´an´ı . . . 23 IPv6 adresy . . . 23 Blokace . . . 24 4 Webov´e rozhran´ı 26 4.1 Vyhled´av´an´ı . . . 26 4.2 Blokace . . . 29

5 Popis vytvoˇren´ych programov´ych prostˇredk˚u 32 5.1 Skripty pro sbˇer informac´ı a jejich agregaci . . . 32

5.2 Skripty pro monitoring . . . 33

5.3 Webov´y server . . . 34

5.4 Datab´azov´y server . . . 35

6 Z´avˇer 37

Seznam pouˇ

zit´

ych zkratek

AAA Authentication, Authorization, and Accounting

Zkratka pro autentizaci, autorizaci a ´uˇctov´an´ı

ARP Address Resolution Protocol

Protokol pro dohled´an´ı MAC adresy na z´akladˇe znalosti IPv4 adresy

API Application Programming Interface

Rozhran´ı vyuˇz´ıvan´e program´atory pro tvorbu aplikac´ı

CAS Central Authentication Service

Protokol umoˇzˇnuj´ıc´ı pˇristupovat k v´ıce sluˇzb´am na z´akladˇe jednoho pˇrihl´aˇsen´ı

DHCP Dynamic Host Configuration Protocol

Protokol umoˇzˇnuj´ıc´ı automatizovan´e pˇridˇelov´an´ı IPv4 adres DHCPv6 Dynamic Host Configuration Protocol version 6

Protokol umoˇzˇnuj´ıc´ı automatizovan´e pˇridˇelov´an´ı IPv6 adres

DNS Domain Name System

Syst´em umoˇzˇnuj´ıc´ı pˇreklad dom´enov´ych jmen na IPv4/IPv6 adresy

IPv4 Internet Protocol version 4

Protokol slouˇz´ıc´ı k adresaci poˇc´ıtaˇcov´ych s´ıt´ı

IPv6 Internet Protocol version 6

Protokol slouˇz´ıc´ı k adresaci poˇc´ıtaˇcov´ych s´ıt´ı

LDAP Lightweight Directory Access Protocol

Protokol slouˇz´ıc´ı k pˇr´ıstupu a ukl´ad´an´ı dat na adres´aˇrov´em serveru

MAC Media Access Control

Identifik´ator s´ıt’ov´eho zaˇr´ızen´ı

NAS Network Access Server

Pˇr´ıstupov´y server

PHP PHP Hypertext Preprocessor

Programovac´ı jazyk

PL/SQL Procedural Language/Structured Query Language

Nadstavba jazyka SQL

RADIUS Remote Authentication Dial-In User Service

S´ıt’ov´y protokol umoˇzˇnuj´ıc´ı centralizovanou autentizaci, autorizaci a ´uˇctov´an´ı

SNMP Simple Network Management Protocol

SQL Structured Query Language

Strukturovan´y dotazovac´ı jazyk pro pr´aci s relaˇcn´ımi datab´azemi.

TCP Transmission Control Protocol

Protokol zajiˇst’uj´ıc´ı spolehliv´e doruˇcen´ı dat v IP s´ıt´ıch.

UDP User Datagram Protocol

Protokol pro doruˇcov´an´ı dat v IP s´ıt´ıch.

VLAN Virtual Local Area Network

Virtu´aln´ı lok´aln´ı s´ıt’.

VPN Virtual Private Network

Technologie k propojen´ı priv´atn´ıch s´ıt´ı pˇres s´ıtˇe veˇrejn´e. VˇSB Vysok´a ˇskola b´aˇnsk´a.

1 ´

Uvod

C´ılem bakal´aˇrsk´e pr´ace je vyvinout a popsat informaˇcn´ı syst´em, kter´y budou dennˇe pouˇz´ıvat s´ıt’ov´ı administr´atoˇri na VˇSB-TU. Jejich potˇreba disponovat takov´ym syst´emem vych´az´ı zejm´ena z ˇcasov´e n´aroˇcnosti dohled´av´an´ı z´aznam˚u pˇri bˇeˇzn´e pr´aci, podpoˇre uˇzivatel˚u, ale i jejich blokac´ı. ˇCas str´aven´y nad dohled´an´ım identity pˇripojen´eho zaˇr´ızen´ı se dnes pohybuje aˇz okolo patn´acti minut a nov´y syst´em by mˇel umoˇznit tuto dobu zkr´atit ide´alnˇe pod jednu minutu. D´ale by mˇel syst´em umoˇznit snadnou anal´yzu pˇr´ıstup˚u do s´ıtˇe, kter´a je s aktu´aln´ımi programov´ymi prostˇredky velmi pracn´a.

D˚uvodem, proˇc je v˚ubec potˇreba tyto informace shromaˇzd’ovat a vyhled´avat v nich, je zpˇrehlednˇen´ı a zrychlen´ı provozn´ı podpory uˇzivatel˚u a tak´e zrychlen´ıˇreˇsen´ı bezpeˇcnostn´ıch incident˚u.

Vˇsichni uˇzivatel´e resp. jejich zaˇr´ızen´ı se do univerzitn´ı s´ıtˇe pˇrihlaˇsuj´ı pomoc´ı sv´eho jedineˇcn´eho osobn´ıho jm´ena a hesla. Tyto pˇrihlaˇsovac´ı ´udaje ovˇeˇruj´ı pˇr´ıstupov´a zaˇr´ızen´ı (AP, pˇrep´ınaˇce) za pomoci RADIUS serveru, proto prvn´ı kapitola bude vˇenov´ana popisu RADIUS protokolu a to v rozsahu nutn´em pro pochopen´ı a realizaci c´ıl˚u t´eto pr´ace. Dalˇs´ı kapitoly pr´ace budou vˇenov´any samotn´emu v´yvoji a implementaci programov´ych n´astroj˚u.

2 Ovˇ

eˇ

rov´

an´ı pˇ

r´ıstup˚

u do s´ıtˇ

e

RADIUS (z anglick´eho Remote Authentication Dial-In User Service) je s´ıt’ov´y protokol umoˇzˇnuj´ıc´ı centralizovanou autentizaci, autorizaci a ´uˇctov´an´ı (AAA model) (HASSELL, J. 2002). RADIUS protokol b´yv´a nasazov´an ve vˇetˇs´ıch s´ıt´ıch kv˚uli moˇznosti pˇridˇelit kaˇzd´emu uˇzivateli jedineˇcn´e pˇrihlaˇsovac´ı ´udaje a centr´alnˇe je uchov´avat. Tento prin-cip je v´yhodnˇejˇs´ı neˇz zabezpeˇcen´ı pˇr´ıstup˚u do s´ıtˇe pomoc´ı pˇredsd´ılen´e fr´aze (z ang-lick´eho pre-shared-key). Rizikem tohoto zabezpeˇcen´ı je, ˇze umoˇzˇnuje pˇripojen´ı do s´ıtˇe komukoli se znalost´ı hesla. Takov´a slabina je pak zneuˇziteln´a potenci´aln´ım ´utoˇcn´ıkem k ´utok˚um na vnitˇrn´ı/vnˇejˇs´ı s´ıt’ se zachov´an´ım vysok´e m´ıry anonymity.

2.1 Architektura

Pro lepˇs´ı pochopen´ı souvislost´ı je potˇreba vˇedˇet, jak konkr´etnˇe jsou RADIUS servery na s´ıti VˇSB nasazeny a co jednotliv´e pojmy znamenaj´ı. Zapojen´ı RADIUS server˚u na uni-verzitn´ı s´ıti je zjednoduˇsenˇe zn´azornˇeno na obr´azku 2.1. Je zde tak´e oranˇzovou a ˇcervenou barvou zn´azornˇeno, jak bude do existuj´ıc´ı architektury implementov´an vyv´ıjen´y in-formaˇcn´ı syst´em.

RADIUS server

Serverem rozum´ıme poˇc´ıtaˇc poskytuj´ıc´ı sluˇzby klient˚um (model klient-server)

(Server Definition 2014). Na univerzitn´ı s´ıti jsou k tomuto ´uˇcelu pouˇz´ıv´any programy Ra-diator aFreeradius. Radiator ovˇeˇruje uˇzivatele EDUROAM, Freeradius ovˇeˇruje uˇzivatele pˇripojuj´ıc´ı se pomoc´ı VPN klienta a uˇzivatele s doˇcasn´ymi ´uˇcty (host´e univerzity v r´amci konan´ych akc´ı).

Klient, kter´y s RADIUS serverem komunikuje, je naz´yv´an pˇr´ıstupov´y server - zn´am´y pod zkratkou NAS (z anglick´eho Network Access Server) (HASSELL, J. 2002). Jedn´a se vˇetˇsinou o s´ıt’ov´y pˇrep´ınaˇc, Wi-Fi access-point (AP) nebo VPN koncentr´ator.

EDUROAM

EDUROAM (EDUcation ROAMing) je projekt, kter´y vznikl v roce 2002 v Nizo-zemsku (KR ˇCM ´A ˇR P.,CALETKA O. 2016) (Fungov´an´ı roamingu 2016). Uˇzivatel˚um

ˇclensk´e organizace umoˇzˇnuje pˇripojen´ı k s´ıti v jin´e organizaci, neˇz je jeho domovsk´a. Nejv´ıce je rozˇs´ıˇren ve Wi-Fi s´ıt´ıch akademick´ych instituc´ı. Pokud budu uvaˇzovat mo-delov´y pˇr´ıpad, kdy na VˇSB-TU pˇrijede v r´amci zahraniˇcn´ı st´aˇze student, napˇr´ıklad ze ˇ

Spanˇelska, bude se moci pˇripojit sv´ymi pˇrihlaˇsovac´ımi ´udaji bez nutnosti si vytv´aˇret nov´y doˇcasn´y ´uˇcet v s´ıti VˇSB. T´ehle funkcionality je doc´ıleno pomoc´ı hierarchie auten-tizaˇcn´ıch vazeb zapojen´ych v projektu. M´ıstn´ı RADIUS server uˇzivatele z ciz´ı organizace pozn´a dle tzv. realmu, kter´y se pˇripojuje za uˇzivatelsk´e jm´eno.

ˇ

Retˇezec identifikuj´ıc´ı uˇzivatele vypad´a obecnˇe takto:abc0123@uco.es.abc0123. Pˇredsta-vuje pˇrihlaˇsovac´ı jm´eno v r´amci domovsk´e instituce a uco.es je realm identifikuj´ıc´ı konkr´etn´ı instituci. Autentizace

”roamuj´ıc´ıho“ uˇzivatele prob´ıh´a fin´alnˇe aˇz v jeho do-movsk´e organizaci, kter´e jsou pˇred´any k ovˇeˇren´ı pˇrihlaˇsovac´ı ´udaje. M´ıstn´ı RADIUS server se s danou organizac´ı spojuje za pomoci n´arodn´ıho nebo koˇrenov´eho RADIUS serveru. Znalost tohoto principu je d˚uleˇzit´a zejm´ena proto, ˇze se mus´ı zohlednit pˇri n´avrhu blokac´ı uˇzivatel˚u.

2.2 AAA model

V´yznam pojmu AAA model byl jiˇz zm´ınˇen v ´uvodu kapitoly 2. Pro dosaˇzen´ı c´ıl˚u t´eto pr´ace je potˇreba pochopit jednotliv´e aspekty AAA modelu a jeho implementaci v proto-kolu RADIUS. Nejv´ıce se je tˇreba zamˇeˇrit pˇredevˇs´ım na autentizaci (pro doc´ılen´ı blokace uˇzivatel˚u) a ´uˇctov´an´ı (sbˇer informac´ı).

Autentizace

Pˇri pˇripojen´ı zaˇr´ızen´ı do s´ıtˇe je jeho veˇsker´y s´ıt’ov´y provoz blokov´an (GNU Radius Refe-rence Manual 2008). Jedinou vyj´ımku tvoˇr´ı komunikace s NAS serverem. NAS uˇzivatele pomoc´ıEAP-over-LAN vyzve k pˇredstaven´ı. Uˇzivatel odeˇsle sv´e jm´eno i heslo a NAS tyto pˇrihlaˇsovac´ı ´udaje zapouzdˇr´ı do Access-Request paketu, kter´y odeˇsle RADIUS ser-veru, jenˇz je ovˇeˇr´ı v˚uˇci datab´azi opr´avnˇen´ych uˇzivatel˚u. Pokud jsou pˇrihlaˇsovac´ı ´udaje v poˇr´adku, odpov´ı RADIUS server paketemAccess-Accept a NAS zapoˇcne uˇzivatelskou relaci. V opaˇcn´em pˇr´ıpadˇe odpov´ı paketemAccess-Reject a uˇzivateli je pˇr´ıstup odepˇren. V situaci, kdy ˇz´adn´a odpovˇed’ nepˇrijde, je poˇzadavek nˇekolikr´at zopakov´an. NAS m˚uˇze tak´e poˇzadavky pˇresmˇerovat na z´aloˇzn´ı RADIUS server.

Existuje tak´e moˇznost m´ısto dvou uveden´ych odpovˇed´ı RADIUS serveru poslat paket

Access-Challenge(Remote Authentication Dial In User Service (RADIUS) 2000). Pomoc´ı tohoto paketu se RADIUS server uˇzivatele dot´aˇze na dodateˇcn´e informace. Pro uˇzivatele to m˚uˇze znamenat, ˇze se mu na zaˇr´ızen´ı zobraz´ı ot´azka, na kterou mus´ı odpovˇedˇet. RADIUS server pot´e odpov´ıd´a opˇet pomoc´ıAccess-Accept,Access-Reject nebo Access-Challenge paketu.

RADIUS server si pˇri ovˇeˇrov´an´ı ´udaj˚u dˇel´a z´aznamy o jejich v´ysledku. Samotn´y z´aznam m˚uˇze vypadat napˇr´ıklad takto:

Sun Oct 9 18:21:47 2016: Login OK:[kal0178@vsb.cz]

(CSID D7-C2-9A-E0-2F-D2 NAS C2960-KOLT92-GH/172.19.17.189)

Z tohoto z´aznamu lze vyˇc´ıst, jak´y uˇzivatel ˇz´adal o pˇr´ıstup do s´ıtˇe (kal0178@vsb.cz), kdy a odkud o nˇej ˇz´adal (v tomhle pˇr´ıpadˇe pˇrep´ınaˇc C2960-KOLT92-GH) a MAC ad-resa uˇzivatelova zaˇr´ızen´ı (D7-C2-9A-E0-2F-D2). Tyto informace jsou vˇsak nedostaˇcuj´ıc´ı, protoˇze napˇr´ıklad ´uplnˇe chyb´ı, jak´a IP adresa byla uˇzivateli pˇridˇelena nebo jak dlouho byl na s´ıti pˇripojen.

Autorizace

Po ´uspˇeˇsn´e autentizaci je moˇzno pomoc´ı pˇr´ıstupov´eho serveru uˇzivatele autorizovat k pouˇzit´ı r˚uzn´ych sluˇzeb. NAS se v pˇr´ıpadˇe ˇz´adosti o autorizaci opˇet chov´a jako prostˇredn´ık a pˇri vyˇrizov´an´ı ˇz´adosti kontaktuje server, kter´y poskytuje ˇz´adanou sluˇzbu a sdˇel´ı mu, ˇze je uˇzivatel tuto sluˇzbu opr´avnˇen pouˇz´ıvat (HASSELL, J. 2002). Ten k n´ı mus´ı m´ıt samozˇrejmˇe dohodnut pˇr´ıstup. V s´ıti VˇSB-TU je pˇri tomto kroku uˇzivateli pˇriˇrazeno VLAN-ID, kter´e urˇcuje do jak´e vnitˇrn´ı s´ıtˇe bude pˇriˇrazen. Protoˇze v s´ıti VˇSB-TU jin´a autorizace pomoc´ı pˇr´ıstupov´eho serveru nen´ı implementov´ana, tud´ıˇz ji nelze vyuˇz´ıt k c´ıli t´ehle pr´ace, nebudu tuto problematiku v´ıce rozv´adˇet.

´

Uˇ

ctov´

an´ı

Hned ze zaˇc´atku je tˇreba podotknout, ˇze slovo ´uˇctov´an´ı vych´az´ı z anglick´eho accounting

a nikoliv billing. Slovo ´uˇctov´an´ı je tedy odvozeno od uˇzivatelsk´eho ´uˇctu, proto se jedn´a o operace k uˇzivatelsk´emu ´uˇctu vztaˇzen´e.

´

Uˇctov´an´ı je pro samotnou anal´yzu pˇr´ıstup˚u ten nejcennˇejˇs´ı zdroj informac´ı. Po ´uspˇeˇsn´e autentizaci NAS kromˇe autorizace zapoˇcne uˇzivatelskou relaci a v pr˚ubˇehu t´eto relace NAS na RADIUS server odes´ıl´a tzv. accounting pakety. Do tˇechto paket˚u se pˇrikl´adaj´ı atributy, coˇz jsou data ve tvaru n´azev-hodnota. Nejpouˇz´ıvanˇejˇs´ı atributy jsou standar-tizov´any v RFC 2865 (Remote Authentication Dial In User Service (RADIUS) 2000), k tˇemto z´akladn´ım atribut˚um se vˇsak, je-li to tˇreba, m˚uˇze pˇridat libovoln´e mnoˇzstv´ı atribut˚u nestandartizovan´ych.

Typy ´uˇctovac´ıch paket˚u 1. Accounting start

Odes´ıl´a se po autentizaci uˇzivatele. 2. Accounting update

Odes´ıl´a se pr˚ubˇeˇznˇe bˇehˇem uˇzivatelsk´e relace. 3. Accounting stop

Odes´ıl´a se po ukonˇcen´ı uˇzivatelsk´e relace.

Ve vˇsech paketech se nach´azej´ı stejn´e atributy a mˇen´ı se pouze ˇcasov´e hodnoty. Jedinˇe u Accounting stop paketu jeden ´udaj pˇrib´yv´a a to d˚uvod ukonˇcen´ı relace

(Acct-Terminate-Cause). V praxi ovˇsem naraz´ıme na probl´em, ˇze r˚uzn´a s´ıt’ov´a zaˇr´ızen´ı do stejn´eho atributu vkl´adaj´ı odliˇsn´e ´udaje. Napˇr´ıklad VPN koncentr´ator do atributu

Calling-Station-Id vkl´ad´a IP adresu, ze kter´e se uˇzivatel pˇripojuje. Oproti tomu pˇri pˇripojen´ı uˇzivatele pomoc´ı bezdr´atov´eho bodu, kde funkci pˇr´ıstupov´eho serveru zajiˇst’uje

Wireless Controller, je jako hodnota atributu Calling-Station-Id uvedena MAC adresa zaˇr´ızen´ı. M˚uˇze tak´e nastat pˇr´ıpad, kdy u klient˚u s IPv6 konektivitou dojde k zaˇc´atku ´

uˇctov´an´ı dˇr´ıve, neˇz je klientovi pomoc´ı DHCP pˇridˇelena IPv4 adresa a tu je tˇreba pozdˇeji doplnit zAccounting update paket˚u. Po konzultaci s administr´atory s´ıtˇe jsme doˇsli k sadˇe atribut˚u, kter´e se budou uchov´avat, a tyto pro pˇrehlednost uv´ad´ım v tabulce 2.1. Nˇekter´e atributy jsou zde uvedeny v´ıcekr´at z d˚uvodu r˚uzn´e interpretace jednotliv´ych s´ıt’ov´ych prvk˚u.

Tabulka 2.1: Atributy accounting paketu

atribut hodnota(pˇr´ıklad) popis

Acct-Session-Id 57fa79ba/4d:67:ca:af:8b:b5/6271137 ID relace

User-Name abc0123@vsb.cz uˇzivatelsk´y login + organizace Framed-IP-Address 158.149.50.24 pˇridˇelen´a IPv4 adresa

Calling-Station-Id 158.149.50.24 pˇridˇelen´a IPv4 adresa Calling-Station-Id 4d:67:ca:af:8b:b5 MAC adresa zaˇr´ızen´ı Calling-Station-Id 62.129.36.134 vzd´alen´a IPv4/IPv6 adresa (VPN)

Called-Station-Id LAP1131-KOL-A1:eduroam jm´eno NAS NAS-Identifier C2960-KOLB9-IJ jm´eno NAS NAS-IP-Address 158.149.50.254 IPv4 adresa NAS Acct-Status-Type Start typ ´uˇctovac´ıho paketu

Timestamp 2016-10-13 09:15:14+02 ˇcasov´a znaˇcka

Z´aznamy o ´uˇctov´an´ı server ukl´ad´a do textov´ych soubor˚u. Jestliˇze vˇsak chceme v tˇechto souborech nˇeco dohled´avat, tak se dost´av´ame do nepˇr´ıjemn´e situace. Pˇri velk´em poˇctu uˇzivatel˚u b´yvaj´ı tyto soubory velmi velk´e a nepˇrehledn´e. Hled´an´ı v nich tak´e ztˇeˇzuje

fakt, ˇze na velik´ych s´ıt´ıch b´yv´a RADIUS server˚u z d˚uvod˚u redundance nˇekolik. Kdyˇz si pˇredstav´ıme situaci, kdy administr´ator dohled´av´a nˇekolik dn´ı star´y z´aznam v textov´em souboru s desetitis´ıci z´aznamy na nˇekolika serverech, tak je z´ahy jasn´e, ˇze tento postup nen´ı pro bˇeˇzn´y provoz vhodn´y. C´ılem tedy bude tato data z RADIUS server˚u extrahovat a ukl´adat do relaˇcn´ı datab´aze. Zn´azornˇen´ı, jak bude navrhovan´y syst´em zakomponov´an do existuj´ıc´ı s´ıtˇe m˚uˇzeme vidˇet na obr´azku 2.1.

2.3 Protokol IPv6

Aˇckoli by se mohlo zd´at, ˇze jiˇz v´ıme, kde hledat vˇsechna pro n´as zaj´ımav´a data, tak v ´uˇctov´an´ı jeden velmi d˚uleˇzit´y ´udaj chyb´ı a to - IPv6 adresa. IPv6 je modern´ı protokol pouˇz´ıvan´y souˇcasnˇe s protokolem IPv4. IPv6 je v nˇekter´ych ohledech od IPv4 velmi odliˇsn´y, i kdyˇz oba vznikly za c´ılem umoˇznit poˇc´ıtaˇc˚um v s´ıti komunikovat. IPv6 se dnes nasazuje pˇrev´aˇznˇe kv˚uli zaplnˇen´ı adresn´ıho prostoru IPv4.

Ke spr´avn´e funkci jak´ehokoli zaˇr´ızen´ı v s´ıti je potˇreba, aby bylo sezn´ameno se s´ıt’ov´ymi parametry. Mezi nejd˚uleˇzitˇejˇs´ı s´ıt’ov´e parametry patˇr´ı IP adresa, maska s´ıtˇe, v´ychoz´ı br´ana a adresy DNS server˚u. U protokolu IPv4 je nejbˇeˇznˇejˇs´ı zp˚usob z´ısk´an´ı tˇechto parametr˚u pomoc´ı DHCP protokolu. Komunikaci s DHCP serverem zahajuje zaˇr´ızen´ı odesl´an´ım paketuDHCP-Discover (DHCP 2016). Protoˇze zaˇr´ızen´ı o s´ıti zat´ım nic nev´ı, tento paket pˇrijde vˇsem zaˇr´ızen´ım, kter´e se na s´ıti nach´azej´ı. Na tuto ˇz´adost zareaguje pouze DHCP server a to paketemDHCP-Offer, kde se klientovi identifikuje a nab´ıdne mu s´ıt’ov´e parametry s informac´ı o d´elce platnosti tˇechto parametr˚u. Klient na tuto odpovˇed’ reaguje paketem DHCP-Request, kde ˇz´ad´a o pˇridˇelen´ı nab´ıdnut´ych parametr˚u. Tato odpovˇed’ je opˇet adresov´ana vˇsem zaˇr´ızen´ım v s´ıti, protoˇze klient poˇr´ad nen´ı opr´avnˇen tyto parametry uˇz´ıvat. Konverzaci zakonˇc´ı DHCP server paketem DHCP-Acknowledge, ˇc´ımˇz pˇridˇelen´e parametry nab´yvaj´ı platnosti a klient je m˚uˇze po dobu platnosti vyuˇz´ıvat. Vˇsechny pˇridˇelen´e parametry si DHCP server ukl´ad´a do vlastn´ıho logu.

Bezstavov´

a konfigurace

Bezstavov´a konfigurace je nov´y zp˚usob z´ısk´av´an´ı komunikaˇcn´ıch parametr˚u pˇri pˇripojen´ı zaˇr´ızen´ı do s´ıtˇe (SATRAPA, P. 2011). Narozd´ıl od stavov´e konfigurace, kdy veˇsker´e komunikaˇcn´ı parametry pˇridˇeluje DHCP server nebo se zad´avaj´ı manu´alnˇe (a tud´ıˇz lze vˇse relativnˇe jednoduˇse dohledat), u bezstavov´e konfigurace pˇrech´az´ı ˇc´ast procesu na samotn´e koncov´e zaˇr´ızen´ı. V IPv6 s´ıti s povolenou bezstavovou konfigurac´ı si ˇc´ast s´ıt’ov´ych parametr˚u pˇridˇel´ı zaˇr´ızen´ı samo na z´akladˇe ohl´aˇsen´ı smˇerovaˇce. Informace, kter´e se v ohl´aˇsen´ı smˇerovaˇce nach´azej´ı, se liˇs´ı podle konfigurace. Pˇri bezstavov´e konfi-guraci si vˇsak vˇzdy v´yslednou IPv6 adresu urˇc´ı zaˇr´ızen´ı. V souˇcasn´e dobˇe nen´ı technicky moˇzn´e koneˇcnou IPv6 adresu ˇz´adn´ym zp˚usobem ovlivnit. Proto se tato IPv6 adresa nem˚uˇze nach´azet nikde v z´aznamech server˚u, pomoc´ı kter´ych by administr´atoˇri mohli

toto zaˇr´ızen´ı identifikovat.

Zamezen´ı probl´emu s identifikac´ı zaˇr´ızen´ı komunikuj´ıc´ıho pomoc´ı protokolu IPv6 by se dalo pomˇernˇe jednoduˇse dos´ahnout pomoc´ı DHCPv6 serveru. Tohle ˇreˇsen´ı m´a ovˇsem jednu velkou nev´yhodu a to chybˇej´ıc´ı podporu ze strany nˇekter´ych operaˇcn´ıch syst´em˚u, kter´e konfiguraci pomoc´ı DHCPv6 serveru nepodporuj´ı, a tak by jim bylo zamezeno pomoc´ı IPv6 protokolu komunikovat. Kv˚uli tomuto omezen´ı budu muset vyuˇz´ıt toho, ˇze i kdyˇz nem´am ˇz´adnou informaci o vyuˇzit´ych IPv6 adres´ach v m´e s´ıti, tak poˇr´ad veˇsker´y provoz prob´ıh´a pˇres univerzitn´ı s´ıt’ov´e prvky, bez kter´ych by komunikace uˇzivatele ne-byla moˇzn´a. Nab´ız´ı se napˇr´ıklad aktivn´ı dotazov´an´ı smˇerovaˇce na jeho tabulku soused˚u (neighbour cache), obdobu ARP tabulky, kterou pouˇz´ıvaj´ı zaˇr´ızen´ı komunikuj´ıc´ı pomoc´ı protokolu IPv4.

3 Volba programov´

ych prostˇ

redk˚

u

a konfigurace server˚

u

Jak jsem jiˇz zm´ınil v pˇredchoz´ı kapitole, tak ve v´ychoz´ım stavu se ´uˇctov´an´ı zaznamen´av´a do textov´eho souboru. Mou snahou by tedy mˇelo b´yt co nejv´yhodnˇejˇs´ı cestou tato data ukl´adat do datab´aze. Tohoto lze doc´ılit bud’ pomoc´ı syntaktick´e anal´yzy (parsov´an´ım) textov´eho souboru, nebo zmˇenou konfigurace RADIUS serveru. Protoˇze RADIUS servery Radiator a FreeRadius pouˇz´ıvan´e na VˇSB podporuj´ı odes´ıl´an´ı dat na SQL servery, budu vyuˇz´ıvat tyto vlastnosti.

IPv6 adresy uˇzivatel˚u jsou z´ısk´av´any ze smˇerovaˇc˚u pomoc´ı SNMP protokolu, kde se poˇzadovan´a data nach´azej´ı v tabulce soused˚u. Pomoc´ı tohoto zp˚usobu ale nelze m´ıt vˇsechna data okamˇzitˇe a mus´ı b´yt zvolen interval, kdy se data budou ze smˇerovaˇc˚u z´ısk´avat. Tento interval mus´ı b´yt dostateˇcnˇe kr´atk´y na to, abychom byli schopni archi-vovat vˇsechny adresy, kter´e se na s´ıti vyskytly, a z´aroveˇn dostateˇcnˇe dlouh´y, abychom pˇr´ıliˇs nezatˇeˇzovali smˇerovaˇce a datab´azi. Nev´yhoda tohoto ˇreˇsen´ı je, ˇze se tabulky stahuj´ı vˇzdy cel´e a v datab´azi bude velk´e mnoˇzstv´ı duplicitn´ıch dat, kter´e bude nutn´e pravidelnˇe agregovat.

Jeden z provozn´ıch poˇzadavk˚u na tento informaˇcn´ı syst´em byl, aby bˇeˇzel na Linuxov´em serveru. Byla zvolena distribuce Debian, kter´a se vyznaˇcuje velmi vysokou spolehlivost´ı a stabilitou. Jako datab´azov´y server jsem zvolil PostgreSQL. Tento datab´azov´y server jsem zvolil pˇredevˇs´ım kv˚uli datov´ym typ˚um. PostgreSQL obsahuje datov´e typy pro MAC adresu a IPv4/IPv6 adresu. Prezentaci dat administr´ator˚um bude zajiˇst’ovat webov´y server Apache.

3.1 Konfigurace serveru Radiator

Server Radiator byl navrˇzen jako modul´arn´ı program (RadiatorR RADIUS Server 2015).

Jedna z jeho konfiguraˇcn´ıch moˇznost´ı umoˇzˇnuje pˇri zpracov´av´an´ı poˇzadavk˚u spustit skript napsan´y v jazyce Perl, kter´ym m˚uˇzeme upravit chov´an´ı cel´eho procesu. Protoˇze popis cel´eho konfiguraˇcn´ıho souboru nespad´a do rozsahu t´eto pr´ace, budu popisovat jen nejd˚uleˇzitˇejˇs´ı parametry z toho d˚uvodu, aby ´upravy byly na jiˇz funguj´ıc´ım serveru replikovateln´e.

Pro ˇreˇsen´ı zadan´ych c´ıl˚u se je tˇreba zamˇeˇrit na tzv. klauzuli handler, kter´a specifikuje, jak´e operace se maj´ı prov´est pro urˇcit´e skupiny pˇripojuj´ıc´ıch se uˇzivatel˚u. Pro lepˇs´ı pˇredstavu uv´ad´ım ˇc´ast konfigurace slouˇz´ıc´ı k odbaven´ı uˇzivatel˚u VˇSB.

<Handler Realm=/^vsb\.cz$/ix > AuthBy LDAP_VSB AuthLog vsbusers AcctLogFileName /var/log/radiator/radiator-detail WtmpFileName /var/log/radiator/wtmp RejectHasReason </Handler>

V uveden´e ˇc´asti konfiguraˇcn´ıho souboru m˚uˇzeme vidˇet, ˇze pro uˇzivatele s realmem vsb.cz bude provedeno ovˇeˇren´ı hesla pomoc´ı LDAP (AuthBy), um´ıstˇen´ı textov´ych sou-bor˚u pro log (AuthLog pro autentizaci,AcctLogFileName pro ´uˇctov´an´ı a WtmpFileName

pro Access-Request pakety) a ˇze v pˇr´ıpadˇe selh´an´ı autentizace se uˇzivateli odeˇsle d˚uvod nezdaru (RejectHasReason). Dle dokumentace (RadiatorR RADIUS Server 2015) lze

do konfigurace pˇridat n´avˇest´ıAuthBy INTERNAL, kde m˚uˇzeme ovlivnit vytv´aˇren´ı od-povˇedi na pˇr´ıchoz´ı ´uˇctovac´ı pakety. V naˇsem pˇr´ıpadˇe odpovˇed’ mˇenit nechceme, m˚uˇzeme ale vyuˇz´ıt toho, ˇze v t´eto f´azi m˚uˇzeme spustit n´ami napsan´y skript, kter´emu server pˇred´a vˇsechny ´uˇctovac´ı atributy ve formˇe asociativn´ıho pole (Satrapa, P. c2000). Pot´e jiˇz nen´ı probl´em pomoc´ı skriptu vˇsechna potˇrebn´a data odeslat do datab´azov´eho serveru.

Pro doc´ılen´ı blokace jsem p˚uvodnˇe pouˇzil skript, kter´y se spustil pˇri pˇrijet´ı paketu

Access-Request a dotazoval se datab´aze na seznamy blokovan´ych uˇzivatel˚u a MAC adres. Radiator m´a bohuˇzel takovou vlastnost, ˇze skript spustil a ukonˇcil pro kaˇzd´y paket zvl´aˇst’, coˇz v´yznamnˇe nav´yˇsilo ˇcas potˇrebn´y pro vyˇr´ızen´ı jednoho poˇzadavku. Server poˇzadavek bˇeˇznˇe vyˇr´ıd´ı v ˇcase kolem 1ms. Pˇri spouˇstˇen´ı skriptu ˇcas potˇrebn´y k vyˇr´ızen´ı poˇzadavku vzrostl na asi 70ms. Tento probl´em se projev´ı pˇri vysok´e z´atˇeˇzi, kdy server nakupen´e poˇzadavky nestihne vyˇr´ıdit vˇcas a uˇzivatel´e se nejsou schopni autentizovat.

Pro implementaci blokace jsem nakonec pouˇzil klauzuliAuthBy FILE, kter´a je prim´arnˇe urˇcen´a k autentizaci uˇzivatel˚u, jejichˇz ´udaje jsou uloˇzeny v textov´em souboru. V´ysledek

autentizace lze pot´e negovat pomoc´ı konfiguraˇcn´ıho parametruBlacklist. Samotn´a kon-figurace m˚uˇze vypadat n´asledovnˇe:

<AuthBy FILE> Identifier check_users NoCheckPassword NoEAP NoDefault Blacklist Filename /etc/radiator/utils/blacklistUsers.txt </AuthBy>

Pro blokaci MAC adres staˇc´ı vytvoˇrit stejnou sekci s jedinou zmˇenou a to pˇrid´an´ım parametruAuthenticateAttribute Calling-Station-Id. Ten n´am umoˇzn´ı kontrolovat m´ısto uˇzivatelsk´ych jmen MAC adresy. V´ysledn´a konfigurace tedy m˚uˇze vypadat n´asledovnˇe:

<Handler Realm=/^vsb\.cz$/ix > <AuthBy INTERNAL> AcctHook file:"/etc/radiator/utils/sqlradacct.pl" </AuthBy> AuthByPolicy ContinueUntilReject AuthBy check_users AuthBy check_mac AuthBy LDAP_VSB AuthLog vsbusers AcctLogFileName /var/log/radiator/radiator-detail WtmpFileName /var/log/radiator/wtmp RejectHasReason </Handler>

Aktualizaci soubor˚u zajiˇst’uje jednoduch´y skript, kter´y si data naˇcte z datab´aze a soubory pˇrep´ıˇse. Radiator zmˇenu souboru detekuje dle data posledn´ı ´upravy, takˇze nen´ı tˇreba sluˇzbu restartovat. Skript je spouˇstˇen pomoc´ı pl´anovaˇce Cron.

Rychlostn´ı optimalizace

Jiˇz jsem se zm´ınil o probl´emu, kter´y nastal pˇri implementaci blokac´ı. Radiator skripty spouˇst´ı a ukonˇcuje zvl´aˇst’ pro kaˇzd´y paket. Blokaci jsem mohl z vˇetˇsiny implementovat konfiguraˇcnˇe, ale u sbˇeru dat z ´uˇctov´an´ı jsem se tomuto pˇr´ıstupu snaˇzil vyhnout, abych neztratil flexibilitu, kterou mi vlastn´ı zpracov´an´ı dat pˇred jejich vloˇzen´ım do datab´aze nab´ız´ı. Aby doba bˇehu skriptu byla co nejkratˇs´ı, tak jsem vytvoˇril jednoduch´y proxy server. Skript tak nemus´ı pokaˇzd´e navazovat ˇsifrovan´e TCP spojen´ı a ˇcekat na proveden´ı poˇzadovan´ych operac´ı datab´aze. Tuto starost jsem pˇrenesl na proxy server, kter´y si s datab´az´ı udrˇzuje perzistentn´ı spojen´ı a pˇredpˇripraven´e dotazy. ˇCinnost skriptu jsem omezil pouze na naform´atov´an´ı potˇrebn´ych ´udaj˚u a sestaven´ı UDP paketu, kter´y je na

proxy server odes´ıl´an pˇres m´ıstn´ı smyˇcku. Proxy server se star´a o ˇcten´ı dat z vyrovn´avac´ı pamˇeti (anglicky buffer) a jejich vkl´ad´an´ı do datab´aze. Dalˇs´ı pˇridan´a hodnota proxy serveru je ta, ˇze v pˇr´ıpadˇe v´ypadku datab´aze pˇrijat´a data ukl´ad´a do mezipamˇeti (anglicky cache). Takto m˚uˇze syst´em fungovat bez jejich ztr´aty. Proxy server je kv˚uli sv´e povaze naps´an jako d´emon.

3.2 Konfigurace serveru FreeRadius

Server FreeRadius narozd´ıl od serveru Radiator nedisponuje takovou flexibilitou, kter´a umoˇzˇnuje upravovat chov´an´ı za pomoc´ı vlastn´ıch skript˚u. Lze vˇsak doc´ılit stejn´eho chov´an´ı jako v pˇredchoz´ım pˇr´ıpadˇe za pouˇzit´ı vhodn´e konfigurace. Pro spolupr´aci Free-Radius serveru s datab´az´ı je tˇreba ke standartn´ı instalaci doinstalovat modul freeradius-postgresql (Guide/SQL HOWTO 2016). Po dokonˇcen´ı instalace je tˇreba v konfiguraˇcn´ım souboruradiusd.conf odkomentovat ˇr´adek $_{INCLUDE sql.conf, ˇc´ımˇz podporu SQL}

po-vol´ıme. V souborusql.conf se specifikuj´ı ´udaje nutn´e pro pˇripojen´ı k datab´azi. Nejd˚uleˇzitˇejˇs´ı ˇr´adky jsou zejm´ena tyto:

database = "postgresql" #N´azev datab´azov´eho programu server = "sixmon.vsb.cz" #Hostname

login = "radius" #Uˇzivatelsk´e jm´eno password = "heslo" #Heslo

radius_db = "radiusdb" #N´azev datab´aze

acct_table1 = "radacct" #N´azev tabulky pro ´uˇctov´an´ı $INCLUDE dialup.conf #Konfiguraˇcn´ı soubor s~SQL dotazy

V konfiguraˇcn´ım souboru ./sites-enabled/default v sekci accounting odkomentov´an´ım ˇr´adku sql urˇc´ıme, ˇze komunikace s datab´azov´ym serverem m´a prob´ıhat pro ´uˇctov´an´ı.

D´ale je tˇreba upravit konfiguraˇcn´ı soubor dialup.conf, kde specifikujeme, jak maj´ı dotazy odes´ılan´e na SQL server vypadat. Pro kaˇzdou ud´alost se zde konfiguruje prim´arn´ı a alternativn´ı dotaz pro pˇr´ıpad, ˇze prim´arn´ı selˇze. Tato vlastnost mi umoˇznila vypoˇr´adat se s probl´emem, kter´y jsem uvedl v kapitole 2.2, a to t´ım, ˇze pˇr´ıstupov´e servery do stejn´eho atributu vkl´adaj´ı odliˇsn´e hodnoty. V naˇsem pˇr´ıpadˇe m´ame v atributu Calling-Station-Id MAC adresu nebo IPv4 adresu, protoˇze FreeRadius odbavuje klienty s´ıtˇe

tuonet-guest a z´aroveˇn klienty pˇripojuj´ıc´ı se pˇres VPN.

Na datab´azov´em serveru jsem v tabulce pro ´uˇctov´an´ı urˇcil (viz. kapitola 3.3), ˇze slou-pec CallingStationId, do kter´eho se tato hodnota ukl´ad´a, je datov´eho typu macaddr

(datov´y typ pro MAC adresu). Kdyˇz tedy FreeRadius na datab´azov´y server odeˇsle do-taz, ˇc´ımˇz se snaˇz´ı do sloupce CallingStationId vloˇzit IPv4 adresu, dotaz je odm´ıtnut a FreeRadius odeˇsle alternativn´ı dotaz, kde je hodnota atributu vkl´ad´ana jiˇz spr´avnˇe do sloupce externalip.

K doc´ılen´ı blokace uˇzivatel˚u je tˇreba vytvoˇrit nov´y konfiguraˇcn´ı soubor, kde specifi-kujeme ´udaje pro pˇripojen´ı k datab´azov´emu serveru. Proto staˇc´ı zkop´ırovat jiˇz funkˇcn´ı soubor sql.conf, uloˇzit ho pod jin´ym n´azvem (zvolil jsem n´azevsql-blacklist.conf) a pouze upravit hodnoty jednotliv´ych konfiguraˇcn´ıch parametr˚u. Tento soubor se zahrne do hlavn´ıho konfiguraˇcn´ıho souboruradiusd.conf pomoc´ıˇr´adku$_{INCLUDE sql-blacklist.conf.}

Pro samotnou blokaci se v souborusites-enabled/default do sekce post-auth pˇridaj´ı tyto ˇr´adky:

#Blokace uˇzivatelsk´eho jm´ena

if ( "%{tolower:%{User-Name}}" == "%{sql-blacklist: SELECT userName FROM blacklist WHERE username=lower(’%{User-Name}’)}") {

reject

update reply {

Reply-Message = "Your account has been blocked." }

}

#Blokace MAC adresy

if ( "%{tolower:%{User-Name}}" == "%{sql-blacklist: SELECT mac FROM blacklist WHERE

mac=lower(’%{Calling-Station-Id}’)}") {

reject

update reply {

Reply-Message = "Your account has been blocked." }

}

3.3 SQL datab´

aze a obsluhuj´ıc´ı skripty

Datab´aze byla navrˇzena s ohledem na n´arazovou z´atˇeˇz, kter´a je zp˚usobena denn´ım reˇzimem student˚u a zp˚usobem zjiˇst’ov´an´ı jejich IPv6 adres. Nejvˇetˇs´ı ˇspiˇcky se oˇcek´avaj´ı v rann´ıch hodin´ach, kdy studenti pˇrich´az´ı do ˇskoly a jejich zaˇr´ızen´ı se pˇripojuj´ı do s´ıtˇe. Pˇri mˇeˇren´ı, kter´e jsem prov´adˇel, bylo bˇeˇzn´e, ˇze ve ˇspiˇck´ach datab´aze zpracov´avala aˇz 1130 dotaz˚u za sekundu. Toto mˇeˇren´ı jsem prov´adˇel pomoc´ı programu PgBadger

a mˇeˇren´ı bylo uskuteˇcniteln´e d´ıky tomu, ˇze v dobˇe psan´ı bakal´aˇrsk´e pr´ace jiˇz syst´em bˇeˇzel v pilotn´ım reˇzimu.

Dle poˇzadavk˚u datab´aze mus´ı zajiˇst’ovat:

1. kontrolu, zda pˇripojuj´ıc´ı se uˇzivatel nen´ı blokov´an 2. vkl´ad´an´ı dat z´ıskan´ych z ´uˇctov´an´ı

3. vkl´ad´an´ı dat z´ıskan´ych z tabulek soused˚u 4. vyhled´av´an´ı dat administr´atorem

Kv˚uli rozd´ılnosti z´ısk´avan´ych dat jsou vytvoˇreny 3 datab´aze, kter´e jsou pouˇz´ıv´any nez´avisle na sobˇe. Pˇri n´avrhu datab´aze bylo tˇreba zajistit, aby v tabulk´ach nebylo velk´e mnoˇzstv´ı dat. Pokud bychom nechali vˇsechna data v jedn´e tabulce, tak bychom ˇcasem za-znamenali obrovskou ztr´atu v´ykonu na datab´azov´em serveru. Trv´an´ı jednotliv´ych operac´ı by se rostouc´ım poˇctem dat postupnˇe prodluˇzovalo z milisekund aˇz na des´ıtky sekund. Jako ˇreˇsen´ı tohoto probl´emu jsem zvolil tzv. partitioning tabulek, coˇz znamen´a, ˇze se tabulka rozdˇel´ı na v´ıce menˇs´ıch tabulek podle urˇcit´eho pravidla. V naˇsem pˇr´ıpadˇe je pro kaˇzd´y den vytvoˇrena nov´a tabulka. Podm´ınka pro existenci z´aznamu v t´ehle tabulce je, ˇze se datum poˇr´ızen´ı z´aznamu mus´ı shodovat s datem, pro kter´e je tabulka urˇcena. Toto rozdˇelen´ı je v´yhodn´e zejm´ena kv˚uli tomu, ˇze pˇri vyhled´av´an´ı dat administr´atorem, kdy je na server odesl´an pˇr´ıkazSELECT, nebudou prohled´av´any vˇsechny tabulky, ale jen ty, kde se z´aznamy opravdu mohou nach´azet. Protoˇze se z´aznamy neuchov´avaj´ı navˇzdy, ale po urˇcit´e dobˇe se maˇzou, tak je moˇzn´e mazat rovnou cel´e tabulky. V opaˇcn´em pˇr´ıpadˇe by se musel kontrolovat z´aznam po z´aznamu, coˇz by mˇelo za n´asledek dalˇs´ı ztr´atu v´ykonu. Konkr´etn´ı proveden´ı jednotliv´ych datab´az´ı je pops´ano v podkapitol´ach 3.3, 3.3 a 3.3.

´

Uˇ

ctov´

an´ı

Datab´aze urˇcen´a pro ´uˇctov´an´ı obsahuje jednu tabulku urˇcenou pro neukonˇcen´e ´uˇctov´an´ı (denn´ı tabulka) a druhou pro archivaci. Nad denn´ı tabulkou se nejˇcastˇeji prov´adˇej´ı pˇr´ıkazy INSERT pro vkl´ad´an´ı z´ıskan´ych dat a pˇr´ıkazy SELECT, kdy se pomoc´ı

Accounting-Update paket˚u kontroluje, zda pˇri zaˇc´atku ´uˇctov´an´ı v atributech nechybˇela pˇriˇrazen´a IPv4 adresa. Protoˇze pˇri kontrole zn´ame identifik´ator sezen´ı (AcctSessionId), m˚uˇzeme z´aznam hledat podle tohoto identifik´atoru, kter´y je jako jedin´y v denn´ı tabulce indexov´an. Kv˚uli zajiˇstˇen´ı co nejmenˇs´ıho poˇctu ˇr´adk˚u v denn´ı tabulce se jiˇz ukonˇcen´e relace v noci pˇresouvaj´ı do historick´e tabulky. Protoˇze ne vˇsechny relace jsou v dobˇe agregace ukonˇcen´e, mus´ı se denn´ı tabulka kontrolovat ˇr´adek po ˇr´adku. Kontroluje se zejm´ena to, zda ˇr´adek obsahuje nenulov´e hodnoty pro sloupce AcctStartTime a Acct-StopTime. Takov´y z´aznam skript vloˇz´ı do historick´e tabulky a z denn´ı ho smaˇze. Agre-gaci zajiˇst’uje skript napsan´y v programovac´ım jazyce Perl. Protoˇze je po celou dobu vyuˇz´ıv´ano pˇredpˇripraven´ych dotaz˚u, je pro agregaci nˇekolika tis´ıc z´azn´am˚u pouˇz´ıv´ano jen dvou dotaz˚u, coˇz zajist´ı vˇetˇs´ı rychlost agregace.

Tabulka 3.1: Tabulka pro data z ´uˇctov´an´ı

n´azev datov´y typ index index - arch´ıv popis radacctid bigserial ano ano id v r´amci tabulky

AcctSessionId text ano ano id relace

UserName text ne ano login uˇzivatele

FramedIPAddress inet ne ano IPv4 adresa

CallingStationId macaddr ne ano MAC adresa zaˇr´ızen´ı AcctStartTime timestamp with timezone ne ano zaˇc´atek relace

AcctStopTime timestamp with timezone ne ano konec relace

externalip inet ne ano extern´ı IPv4/IPv6 adresa (VPN pˇripojen´ı) ipv6pref cidr ne ne prefix IPv6 adresy pˇridˇelen´e VPN koncetr´atorem

ipv6id text ne ne suffix IPv6 adresy pˇridˇelen´e VPN koncetr´atorem framedipv6 inet ne ano IPv6 adresa pˇridˇelen´a VPN koncetr´atorem calledstationid text ne ne identifik´ator pˇr´ıstupov´eho serveru

nasidentifier text ne ne identifik´ator pˇr´ıstupov´eho serveru

IPv6 adresy

V souˇctu se v tabulk´ach soused˚u bˇeˇznˇe nach´az´ı nˇekolik tis´ıc p´ar˚u MAC a IPv6 adres. Protoˇze z´ısk´av´an´ı informac´ı o IPv6 adres´ach vyskytuj´ıc´ıch se na s´ıti prob´ıh´a v pra-videln´ych intervalech stahov´an´ım cel´ych tabulek soused˚u, bude tento proces hlavn´ım d˚uvodem ˇspiˇcek na datab´azov´em serveru. Tabulka, do kter´e tato data pˇrich´azej´ı, proto mus´ı b´yt co nejv´ıce efektivn´ı. Z tohoto d˚uvodu byla vytvoˇrena tabulka urˇcen´a pouze ke sbˇeru dat. Protoˇze jsme se chtˇeli vyhnout tomu, aby se v tabulce u jednotliv´ych p´ar˚u aktualizoval ˇcas, kdy byly v s´ıti spatˇreny, tak se nad touto tabulkou pˇri sbˇeru informac´ı spouˇst´ı pouze pˇr´ıkaz INSERT. Indexace nad tabulkou neprob´ıh´a, coˇz pˇr´ıkaz INSERT

Jako dalˇs´ı optimalizaˇcn´ı metodu jsem zvolil uˇzit´ı tzv. pˇredpˇripraven´ych dotaz˚u (z an-glick´eho prepared statements), kter´e zajist´ı lepˇs´ı spolupr´aci mezi skriptem vkl´adaj´ıc´ım data a datab´az´ı. Pˇri pouˇzit´ı pˇredpˇripraven´eho dotazu se na datab´azov´y server dotaz poˇsle pouze jednou a pot´e se odes´ılaj´ı pouze data, kter´a si server do dotazu dosazuje. Server tak nemus´ı neust´ale dokolaparsovat a pˇripravovat jeden a ten sam´y dotaz (ˇZ ´AK, K. 2004).

Tabulka 3.2: Neagregovan´a tabulka p´ar˚u MAC a IPv6 adres n´azev datov´y typ index popis

sweep time time ne ˇcas sbˇeru informac´ı

ipv6 inet ne IPv6 adresa

mac macaddr ne MAC adresa

date date ne datum sbˇeru informac´ı

Protoˇze by vyhled´av´an´ı nad tabulkou bylo neefektivn´ı, tak se veˇcer, kdy je minim´aln´ı provoz, tabulka agreguje. M˚uˇzeme ji proto nazvat jako denn´ı. Agregaci zajiˇst’uje agregaˇcn´ı skript napsan´y v jazyce Perl. Agregaˇcn´ı skript nalezne ˇcas, kdy byl p´ar MAC-IPv6 vidˇen poprv´e a naposled. Tento ˇr´adek vloˇz´ı do tabulky slouˇz´ıc´ı k archivaci z´aznam˚u. Tato tabulka je indexov´ana a rozdˇelena (partitioning podle data) pro zajiˇstˇen´ı rych-losti vyhled´av´an´ı. Agregaˇcn´ı skript tˇesnˇe pˇred ukonˇcen´ım smaˇze denn´ı tabulku pomoc´ı pˇr´ıkazu TRUNCATE a z archivu smaˇze star´e tabulky. Jelikoˇz pˇri bezpeˇcnostn´ıch inci-dentech dotazy na dohled´an´ı uˇzivatele pˇrich´az´ı vˇetˇsinou aˇz po nˇekolika dnech, tak nee-fektivnost vyhled´av´an´ı nad denn´ı tabulkou nepˇredstavuje probl´em. Tak´e se domn´ıv´am, ˇze by toto ˇreˇsen´ı nemˇelo m´ıt v budoucnu v´ykonnostn´ı probl´emy, kdyˇz vezmu v potaz pravdˇepodobnost, ˇze IPv6 provoz bude nar˚ustat a ne klesat.

Tabulka 3.3: Agregovan´a tabulka pro p´ary MAC-IPv6 n´azev datov´y typ index popis

id bigserial ano id v r´amci tabulky

ipv6 inet ano IPv6 adresa

mac macaddr ano MAC adresa

first seen time ne prvn´ı v´yskyt p´aru IPv6/MAC last seen time ne posledn´ı v´yskyt p´aru IPv6/MAC

date date ne datum poˇr´ızen´ı z´aznamu

Blokace

Logika blokace byla jiˇz pˇribliˇznˇe pops´ana v kapitole 3.1. Pˇri prvn´ı implementaci funkci-onality pro blokov´an´ı uˇzivatel˚u na s´ıti byla vytvoˇrena jednoduch´a tabulka se sloupci pro

MAC adresu a pro login uˇzivatele. Pro lepˇs´ı orientaci v datech byly pˇrid´any jeˇstˇe dalˇs´ı sloupce, kter´e se na funkci nepod´ılej´ı, ale administr´ator˚um poskytuj´ı dodateˇcn´e infor-mace, jako je ˇcas blokace, kdo j´ı provedl a d˚uvod blokace. Po proveden´ı prvn´ıch blokac´ı jsem byl nucen jejich logiku dodateˇcnˇe upravit z d˚uvodu, ˇze nˇekteˇr´ı uˇzivatel´e blokace obch´azeli t´ım, ˇze pˇresvˇedˇcili spoluˇz´aky, aby jim dali sv´e pˇrihlaˇsovac´ı ´udaje. Webov´e roz-hran´ı proto pˇri blokaci loginu uˇzivatele projde datab´azi pro ´uˇctov´an´ı a nalezne vˇsechny MAC adresy, pod kter´ymi se kdy uˇzivatel pˇripojil. Tyto MAC adresy jsou pot´e blo-kov´any tak´e a jsou od ostatn´ıch odliˇseny pomoc´ı sloupce owner. D´ıky tomu m˚uˇzou b´yt pˇri odblokaci snadno nalezeny a z tabulky smaz´any. Vedlejˇs´ı efekt tohoto pˇr´ıstupu je, ˇze m˚uˇzou b´yt zablokov´ana i zaˇr´ızen´ı, kter´a blokovan´y uˇzivatel nevlastn´ı. Syst´em na tento pˇr´ıpad administr´atora upozorn´ı a je na nˇem, zda takov´e zaˇr´ızen´ı do blokace zahrne.

Tabulka 3.4: Tabulka pro blokace n´azev datov´y typ index popis

id bigint ano id v r´amci tabulky

username text ne login uˇzivatele

realm text ne realm uˇzivatele

mac macaddr ne MAC adresa zaˇr´ızen´ı uˇzivatele blockedby text ne osoba, kter´a uˇzivatele zablokovala

blocked text ne osoba, kter´a uˇzivatele odblokovala

reason text ne d˚uvod blokace

4 Webov´

e rozhran´ı

Webov´e rozhran´ı slouˇz´ı jako jednoduch´a cesta, jak se samotn´ym syst´emem pracovat. Obsluha se tedy nebude muset pˇripojovat pˇr´ımo k datab´azi a ˇz´adan´a data z´ısk´avat po-moc´ı ruˇcnˇe psan´ych SQL dotaz˚u. V´ysledky vyhled´av´an´ı jsou nav´ıc obohacen´e o reverzn´ı DNS pˇreklady IPv4 adres a v´yrobce s´ıt’ov´ych karet. Obsluha m˚uˇze vyhled´avat ´uˇctovac´ı logy a blokovan´e uˇzivatele. Mezi kategoriemi vyhled´av´an´ı se pˇrep´ın´a pomoc´ı postrann´ıho menu. Webov´e rozhran´ı nav´ıc umoˇzˇnuje kromˇe autentizace i autorizaci uˇzivatele, kter´y v rozhran´ı bude pracovat.

4.1 Vyhled´

av´

an´ı

Vyhled´av´an´ı v logu ´uˇctov´an´ı vyuˇzij´ı pˇredevˇs´ım ˇclenov´e bezpeˇcnostn´ıho t´ymu pˇri do-hled´av´an´ı identity zaˇr´ızen´ı, kter´e figurovalo v bezpeˇcnostn´ım incidentu. V praxi se vˇsak v logu hled´a i kv˚uli provozn´ı podpoˇre uˇzivatel˚u. ˇCasto se totiˇz st´av´a, ˇze uˇzivatel, kter´y se kv˚uli probl´emu obr´at´ı na helpdeskov´e pracoviˇstˇe, neozn´am´ı, ˇze byl jeho probl´em vyˇreˇsen a oper´ator helpdesku nev´ı, jestli m˚uˇze poˇzadavek uzavˇr´ıt. D´ale se d´a pomoc´ı tohoto logu velmi rychle vylouˇcit probl´em s autentizac´ı na s´ıti a lze se zamˇeˇrit na hled´an´ı probl´em˚u jin´ych.

K vyhled´av´an´ı v logu slouˇz´ı jednoduch´y formul´aˇr, kde lze zadat v´ıce vyhled´avac´ıch krit´eri´ı. Nalezeny budou z´aznamy, kter´e obsahuj´ı pr´avˇe vˇsechna zadan´a krit´eria. Pro proveden´ı vyhled´av´an´ı mus´ı b´yt vyplnˇeno alespoˇn jedno krit´erium a vymezen´a ˇcasov´a oblast, ve kter´e se m´a z´aznam pˇribliˇznˇe nach´azet. Kdyby nebyla zadan´a ˇcasov´a ob-last, nemohlo by se vyuˇz´ıt partitioningu tabulek v SQL datab´azi a t´ım by doch´azelo k nadmˇern´e z´atˇeˇzi. Tato podm´ınka je tak´e d˚uleˇzit´a kv˚uli tomu, ˇze prohl´ıˇzeˇce kolabuj´ı, kdyˇz dojde k v´ypisu velk´eho mnoˇzstv´ı z´aznam˚u (ˇr´adovˇe tis´ıc˚u). Pro snadnˇejˇs´ı zad´av´an´ı spr´avn´eho form´atu data do formul´aˇre byly do rozhran´ı implementov´any projekty Mo-mentum aPikaday, d´ıky nimˇz si obsluha datum navol´ı pomoc´ı kalend´aˇre (viz obr. 4.1). Na obr´azku 4.2 m˚uˇzeme vidˇet jak zah´ajit hled´an´ı jednotliv´ych z´aznam˚u, aktu´alnˇe tedy dle uˇzivatelsk´eho jm´ena. V´ysledek tohoto vyhled´av´an´ı m˚uˇzeme vidˇet na obr´azku 4.3.

Obr´azek 4.1: Formul´aˇr pro vyhled´av´an´ı v logu ´uˇctov´an´ı

Obr´azek 4.3: V´ysledky vyhled´av´an´ı v logu ´uˇctov´an´ı Z v´ysledku m˚uˇzeme vyˇc´ıst n´asleduj´ıc´ı informace:

1. UserName

Jm´eno pˇrihl´aˇsen´eho uˇzivatele. Jm´eno je uloˇzeno pˇresnˇe tak, jak ho uˇzivatel zadal, vˇcetnˇe velikosti p´ısmen.

2. NAS

M´ısto, kde se uˇzivatel pˇrihl´asil. Z ˇretˇezce v prvn´ım ˇr´adku napˇr´ıklad vyˇcteme, ˇze se uˇzivatel pˇrihl´asil do s´ıtˇe Eduroam na fakultˇe elektrotechniky a informatiky (FEI), v m´ıstnosti B425 a ˇslo o bezdr´atov´e pˇripojen´ı pˇres Wi-Fi access-point LAP2602. 3. AcctStartTime a AcctStopTime

Zaˇc´atek a konec uˇzivatelsk´e relace. 4. FramedIPAddress

Pˇridˇelen´a IPv4 adresa a jej´ı reverzn´ı DNS z´aznam. 5. mac

MAC adresa s´ıt’ov´e karty pˇripojen´eho zaˇr´ızen´ı a jm´eno v´yrobce s´ıt’ov´e karty. Zde se pravdˇepodobnˇe jedn´a o mobiln´ı telefon.

6. TerminateCause

D˚uvod ukonˇcen´ı relace. Nejˇcastˇejˇs´ı d˚uvody jsou n´asleduj´ıc´ı: Idle-Timeout- Ztr´ata sign´alu.

User-Request- Manu´aln´ı odhl´aˇsen´ı uˇzivatele.

Admin-Reset - Nestandartn´ı chov´an´ı pˇripojen´eho zaˇr´ızen´ı (relace ukonˇcena ak-tivn´ım prvkem).

Reauthentication-Failure- Zaˇr´ızen´ı nereagovalo na ˇz´adost o reautentizaci, nebo uˇzivatel nem´a v zaˇr´ızen´ı uloˇzen´e pˇrihlaˇsovac´ı ´udaje a pˇri reautentizaci je zadal ˇspatnˇe.

Na nalezen´e ´udaje lze tak´e klepnout a t´ım zah´ajit nov´e hled´an´ı. Ve v´ysledc´ıch se m˚uˇze objevit z´aznam z VPN pˇripojen´ı (viz. obr.4.4). V tˇechto v´ysledc´ıch pˇribudou n´asleduj´ıc´ı informace:

1. externalIP

2. framedIPv6

IPv6 adresa pˇridˇelen´a VPN koncetr´atorem. Tuto adresu lze pˇridˇelit d´ıky tomu, ˇze se uˇzivatel pˇripojuje pˇres VPN klienta. VPN klient IPv6 adresu nastav´ı tzv. sta-ticky. Nedoch´az´ı proto k n´ahodn´emu v´ybˇeru adresy na stranˇe uˇzivatelova zaˇr´ızen´ı.

Obr´azek 4.4: V´ysledky vyhled´av´an´ı v logu ´uˇctov´an´ı - VPN pˇripojen´ı

4.2 Blokace

Blokaci uˇzivatele lze prov´est pomoc´ı tlaˇc´ıtka z v´ysledk˚u vyhled´av´an´ı (viz. obr.4.2) nebo pˇres menu klepnut´ım na odkaz Block user/mac (viz. obr.4.5). V pˇr´ıpadˇe, ˇze je blokace provedena z v´ysledk˚u vyhled´av´an´ı, je formul´aˇr pˇredvyplnˇen. Ve formul´aˇri (viz. obr.4.6) pro blokaci se vyplˇnuje blokovan´y uˇzivatel nebo MAC adresa a d˚uvod blokace.

V praxi se do d˚uvodu blokace bˇeˇznˇe vkl´ad´a ˇc´ıslo ticketu z vnitˇrn´ıho ticketovac´ıho syst´emu. V pˇr´ıpadˇe, ˇze je blokov´an uˇzivatel, syst´em nalezne MAC adresy zaˇr´ızen´ı, z kter´ych se uˇzivatel pˇrihl´asil. Tyto adresy uvede v informaˇcn´ı tabulce (viz. obr.4.7) a upozorn´ı na zaˇr´ızen´ı, z kter´ych se pˇrihlaˇsovalo v´ıce uˇzivatel˚u. Pokud administr´ator na takov´eto upozornˇen´ı naraz´ı, provede kontrolu (napˇr´ıklad dle poˇctu pˇrihl´aˇsen´ı), zda se opravdu jedn´a o zaˇr´ızen´ı blokovan´eho uˇzivatele a nedoˇslo tak k blokaci nˇekoho jin´eho.

Obr´azek 4.5: Menu uˇzivatelsk´eho prostˇred´ı

Na obr´azku 4.6 m˚uˇzeme vidˇet tak´e seznam blokovan´ych uˇzivatel˚u. K blokaci se au-tomaticky pˇrid´av´a informace o tom, kdy byla blokace provedena, a osobn´ı ˇc´ıslo admi-nistr´atora, kter´y blokaci provedl. Z tohoto seznamu lze blokace zruˇsit pomoc´ı tlaˇc´ıtka

unblock. Tak´e lze pomoc´ı tlaˇc´ıtka devices odblokovat jednotliv´a zaˇr´ızen´ı. To se pouˇzije, pokud se i pˇres kontrolu pˇri blokaci zablokovalo zaˇr´ızen´ı jin´eho uˇzivatele.

Obr´azek 4.6: Formul´aˇr pro blokaci uˇzivatele

5 Popis vytvoˇ

ren´

ych programov´

ych

prostˇ

redk˚

u

V t´eto kapitole jsou pops´any jednotliv´e souˇc´asti informaˇcn´ıho syst´emu a vazby mezi nimi. Kapitola je ˇclenˇena na podkapitoly dle hlavn´ıho ´uˇcelu jednotliv´ych ˇc´ast´ı syst´emu.

5.1 Skripty pro sbˇ

er informac´ı a jejich agregaci

ipv6monitor.pl

Pˇripojuje se pomoc´ı SNMPv2c protokolu na routery definovan´e v poli ip list. Pˇres tzv. bulk-request stahuje p´ary IPv6 adresa - MAC adresa a ty vkl´ad´a do datab´aze (ta-bulkaipv6 daily). Skript ignorujelink-local adresy - tj. adresy patˇr´ıc´ı do s´ıtˇe FE80::/10. Skript je um´ıstˇen na datab´azov´em serveru a je pravidelnˇe kaˇzd´ych 5 minut spouˇstˇen pomoc´ı pl´anovaˇce ´uloh Cron.

sqlradacct.pl

Je spouˇstˇen RADIUS serverem RADIATOR pˇri kaˇzd´em pˇrijet´ı ´uˇctovac´ıho paketu. Skript si od RADIUS serveru pˇrevezme vybran´e atributy pˇrijat´eho ´uˇctovac´ıho paketu a ty pˇres m´ıstn´ı smyˇcku pomoc´ı UDP protokolu odeˇsle na proxy server acctProxy.pl, odkud jsou atributy vloˇzeny do datab´aze.

ipv6agregator.pl

Slouˇz´ı pro agregaci dat z tabulkyipv6 daily. Nalezne prvn´ı a posledn´ı v´yskyt p´aru IPv6 adresa - MAC adresa a ten vloˇz´ı do tabulky ipv6 master. Po ´uspˇeˇsn´e agregaci smaˇze neagregovanou tabulku a agregovanou tabulku starˇs´ı neˇz tˇri mˇes´ıce.

Skript je um´ıstˇen na datab´azov´em serveru a je pravidelnˇe spouˇstˇen o p˚ulnoci pomoc´ı pl´anovaˇce ´uloh Cron.

acctAgregator.pl

Slouˇz´ı pro agregaci dat z tabulkyradacct. Nalezne vˇsechny ukonˇcen´e relace a ty pˇresune do tabulky accounting. Odhaluje relace, kter´e nebyly korektnˇe ukonˇceny (na RADIUS server nepˇriˇsel paket Accounting-Stop). Nakonec smaˇze agregovanou tabulku, kter´a je starˇs´ı neˇz tˇri mˇes´ıce.

Skript je um´ıstˇen na datab´azov´em serveru a je pravidelnˇe spouˇstˇen o p˚ulnoci pomoc´ı pl´anovaˇce ´uloh Cron.

acctProxy.pl

acctProxy.pl je jednoduch´y proxy server. Naslouch´a na voliteln´em UDP portu, kde mu skript sqlradacct.pl zas´ıl´a data, kter´a maj´ı b´yt vloˇzena do datab´aze.

Proxy server zahazuje data, kter´a nebyla posl´ana pˇres m´ıstn´ı smyˇcku nebo ne´upln´a data. Server si udrˇzuje trval´e ˇsifrovan´e spojen´ı na datab´azov´y server. SQL dotazy jsou kv˚uli vyˇsˇs´ımu v´ykonu pˇredpˇripraven´e.

V pˇr´ıpadˇe ztr´aty spojen´ı na datab´azov´y server se spojen´ı pokouˇs´ı obnovit a pˇrijat´a data si ukl´ad´a v mezipamˇeti. Pˇri obnovˇe spojen´ı data z mezipamˇeti vkl´ad´a v pomˇeru 1:10 s novˇe pˇrijat´ymi daty. Pokud by dat v mezipamˇeti bylo mnoho a jejich vloˇzen´ı by trvalo dlouho, mohlo by doj´ıt k pˇreteˇcen´ı vyrovn´avac´ı pamˇeti.

Server bˇeˇz´ı jako d´emon na pozad´ı a je spouˇstˇen automaticky pˇri startu operaˇcn´ıho syst´emu. Je moˇzn´e ho ovl´adat pomoc´ı init skriptu accounting.

blacklistGenerator.pl

Skript z´ısk´a seznam blokovan´ych uˇzivatel˚u z datab´aze a vytvoˇr´ı soubor naform´atovan´y pro pouˇzit´ı se serverem Radiator. V pˇr´ıpadˇe, ˇze je datab´azov´y server nedostupn´y, po-nech´a p˚uvodn´ı soubor nedotˇcen.

Skript je um´ıstˇen na RADIUS serveru a je kaˇzdou minutu spouˇstˇen pomoc´ı pl´anovaˇce ´

uloh Cron.

5.2 Skripty pro monitoring

Skripty pro monitoring byly navrˇzeny jako moduly pro informaˇcn´ı syst´em Nagios. Ten umoˇzˇnuje automatizovanou kontrolu jednotliv´ych sluˇzeb a v pˇr´ıpadˇe probl´emu upozorn´ı

syst´emov´e administr´atory. Moduly signalizuj´ı stav sluˇzby pomoc´ı n´avratov´ych k´od˚u. V´yznamy jednotliv´ych k´od˚u jsou n´asleduj´ıc´ı:

• K´od 0 - v poˇr´adku • K´od 1 - upozornˇen´ı • K´od 2 - kritick´a chyba

Proto budu v popisu modul˚u uv´adˇet, kter´e kontroly prov´ad´ı a jak´y n´avratov´y k´od vr´at´ı, pokud modul odhal´ı probl´em.

check acccounting

Je modul urˇcen´y ke kontrole proxy serveruacctProxy.pl. Modul je spouˇstˇen na RADIUS serveru. Kontroluje zda:

1. Bˇeˇz´ı d´emon (k´od 2).

2. Se lze pˇripojit k datab´azov´emu serveru (k´od 1).

3. Zda se testovac´ı data odesl´ana modulem na proxy server uloˇz´ı do datab´aze (k´od 2). check postgresql

Je modul urˇcen´y ke kontrole datab´azov´eho serveru, kde je tak´e spouˇstˇen. Modul kont-roluje zda:

1. Se lze pˇripojit k datab´azov´emu serveru (k´od 2). 2. Se v denn´ıch tabulk´ach nach´az´ı nov´a data (k´od 1). 3. Se provedla agregace (k´od 1).

5.3 Webov´

y server

Tabulka 5.1: Seznam PHP skript˚u

n´azev popis

block.php Str´anka slouˇz´ıc´ı k blokov´an´ı uˇzivatel˚u. credentials.php Obsahuje funkce pro pˇripojen´ı se k datab´azi.

devices.php Str´anka pro zobrazen´ı blokovan´ych zaˇr´ızen´ı uˇzivatele. functions.php Funkce, kter´e volaj´ı jednotliv´e str´anky.

index.php Str´anka slouˇz´ıc´ı k vyhled´av´an´ı log˚u.

unblock.php Zajiˇst’uje odblokov´an´ı uˇzivatel˚u a hled´an´ı v historii blokac´ı. vendor.php Zjiˇst’uje v´yrobce s´ıt’ov´e karty podle MAC adresy pˇres extern´ı API.

Tabulka 5.2: Seznam javascript skript˚u

n´azev popis

showHide.js Minimalizuje/maximalizuje jednotliv´e tabulky s v´ysledky vyhled´av´an´ı. vendor.js Zobraz´ı v´yrobce s´ıt’ov´e karty pˇri najet´ı myˇsi nad MAC adresu.

Tabulka 5.3: Pouˇzit´e knihovny tˇret´ıch stran

n´azev popis

CAS Umoˇzˇnuje pˇrihl´aˇsen´ı uˇzivatele pˇres ˇskoln´ı syst´em jednotn´eho pˇrihlaˇsov´an´ı. pikaday.js Pouˇzito pro implementaci kalend´aˇre.

moment.js Pouˇzito pro implementaci kalend´aˇre.

5.4 Datab´

azov´

y server

Seznam datab´az´ı

Tabulka 5.4: Seznam datab´az´ı

n´azev tabulky obsah

radiusdb radacct, accounting Data z ´uˇctov´an´ı. ipv6db ipv6 daily, ipv6 master Data z tabulek soused˚u. blacklist blacklist, blacklistarchive Seznam blokovan´ych uˇzivatel˚u.

´ Uˇcty

Tabulka 5.5: Tabulka ´uˇct˚u pro pˇr´ıstup k datab´azov´emu serveru ´

uˇcet opr´avnˇen´ı

radius Pˇr´ıkazy INSERT, UPDATE nad tabulkami v datab´azi radiusdb. blacklist Vˇsechny pˇr´ıkazy nad tabulkami v datab´azi blacklist.

Pˇr´ıkaz SELECT nad vˇsemi tabulkami v datab´azi radiusdb. ipv6usr Pˇr´ıkaz INSERT nad tabulkou ipv6 daily.

web Pˇr´ıkaz SELECT nad vˇsemi tabulkami ve vˇsech datab´az´ıch. agregator Vˇsechny pˇr´ıkazy nad vˇsemi tabulkami

Partitioning tabulek

O partitioning tabulek se staraj´ı procedury napsan´e v PL/SQL. Tyto funkce jsou spouˇstˇeny pomoc´ı spouˇstˇeˇc˚u (z anglick´ehotrigger). Kromˇe procedur urˇcen´ych k partitioningu tabu-lek uv´ad´ım i proceduru slouˇz´ıc´ı k uloˇzen´ı IPv6 adresy pˇridˇelen´e VPN koncentr´atorem, kter´a ze serveru FreeRadius pˇrich´az´ı rozdˇelen´a do dvou sloupc˚u (jako prefix a suffix IPv6 adresy). Adresa pak m˚uˇze b´yt uloˇzena jako datov´y typ inet (datov´y typ urˇcen´y pro IPv4/IPv6 adresy).

Tabulka 5.6: Seznam procedur a spouˇstˇeˇc˚u procedura spouˇstˇeˇc ´uˇcel

ipv6 partition function ipv6 trigger Partitioning tabulky ipv6 master. acc partition function acc trigger Partitioning tabulky accounting.

6 Z´

avˇ

er

C´ılem pr´ace bylo vyvinout informaˇcn´ı syst´em, kter´y umoˇzn´ı anal´yzu pˇr´ıstup˚u do s´ıtˇe VˇSB-TU a blokaci vybran´ych uˇzivatel˚u. Bylo tˇreba identifikovat zdroje poˇzadovan´ych in-formac´ı, jejich z´ısk´an´ı a ukl´ad´an´ı. Tento syst´em pak byl implementov´an do produkˇcn´ıho prostˇred´ı univerzity.

V ´uvodn´ı kapitole jsem popsal nejd˚uleˇzitˇejˇs´ı aspekty ohlednˇe RADIUS protokolu, kter´e jsou kl´ıˇcov´e pro v´yvoj a implementaci poˇzadovan´ych funkcionalit. D´ale jsem pˇribliˇznˇe popsal vazby mezi jednotliv´ymi s´ıt’ov´ymi prvky, kter´e se na autentizaci uˇzivatel˚u pod´ıl´ı a struˇcnˇe popsal jejich princip. Nakonec jsem, v n´avaznosti na identifikaci jednotliv´ych zaˇr´ızen´ı, popsal z´asadn´ı rozd´ıl mezi protokolem IPv4 a protokolem IPv6.

Po teoretick´em ´uvodu jsem v n´asleduj´ıc´ı kapitole zanalyzoval rozˇsiˇritelnost nasazen´ych softwarov´ych prostˇredk˚u umoˇzˇnuj´ıc´ı autentizaci uˇzivatel˚u. Po zhodnocen´ı jejich moˇznost´ı jsem programy pˇrekonfiguroval, abych upravil jejich chov´an´ı. Kv˚uli funkˇcnosti t´eto kon-figurace jsem pro program RADIATOR vyvinul programov´y modul, kter´y z nˇej pˇrepos´ıl´a poˇzadovan´e informace.

Ke spr´avn´e funkci modul˚u bylo tˇreba tak´e navrhnout datab´azi s ohledem na co nejvyˇsˇs´ı rychlost zpracov´an´ı dotaz˚u. K zajiˇstˇen´ı t´eto vlastnosti jsem vytvoˇril agregaˇcn´ı skripty pro oddˇelen´ı aktu´aln´ıch a historick´ych dat. Pro zajiˇstˇen´ı vˇetˇs´ı rychlosti vyhled´av´an´ı his-torick´ych dat byla pouˇzita technika zvan´a partitioning. Pro rychlejˇs´ı vkl´ad´an´ı dat do datab´aze jsem se snaˇzil co nejv´ıce vyuˇz´ıvat pˇredpˇripraven´ych dotaz˚u. Uveden´e optima-lizaˇcn´ı metody jsem v kapitole tak´e teoreticky popsal.

Kv˚uli absenci informac´ı o IPv6 adres´ach jsem naprogramoval skripty, kter´e pravidelnˇe stahuj´ı tabulky soused˚u ze smˇerovaˇc˚u. Nakonec jsem popsal princip blokac´ı jednotliv´ych uˇzivatel˚u. Implementace tˇechto n´astroj˚u tak´e zahrnovala ´uplnou konfiguraci novˇe nain-stalovan´eho SQL serveru a webov´eho serveru.

V pˇredposledn´ı kapitole jsem popsal mnou vyvinut´e webov´e rozhran´ı, kter´e pˇrehlednˇe zobrazuje uloˇzen´e ´udaje a umoˇzˇnuje velice snadn´ym zp˚usobem uˇzivatele zablokovat. Webov´e rozhran´ı tak´e umoˇzˇnuje autentizaci a autorizaci povˇeˇren´ych pracovn´ık˚u.

V posledn´ı kapitole jsem zdokumentoval vˇsechny pouˇzit´e programov´e prostˇredky vˇcetnˇe vazeb mezi nimi. Do popisu jsem zahrnul vysvˇetlen´ı ´uˇcelu jednotliv´ych skript˚u a da-tab´azov´ych procedur. D´ale je zde seznam uˇzivatel˚u, kteˇr´ı sm´ı do datab´aze pˇristupovat, a jejich opr´avnˇen´ı. V kapitole jsou tak´e pops´any skripty urˇcen´e pro monitoring jednot-liv´ych sluˇzeb.

Syst´em bych chtˇel nad´ale rozvinout t´ım, ˇze bych rozˇs´ıˇril funkˇcnost webov´eho rozhran´ı o automatick´e odes´ıl´an´ı e-mail˚u zablokovan´ym uˇzivatel˚um. Administr´atoˇri by je tak ne-museli pˇri kaˇzd´em incidentu ps´at sami, ˇc´ımˇz by jejich pr´ace byla jeˇstˇe v´ıce zefektivnˇena. D´ale bych chtˇel zobecnit zdrojov´y k´od, aby mohl b´yt syst´em hladce nasazen i v jin´ych s´ıt´ıch.

Vˇsechny uveden´e n´astroje jiˇz byly otestov´any a implementov´any do st´avaj´ıc´ı s´ıtˇe. N´astroje jsou ´uspˇeˇsnˇe a rutinnˇe pouˇz´ıv´any v provozu pˇri ˇreˇsen´ı bezpeˇcnostn´ıch probl´em˚u i pˇri technick´e podpoˇre uˇzivatel˚u.

7 Literatura

DHCP 2016. Netacad.com [online]. [cit. 2016-11-27]. Dostupn´e z:

https://static-course-assets.s3.amazonaws.com/RSE503/en/index.html#10.0.1.1. Fungov´an´ı roamingu 2016. Eduoram.cz [online]. 2012 [cit. 2016-11-27].

Dostupn´e z: https://www.eduroam.cz/cs/uzivatel/fungovani roamingu.

GNU Radius Reference Manual 2008 [online]. Free Software Foundation, 2008 [cit. 2016-11-27]. Dostupn´e z: https://www.gnu.org/software/radius/manual/radius.pdf

Guide/SQL HOWTO 2016. The FreeRADIUS Server Project and Contributors [online]. 2016 [cit. 2017-01-11].

Dostupn´e z: https://wiki.freeradius.org/guide/SQL-HOWTO

HASSELL, J. 2002.RADIUS. 1005 Gravenstein Highway North, Sebastopol, CA 95472: O’Reilly Media, 2002. ISBN 0-596-00322-6.

KR ˇCM ´A ˇR P.,CALETKA O. 2016. Roamingov´a s´ıt’ eduroam: pˇripojen´ı po cel´em svˇetˇe [online]. 2016 [cit. 2016-11-27]. Dostupn´e z:

https://www.root.cz/clanky/roamingova-sit-eduroam-pripojeni-po-celem-svete/

RadiatorR RADIUS Server 2015 [online]. Open System Consultants Pty., 2015 [cit.

2016-12-30].

Dostupn´e z: https://www.open.com.au/radiator/ref.pdf

Remote Authentication Dial In User Service (RADIUS) 2000. The Internet Enginee-ring Task Force [online]. 2000 [cit. 2016-11-27].

Dostupn´e z: https://tools.ietf.org/html/rfc2865.

SATRAPA, P. c2000. Perl pro zelen´aˇce: [nauˇcte se programovat v Perlu]. 1. Praha: Neokortex. Bestseller for all. ISBN 80-863-3002-8.

SATRAPA, P. 2011.IPv6: internetov´y protokol verze 6. 3., aktualiz. a dopl. vyd. Praha: CZ.NIC, c2011. CZ.NIC. ISBN 9788090424845.

Server Definition 2014. TechTerms [online]. 2014 [cit. 2016-11-27]. Dostupn´e z: http://techterms.com/definition/server

ˇ

Z ´AK, K. 2004. PostgreSQL: pˇripraven´e dotazy a oddˇelen´ı dat od dotaz˚u. Root.cz [online]. 2004 [cit. 2016-12-30]. Dostupn´e z: https://www.root.cz/clanky/postgresql-pripravene-dotazy-a-oddeleni-dat-od-dotazu/