Szakdolgozat
Bogár András
Debrecen 2015
Debreceni Egyetem Informatikai Kar Informatikai Rendszerek és Hálózatok Tanszék
Az NI Hungary Kft. hálózatának elemzése, tesztelése, és továbbfejlesztésének tervezése
Témavezető:
Külső konzulens:
Készítette:
Almási Béla
Varga Ferenc
Bogár András
Egyetemi docens
Hálózati adminisztrátor
Mérnökinformatikus BSc
Debrecen 2015
2
Plágium - Nyilatkozat Szakdolgozat készítésére vonatkozó szabályok betartásáról nyilatkozat
Alulírott ………………….…………………… (Neptunkód: ………………) jelen nyilatkozat aláírásával kijelentem, hogy a …………………………………………………………………………………………………... című szakdolgozat/diplomamunka (a továbbiakban: dolgozat) önálló munkám, a dolgozat készítése során betartottam a szerzői jogról szóló 1999. évi LXXVI. tv. szabályait, valamint az egyetem által előírt, a dolgozat készítésére vonatkozó szabályokat, különösen a hivatkozások és idézések tekintetében. Kijelentem továbbá, hogy a dolgozat készítése során az önálló munka kitétel tekintetében a konzulenst, illetve a feladatot kiadó oktatót nem tévesztettem meg. Kijelentem, hogy az elektronikusan feltöltött és a papír alapú dokumentum mindenben megegyezik. (TVSZ 24.§ (8). alapján) Jelen nyilatkozat aláírásával tudomásul veszem, hogy amennyiben bizonyítható, hogy a dolgozatot nem magam készítettem vagy a dolgozattal kapcsolatban szerzői jogsértés ténye merül fel, a Debreceni Egyetem megtagadja a dolgozat befogadását és ellenem fegyelmi eljárást indíthat. A dolgozat befogadásának megtagadása és a fegyelmi eljárás indítása nem érinti a szerzői jogsértés miatti egyéb (polgári jogi, szabálysértési jogi, büntetőjogi) jogkövetkezményeket.
………………….…………………… hallgató Debrecen, ………………….………
3
Tartalomjegyzék 1. Bevezetés............................................................................................................................................. 6 1.1. A szakdolgozat célja, áttekintése ................................................................................................. 6 1.2. Az NI Hungary Kft.-ről röviden ................................................................................................... 7 2. A hálózat elemzése .............................................................................................................................. 8 2.1. Vezetékes hálózat felépítése......................................................................................................... 8 2.1.1. Fizikai kábelezés bemutatása ................................................................................................ 8 2.1.2. A Háromrétegű Hálózati Modellről ...................................................................................... 9 2.1.3. Az Access Layer.................................................................................................................. 10 2.1.4. A Distribution Layer ........................................................................................................... 12 2.1.5. A Core Layer ....................................................................................................................... 14 2.2. A hálózat kapcsolatai ................................................................................................................. 17 2.2.1. Az internetvonal .................................................................................................................. 17 2.2.2. VPN kapcsolódási lehetőség kollégáink, partnereink számára ........................................... 17 2.2.3. DMVPN: WAN kapcsolat publikus Interneten keresztül ................................................... 18 2.2.4. A WAN kapcsolatok ........................................................................................................... 19 2.3. VoIP Telefónia bemutatása Debrecenben .................................................................................. 22 2.3.1. Quality of Service az NI-nál................................................................................................ 22 2.3.2. A VoIP telefonhálózat bemutatása ...................................................................................... 23 2.3.2. Skype for Business kliens, a mobilis softphone szoftver .................................................... 25 2.4. Vezeték nélküli hálózat ismertetése ........................................................................................... 27 2.4.1. Az IEEE 802.11 protokoll család ........................................................................................ 27 2.4.2. LWAP protokoll és hierarchia bemutatása .......................................................................... 28 2.4.4. Az NI, INET, SCAN, és NI-DSL SSID .............................................................................. 29 2.4.3. A RADIUS protokoll ismertetése........................................................................................ 30 2.5. Hálózatunkban működő fontosabb protokollok, technológiák................................................... 31 2.5.1. IEEE 802.1Q: Trunking, VLAN hálózatok ......................................................................... 31 2.5.2. LACP link aggregációs protokoll ........................................................................................ 32 2.5.3. Access Control List / Filter List .......................................................................................... 33 2.5.4. Az OSPF forgalomirányító protokoll .................................................................................. 35 2.5.5. SSH és HTTPS protokoll alapú hozzáférés eszközeinkhez ................................................ 36 2.6. Hálózati eszközeink biztonságos menedzsmentje ...................................................................... 37 2.6.1. Biztonságos menedzsment garantálása ............................................................................... 37 2.6.2. A TACACS+ rendszer bemutatása...................................................................................... 38
4
2.6.3. A hálózat monitorozása syslog segítségével ....................................................................... 39 2.6.4. Az SNMP protokoll használata a hálózatban ...................................................................... 41 2.6.5. A SolarWinds Orion platform ............................................................................................. 42 3. A hálózat tesztelése ........................................................................................................................... 44 3.1. A tesztelések és mérések célja, áttekintése ................................................................................ 44 3.2. A mérésekhez, tesztelésekhez használt eszközök ...................................................................... 45 3.2.1. Fluke Networks AirMagnet Spectrum XT adapter ............................................................. 45 3.2.2. SolarWinds Orion NTA NetFlow modul ............................................................................ 46 3.2.3. Dell AirWave Wireless Monitoring eszköz ........................................................................ 48 3.2.4. Biztonsági tesztelésekhez, mérésekhez hálózati eszközök .................................................. 48 3.3. Általános hálózati mérések......................................................................................................... 51 3.3.1. A hálózati eszközök fizikai védelmének vizsgálata ............................................................ 51 3.3.2. Belső vezetékes hálózat sávszélességének felmérése.......................................................... 51 3.3.3. A WLAN hálózat tesztelése ................................................................................................ 52 3.4. Az internet és WAN vonalak vizsgálata..................................................................................... 55 3.4.1. Az internetvonal tesztelése .................................................................................................. 55 3.4.2. A WAN kapcsolatokon végzett mérések............................................................................. 56 3.5. Biztonsági tesztelések ................................................................................................................ 59 3.5.1. MAC elárasztásos és DHCP kiéheztetéses támadás szimulálása ........................................ 59 3.5.2. Hamis DHCP szerver felállítása .......................................................................................... 61 3.5.3. Rogue AP-k elleni védelem................................................................................................. 64 3.5.4. Port letapogatás hálózati eszközeinken ............................................................................... 66 4. Továbbfejlesztési javaslatok ............................................................................................................. 69 4.1. Aggregált linkek kialakítása az Access és Distribution rétegek között ...................................... 69 4.2. Operációs rendszer frissítése a támogatott eszközökön ............................................................. 69 4.3. Másodlagos internetvonal bérlése, HSRP engedélyezése .......................................................... 70 4.4. QoS profilok verzióinak az egységesítése a globális hálózatban ............................................... 70 5. Összefoglalás..................................................................................................................................... 71 6. Köszönetnyilvánítás .......................................................................................................................... 72 7. Irodalomjegyzék ................................................................................................................................ 73 8. Mellékletek........................................................................................................................................ 80
5
1. Bevezetés 1.1. A szakdolgozat célja, áttekintése Szakdolgozatom témaválasztásánál fontos szempont volt számomra, hogy olyan témát válasszak, ami a jövőbeli érdeklődésemet tükrözi. Az NI Hungary Kft. IT infrastruktúra gyakornokaként, és az Infrastructure Operations Center globális csapatának tagjaként dolgozom több mint egy éve, főként hálózati eszközökön. Gyakornoki pozícióm, és érdeklődési köröm miatt erre a témára esett választásom. A szakdolgozatom célja egy átfogó kép nyújtása az NI Hungary Kft. hálózatáról. Elemezni fogom, általános méréseket és biztonsági teszteléseket fogok végrehajtani rajta. A szakdolgozat utolsó fejezetében továbbfejlesztési javaslatokat nyújtok. Szakdolgozatomban első részében az NI Hungary Kft. hálózati felépítését fogom bemutatni a Cisco által javasolt Hierarchikus Hálózati Modell alapján. Bemutatom a hálózat vezetékes felépítését; internetvonalát és WAN kapcsolatait; VoIP telefonhálózatot; a vezeték nélküli hálózatot; az eszközökön használt fontosabb technológiákat, protokollokat. Bemutatom, hogyan menedzseljük a hálózati eszközöket biztonságosan. A második részben bemutatom a mérésekhez, tesztelésekhez használt eszközöket, azok véghezviteli módszerét. Általános méréseket fogok végezni a hálózaton; annak kapcsolatain (internet és WAN vonalakon); és biztonsági teszteléseket végzek az eszközökön. A harmadik, és egyben utolsó részben továbbfejlesztési javaslatokat fogok nyújtani, melyek alkalmazásával a hálózat jobbá tehető.
6
1.2. Az NI Hungary Kft.-ről röviden A National Instruments amerikai vállalatot Dr. James Trurchard alapította 1976-ban. Olyan mérőeszközöket
terveztek,
melyek
hatékonyabban,
gyorsabban
gyűjtöttek
mérési
eredményeket az akkoriban használt eszközökhöz képest. Az évek alatt nagy sikereket értek el, egy olyan nemzetközi vállalatot teremtettek, ami remekül megállja a helyét a hardvergyártás, automatizálás, és szoftvertervezés terén, több iparágban. A világon jelenleg 4 nagyobb központtal (Austin, Debrecen, Penang, Costa Rica), 45 irodával, és 7300 foglalkoztatottal rendelkezik világszerte. Tesztelő, automatizáló, beágyazott és monitorozó rendszerek gyártása és fejlesztése folyik. Fontos szempont a vállalat mindennapjaiban a környezetvédelem, hatékonyság, és a rugalmas megoldások keresése innováció által. A hardvereket a vállalat által tervezett LabVIEW szoftver segítségével egyszerűen, rugalmasan lehet konfigurálni. Az NI Hungary Kft. 2000-ben lett alapítva Magyarországon, Debrecenben. Az anyacég jó minőségű munkaerőpiacot keresett, ahol kulcsfontosságú helyen tud gyártelepet alapítani. A befektetés olyan sikeres lett, hogy 15 éve folyamatos fejlesztések folynak a debreceni telephelyen. A debreceni telephely a vállalat termelésének 60%-át adja, itt főként kutatásokat végeznek a gyártási folyamatok mellett, fontos szerepet ellátva a National Instruments vállalat egészének részeként.
7
2. A hálózat elemzése 2.1. Vezetékes hálózat felépítése 2.1.1. Fizikai kábelezés bemutatása Category 6 és 5e típusú UTP (Unshielded Twisted Pair) kábel van használatban a vezetékes eszközök csatlakoztatására. A kábelek az IDF szobákból (Intermediate Distribution Frame, kábelrendező szoba) vannak kivezetve. A Cat 6 és Cat 5e típusú kábelek képesek kiszolgálni a mindennapos igényeken túl a nagyobb igényeket is, köszönhetően az 1 Gbps sebesség támogatásának. A 8.3.1.-es táblázatban összefoglalom a két típusú főbb specifikációját. Kategória Category 5e Category 6
Osztály Class D Class E
Frekvencia 100 MHz 250 MHz
Sebesség 10/100/1000 Mbps 10/100/1000 Mbps
Maximális távolság 100 méter (33 feet) 100 méter (33 feet)
8.3.1. táblázat: Category 5e és 6 típusú kábelek főbb specifikációjának összehasonlítása. A Category 6-os típusnak az az előnye az 5e típushoz képest, hogy magasabb a működési frekvenciája, kisebb az áthallása, és ezek által kisebb az interferenciája is a Cat 5e típusú kábelekhez képest. A kábelek a TIA/EIA-568B standardja szerint vannak bekötve [21]. A hálózatban egyenes kötésű, T568B sémájú kábeleket használunk: a bekötési sémát a 8.3.2.-es táblázaton szemléltetem, a színkódokkal. NF 1
1 NF
N
2
2
N
ZF 3
3 ZF
K
4
4
K
KF 5
5 KF
Z
6
6
Z
BF 7
7 BF
B
8
8
B
8.3.2. táblázat: TIA/EIA-568B bekötési szabvány színkódokkal szemléltetve.
8
Az egyenes kötésű kábel esetén mindkét végződésnél azonos bekötési sémát követ, a TX / RX érpár nincs megfordítva. A keresztkötésű kábel esetén a két oldal különböző bekötési sémát követ, a TX / RX érpárok megfordítása már a kábelen belül megtörténik. Manapság majdnem minden hálózati eszköz támogatja az Auto-MDIX funkciót, ezzel lehetővé téve azt, hogy a két végpont egyeztetés után felismerje, és beállítsa a TX / RX végződéseket, ezzel lehetővé téve az adatátvitelt különböző típusú és sebességű kábelek között. A kábelek kivezetése az IDF szobákból a végpontokig a létesítményüzemeltetési osztály feladata. Ezután a Service Desk kollégái ellenőrzik a kivezetett kábeleket, mérési teszteket végeznek rajtuk. Hiba észlelése esetén a kábel javítva lesz, amint lehetséges. A hálózati eszközök jó minőségű kábelekkel vannak felszerelve, egy esetleges meghibásodás lehetősége alacsony. Mint látni fogjuk, ez elengedhetetlen a minőség, és sebesség eléréséhez a magasabb rétegekben, a Háromrétegű Hálózati Modellben.
2.1.2. A Háromrétegű Hálózati Modellről A Háromrégetű Hálózati Modellt a Cisco javasolta először, mint klasszikus hálózati modellt. A Cisco a hálózati modellt négy alapra helyezte [1], melyek a következők: Hierarchia: minden rétegnek megvan a maga szerepe a hálózatban, ezzel egyszerűsítve a fejlődést, működést, és a kezelést. Csökkenti a hibatartományokat minden rétegben. Modularitás: lehetővé teszi az akadálymentes hálózat, és beágyazott szolgáltatások igények bővítését igények szerint. Ellenállóság: kielégíti a végfelhasználók és adminisztrátorok elvárásait azzal, hogy hiba esetén is képes tovább működni teljes funkcionalitással. Rugalmasság: a terhelés megosztását lehetővé teszi minden hálózati erőforrás által. Ezek a pontok egymástól függnek, és szükséges megérteni hogyan működnek egymással együtt. Ezekből jött létre a javasolt Három- és Kétrétegű Hálózati Modell. A három réteg az az Access, Distribution, Core Layer. A rétegeknek előre specifikált szerepük és funkciójuk van. A Háromrétegű Hálózati Modell esetén a Distribution és Core Layer külön rétegek, viszont a Kétrétegű Hálózati Modellben nem (8.1.1.-es ábra).
9
8.1.1. ábra: A Három- és Kétrégetű Hálózti Modell.
Debrecenben a Háromrétegű Hálózati Modell alapján lett felépítve a hálózat, melyben elsődleges szempont a redundancia és stabil működés. A Core és Distribution rétegekben Juniper EX típusú Layer 3-as switchek, az Access rétegben Cisco Catalyst, nagy teljesítményű Layer 2-es switchek működnek. Az eszközök közötti kapcsolatok kialakítása redundáns. A következő fejezetekben (2.1.3, 2.1.4, 2.1.5) bemutatom az Access, Distribution, és Core rétegeket, az általuk ellátott feladatokat, valamint a telephelyen használatban lévő eszközöket, és specifikációikat.
2.1.3. Az Access Layer Az Access Layer teszi lehetővé a felhasználók vezetékes eszközei számára a hálózatához való csatlakozást. Az Access rétegben működő eszközök IDF szobákban vannak elhelyezve. Az eszközöknek a következő tulajdonságokkal kell rendelkezniük [1]: magas portsűrűség; rendelkezésre állás kielégítése; Layer 2-es, alacsony szintű biztonság garantálása; QoS (Quality of Service): csomagok megcímkézése típus szerint; PoE (Power Over Ethernet, [22]) támogatása VoIP telefonok számára.
10
8.2.1. kép: Egy gyártósori területen elhelyezkedő kábelrendező szoba berendezései.
Az Access rétegben egységesen Cisco Catalyst 4506-E (WS-C4506-E, [23]) típusú vázak működnek, amely a 8.2.2.-es képen is látható. A vázak redundáns áramellátással, tápegységgel rendelkeznek. Öt darab bővítőkártyát lehet bennük működtetni.
8.2.2. kép: Egy Access rétegben működő Cisco Catalyst 4506-E váz.
11
A legfontosabb elem a vázakat irányító modul (supervisor engine), mely egy Supervisor Engine II-Plus (WS-X4013+, [24]). Ez felel a váz teljes irányításáért. A modul képes Layer 23-4 forgalom kezelésére. Csak Layer 2-es adatforgalom irányítására, és csomagok megcímkézésére (ez a 2.3.1.-es: „Quality of Service az NI-nál” fejezetben lesz bemutatva) lettek konfigurálva a vázakban található irányító modulok a telephelyen. Öt darab WS-X4548GB-RJ45V típusú bővítőkártyát [25] irányít a vázakban. A bővítőkártya modulok 48 porttal rendelkeznek, melyek támogatják a PoE-t, és 10/100/1000 Mbps sebességet. Az irányító modulok két 10 Gbps Ethernet kapcsolaton keresztül kapcsolódnak a Distribution rétegben található switchek felé. Ezek nem használnak link aggregációs protokollt, de a switch block kialakításának köszönhetően a redundancia biztosított.
2.1.4. A Distribution Layer A Distribution Layer az Access és Core rétegek között helyezkedik el, nagyon fontos szerepe betöltve: Layer 2 és Layer 3 közötti határvonalat képez. Ez azt jelenti, hogy: Több hozzá kapcsolódó Access rétegbeli switchet kell egyszerre kezelnie; az IP csomagokat szabályok szerint kell szűrnie; Layer 3-as csomagokat kell irányítani a routing folyamatai által, nagy sebességgel; QoS szabályok szerint kell kezelnie az érkező csomagokat; Skálázhatóságot kell biztosítania az alacsonyabb és magasabb réteg felé. A Distribution rétegben található switchek processzorigényes számításokkal dolgoznak: ide érkeznek az Access rétegből a csomagok, melyeket szűrni kell ACL-ekkel és Filter List-ekkel (2.5.3.-as fejezet: „Access Control List / Filter List bemutatása), és a routing által továbbítani. Az úgynevezett switch block struktúrával [1, 2] redundáns kapcsolatokat tudunk kialakítani a Distribution és az Access réteg között. Az ajánlás szerint minimum két Distribution rétegben található switchnek kell lennie benne. Az Access switchek száma lehet több, mint kettő. Fontos benne a redundáns kapcsolattervezés: az Access switcheknek minden Distribution switch felé kell uplink kapcsolattal rendelkezniük. A Distribution rétegben is szükséges egy kapcsolat a switchek között. A 8.1.2.-es ábrán láthatjuk a switch block felépítését.
12
8.1.2. ábra: Teljes redundancia kialakítása a switch block segítségével.
Két switch block van használatban a telephelyen: az A és a C épületben (BLD1 – BLD3). Két Distribution switch található bennük: Distro01-BLD1 – Distro02-BLD1; Distro01-BLD3 – Distro02-BLD3. A switchek redundáns áramellátással, két tápegységgel rendelkeznek. Mint említettem, a hozzájuk kapcsolódó Access rétegbeli switchek redundáns kapcsolattal rendelkeznek a saját switch blokkjukban található Distribution switchekkel (8.1.3. ábra).
8.1.3. ábra: A 3-as épületben (BLD3) található switch block felépítése.
Juniper EX4550-es, EX4550-32F típusú switchek működnek [26]. Az EX4550-32F típus fixen 32 darab 10 Gbps sebességű Ethernet vagy optikai porttal van felszerelve. A switch megfelelő teljesítményt nyújt, megfizethető áron. Támogat minden szükséges protokollt,
13
technológiát, ami a telephelyen szükséges. Lehetséges vele több Juniper eszköz egy logikai eszközzé való összekapcsolása, akár más típusú eszközzel (ez a virtual stacking).
8.2.3. kép: Az általunk használt Juniper EX4550-es switch a Distribution rétegben.
Több indok miatt alkalmazunk Juniper eszközöket: jobb ár/érték aránnyal bírnak; modulárisabb,
FreeBSD
alapú
az
operációs
rendszerük,
a
JunOS;
átláthatóbban
konfigurálhatóak. Mint ahogy látni fogjuk, a Core rétegben is Juniper eszközöket működnek: ez is mutatja, hogy bevált, jól működő eszközök. Sok irodában használjuk őket EX4200-as switchekkel, a virtual stacking támogatása miatt az EX4550-es modellt.
2.1.5. A Core Layer A Core Layer feladata, hogy a Distribution rétegből érkező csomagok nagyon gyors sebességgel legyenek továbbítva. A rétegben található switchek nem végeznek csomagszűrést, vagy manipulációt. Nincs olyan processzorigényes feladatot, amiért a Distribution réteg felel [2]. Konfigurációjuk optimalizált a csomagok továbbítására. A Core réteg tervezésénél az egyszerűség, ellenállóság, és redundancia játszik meghatározó szerepet. Az ide érkező csomagok már átestek a szűrésen, így csak továbbítani kell őket. Nagyon fontos hogy a QoS megfelelően működjön. Minden eszköz között aggregált kapcsolat vannak kialakítva LACP protokoll segítségével (ez a 2.5.2.-es: „LACP link aggregációs protokoll” fejezetben kerül bemutatásra.).
14
8.1.4. ábra: A Core és Distribution rétegben található eszközeink topológiája.
A Core rétegben Juniper EX4500-as, ex4500-40f típusú switchek működnek az MDF (Main Distribution Frame, központi kábelrendező) szobákban [27]. Az EX4500 az EX4550 egy előző generációja. Az EX4500-as sorozatot adatközpontokba tervezték, így fix 10 Gbps sebességű Ethernet vagy optikai portokkal szerelték fel. Itt jelent meg elsőként az, hogy különböző típusú Juniper switchet tud egy logikai eszközként kezelni.
8.2.4. kép: A Core rétegben használt Juniper EX4500-es switch.
Felmerülhet a kérdés, hogy miért van az, hogy újabb típusú EX4550-es switchek vannak használatban a Distribution rétegben, és régebbi típusú EX4500 switchek a Core rétegben? Ez azért van, mert a hardverek öt évre vannak vásárolva, így a hálózati eszközök is. Mikor
15
lecserélésre kerültek a Distribution rétegben található switchek (Cisco Catalyst 3750-es típusú switchekről), az EX4550-es switchek olcsóbbak voltak, mint az EX4500-asak, így ezeket vásároltuk meg. Jövőre lesznek a mostani Core rétegben működő eszközeink öt évesek, így akkor fog megtörténni a cseréjük.
16
2.2. A hálózat kapcsolatai 2.2.1. Az internetvonal Az internetvonal egy bérelt, szimmetrikus Ethernet kapcsolat, mely 400 Mbps sebességű. Ez 400 Mbps letöltési, és 400 Mbps feltöltési sebességet jelent. A szimmetrikus internetkapcsolat azonos letöltési és feltöltési sebességgel bír. A szimmetrikus Ethernet a következő előnyökkel rendelkezik: Nagyobb méretű fájlok feltöltése a letöltéssel egyenlő, nagy sebességgel; Felhőalapú szolgáltatások könnyebb használata (Panzura, Office 365, Amazon Cloud). Ezt nem lakossági ügyfeleknek, hanem üzleti partnereknek alakították ki, ahol ugyanolyan fontos a letöltési, mint a feltöltési sebesség. Ez a szolgáltatás árában is meglátszik, mely akár sokszorosa is lehet a lakossági internet előfizetés árának. A közelmúltban lett 200 Mbps sebességről bővítve 400 Mbps sebességre, az újfajta cloud és a Microsoft Office 365 szolgáltatás bevezetése miatt. Feltétellé vált a nagyobb sebesség garantálása a telephelyen. Az internetvonalon végzett méréseket a 3.4.1.-es: „Az internetvonal tesztelése” fejezetben mutatom be. Az internetvonalon keresztül VPN kapcsolódási lehetőséget biztosítunk a kollégáink és partnereink számára (2.2.2.-es fejezet: „VPN kapcsolódási lehetőség kollégáink, partnereink számára”), illetve egy mindkét WAN vonalat érintő kimaradás esetén a DMVPN felhőnkbe kapcsolódhatunk rajta keresztül, ezzel pótolva bérelt WAN kapcsolatainkat (2.2.3.-as fejezet: „DMVPN: WAN kapcsolat publikus Interneten keresztül”).
2.2.2. VPN kapcsolódási lehetőség kollégáink, partnereink számára A telephelyen kétféle VPN kapcsolódási lehetőség van biztosítva az internetvonalon: Cisco VPN Concentrator szervereken keresztül partnereknek, és a Pulse Secure SSL VPN szervereken keresztül a kollégák számára. A Cisco VPN Concentrator szerverek segítségével a partnerek kapcsolódását ACL-ekkel tudjuk engedélyezni és szabályozni: kontrollált hozzáférést biztosítani nekik azokhoz a belső erőforrásokhoz, amivel szükséges dolgozniuk a hálózatban. Egy VPN Concentrator 3000 típusú szerver látja el ezt a feladatot. A partnereknek külön Active Directory fiókjuk van, amelyben
17
fel van tüntetve az a speciális ACL, mely meghatározza a hozzáférésüket a szükséges erőforrásokhoz az ACS (Access Control Server) szervereken; az ACL-ek működését a 2.5.4.es fejezetben fogom tárgyalni. A Pulse Secure SSL VPN szerverünkkel a dolgozók hozzáférését biztosítjuk. Debrecenben egy Juniper SA4500-as SSL VPN szerver látja el a feladatot. A VPN szerver fizikailag 1000 aktív felhasználóig probléma nélkül képes a feladatát ellátni. A megvásárolt licenc szerint a telephelyen maximum 100 aktív felhasználót képes kezelni egyidejűleg a VPN szerverhez. Az SSL VPN technológia megengedi, hogy egy böngésző ablakából elérjük a belső erőforrásokat. A Pulse Secure belépéskor (megfelelő authentikációja, tanúsítvány ellenőrzése, és operációs rendszer vírusirtóval való meglétének ellenőrzése után) egy IP címet oszt ki a csatlakozott felhasználónak, aki ezután képes hozzáférni a vállalati erőforrásokhoz. Az SSL VPN szerver segítségével nyomon követhető a felhasználók bejelentkezése, státusza (Active Directory név, IP cím melyet az SSL VPN osztott ki neki, operációs rendszer, és hitelesítés státusz). Hibaelhárításnál a naplózás nagyon hasznos információkat tud adni. A National Instruments világszerte a nagyobb irodáiban konzisztens beállítású Juniper SSL VPN szervereket üzemeltet, tipikusan a telephelyen használt típussal, de vannak irodák, ahol másfajta üzemel, csak erősebb hardver specifikációkkal. A Cisco VPN Concentrator szerverek nagyon kevés helyen üzemelnek még, hiszen már nem támogatott eszközök.
2.2.3. DMVPN: WAN kapcsolat publikus Interneten keresztül Ahol az ország vagy város szolgáltatói nem teszik lehetővé, vagy az iroda olyan kicsi, hogy nem éri meg üzemeltetni egy dedikált WAN kapcsolatot, interneten keresztül a Cisco DMVPN (Dynamic Multipoint VPN, [28]) technológiáját használva tesszük elérhetővé a kollégáknak a vállalati erőforrásokhoz való hozzáférést, iroda szintjén (ez a Site-to-Site VPN megoldás). A DMVPN egy olyan dinamikus, titkosított VPN alagúthálózatot hoz létre, mely a GRE (Generic Routing Encapsulation, [6]), az NHRP (Next Hop Resolution Protocol, [7]), az IPsec (Internet Protocol Security), illetve ISAKMP (Internet Security Association and Key Management Protocol, [8]) protokollokon keresztül valósul meg.
18
A DMVPN hub-and-spoke topológiát használ, melyben vannak elsődleges és tartalék routerek. mGRE (multipont GRE) alagutak épülnek fel a benne található routerek között, melyek összekötik a hub routereket a spoke routerekkel. Ezt nevezzük DMVPN felhőnek (DMVPN Cloud). Maximum 500 irodát vagyunk képesek egy DMVPN felhőbe foglalni. A DMVPN felhőben egységes forgalomirányítási protokoll van használatban, BGP, EIGRP vagy OSPF. A globális hálózatban üzemelő DMVPN felhőben az EIGRP protokoll van használatban. A DMVPN felhő kialakítása magas szakértelmet kíván, viszont megvannak az előnyei: az összes Cisco router támogatja, így minden Internet és WAN kapcsolattal rendelkező irodában tudjuk használni, mint tartalék WAN kapcsolatot. Az alagút monitorozva van a SolarWinds Orion által, hiba esetén azonnal képesek vagyunk reagálni.
2.2.4. A WAN kapcsolatok A WAN (Wide Area Network, nagy kiterjedésű hálózat) olyan telekommunikációs hálózat, mely képes több kontinensen túlnyúlva, távoli eszközöket, irodákat közvetlenül összekapcsolni. Jellemzően az irodák túlnyomó többségében található dedikált WAN kapcsolat. Ahol nem lehetséges, ott DMVPN kapcsolattal van biztosítva a WAN kapcsolat. Többféle WAN technológia létezik, melyeket két nagyobb típusban különböztetjük meg: áramkörkapcsolt és csomagkapcsolt. Az áramkörkapcsolt hálózatban egyfajta áramkör kerül felállításra a WAN hálózatban található switchek között, melyek dedikált kapcsolatot hoznak létre. Ennek előnye az, hogy a sávszélessége fix, és a válaszideje is alacsony. A csomagkapcsolt hálózat IP csomagokba ágyazza bele az adatrészt, legyen az hang, videó, vagy egyéb adatcsomag. A csomagkapcsolt hálózat emiatt jól skálázható, hatékony, és konvergens hálózat felállítására ad lehetőséget. A debreceni telephelyen a Verizon által kialakított MPLS (Multiprotocol Label Switching, [9]) WAN kapcsolatokat használjuk. Az MPLS protokollt a WAN technológiákban a csomagkapcsolt típusok közé soroljuk. A csomagok Layer 2-es megcímkézésével a QoS szolgáltatás integrálva van a protokollba. A protokoll képes hatékonyan titkosítani a kapcsolatot. Gyorsabban áll helyre egy hiba esetén, mint a hasonló technológiát használó protokollok (ATM, Frame Relay) [29].
19
8.1.5. ábra: MPLS WAN Cloud kapcsolat illusztrációja a három telephelyünk között.
Mint ahogy fentebb említettem, a telephelyen két darab WAN vonalat bérlünk, melyek MPLS protokollt használnak Ethernet kapcsolatokon keresztül. A két WAN router a két MDFben található (BLD1 és BLD3). A routerek konfigurációja lehetővé teszi a terhelés megosztását a két WAN vonalon.
8.1.6. ábra: Két WAN kapcsolatunk ábrája.
20
A WAN kapcsolatok idén tavasszal bővítésen estek át: márciusban a két darab 10 Mbps sebességű kapcsolatot 15 Mbps sebességre, majd ősszel 40 Mbps sebességre bővítették. A routereket az IOC csapat és a hálózati mérnökök kezelik, nem a szolgáltató. Így a QoS profilt kezelhetjük, továbbá meghibásodás esetén azonnal reagálhatunk és hozzáférhetünk az eszközökhöz (ezt nevezzük a vállalatnál „MWAN” típusú routernek; az „MSc” típusú routereket a szolgáltató kezeli). A tavaszi és őszi fejlesztések után a kapcsolatok érezhetően gyorsabbak lettek. Manapság már nem kapunk értesítést arról, hogy elértük a 85%-os sávszélesség terheltséget a WAN vonalaikon. A WAN kapcsolatokon konvergált hálózati forgalom halad keresztül: videó, hang, adat IP csomagokba ágyazva. Fontos emiatt, hogy a legmagasabb QoS osztálynak, a VoIP forgalomnak megfelelő legyen a késleltetése. Mint a következő fejezetben látni fogjuk, ez nagyon fontos, hogy teljesüljön, hiszen a VoIP telefonhálózat forgalmának a jelentős része a WAN vonalainkon halad keresztül. A WAN hálózatunkban az MPLS routereken egységes a QoS profilok alkalmazása, hogy fenntartsuk a homogén beállításokat, és minőséget. A QoS profilokat hálózati mérnökeink készítik el és tesztelik le. A QoS-t és a működését a következő, 2.3.1.-es: „Quality of Service az NI-nál” c. fejezetben fogom bemutatni.
21
2.3. VoIP Telefónia bemutatása Debrecenben 2.3.1. Quality of Service az NI-nál Egy vállalat konvergált hálózatában, melyben egyszerre jelen van az adat, a hang, és a videó, a különböző adatfolyamok között különbséget kell tenni. A Quality of Service ezt a célt szolgálja. A Cisco Enterprise Medianet Quality of Service Design 4.0 QoS architektúráját használjuk QoS profilunk alapjául a WAN routereken. A QoS profilban definiálva vannak a QoS osztályok, melyek a priorizálás alapját fogják adni. A QoS folyamat első lépése a beérkező csomagok megcímkézése. Az Access rétegben található switch az interfészeken keresztül beérkező csomagokat megvizsgálja, Extended ACLek illesztésével: az Extended ACL-ekben vannak definiálva a QoS osztályok típusa, az IP cím és port szám alapján. Minden ACL-hez külön DSCP (Differentiated Services Code Point) érték tartozik. A mintaillesztés után a Layer 3-as ToS (Type of Service) 8 bites mező első 6 bitjét beállítja a csomagra illeszkedő DSPC értékkel. Ezt az általunk használt Access switchek hardveresen, nagy sebességgel tudják megtenni, minimális terheléssel. A Distribution és Core rétegekben a csomagok a DSCP értékek alapján a megfelelő prioritásban részesülnek. Konzisztens beállításokat alkalmazunk a rétegekben és az eszközökön, a legjobb minőség nyújtása érdekében. A hálózaton belüli routing után a WAN routerek felé irányulhatnak a megcímkézett csomagok. A megformálás (shaping) folyamata során a csomagokat a router besorolja a megfelelő QoS osztályba. Az osztályok a beállított prioritás szerint vannak kezelve, és be van állítva azok számára elérhető, maximális sávszélesség. A kimenő interfészen a QoS osztályok szerint vannak a csomagok továbbítva. Előfordulhat az, hogy az adott QoS osztálynak már nincs használható sávszélessége, és tele van. Ekkor az érintett osztályba érkező csomag el lesz dobva. Ez magas terheltségnél megfigyelhető (mikor a sávszélesség 85%-nál jobban terhelve van). Viszont ez nem következhet be a hang (voice) QoS osztályának csomagjai esetében. Ha a hang QoS osztályban csomagveszteséget tapasztalunk, akkor ez rossz beállítást, konfigurációt jelenthet, vagy a sávszélesség elégtelenségét. A QoS segítségével a csomagokat címkézés után, a QoS profilokban definiált osztályok által tudjuk priorizálni, kezelni. QoS nélkül a konvergált hálózatokban nem lenne lehetséges a szolgáltatások minőségét garantálni. Ezért fontos, hogy az osztályok megfelelő meghatározása
22
és definiálása. Mint láthatjuk, egy modern, konvergált hálózatban, melyben üzemel egy VoIP telefonhálózat, a QoS elengedhetetlen.
2.3.2. A VoIP telefonhálózat bemutatása A VoIP telefonhálózat a konvergált hálózat infrastruktúráját használja. Költséghatékony, hiszen egy másik infrastruktúra kiépítése nélkül képesek vagyunk arra, hogy telefonhálózatot üzemeltessünk. Ezért VoIP telefonhálózat legfontosabb előfeltétele, hogy a QoS (mint ahogy az előző fejezetben bemutattam) megfelelően legyen konfigurálva a hálózati eszközökön. Ez biztosítja a minőségi feltételeit a VoIP telefonhálózatnak a konvergált hálózati környezetben. A debreceni VoIP telefonhálózat három részből tevődik össze: 1, a telefonközpontból; 2, a VoIP telefonokból vagy softphone kliensekből; 3, a voice gateway-ből és GSM modulból. A fejezet további részében szeretnék átfogó képet adni a VoIP telefonhálózatunk felépítéséről és működéséről. A VoIP telefonok az Ethernet infrastruktúrán keresztül kapják az áramellátást [22], és egyedi IP címmel rendelkeznek. A hálózati infrastruktúrában a Voice VLAN segítségével és QoS osztályozással van biztosítva a VoIP telefonok hívásának minősége. A telefonok bejelentkeznek a helyi telefonközpontba, és regisztrálják magukat. Minden telefon egy felhasználóhoz van regisztrálva mellék szerint, mely a Windows Active Directory-val együtt van összekapcsolva a telefonközpontban. Cisco 7945-ös VoIP telefonokat használunk. A telefonközpont, a Cisco Unified Communications Manager (UCM) egy virtualizált szerveren fut. A szerveren alkalmazás és rendszerszintű redundancia van kialakítva. A Cisco SCCP (Skinny Call Control Protocol, [30]) protokollját használjuk. A telefonközpont a bejövő hívásokat értelmezi mintaillesztéssel, és eldönti, hogy vállalaton belül, vállalaton kívül PSTN vonalon, vagy mobilhálózaton keresztül kell a hívást kiküldenie. A telefonközpontjaink képesek nemzetközi kiépítettségük miatt a WAN hálózaton a Cisco TEHO implementációját használni (Tail End Hop Off, [31]). Ez azt jelenti, hogy egy nemzetközi hívás esetén a WAN hálózaton keresztül a külföldi hívotthoz legközelebb tartózkodó központhoz vagy voice gateway-hez kapcsolódni, és segítségével folytatni a hívási folyamatot. Ezzel olcsóbban és költséghatékonyan tudunk nemzetközi hívást helyi hívásként indítani. A telefonközpont építi fel a hívást a hívó és a hívott fél között (akár SIP trunk segítségével), viszont maga a hívás a
23
két fél között megy végbe. Ezt a két típusú forgalmat hívjuk Voice (hang) és Control (irányító) forgalomnak. Mikor a hívás véget ér, a felek jelzik ezt, és a központ leépíti a hívást.
8.1.7. ábra: A VoIP telefonhálózat felépítése Debrecenben.
A voice gateway és a GSM modul felel a hívás kifelé menő tárcsázásáért a PSTN vonalra (Public Switched Telephone Network), vagy a mobilhálózatra. A PSTN vonal használatakor a mellék is használható, mint hívószám (minden dolgozónk saját telefonszámmal rendelkezik a melléke alapján), tehát a hívott félnél megjelenik a rendes telefonszáma is. A GSM modul esetén viszont ez nem lehetséges, hiszen bizonyos számú vásárolt mobiltelefonszámon keresztül történik a kitárcsázás, így a mobiltelefonszám jelenik meg a hívásnál, nem a mellék. A telefonközpont tárcsázásnál dönti el, hogy a PSTN vonalra a voice gateway-en keresztül, vagy a mobilhálózatra kell kiküldeni a hívást a GSM modulon keresztül. Manapság már minden irodában található voice gateway, és Debrecenben két darab GSM modul. A VoIP telefonhálózat az elmúlt évben nagy bővítésen ment keresztül, a befektetett összeg a hívások költséghatékonysága miatt hamar megtérül az ára idővel. Az idén folyó Skype For Business rendszerünk fejlesztése miatt elérhetővé vált, hogy a softphone kliensek használni 24
tudják a VoIP és PSTN hálózatunkat, ezzel lehetővé téve azt, hogy VoIP telefonok mellett laptopokról és asztali számítógépekről is kezdeményezhessünk hívásokat.
2.3.2. Skype for Business kliens, a mobilis softphone szoftver A softphone egy szoftver, mellyel általános felhasználású eszközről kezdeményezhetünk hívásokat dedikált hardver (például telefon) helyett. A szoftver használható például munkaállomásokon, notebookokon, okostelefonon, vagy tableten. Manapság széleskörű támogatottságot élvez, a legelterjedtebb operációs rendszerekre (Windows, Mac OS X, Android, stb.) feltelepíthetőek a softphone kliensek általában [32]. A vállalat a Microsoft Skype for Business (röviden: SfB) platformját használja. A Microsoft Lync a Skype for Business alkalmazás elődje. Eredetileg vállalati szintű instant üzenetküldő szolgáltatás volt, melyet kibővítettek VoIP telefonhívások és videokonferenciák kezelésére is. A SfB kliens használata elengedhetetlen Windows Active Directory nélkül: minden felhasználó authentikációja az Active Directory profiljával történik, és profilja egyedi attribútumokkal rendelkezik, melyet a SfB használ. A SfB kliens használható softphone szoftverként is, köszönhető a platform UCM szerverekkel való integrációnak. A bejelentkezés során bejelentkezik a Skype for Business kliens a szerverekre, és az UCM telefonközpontokba is. Így képesség válik hagyományos telefonhívások fogadására is. Egyszerre lehetséges több eszközzel való bejelentkezés is (például asztali számítógépen, notebookon, és telefonon keresztül). Az UCM szerver beérkező hívás esetén kapcsolatba lép a SfB szerverekkel, melyek minden bejelentkezett eszközön jelzik a hívást. Az első eszközzel, melyen a felhasználó fogadja a hívást, a Skype for Business szerverek és az UCM szerverek felépítik a P2P (Peer to Peer, ponttól pontig) kapcsolatot. A SfB kliensek SIP protokollt használ. Ez egy széleskörűen támogatott protokoll, mely a UCM szervereken is alapértelmezés. Kimenő hívás indításánál a felhasználó által beírt telefonszám számtranszformáción esik át a kliensben, ezt küldi tovább a SfB, majd UCM szerverek felé (control signaling). Az UCM szerver ezen a ponton felépíti a kapcsolatot (WAN vagy PSTN vonalon, illetve GSM hálózaton keresztül). Miután a kapcsolat felépült, a két végpont P2P, direkt kommunikációt fog folytatni egymással (voice signaling). A kapcsolat
25
leépítésénél ugyanez történik: a kapcsolat leépítését kezdeményező kliens felveszi a kapcsolatot az UCM szerverrel, mely lebontja a felépített, direkt kapcsolatot. Mint láthatjuk, a kliens segítségével nem csak hang- és konferenciahívások, hanem telefonhívások is indíthatóak. Mivel mobilis (akár egy notebookon is futtatható), így lehetséges az, hogy bárhonnan használható legyen: a dolgozó kubikjából, egy konferencia szobából, vagy a folyosókon található ülőhelyekről. A WLAN hálózaton keresztül is képes működni, így teljesen mobilissé válik a felhasználó, nincs helyhez kötve. A következő fejezetben látni fogjuk, hogy a vezeték nélküli hálózatot használva zökkenőmentesen lehet akár WLAN kapcsolaton keresztül is használni a SfB softphone klienst.
26
2.4. Vezeték nélküli hálózat ismertetése 2.4.1. Az IEEE 802.11 protokoll család Az IEEE 802.11 protokoll család a vezeték nélküli helyi hálózatok (WLAN) adatátviteli protokolljait foglalja magában. Az OSI modell két alsó rétegét használja, az adatkapcsolati (MAC, Media Access Control) és fizikai (PHY, Physical) rétegeket [33]. Az alap protokoll (IEEE 802.11-1997 Legacy) 1997-ben lett kifejlesztve, azóta számos fejlesztésen ment át, újabb protokollokkal bővítve az IEEE 802.11 protokoll családot. Az Access Pointok által használt IEEE 802.11 protokollok az IEEE 802.11b/g/n/ac. Ezek a 2,4 GHz-es frekvencia tartományt (IEEE 802.11b/g/n: 2412 MHz – 2472 MHz) és az 5 GHzes frekvencia tartományt (IEEE 802.11ac: 5170 MHz – 5825 MHz) használják [34]. A frekvencia tartományok csatornákra lettek osztva, melyek gondoskodnak arról, hogy ne legyen interferencia, ha több WiFi hálózatot vagy AP-t szeretnénk egymáshoz közel üzemeltetni. A 2.4 GHz esetén 13 csatorna használható, a javasolt sávszélesség csatornánként 22 MHz. 5 GHz esetén 36-tól 161-ig használhatóak a csatornák, és a javasolt sávszélesség 80-160 MHz. Minden régióban más csatornák használhatóak, a fenti csatornák száma az európai régióra értendőek.
8.1.8. ábra: A 2,4 GHz-es frekvenciában a csatornák kiosztása.
A telephelyen a LWAP (Lightweight Access Point Protocol, 2.4.2.-es fejezet) protokoll van használatban, így az AP-k vezérlését és a csatornák beállítását a WLC (Wireless LAN Controller) végzi. A javasolt megoldást használja, vagyis az interferencia elkerülése végett a 2,4 GHz-es frekvencia tartományban 1-es, 6-os, és 11-es csatornákat. Részletesen a 3.3.3-as: „A WLAN hálózat tesztelése” c. fejezetben fogom tesztelni a WLAN hálózatunkat, vizsgálva a csatornák kiosztását, és azok kihasználtságának mértékét.
27
2.4.2. LWAP protokoll és hierarchia bemutatása A Lightweight Access Point protokoll egy olyan technológia, amely lehetővé teszi több Access Point (röviden: AP, hozzáférési pont) egyidejű üzemeltetését, menedzsmentjét azonos séma és beállítások szerint [35]. A telephelyen ez a protokoll lett implementálva, hiszen sokkal egyszerűbb a kezelése, mintha autonomous kezelésű hozzáférési pontokat használnánk. Az AP-kat egy Wireless LAN Controller (WLC) eszköz vezérli. A telephelyen két ilyen eszköz van használatban. Segítségükkel egyszerűsíthető a vezeték nélküli hálózat kiterjesztése, működtetése, monitorozása, menedzsmentje, és beállítások módosítása. Változtatás esetén két eszközön kell elvégezni a módosításokat (nálunk két WLC üzemel). Ez egyszerűsíti a telephely vezeték nélküli hálózatának üzemeltetését, hiba esetén a probléma keresését is. Több hozzáférési pont fedi le a telephely területét, különböző csatornákat használva (1-6-11). Így kisebb lesz az interferencia, lehetővé válik a roaming, a megszakításmentes vezeték nélküli kapcsolat [36].
8.1.9. ábra: LWAP protokoll felépítése.
A WLC a Wireless Control System-el működik együtt; a Wireless Control System futhat például a Cisco Secure ACS (Access Control Server) szerverén is, mint ahogy Debrecenben is. Az ACS szerver segítségével történik a kliensek authentikációja, és monitorozása (mely a
28
2.4.3.-as fejezetben: „A RADIUS protokoll ismertetése” kerül bemutatásra). A hozzáférési pontok csatornakiosztását a WLC határozza meg az interferencia elkerülése végett. Európában található irodáink a debreceni telephely ACS szervereit használják authentikációra, mert helyileg nincs saját szerverük. Viszont a protokollnak van egy nagy hátránya, mely maga a legnagyobb előnye: a centralizáltság. Mivel minden hozzáférési pontot a WLC-k és az ACS szerverek irányítanak, így hiba esetén az egész vezeték nélküli hálózatot jelentős leállás veszélyeztetheti. Általában a WLC-k között is lehetséges egyfajta redundanciát létrehozni, mely több WLC esetén az AP-k képesek kapcsolatba lépni a tartalék WLC-vel hiba esetén, így megelőzve a vezeték nélküli hálózat teljes leállását.
2.4.4. Az NI, INET, SCAN, és NI-DSL SSID Több SSID van használatban a telephelyen, ezekből a legfontosabb az NI SSID. Az NI SSID belső erőforrásokhoz ad hozzáférést. WPA2 Enterprise 802.1X [10] authentikációs protokollt használ RADIUS protokollal, mely az adott felhasználó Windows Active Directory profilját authentikálja. Az NI SSID-t a felhasználó az Active Directory fiókjával használhatja, és hozzáférést ad a belső, vállalati erőforrásokhoz. Figyeljük a felhasználók authentikációját, és magas számú sikertelen authentikáció esetén felvesszük a felhasználóval a kapcsolatot a hiba megtalálására, mielőtt a felhasználó fiókja lezárásra kerülne. Az INET, más néven Internet SSID publikus, nyílt authentikációjú elérést biztosít a telephely területén. Speciális ACL-ekkel van biztosítva az, hogy belső erőforrásokhoz ne férhessenek hozzá a kliensek. Ezt az SSID-t használhatják vendégeink, látogatóink. A SCAN SSID hordozható, mobil szkennereknek számára van fenntartva a gyártósor területén. MAC cím alapján történik az authentikáció. Más erőforrásokhoz férhetünk vele hozzá, mely a mobil szkennerek számára van fenntartva a gyártósor és a raktár területén. Az NI-DSL SSID egy külön vezeték nélküli router által sugárzott WiFi hálózat, a Service Desk területén. Elsődleges feladata a WiFis, VPN-es problémák kivizsgálása a Service Desk kollégák számára. Lehetséges vele ellenőrizni, hogy milyen kapcsolódási probléma állhat fent.
29
2.4.3. A RADIUS protokoll ismertetése A RADIUS protokoll (Remote Authentication Dial-In User Service, [11, 12]) látja el az AAA szolgáltatásokat a vezeték nélküli hálózatban: az Authentication-t (hitelesítést), Authorization-t (meghatalmazást), és az Accounting-ot (profilkezelést). A RADIUS egy kliens/szerver protokoll, mely a Layer 4-es transzport rétegben az UDP (User Datagram Protocol, [13]) protokoll 1812-1813 portjait használja. Az UDP szállítási rétegbeli protokoll egy nagyon egyszerű, gyors, kapcsolatmentes protokoll, kicsi válaszidővel, mely nem használ nyugtázást. A RADIUS a globális hálózatban a 802.1X authentikáció alapjául szolgál. A felhasználó számítógépe hozzáférést kezdeményez a vezeték nélküli hálózathoz a Network Access Server-től a WLC-n keresztül, melynek feladatát az ACS (Access Control Server) szerverek látják el. A szerver leellenőrzi és egyezteti a felhasználó hitelesítési adatait a helyi Active Directory szerveren. A telephelyen két ACS szerver végzi az authentikációt RADIUS protokollal. A szerverek az egész EMEA (Europe, Middle East and Africa) régióban végzik az irodákban működő kliensek authentikációját. A RADIUS protokoll széleskörűen elterjedt, melyet sok vállalat használ. A következő fejezetekben ilyen protokollokat fogok bemutatni, melyek egy vállalati hálózat számára elengedhetetlenek, és szükségesek.
30
2.5. Hálózatunkban működő fontosabb protokollok, technológiák 2.5.1. IEEE 802.1Q: Trunking, VLAN hálózatok Manapság a Layer 2-es környezet lehetőséget ad arra, hogy egy fizikai switchen több virtuális helyi hálózatot, VLAN-t konfiguráljunk. Az eszközök, melyek egy VLAN-ba tartoznak, közös üzenetszórási tartományon osztoznak, és nem feltétlenül egy fizikai eszközre vagy helyre vannak korlátozva. Ez az IEEE 802.1Q [37]. Más VLAN-ba tartozó végpontoktól nem fognak üzenetet kapni, csak a saját VLAN-jukba tartozó végpontoktól.
8.1.10. ábra: VLAN hálózatok kiterjedésének szemléltetése.
Ha a VLAN hálózatba tartozó eszközöket össze szeretnénk kötni Layer 3-as eszközökkel (például egy routerrel), szükségünk lenne annyi uplink kapcsolatra a switch és a router között, amennyi VLAN található a switchen. A trunk kapcsolat ezzel szemben képes a rajta engedélyezett VLAN-okból származó üzeneteket szállítani a router felé, ezzel egyetlen linket és kevesebb erőforrást használva több uplink port helyett. A trunk kapcsolat csak a rajta engedélyezett VLAN hálózatból érkező csomagokat továbbítja. A telephelyen több VLAN van használatban, de három nagyobb típusban: irodai területen lévő VLAN-ok (Office VLANs): bármilyen belső és külső erőforrást elérhetnek; a gyártósori switcheken működő VLAN-ok (Manufacturing VLANs): korlátozott eléréssel bírnak a külső / belső erőforrásokhoz; és a VoIP eszközöknek fenntartott VLAN-ok (Voice VLANs). Általában minden VLAN egy alhálózathoz tartozik, és a DHCP szerverek osztják ki az IP címet számukra. 31
A VLAN-ok elengedhetetlenek egy vállalat hálózatában, hiszen mint látjuk, határvonalat képeznek a hálózat különböző területei között. A trunk kapcsolatok szintén elengedhetetlenek. Lehetséges aggregált kapcsolatokon trunk kapcsolatokat definiálni, és általában ez a bevett szokás. Mint látni fogjuk a következő, 2.5.2.-es fejezetben, sokat javíthat a hálózat minőségén és redundanciáján.
2.5.2. LACP link aggregációs protokoll A számítógépes hálózatokban gyakran használt a link aggregáció két hálózati eszköz között. Az aggregáció segítségével több fizikai kapcsolatot vagyunk képesek egyetlen logikai kapcsolatként kezelni. Ez több szempontból is előnyös: Növeli a sebességet; Növeli a redundanciát; Lehetővé teszi a terhelésmegosztást a linkeken. A link aggregáció lehetővé teszi azt, hogy két hálózati eszköz között nagyobb sebességet tudjunk biztosítani. Előfeltétele, hogy mindkét eszközön ugyanolyan típusú és sebességű portok vegyenek részt az aggregációban: a portok sebességének többszörösét vagyunk képesek elérni. Viszont az eszközöknél vannak korlátok. Cisco eszközöknél csak 8 darab interfész képes részt venni az aggregációban és egy eszközön maximum 6 darab ilyen aggregált kapcsolatot képes működtetni. Juniper eszközöknél is vannak hasonló korlátok [38]: 8-12-16 darab interfész lehet tagja egy LAG-nak (Link Aggregation Group, Link Aggregációs Csoport), és maximum 32111-255 darab aggregált csoportot képesek kezelni (eszköz típusától függően). Az LACP protokoll (Link Aggregation Control Protocol, [14]) használatával a Distribution és Core rétegek között aggregált linkek vannak kialakítva. Két darab, 10 Gbps full duplex Ethernet kapcsolatot tartalmaz egy aggregált link. Az Access rétegben található switchek nem rendelkeznek aggregált linkekkel, csak a switch block redundanciájának megfelelően két-két uplink portjuk van a Distribution rétegben található eszközök felé.
32
2.5.3. Access Control List / Filter List Az Access Control List, vagy Juniper eszközök esetében Filter List egy alacsony szintű tűzfal, mellyel szabályozhatjuk a hozzáférést bizonyos erőforrásokhoz a hálózatban [2, 40]. Segítségével csomagokat tudunk irányítani: meghatározott szabályok által tovább engedhetjük, vagy eldobhatjuk őket. Ennek több előnye is van: Limitálhatjuk a hálózati hozzáférést vállalati környezetben: a telephelyen szigorú szabályok vannak a termelés területén található alhálózatban, így a külvilágba való kommunikációt ACL-ek és Filter List-ek szűrik; Alapszintű védelmet tudunk vele létrehozni: szabályozni tudjuk, hogy bizonyos hosztok milyen erőforrásokhoz férjenek hozzá. Erre nagyon jó példa a 100-as ACL használata a debreceni telephely felsőbb rétegben található eszközein (Core és Distribution rétegek); Szabályozni tudjuk a forgalom típusát is: engedélyezni tudjuk a TFTP forgalmat, és egyidejűleg tiltani a Telnet protokoll csomagjait. Kétfajta ACL típust különböztetünk meg, melyeket számozással is jelölünk: standard és extended (kibővített) ACL-eket. Az ACL-eket tudjuk nevesíteni: névvel ellátni a jobb kezelhetőség és megjegyezhetőség érdekében. Az ACL-eket bejövő (inbound) és kimenő (outbound) forgalom szűrésére tudjuk beállítani. Distribution rétegben található eszközeinken Filter Listeket, az internet és WAN routereinken Extended ACL-eket használunk. Hogy lássuk a felépítésüket és konfigurációjukat, bemutatom a standard- extended ACL és Filter List felépítését és konfigurációját. A standard ACL (1 – 99, 1300 – 1999) forrás IP cím, vagy címtartomány szerint szűr a forgalmat. Először érdemes a hoszt IP címeket definiálni, majd pedig az egyre tágabb címtartományokat. Ezzel optimalizálhatjuk az ACL-t. A 8.2.5.-ös képen láthatjuk a standard ACL konfigurációjának példáját egy adott interfészen, bejövő forgalomra.
8.2.5.-es kép: Egy standard ACL konfigurálása és alkalmazása a Gi0/1 interfészen.
33
Az extended ACL (100 – 199, 200 – 2699) több feltétel alapján való szűrésre alkalmasak: nem csak Layer 3-as, hanem Layer 4-es fejrészeket is képes vizsgálni. Ezzel lehetővé válik, hogy Layer 4-es protokollokat (TCP, UDP) port szám alapján szűrni tudjunk. A 8.2.6.-os képen láthatjuk egy extended ACL konfigurálását és alkalmazását egy adott interfészen, bejövő forgalomra.
8.2.6.-es kép: Egy extended ACL konfigurálása és alkalmazása a Gi1/1 interfészen.
A Juniper eszközön alkalmazott Filter List-ek működése megegyezik a Cisco eszközön használt ACL-ekkel. Legfőbb különbség a szintaktikai megfogalmazásban van. A 8.2.7.-es képen látható, hogyan kell konfigurálni és alkalmazni két Filter List-et (filter_SSH és filter_Telnet) egy adott interfészen bejövő forgalomra.
8.2.7.-es kép: Két Filter List konfigurálása és alkalmazása a ge-1/3/0 interfészen.
A telephelyen a gyártósorban alkalmazott ACL-ek, és globálisan összes eszközön használt 100-as Management ACL / Filter List a fontos. A gyártósorban alkalmazott ACL gondoskodik arról, hogy külvilágba ne kerülhessen ki érzékeny forgalom (ezzel megelőzve az adatok kiszivárogtatását). A 100-as Management ACL / Filter List kontrollálja a hozzáférést a hálózati eszközökhöz, ezzel megelőzve azt, hogy illetéktelen egyén tudjon kapcsolatot létesíteni SSH
34
protokollon keresztül. Ezt később, a 2.5.1-es fejezetben fogom részletesen bemutatni és tárgyalni. Az ACL / Filter List egy módja a forgalomirányításnak, de léteznek más módok is. Mint a következő fejezetben látni fogjuk, az OSPF protokoll is képes a forgalom hatékony irányítására.
2.5.4. Az OSPF forgalomirányító protokoll Az OSPF routing protokoll (Open Shortest Path First, [15]) egy kapcsolat-állapot (link state) alapú forgalomirányító protokoll [2]. A protokollt használó eszközök Dijkstra Shortest Path First algoritmusát használják a legrövidebb, legjobb út (route) meghatározására. Területeket (area) használ, így jobban feloszthatóbbá, optimalizálhatóbbá válik egy nagyobb hálózatban. Az OSPF protokollban a területek miatt többféle típusú router vesz részt, melynek az osztályozása a következő [7.1.5]: területen belül működő router (IR, Internal Routers); terület határán működő router (ABR, Area Border Router); gerinchálózatban működő router (BR, Backbone Router); AS határon működő router (ASBR, Autonomous System Border Router).
8.1.11. ábra: Az OSPF protokollban működő routerek szemléltetése. A területeken belül található egy Designated Router (továbbiakban: DR), mely az OSPF forgalomirányítási információk központi elosztója. A DR mellett kiválasztásra kerül egy
35
Backup Designated Router (továbbiakban: BDR), mely figyeli a DR állapotát, és meghibásodása esetén átveszi a szerepét. A területen belül található routereken beállítódik az OSPF folyamat prioritása és a router ID azonosítója, melyek által a DR és BDR kiválasztási folyamatban szerepet játszanak. A DR és BDR routereknek köszönhetően az OSPF területen belül generált adatforgalom minimális lesz, az útválasztók csak a DR és BDR routerekkel építenek ki szomszédsági viszonyt. Az OSPF területek a határán található ABR-ek az LSDB-ből (Link State database) nem a teljes routing információt osztják meg a velük szomszédos területekkel, hanem az LSU (Link State Update) csak egy összegzett IP címet és alhálózati maszkot tartalmaz. Minden terület saját, egyedi Dijkstra algoritmust futtat, és a terület térképe nem lesz megosztva más területekkel. A területekre való bontással az OSPF egy nagyon jól skálázható, hatékony forgalomirányító protokollá vált, amit nagyobb hálózatokban gyakran alkalmaznak. A telephelyen az OSPF protokollt alkalmazzuk az eszközökön. Kisebb irodák esetében EIGRP protokollt használunk. Kijelenthetjük, hogy nagyobb vállalatoknál hasznos az OSPF protokoll használata. Minden alhálózat egy külön OSPF területet képvisel, és ezeknek a megosztása történik a protokollban.
2.5.5. SSH és HTTPS protokoll alapú hozzáférés eszközeinkhez A hálózati eszközökön SSH és https protokollok vannak csak engedélyezve. Ez feltétlen szükséges, hiszen ha Telnet vagy http protokollokat használnánk, egy lehallgatásos támadás esetén a támadó minden forgalmat képes lenne figyelni. Így SSH és https alapú menedzsmentet lett kialakítva, a titkosítás és biztonság maximalizálása érdekében. Mint ahogy majd a következő nagyobb, 2.6.-os fejezetben bemutatom, a titkosított kapcsolaton keresztül érjük el és menedzseljük eszközeinket. Eszközeinket CLI-n (Command Line Interface) keresztül menedzseljük. Speciális eszközök esetében (például WLC-knél) https protokollon keresztül történik a hozzáférés. A biztonságos menedzsmenthez szükséges beállításokat a következő fejezetben fogom tárgyalni, példák segítségével.
36
2.6. Hálózati eszközeink biztonságos menedzsmentje 2.6.1. Biztonságos menedzsment garantálása A hálózati eszközökön múlt év decemberében egységesítettük a menedzselés során használt protokollt, és fixáltuk, hogy mely biztonságos alhálózatokból legyen lehetséges a hálózati eszközök menedzselése. Ezt a szerepet látja el a 100-as ACL / Filter List, és a biztonságos menedzsmentet az SSH protokoll 2. verziója garantálja. Előfeltétel Cisco eszközökön, hogy a használt image fájl K9-es legyen. A Juniper eszközök általában kompatibilisek A továbbiakban szeretném bemutatni, hogyan állítottuk be az SSH konfigurációt Cisco és Juniper eszközökön. A 8.2.8.-as képen látható módon leellenőrizzük az eszköz IOS verzióját, és képfájlt. Szükséges, hogy K9-es legyen a képfájl, hogy az SSH protokoll 2. verziója támogatva legyen.
8.2.8. kép: Az eszközön futó IOS verzió és képfájl ellenőrzése.
A 8.2.9.-as képen szerint megfelelő erősségű RSA kulcsot generálunk, és az SSH v2 protokollt aktiváljuk az alapértelmezett beállításokkal.
8.2.9. kép: RSA kulcs generálása és az SSH protokoll aktiválása konfigurációs módban.
A 8.2.10.-es kép konfigurációja alapján alkalmazzuk a 100-as ACL-t a 0-4-es VTY vonalakon bejövő forgalomra, és teszteljük az SSH protokollal. Ha sikeres a teszt, letiltjuk a Telnet protokollt, és az 5-15-ös VTY vonalakon történő bejelentkezés.
37
8.2.10. kép: A 0-4-es VTY vonalakon az SSH protokoll aktiválása, majd tesztelés után kikapcsolása; és az 5-15-ös VTY vonalak deaktiválása (konfigurációs részlet).
Juniper eszközökön ugyanez a Shell-szerű környezet miatt ez sokkal gyorsabb lesz. A „commit confirmed” parancs segítségével van 10 percünk, hogy a beállításokat. Ha nem, az idő lejárta után az eszköz visszaállítja az eredeti konfigurációt. Ha a bejelentkezés megfelelően működik, a „commit” paranccsal tudjuk véglegesíteni az új konfigurációt. A 8.2.11.-es képen látható konfigurációval, edit módban egyszerűen aktiválható az SSH protokoll.
8.2.11. kép: A fent alkalmazott SSH konfigurációk alkalmazása Juniper eszközökön.
A 100-as Menedzsment ACL / Filter List tartalma nem megosztható, hiszen biztonsági szerepet lát el, megosztása érzékenyen érintené a telephely hálózati eszközeinek biztonságát. Ezen konfigurációk alkalmazása mellett minden eszköz biztonságosabbá tehető, és alapvetően számít. Az SSH protokollnak köszönhetően az eszközök menedzselése titkosított, biztonságos.
2.6.2. A TACACS+ rendszer bemutatása A Terminal Access Controller Access Control System Plus protokoll a Cisco által fejlesztett, az eredeti TACACS (Terminal Access Controller Access Control System, [16]) AAA rendszer utódja [41]. Egy hozzá hasonló protokollt, a RADIUS-t a 2.2.1.-es fejezetben ismertettem. A 38
TACACS+ a TCP (Transmission Control Protocol, [17]) csomagokat használja kommunikáció során UDP helyett, így biztosítva a csomagok küldésének felügyeletét és irányítását. A TACACS+ az ACS szervereink része. A TACACS+ segítségével regisztráljuk a hálózati adminisztrátorokat, hogy hozzáférést nyújtsunk nekik az eszközökre való bejelentkezéshez. A TACACS+ segítségével akár felhasználókat is hitelesíthetnénk a WLAN hálózaton, viszont manapság már elavult és ritkán használt protokoll, így a RADIUS-t használjuk erre a célra. A TACACS+ mind Cisco, és Juniper eszközök által támogatottságot élvez. A TACACS+ megfelelő beállítása után az eszköz az ACS szervereken regisztrálódik, és használhatja az adatbázist a hitelesítésére. Hasznos protokoll, viszont egy új építésű hálózatban nem hatékony manapság alkalmazni.
2.6.3. A hálózat monitorozása syslog segítségével A syslog az 1980-as években a Sendmail projekt keretein belül lett fejlesztve először [43]. A syslog protokoll az IETF (Internet Engineering Task Force) által lett standardizálva az [RFC5424]-ben [19], 2009 márciusában. A protokoll széleskörűen elterjedt üzenő szolgáltatás: különböző események hatására, bekövetkezésére küld ki üzeneteket strukturált formában. Nagyon sok eszköz és szoftver használja manapság (switchek, routerek, nyomtatók, szerverek, alkalmazások, csak hogy néhány fontosabb példát említsek). A syslog protokoll UDP szállítás rétegbeli protokollt használ, és az 514-es porton fogadja az üzeneteket a syslog szerver alapértelmezetten [2, 3]. A syslog üzenet két részből tevődik össze: egy területi kód, mely meghatározza, melyik alkalmazás küldte el a syslog üzenetet ([RFC3164] határozta meg a listát – [18]), és egy fontossági kód, mely meghatározza a hiba vagy esemény súlyát. A fontossági kód osztályozása 0-tól 7-ig terjed, és minél kisebb a kód, annál nagyobb a probléma [3]. A két kódnak megfelelően az üzenetet a syslog szerver kezelni képes előre beállított szabályok, kritériumok alapján kezelni. Fontos, hogy a megfelelő kódokra megfelelő cselekvés váltódjon ki; például egy magasabb szintű syslog üzenet esetén (4-es kód alatt) ügyeletes értesítés legyen kiküldve. A 8.3.3.-as táblázatban bemutatom a syslog üzentek kódjait, az adott kódhoz tartozó fontossági szintet, a kulcsszavát, és az szint jelentését [42].
39
Kód 0 1 2 3 4 5 6 7
Fontosság Kulcsszó Érték jelentése vészhelyzet emerg A rendszer használhatatlanná vált. riasztás alert A rendszer azonnali javítása szükséges. kritikus crit Kritikus szintű esemény következett be. hiba err Hiba szintű esemény következett be. figyelmeztetés warning Később hibához vezethető esemény történt. megjegyzés notice Szokatlan esemény következett be. információ info Normális működés közbeni üzeneteket jelöli. debug debug Csak a fejlesztőknek szánt üzeneteket jelöli.
8.3.3. táblázat: A syslog protokoll kódjai, azok fontossága, kulcsszava, és az értékük jelentése.
A globális hálózatban két syslog szerver üzemel: a SolarWinds Orion platform syslog szervere és a Splunk. Az Orion a beállított, elsődleges syslog szervere, a Syslog Viewer kezeli a syslog üzeneteket és fontosságuknak megfelelő riasztásokat küld ki a hálózati adminisztrátoroknak az üzenet beérkezésekor azonnal. A 8.2.12.-es képen láthatjuk, ahogy valós időben érzékeli a syslog üzeneteket a SolarWinds Orion Syslog Viewer programja.
8.2.12. kép: Az Orion Syslog Viewer program valós időben érzékelt syslog üzenetekkel.
40
Az Orion syslog szervere a beérkezett üzeneteket egyenesen továbbítja a Splunk szerver felé. A Splunk Inc. által fejlesztett Splunk platform felel a syslog üzenetek hosszú távú tárolásáért és archiválásáért. A Splunk segítségével biztonságos HTTPS kapcsolaton keresztül az összes eddigi syslog üzenethez hozzáférhetünk, kereshetünk régebbi üzeneteket az archívumában. A syslog üzenetek által történő monitorozás az elsődleges módszer hálózati eszközeink monitorozására, és megfigyelésükre. A SolarWinds Orion segítségével teljesen testre szabható riasztásokat vagyunk képesek létrehozni: például egy kritikusabb syslog üzenet esetén a riasztásban az eszköz adatait és állapotára vonatkozó információkat is csatolhatunk a syslog üzenet mellett. A syslog üzenetek mellett az SNMP protokoll segítségével is lehetséges a hálózat monitorozása, viszont mi azt alapvetően csakis menedzselési célokból használjuk.
2.6.4. Az SNMP protokoll használata a hálózatban Az eszközökön az SNMP v2c (Single Network Management Protocol v2c, [20]) protokoll van engedélyezve. Az SNMP protokollt hálózaton található eszközök menedzselésére használjuk [44]. Alkalmazás rétegbeli protokoll, mely szerver – kliens felépítésű. A 161-es UDP portot használja a szerver SNMP kérések fogadására, küldésére, a 162-es UDP portot a trap üzenetek fogadására. Négy részből áll:
Menedzselt eszköz;
Agent – szoftver, mely a menedzselt eszközön fut;
Network management station (NMS) – Manager, mely az SNMP kezelő szerveren fut;
Management Information Base (MIB) – adatbázis, mely megtalálható a menedzselt eszközön, és az SNMP kezelő szerveren.
A menedzselt eszközökön a konfigurált agent segítségével az NMS-nek egyirányú (csak olvasási) vagy kétirányú (olvasási és írási) jogosultsága van. Az Agent és Manager GET – SET kérésekkel és válaszokkal kommunikálnak egymásnak. Az Agent – ha konfigurálva van – képes Trap (csapda) üzeneteket küldeni bizonyos események bekövetkeztekor, melyet az SNMP kezelő szerver detektál (UDP 162-es porton). Minden eszköznek van egy eszköz azonosítója (Object ID) az MIB-ban, amivel az Manager és az Agent is rendelkezik. Ezen az OID-n keresztül éri el az eszköz Agent-jét a Manager
41
szoftver, és a menedzselt eszköz az MIB-ban tárolhat bizonyos adatokat és beállításokat, melyeket a Manager képes kiolvasni (például processzor és memória kihasználtság, hőmérsékleti szintek) [45]. A hálózatban jelenleg két SNMP szerver van használatban: a SolarWinds Orion, és egy tartalék szerver. Az SNMP protokollt hálózati eszközök menedzselésére használjuk az Orion segítségével (bejelentkezés konfigurációk lementéséhez, nyers adatok összegyűjtése, scriptek végrehajtása), kritikus hibák monitorozását pedig a syslog üzenetek figyelésével tesszük. Az Orion segítségével lehetséges automatizált változtatásokat végrehajtani SNMP protokollal való bejelentkezés segítségével az eszközökön. Ez is egy nagy előnye a protokollnak, hiszen beavatkozás nélkül képesek vagyunk az Orionon keresztül automatizáltan változtatásokat végrehajtani a hálózati eszközökön.
2.6.5. A SolarWinds Orion platform A SolarWinds Orion platformot használjuk elsődlegesen a hálózati eszközök állapotának monitorozására. A SolarWinds Orion a SolarWinds Inc. által készített platform, melyhez több beépülő modult van lehetőségünk vásárolni a platform tudásának bővítésére. Mi az NPM, NCM, NTA modulokat használjuk. A SolarWinds Orion a hálózati eszközöket monitorozza általánosságban SNMP v2c protokollal történő bejelentkezéssel, és Syslog üzenetek figyelésével (ezek az előző bemutatásra kerültek). Az alap modul, melyet a SolarWinds Orion platformhoz kaptunk az a Network Performance Monitor (NPM). A modul a következő feladatokat látja el: Monitorozott eszköz válaszideje és csomagvesztesége; Eszköz interfészeinek figyelése, áthaladó forgalom terheltségének monitorozása; SNMP v2c monitorozás esetén az eszköz állapotának lekérdezése (CPU, RAM, stb.); A másodlagos modul, az a Network Configuration Management (NCM). A modult elsősorban az eszközök konfigurációjának monitorozására használjuk, de más célokat is ellát: Eszközök és erőforrások figyelés, riasztások küldése probléma esetén; Eszközökről való konfigurációk mentése (startup – running) naponta; Konfigurációs változás érzékelése valós időben (Real Time Change Detection); Megírt konfigurációk vagy scriptek lefuttatása az NCM által monitorozott eszközökön;
42
Problémás konfigurációval rendelkező eszközök kimutatása (compliance report készítés). Az eszközökről az NCM a syslog üzenetek által érzékeli, hogyha változás következik be legyen az egy konfigurációs változás, dedikált vonalon érzékelt hiba, vagy interfészen történt változás. A problémás konfigurációval rendelkező eszközökről egy jelentést képes készíteni, aminek a feltételeit mi szabjuk meg mintaillesztések alapján. A NetFlow Traffic Analyzer (NTA) modul az eszközökről érkező NetFlow csomagokat elemzi, grafikus felületen megjeleníti, és az Orion SQL adatbázisában eltárolja. Ennek segítségével monitorozni tudjuk hálózatunk terheltségét, és nagyobb terhelés esetén az adott irodában lévő, infrastruktúrában dolgozó kollégákat értesíteni az internet és dedikált vonal terheltségéről.
43
3. A hálózat tesztelése 3.1. A tesztelések és mérések célja, áttekintése A debreceni telephelyen elvégzett tesztelésekkel, mérésekkel szerettem volna a hálózat állapotát megvizsgálni, gyengeségekre és sebezhetőségekre fényt deríteni. Általános méréseket és biztonsági teszteléseket végeztem az eszközökön. A 3.3-as fejezetben általános teszteléseket, méréseket végeztem: először megvizsgáltam az eszközök fizikai védelmét (mint például a helységeket, az eszközökön engedélyezett portokat), vezetékes és vezeték nélküli hálózaton méréseket végeztem mind sebesség, mind minőség szempontjából. A 3.4-es fejezetben az internet és WAN vonalakon végeztem méréseket. Az internetvonal sebességét mértem két napon, munkaidőben és munkaidőn kívül hat percenként, egy órán át, tíz mérést elvégezve. A WAN vonalakon végzett mérések során azoknak a terheltségét vizsgáltam, a „follow-the-sun” időpontokban, tehát a műszakváltásnál Penang - Debrecen, és Debrecen – Austin időpontjai alatt. A 3.5-ös fejezetben általános biztonsági teszteléseket végeztem: MAC elárasztásos és DHCP kiéheztetéses támadást szimuláltam; hamis DHCP szervert állítottam be a hálózatra; egy Rogue AP-t üzemeltem be. Port letapogatást végeztem a Distribution rétegben található hálózati eszközökön. A teszteléseket biztosított környezetben, engedéllyel hajtottam végre. A mérésekről részletes dokumentáció készült, mely a szakdolgozatomban és a mellékletekben megtekinthető. A tesztelések, mérések során semmi problémát nem tapasztaltam, minden rendben történt. A tesztelések, mérések során használt eszközöket a következő fejezetben kívánom bemutatni.
44
3.2. A mérésekhez, tesztelésekhez használt eszközök 3.2.1. Fluke Networks AirMagnet Spectrum XT adapter A Fluke Networks által kifejlesztett AirMagnet Spectrum XT RF spektrum analizátort és vele működő programok segítségével végeztem méréseket a WLAN hálózaton. Több mérésre is sor az eszközzel. Egy hétig volt alkalmam használni az eszközt, elvégezni a méréseket. Az eszközt egy kisebb méretű laptoppal, és egy extra WiFi-s adapterrel kaptuk meg előre telepítve a szükséges programokkal (az extra adapter az IEEE 802.11a sávot képes felismerni).
8.2.13. kép: A WLAN hálózat teszteléséhez használt eszközök.
8.2.14. kép: AirMagnet Spectrum XT RF spektrum analizátor USB adaptere
45
Három programot használhattunk az adapterrel: AirMagnet WiFi Analyzer PRO, AirMagnet Survey PRO, AirMagnet Spectrum XT. Ezen programokból az AirMagnet WiFi Pro, és AirMagnet Spectrum XT programokkal végeztem méréseket. A Survey Pro programhoz szükséges feltölteni az épület alaprajzait, bejelölni a hozzáférési pontok helyét – majd felmérést végezni, körbejárni az eszközökkel, hogy elkészítse a részletes felmérést. A mérések során az eszköz által mért átlagos eredményeket fogom bemutatni, reprezentálni, mert konkrét, numerikus kimutatást a mérésekről nem tudott készíteni.
3.2.2. SolarWinds Orion NTA NetFlow modul Mint ahogy a 2.6.5.-ös fejezetben bemutattam, a SolarWinds Orion platform NTA modulja képes a NetFlow adatok fogadására hálózati eszközeinkről, összegyűjtve őket, letárolva az SQL szerverben, majd gráf formájában megjelenítve az interfész adatlapján.
8.2.15. kép: Az Orion NTA moduljának a kezdőoldalon elhelyezett áttekintő doboza.
Az NTA Modul doboza (8.2.15. kép) az Orion kezdőoldalán tudatja a felhasználókkal, hogy a megfigyelt interfészek közül (ahol az „ip
flow egress / ip flow ingress" parancs konfigurálva
az interfészen) melyek azok, melyeken erősebb terhelés tapasztalható. Ez hasznos, hiszen azonnal láthatjuk, hogy hol tapasztalható nagyobb terhelés a globális hálózatban. Minden megfigyelt interfész rendelkezik egy NetFlow adatlappal, melyen az Orion valós időben képes megmutatni, hogy mely végpontok terhelik a kapcsolatot, IP cím szerint. Az
46
eszközök DNS nevét IP cím alapján DNS lekérdezéssel meghatározza, és feltünteti. Minden végpont egy külön színt fog a kirajzolt grafikonon használni. A végpont DNS neve alapján azonosíthatóvá válik az eszközt használó végfelhasználó, aki a kapcsolatot terheli.
8.2.16. kép: Az NTA modul által generált NetFlow grafikon az egyik MPLS vonalunkról.
A 3.4.2.-es: „A WAN kapcsolatokon végzett mérések” fejezetben az NTA által generált grafikonokat használtam a méréseknél, leolvasva a bizonyos időpontok során mért terheltségi adatokat a grafikonról. Egy ilyen grafikon a példája a 8.2.16.-os képen megtekinthető. Természetesen a méréshez használt grafikonok megtekinthetőek a szakdolgozat csatolmányai között.
47
3.2.3. Dell AirWave Wireless Monitoring eszköz A Dell AirWave Wireless Monitoring a vezeték nélküli hálózatot monitorozó eszköz, mely globálisan monitorozza vezeték nélküli eszközöket: hozzáférési pontokat, és WLC-ket például. A platform képes nyilvántartani a vezeték nélküli hálózat topológiáját, teljesítményét, lefedettségét, jelerősségét, interferenciáját. Továbbá a vezeték nélküli hálózat biztonságát is figyeli: képes kiszűrni a működő Rogue Access Point-okat. A biztonsági tesztelések során a Rogue AP-k felismerését vizsgáltam az eszközzel. A detektálás során meghatározza a paramétereit (SSID, WLAN/LAN MAC Address, jelerősség, titkosítás megléte/típusa), és hogy pontosan hol csatlakozik az eszköz a vezetékes hálózathoz. A paraméterekre alapozva szeretném bemutatni azt az eszközön, hogy milyen gyorsan és mekkora hatékonysággal képes detektálni a tesztelés során használt vezeték nélküli routeremet, melyet rogue AP-ként használok majd a 3.5.2.-ös fejezetben. A következő fejezetben a vezeték nélküli routert is be fogom mutatni, mint teszteléshez használt eszközt.
3.2.4. Biztonsági tesztelésekhez, mérésekhez hálózati eszközök A 3.5.1.-es „MAC elárasztásos és DHCP kiéheztetéses támadás szimulálása” című fejezetben egy már nem használt, leselejtezett egy Catalyst 2960-as sorozatú, WS-C296024TT-L típusú switch hajtottam végre a tesztelést. Az eszköz („deb-test-switch” nevet kapta). Az eszközre a helyi IDF-ben található Access rétegbeli switch konfigurációját másoltam le, ezzel implementálva a szükséges tesztkörnyezetet (Acc01-035-BLD3). Természetesen a konfigurációba nem emeltem át érzékeny adatokat, így ez megoszthatóvá vált, és a szakdolgozat csatolmányában megtekinthető.
8.2.17. kép: 3.5.1.-es biztonsági tesztelésnél használt switch specifikációja.
A 3.5.2.-es „Hamis DHCP szerver felállítása” és a 3.5.3-as „Rogue AP-k elleni védelem” című fejezetekben saját vezeték nélküli routeremet használtam, mely egy TP-Link WR841ND 48
típusú vezeték nélküli router, OpenWrt 15.05 Chaos Calmer verziójú operációs rendszerrel. Egyszerre funkcionál switchként, routerként, hozzáférési pontként, és DHCP szerverként (allin-one eszköz). A rádiójának „OpenWrt” SSID-t állítottam be, WPA2 PSK titkosítású jelszavas védelemmel. Ezzel lehetővé tettem, hogy DHCP szerverként és Rogue AP-ként funkcionáljon. A pontos beállításokról a fejezetekben kívánok többet beszélni.
8.2.18. kép: A teszteléshez használt vezeték nélküli router – TP-Link WR841ND
A 3.5.4.-es „Port letapogatás hálózati eszközeinken” és a 3.5.1.-es „MAC elárasztásos és DHCP kiéheztetéses támadás” fejezetekben Xubuntu 14.04.3 LTS operációs rendszert használtam. A virtuális hálózati kártyát bridging segítségével kötöttem össze a fizikai Ethernet porttal. Rajta futtattam az „macof” és „nmap” parancsokat. A „macof” a dsniff csomag része, és a „sudo
apt-get install dsniff”
paranccsal lehet a
csomagot letölteni. Továbbá a 3.3.2.-es „Belső vezetékes hálózat sávszélességének felmérése” című fejezetben a rendszer lemezképét használtam a mérések elvégzésére. Root jogosultság szükséges a futtatásához. Az „nmap” eszköz a GNU\Linux disztribúciójú operációs rendszerek részét képezik, megtalálhatóak alapértelmezetten a rendszerben. Mint a macof esetében is, itt is root jogosultság szükséges a futtatásához.
49
8.2.19. kép: A 3.5.1.-es és 3.5.4.-es fejezetekben használt Xubuntu operációs rendszer specifikációja.
50
3.3. Általános hálózati mérések 3.3.1. A hálózati eszközök fizikai védelmének vizsgálata Amikor hálózati eszközök védelméről beszélünk általánosságban, a szoftveres védelemre gondolunk. Viszont az eszközök fizikai védelmét sem szabad elhanyagolni, hiszen ez legalább olyan fontos, mint maga a szoftveres védelem megléte [46]. Többféle módon kell biztosítani az eszközök védelmét: Légkondicionált, elektromágneses interferenciától védett helységben kell elhelyezni; Redundáns, szünetmentes (UPS) áramforrást kell szolgáltatni; A fizikai hozzáférését biztosító interfészeket (aux, konzol portok, stb.) védeni kell; Zárt helyiségben kell őket tárolni, amihez csak a meghatalmazottaknak van hozzáférése. A telephelyen minden IDF és MDF szoba légkondicionált, megfelelően árnyékolt (elektromágnesesség és interferencia ellen), és redundáns áramforrással rendelkezik. Egy esetleges áramkimaradás esetén a szünetmentes tápegységek átveszik az eredeti áramforrás szerepét addig, míg a kinti generátorok be nem kapcsolnak. A helységekbe csak a megfelelő jogosultságú embereknek van belépési joga, melyet általában az adott személy badge kártyájával lehet kinyitni. A konzol portok megfelelően vannak védve jelszóval, és a nem szükséges portok le vannak tiltva az eszközökön. Az eszközökhöz hiba esetén távoli hozzáférést biztosító PC-k és laptopok megfelelő tároló szekrényekben vannak elhelyezve. Az eszközök biztosított, megfelelő felszereltségű helységekben vannak elhelyezve.
3.3.2. Belső vezetékes hálózat sávszélességének felmérése A következő egyszerű teszt során az intranet által nyújtott belső sávszélességet teszteltem. A teszteléshez használt fájl 3.2.4.-es fejezetben bemutatott Xubuntu virtuális rendszer 4 GB-os méretű lemezképe volt. Az egyik helyi fájlszerverre töltöttem fel és le a Windows Intézőjével. Összesen tíz mérést végeztem (öt letöltési, és öt feltöltési tesztet). Mivel egy nagyméretű fájlt használtam, mely egy SSD meghajtóról volt feltöltve és letöltve a szerverre (mely RAID5 tömböt használ), így a szűk keresztmetszet a belső hálózati sebesség volt. A méréseket
51
dokumentáltam képernyőmentésekkel, és táblázatban foglaltam össze az értékeit. Az értékek másodpercenként mért megabájt (MB/s) sebességben értendőek. Feltöltési sebesség
Letöltési sebesség
1. mérés
112,00
110,00
2. mérés
112,00
111,00
3. mérés
112,00
109,00
4. mérés
112,00
110,00
5. mérés
112,00
110,00
Mérések átlag
112,00
110,00
8.3.4. táblázat: A belső vezetékes hálózaton mért letöltési és feltöltési sebességek.
Mint láthatjuk, a belső hálózaton való feltöltés és letöltési sebességek átlaga kielégítőek – 112 MB/s feltöltési, és 110 MB/s átlagos letöltési sebességek. Ez az elvárható a gigabites belső hálózati sebességtől. A le- és feltöltési sebességek a teszt során konstansak voltak, néha ingadozás volt tapasztalható. Ezek az ingadozások elhanyagolható mértékűek voltak, pár másodpercig álltak fenn. asdasd
3.3.3. A WLAN hálózat tesztelése A WLAN hálózat tesztelésénél következő szempontokat vettem figyelembe: a csatornák terheltségét, és a hozzáférési pontok jelerősségét. Sajnos numerikus formában nem tudták a méréseket végző programok (AirMagnet WiFi Pro, és AirMagnet Spectrum XT) dokumentálni a mérések eredményét, így a mérések során készített képernyőmentéseket fogom bemutatni, melyek átlagosan mutatják az adott területen tapasztalt eredményeket. Az eszközökkel a felmérés a következő módon zajlott: az épületek (BLD1, BLD2, BLD3) emeleteit és a gyártósor területét bejártam a 3.2.1.-es fejezetben bemutatott teszteszközökkel, az élőben kijelzett mérési adatokat rögzítettem képernyőmentések formájában. Igyekeztem a forgalmas és távoli helyeket is meglátogatni, hogy fény derülhessen arra, hogy tapasztalható-e interferencia és hiány a jelerősségben.
52
A felső grafikonon a csatornák a terheltségét, míg az alatta lévő grafikon a hozzáférési pontok által sugárzott csatornák erejét mutatja. Néhány grafikon kerül bemutatásra, melyek általánosságban jellemzik az épületek és a gyártósor területén mért eredményeket.
8.2.20. és 8.2.21. kép: BLD1-ben és 2-ben a mérés során rögzített adatok, grafikonok.
8.2.22. és 8.2.23. kép: BLD3-ban és a gyártósor területén a mérés során rögzített adatok, grafikonok.
53
A grafikonokon látható adatok az adott épületekben és a gyártósoron mért eredményeket tükrözik. A mérés során tapasztaltam, hogy mindenhol egyenletes volt a WLAN hálózat lefedettsége, jó térerősséggel, és minimális interferenciával. A forgalmasabb helyeken, ahol több ember található és több Access Point működik, ott magasabb volt az interferencia az átlagosnál, de ez el is várható. Az elmúlt időszakban végrehajtott fejlesztések a WLAN hálózatban megtették hatásukat, ott ahol régebben rossz teljesítmény volt tapasztalható, manapság már nincs panasz. A mérés zárásaként elmondható, hogy a WLC jól működik, és megfelelően rendeli ki a csatornákat az egyes hozzáférési pontokhoz, ezzel minimalizálva az esetleges interferenciát a telephely területén található hozzáférési pontok között.
54
3.4. Az internet és WAN vonalak vizsgálata 3.4.1. Az internetvonal tesztelése Az internetvonalon végzett tesztelés során annak sebességét vizsgáltam. A méréseket az Ookla Speedtest sebességmérőjével végeztem [47]. Négy mérési időszakon keresztül végeztem méréseket, amelyek eredményét táblázatokban dokumentáltam. Egy mérési időszak alatt a vonal sebességét mértem egy órán keresztül, hat percenként mérést végezve. A mérési időszakot két napon ismételtem meg, kétszer délelőtt, kétszer este: délelőtt, munkaidőben 10.00-11.00 között; este, munkaidőn kívül 19.00-20.00 között. A mérés során a várható értékeket, szórásokat, és szórásnégyzeteket meghatároztam. A dokumentációt (a mérések során kapott eredményeket, a táblázatokat) csatoltam a szakdolgozat mellékletéhez. A táblázat mértékegységei Megabit másodpercenként (Mbps) sebességben értendők.
10.00 - 11.00 Letöltési Feltöltés sebesség sebesség
19.00 - 20.00 Letöltési Feltöltés sebesség sebesség
1. mérés
323,45
391,33
380,13
391,96
2. mérés
330,92
392,24
382,45
394,45
3. mérés
318,50
391,71
379,69
394,29
4. mérés
322,42
392,01
383,57
393,30
5. mérés
328,99
395,37
373,47
395,45
6. mérés
332,07
392,91
375,14
390,71
7. mérés
328,09
389,38
385,76
393,23
8. mérés
316,86
389,01
373,18
399,05
9. mérés
327,98
392,19
375,39
395,36
10. mérés
321,45
391,16
373,52
392,81
Várható Érték
325,07
391,73
378,23
394,06
Szórás
5,27
1,78
4,68
2,29
Szórásnégyzet
27,72
3,18
21,86
5,24
8.3.5. táblázat: az első napon munkaidőben és munkaidőn kívül mért sebességek.
55
10.00 - 11.00 Letöltési Feltöltés sebesség sebesség
19.00 - 20.00 Letöltési Feltöltés sebesség sebesség
1. mérés
327,21
385,30
377,76
393,07
2. mérés
302,16
385,90
382,32
395,29
3. mérés
312,92
380,53
376,92
394,16
4. mérés
315,10
385,44
360,89
395,23
5. mérés
309,83
385,72
354,46
397,90
6. mérés
317,23
389,34
356,00
395,88
7. mérés
328,30
385,53
381,39
396,78
8. mérés
312,76
384,94
348,71
394,17
9. mérés
338,63
387,36
348,89
389,10
10. mérés
343,28
390,80
357,13
394,26
Várható Érték
320,74
386,09
364,45
394,58
Szórás
13,17
2,75
13,61
2,39
Szórásnégyzet
173,37
7,57
185,14
5,69
8.3.6. táblázat: az második napon munkaidőben és munkaidőn kívül mért sebességek.
A mérési periódusok során kapott eredmények a valóságot tükrözik. A vonal mindennapos használatakor felhasználói szempontból nincs teljesítménybeli probléma, jó minőségű sebességet nyújt. A fennmaradó átlagos letöltési és feltöltési sebességek felhasználók számára tökéletesen elég. Az, hogy nem értem el sosem a 400 Mbps sebességet a mérések során a háttérben folyó replikációs folyamatokkal magyarázható, mint ahogy a 2.2.1.-es fejezetben bemutattam (Office 365, Panzura szolgáltatások például).
3.4.2. A WAN kapcsolatokon végzett mérések Hasonlóan az internetvonalon végzett mérésekhez, a WAN kapcsolatok mérésénél azok terheltségét mértem, a SolarWinds Orion által rögzített NetFlow adatok segítségével. A két WAN kapcsolaton, két különböző napon (2015. 11. 13. és 2015. 11. 16.) végeztem méréseket, délelőtt 9 – 10 óra, és délután 16 – 17 óra között (UTC+1, Budapest időzóna szerint). Mint
56
ahogy az internetkapcsolaton történt mérések során, itt is tíz mérést végeztem egy óra alatt, hat percenként. Azért ezt a két időpontot választottam, mert ilyenkor a „follow-the-sun” elv szerint, ezen időpontokban történik meg Penang – Debrecen, és Debrecen – Austin között a műszakváltás. A mérések dokumentációja (a táblázatok, és a SolarWinds Orion által generált NetFlow gráfok) megtekinthető a szakdolgozat mellékletében, és a csatolmányok között. A táblázat mértékegységei Megabit másodpercenként (Mbps) sebességben értendők.
1. Nap 9.00 - 10.00
2. Nap
16.00 - 17.00
9.00 - 10.00
16.00 - 17.00
Bejövő Kimenő Bejövő Kimenő Bejövő Kimenő Bejövő Kimenő
1. mérés
0,00
1,55
8,53
1,87
3,30
5,53
4,10
2,38
2. mérés
0,29
2,71
0,88
2,12
3,80
1,92
3,56
1,85
3. mérés
0,00
2,93
1,66
2,59
4,40
2,17
5,39
2,48
4. mérés
0,76
3,15
1,53
4,79
3,46
1,45
6,58
1,30
5. mérés
0,85
3,61
2,33
5,94
3,45
1,69
9,02
3,75
6. mérés
0,78
3,96
1,74
2,10
3,73
1,71
6,20
2,25
7. mérés
0,52
3,76
3,15
2,82
3,64
1,68
5,46
2,19
8. mérés
0,65
1,64
2,42
2,93
4,05
3,27
6,42
1,55
9. mérés
0,55
5,33
1,65
2,36
5,02
1,75
5,50
1,78
10. mérés
0,43
1,60
1,98
2,77
6,10
3,03
5,09
1,82
Várható érték
0,48
3,02
2,59
3,03
4,17
2,42
5,77
2,14
Szórás
0,31
1,22
2,18
1,31
0,89
1,25
1,59
0,68
8.3.7. táblázat: Az első WAN vonalon (deb-gw-mpls-bld1) végzett mérések, két napon, délelőtt és délutáni időszakban.
A mérések során első WAN vonal (deb-gw-mpls-bld1) terhelése alacsony volt: ritkán érte el a terhelés az 5 Mbps sebességet. Láthatunk néha megemelkedett terheltséget, ilyenkor burstszerű forgalom volt tapasztalható (magas terheltség rövid ideig).
57
1. Nap 9.00 - 10.00
2. Nap
16.00 - 17.00
9.00 - 10.00
16.00 - 17.00
Bejövő Kimenő Bejövő Kimenő Bejövő Kimenő Bejövő Kimenő
1. mérés
2,20
0,12
3,30
3,14
1,45
0,56
1,12
1,87
2. mérés
1,27
0,11
2,79
2,94
3,94
0,62
1,62
0,35
3. mérés
8,87
0,95
5,81
3,03
3,72
0,60
2,87
0,17
4. mérés
0,78
1,34
5,20
3,59
1,42
0,33
3,54
0,29
5. mérés
1,84
1,17
5,51
3,16
2,62
1,07
8,50
0,25
6. mérés
1,19
2,44
6,57
3,37
0,78
0,72
7,96
0,25
7. mérés
3,08
5,81
2,62
4,79
1,81
1,21
2,85
0,99
8. mérés
0,68
1,44
2,29
13,54
0,56
0,51
2,84
1,38
9. mérés
2,56
3,10
2,17
0,92
1,03
2,52
3,92
0,90
10. mérés
0,94
5,13
1,84
5,07
1,82
1,85
1,11
0,70
Várható érték
2,34
2,16
3,81
4,36
1,92
1,00
3,63
0,72
Szórás
2,43
1,97
1,77
3,42
1,17
0,70
2,60
0,57
8.3.8. táblázat: A második WAN vonalon (deb-gw-mpls-bld3) végzett mérések.
A második WAN vonalon (deb-gw-mpls-bld3) végzett mérések is alacsony terhelést mutattak, itt is ritkán érte el a vonal terheltsége az 5 Mbps sebességet, olyankor burst-szerű forgalom volt tapasztalható. Az esti és hajnali órákban történnek az automatizált mentési folyamatok, így a vonalak nagyobb terheltséget mutatnak. Természetesen ilyenkor normál munkaidőn kívül vagyunk, így a mentési folyamatok futtatása megengedett (például a Dell NetVault mentési folyamatok az európai régióban). A méréseket ezen időszakban nem végeztem el, érdekességnek említettem meg. A tesztek mutatják, hogy a két 40 Mbps sebességű WAN vonal kiszolgálja az igényeket, és az alapvető terhelési időszakokban (régiónkénti műszakváltásnál) sincs erőteljesebb terhelés a vonalakon.
58
3.5. Biztonsági tesztelések 3.5.1. MAC elárasztásos és DHCP kiéheztetéses támadás szimulálása A switchek a CAM (Content Address Memory) táblában tartják nyilván, hogy portjaikon keresztül milyen MAC címeket (eszközöket) érnek el. A switch képes arra, hogy a címzettnek unicast üzenet formájában juttassa el az Ethernet kereteket a megfelelő porton keresztül. A hub viszont a kapott keretet az összes portján keresztül broadcast üzenet formájában továbbítja. A támadó a switch CAM tábláját megtelíti hamis MAC címekkel. A switch hubként kezd el funkcionálni, a rendes üzenetek címzettjeit nem tudja megtalálni a CAM táblában, a kereteket unicast üzenetként az összes porton keresztül továbbítja. A támadó lehallgathatja a kereteket, IP telefonhívás esetén akár a hívást is. A switch jobban leterhelődik, és hálózati szolgáltatást zavaró (DoS, Denial of Services) állapot léphet fel. A MAC elárasztásos támadás a DHCP kiéheztetés (starvation) támadás alapja is, hiszen a támadó a DHCP szervertől véletlenszerűen generált MAC címekkel lenullázza az adott alhálózat szabad IP címeit. A támadás a „dsniff” csomagban található „macof” eszközzel szimuláltam a támadást. Mint ahogy a 3.2.4-es fejezetben említettem, a csomagot telepíteni kell külön. A „macof” véletlenül generált MAC üzenetekkel árasztja el a kijelölt interfészt.
8.2.24. kép: A tesztelés előtt elérhető MAC címek száma a switchen - 8090.
59
Mint láthatjuk a 8.2.24.-es képen, a switchen 8090 elérhető MAC cím van, melyet a portokhoz tud rendelni. A tesztelés elindításához a Xubuntu termináljában root felhasználóként kell bejelentkezni, majd a „macof –i eth0” parancsot kiadni az elárasztás elindításához az Ethernet interfészen keresztül.
8.2.25. kép: A MAC elárasztásos parancs futása, kimenettel együtt (részlet).
A parancsot futni hagytam több másodpercig, és figyeltem a switch syslog üzeneteit (8.2.25.ös kép). Mivel az idő lejárta után nem tapasztaltam üzenetet, így leállítottam a futását, és leellenőriztem a MAC tábla telítettségét a switchen.
8.2.26. kép: A tesztelés után elérhető MAC címek száma a switchen - 0.
A 8.2.26.-os képen látható, hogy a MAC tábla telítődött, és nem tud a switch több MAC címet a portokhoz hozzárendelni. A tesztelés eredményeként elmondható, hogy az Access switcheken futó konfiguráció nem véd meg a MAC elárasztásos támadás ellen.
60
A támadás kivédése egyszerűen konfigurálható: engedélyezni kell a végfelhasználók portjain a biztonsági beállításokat a „switchport port-security” paranccsal, és az interfészhez kapcsolható MAC címeket korlátozni kell, a „switchport port-security maximum 10” paranccsal. Azt, hogy a switchport lekapcsoljon a biztonsági szabály megszegése esetén, a „switchport port-security violation shutdown” paranccsal tudjuk konfigurálni [4, 48]. A konfiguráció menete látható a 8.2.27-es képen.
8.2.27. kép: A felhasználói switch portok biztosítása MAC Flooding támadás ellen.
Ezen beállítások alkalmazása mellett a végfelhasználói portokon (figyelem, trunk portokon tilos alkalmazni ezt a biztonsági beállítást) védelmet kaphatunk a MAC elárasztásos támadásokkal szemben. Ez megvéd a DHCP kiéhetetéses támadás ellen is, hiszen a MAC címek korlátozásával a támadó nem lesz képes tovább változtatni a MAC címét, melyet az IP címek kérésére használ. A portja lekapcsol, és nem tudja tovább elárasztani a hálózatot hamis MAC címekkel, illetve több IP címet kérni.
3.5.2. Hamis DHCP szerver felállítása A hálózaton keresztülhaladó forgalmat nem csak MAC elárasztásos támadás segítségével lehet lehallgatni. A hálózatban egy nem hivatalos, Rogue DHCP szerver felállításával a támadónak lehetősége nyílik arra, hogy a hálózatra becsatlakozó felhasználói eszközöknek az ő DHCP szervere osszon ki IP címet, és rajta keresztül haladjon át a forgalom. Így hozzá is férhet az eszközökhöz (ha azok nincsenek jól biztosítva) és lehallgathatja a forgalmukat. Ez is a MITM (Man-in-the-Middle) típusú támadások közé sorolható [49]. A tesztelés során a 3.2.3.-as fejezetben bemutatott TP Link WR841ND routert használtam. A router SW1 switchportját bekötöttem az Access rétegbeli switch G6/27-es portjába, így lehetővé téve azt, hogy a router DHCP szervere belehallgathasson a switchen található, vele azonos VLAN-ban a Layer 2-es DHCP üzenetekbe. A WAN portot a G6/31-es portba 61
csatlakoztattam, hogy megkapja az alhálózat adatait a routeren található DHCP szerver. A felépítés a 8.1.12.-es ábrán látható.
8.1.12. ábra: A tesztkörnyezet felépítése.
Az tesztelés során azt vizsgáltam, hogy új IP címet kérve tíz alkalommal a teszt laptop számára, a Rogue DHCP szerver képes-e kiosztani IP címet, vagy egyáltalán érzékeli-e a DHCP kéréseket. Nem tudott kiosztani IP címet, és nem érzékelte a DHCPREQUEST kéréseket. Ezen a ponton megvizsgáltam az Access switch konfigurációját. A konfigurációból kiderült, hogy két 10 Gbps uplink porton van alkalmazva az „ip dhcp snooping trust”
parancs. Az ilyen módú beállítás azt eredményezi, hogy a DHCP üzeneteket
a switch csak a trusted, megbízható portok felé továbbítja, és figyelmen kívül hagyja a többi switchportot. Ha egyes portokon az „ip dhcp snooping untrust” parancsot használjuk, minden porton keresztül továbbítja a switch a DHCP típusú broadcast üzeneteket, e portok kivételével. A tesztet folytattam: bekapcsoltam a vezeték nélküli hálózatot a routeren. A teszt laptopot először csatlakoztattam a rendes WLAN hálózathoz, majd a router által sugárzott WLAN hálózathoz (ezen a ponton a vezeték nélküli router Rogue AP-ként is funkcionált). Az így módosított, új tesztkörnyezetet a 8.1.13.-as ábrán illusztráltam.
62
8.1.13. ábra: a tesztkörnyezet módosított felépítése.
A laptop a rendes WLAN hálózaton kapott IP címet megpróbálta használni a router WLAN hálózatán. Mivel előzőleg más alhálózaton volt (más paraméterekkel), és ugyanezeket próbálta használni, így az első DHCP kérését elutasította a DHCP szerver. Ekkor egy DHCPNAK broadcast üzenetet küldött ki a switchportjain, és WLAN hálózaton. Ezt az Access switch érzékelte, és eldobta a csomagot a DHCP Snooping beállítások miatt. Ez a 8.2.28. és a 8.2.29 képeken látható: az érzékelt DHCPREQUEST kérés, és a DHCPNAK válasz a DHCP szerveren; a DHCPNAK válasz érzékelése a switchen és a csomag eldobása.
8.2.28. kép: A Rogue DHCP szerveren látható üzenet, a DHCPNAK válasz kiküldésekor.
8.2.29. kép: A switch által érzékelt és eldobott DHCPNAK válasz, syslog üzenet formában.
A tesztekből láthatjuk, hogy az alkalmazott biztonsági beállítások megfelelőek, és nem lehetséges egy Rogue DHCP szerver felállítása.
63
3.5.3. Rogue AP-k elleni védelem A Rogue AP egy olyan hozzáférési pont, melyet a hálózatban engedély nélkül helyezett el dolgozó vagy támadó szándékú egyén. Az ilyen AP-k működtetése biztonsági kockázatot, minőségbeli problémát is jelenthet az általuk keltett interferencia miatt [50]. Több esetben előfordult a vállalatnál, hogy dolgozó azért helyezett el saját hozzáférési pontot, mert gyenge volt a jelerősség a kubikja környékén. Az ilyen eszközök általában nem rendelkeztek megfelelő biztonsági beállításokkal: az adminisztrációs felületük könnyen hozzáférhető, az SSID-juk nem megfelelő titkosítási protokollal vagy jelszóval volt védett. Ezért könnyebben hozzáférhetőek voltak, mint vállalati vezeték nélküli hálózat. A második esetben egy támadó szándékkal rendelkező egyén helyezi ki a saját hozzáférési pontját egy vállalat területén, melyet becsatlakoztat a rendes hálózatba (vezetékes vagy vezeték nélküli hálózaton keresztül). Az AP-nak ugyanaz lesz az SSID-ja mint a rendes AP-knak, és ugyanazt a titkosítást is használhatja (feltéve, hogy a támadó rendelkezik a megfelelő háttér információval a hálózatról), egyetlen különbsége a MAC címe lesz. A támadó a hozzá csatlakozó eszközökhöz hozzáférhet, a rajta keresztülhaladó forgalmat lehallgathatja, illetve manipulálhatja, és eltérítheti a DNS kéréseket is. Ez is a MITM támadás mintapéldája. A tesztelés során vizsgáltam, mennyi idő alatt detektálja az Airwave a Rogue AP-t, kapunke róla figyelmeztetést, és mennyire pontosan képes meghatározni a helyét. Egy órával az AP bekapcsolása és konfigurálása után figyelni kezdtem az értesítéseket. Mivel nem kaptam értesítést az eszköz felismeréséről két óra elteltével sem, az AirWave adatbázisát kezdtem el átnézni, annak profilja után kutatva, hogy az eszközt felismerte. Rövid keresés után megtaláltam az AirWave által készített profilját az eszköznek, amely minden fontos információt tartalmazott róla. A felfedezés során pontos profilt készít eszközről. Az AirWave által készített, fontos információk mellyel azonosítani lehet a Rogue AP-t, a következők: az általa sugárzott SSID-k; vezetékes és vezeték nélküli MAC címe; az eszköz gyártója; az eszköz IP címe; csatornája és titkosításának típusa; csatlakozott kliensek száma; az eszköz, ami először felfedezte; milyen módszerrel lett felfedezve; az utolsó AP, mely felfedezte; az eszköz jelerőssége és helye.
64
8.2.30. kép: A Rogue AP-ról az AirWave által készített profil. Ahogy a 8.2.30.-as képen is látható, az AirWave vezet egy úgynevezett Felfedezési Naplót, mellyel nyomon követi, hogy mely eszközökön és mikor fedezte fel a Rogue AP-t. Több eszközön keresztül is képes nyomon követni a Rogue AP-t: Access rétegben található switchen képes megmondani, hogy mely portra csatlakozik az eszköz.
8.2.31. kép: A Rogue AP-ról az AirWave által vezetett Felfedezési Napló. Az AirWave – ha fel vannak töltve a számára szükséges tervrajzok, melyeken be vannak jelölve a hivatalos hálózatban működő AP-k – képes meghatározni a Rogue AP helyét elfogadható pontossággal. A következő, AirWave által generált térkép mutatja, hogy a felmérések alapján a Rogue AP hol található: ez a lefelé mutató háromszög a 8.2.32.-es képen, közepén egy áthúzott router ikonjával. Az eszköz eredeti helyét a kék X-el jelöltem.
65
8.2.32. kép: Az AirWave által érzékelt Rogue AP helye. Az X jelöli a pontos helyét. Mint láthatjuk, az AirWave majdnem pontosan érzékelte az általam kihelyezett Rogue AP lokalizációját – körülbelül két métert tévedett (a lépcsőházat jelölte meg, mint a helyét). Ha az összes tulajdonságát érzékelte, akkor miért nem érkezett róla értesítés? A válasz egyszerű: a Classification osztálya „Suspected Rogue” volt. Ahhoz, hogy egy eszközről kaphassunk értesítést, „Rogue” Classification szükséges. Ettől eltekintve (mely egyértelmű vizsgálatot igényel, hogy miért nem kapta meg a „Rogue” osztályozást), a Rogue AP detektálása sikeres volt, minden tulajdonságát sikerült felfednie az AirWave-nek, és a helyét is meghatároznia két méteres pontossággal.
3.5.4. Port letapogatás hálózati eszközeinken A port letapogatási technika manapság az egyik legalapvetőbb felderítési technikája annak, hogy kiderítsük, az adott célpont eszközön mely portok vannak nyitva, tehát milyen hálózati szolgáltatások futhatnak rajta. A nyitott portok meghatározásával felderíthetjük a célpont sebezhető szolgáltatásait és rajtuk keresztül támadhatjuk meg az eszközt. A tesztelést elvégezhetjük az nmap (Network Mapper) nevű eszközzel, melyet a hálózat felfedezésére és biztonsági célokból történő letapogatásra használnak [51].
66
A letapogatás során az nmap egyszerű üzenetet küld minden port felé. A kapott válasz minden port esetében megmutatja, hogy használatban van-e. A letapogatás általában TCP portokon történik, hiszen a TCP protokoll kapcsolat-orientált, így nagy valószínűséggel visszajelzést fog adni a támadónak a port nyitottságáról. Majdnem minden hálózatba kötött eszközön lehet alkalmazni a letapogatást: routereken, switcheken, szervereken, szünetmentes tápegységeken, és így tovább. A tesztelés során a Distribution rétegben található switchen fogom elvégezni a letapogatást, mely az alapértelmezett átjáró szerepét tölti be a hálózatban. A terminálban „route –n” paranccsal meghatároztam az alapértelmezett átjáró IP címét. Root jogosultsággal futtattam az „nmap –A –T4 10.95.53.1” parancsot. Az nmap a „-A” kapcsolóval detektálja az eszközön futó operációs rendszert és a szolgáltatásokat; a „–T4” kapcsolóval gyorsítja a parancs végrehajtását.
8.2.33. kép: Port letapogatás az alapértelmezett átjárón, a Distribution rétegbeli switchen. A parancs kimenete sokatmondó: sikerült meghatároznia az egyetlen nyitott portot és szolgáltatást; az eszköz MAC címét, típusát; az operációs rendszer típusát és verzióját. A kimenet eléggé pontos, tükrözi a valós adatokat.
67
Az 22-es TCP porton kívül (mely az SSH protokoll portja) nincs más port nyitva. A Juniper eszközök egyik sajátossága, hogy http kapcsolaton keresztül is lehet őket konfigurálni. A http protokoll nem titkosított, plain text formátumot használ, így lehallgatható; de mint látjuk, nincs engedélyezve az eszközön. Az általános biztonsági beállítások konzisztensek a hálózati eszközeinken, így a Distribution és Core switcheken elvégzett letapogatás is ugyanezt az eredményt produkálta. A támadó nem tud sebezhető szolgáltatásokat találni a switchen, hiszen nincs más port nyitva az SSH-n kívül.
68
4. Továbbfejlesztési javaslatok 4.1. Aggregált linkek kialakítása az Access és Distribution rétegek között A redundancia növelése érdekében érdemes megfontolni az Access és Distribution rétegek között az aggregált linkek kialakítását. Természetesen a switch block koncepciójának köszönhetően a redundancia biztosított, viszont ha a jövőben bővítésre kerül a sor, érdemes megvizsgálni a lehetőségét annak, hogy redundancia mellett biztosítsunk aggregált kapcsolatokat az Access és Distribution rétegben található switchek között. Ez azt is jelentené, hogy az MST feszítőfa topológiát is felül kéne vizsgálni minden switch blokkban [39], illetve hogy van-e szabad switch port az eszközön, amiket lehetne használni a link aggregáció kialakításához.
4.2. Operációs rendszer frissítése a támogatott eszközökön A szakdolgozat írása alatt tapasztaltam, hogy előfordulnak olyan eszközök, melyeken nem a legfrissebb, elérhető IOS vagy JunOS verziójú operációs rendszer fut. Ennek elsődleges feltétele, az eszköz támogatottsága. Ha az eszközön nincs garancia, akkor a gyártók nem fogják elérhetővé tenni az operációs rendszerének frissítését. Az operációs rendszer frissítésével viszont fontos, hogy megfelelő tesztelést végezzünk a frissített eszközökön. Egy új verziójú operációs rendszer nem biztos, hogy tökéletesen fog működni az eszközön, és az sem kizárt, hogy használhatatlan lesz vele a frissített eszköz. Az eszközök frissítése előtt egy teszteszközön kell elvégezni a frissítést, és tesztelni az operációs rendszer általános stabilitását. Ha a tesztek sikeresek voltak, akkor egyesével lehetséges az eszközök frissítése. Miután egy eszköz frissítése megtörtént, azon is teszteket kell végezni. A frissítési folyamat hosszú időt venne igénybe, viszont lehet, hogy ha frissebb operációs rendszert használnánk eszközeinken, a jobb optimalizáltság miatt hatékonyabb lenne a működés.
69
4.3. Másodlagos internetvonal bérlése, HSRP engedélyezése A 2.2.1.-es fejezetben láthattuk, hogy egyetlen internetvonal van használatban a telephelyen. Egy esetleges hardveres meghibásodás, szolgáltatói hiba, vagy vonalon bekövetkezett sérülés az egész telephelyet érintő kimaradást eredményezhet. Ajánlásom szerint a jövőben érdemes lenne bérelni egy másodlagos internetvonalat. Ekkor lehetséges lenne az elsődleges és másodlagos internetvonalak routerein a HSPR (Hot Standby Router Protocol, [52]) engedélyezése. Segítségével lehető lenne redundáns internetkapcsolatot kialakítani, és biztosítani a telephely internetkapcsolatát egy esetleges megszakítás esetén.
4.4. QoS profilok verzióinak az egységesítése a globális hálózatban Mint ahogy a 2.3.1.-es fejezetben bemutattam, a WAN routereken QoS profilok működnek, melyekben a csomagok osztályozva vannak. Debrecenben a Cisco által javasolt 4.0-ás QoS profilt alkalmazzuk, viszont más irodákban található WAN routereken nem csak ez a verzió van használatban, hanem más verziók is. A jövőben megfontolható lenne az, hogy egységes QoS profilokat használjunk. Így hatékonyabbá és jobb minőségűvé lehetne tenni az MPLS WAN hálózat működését.
70
5. Összefoglalás A szakdolgozat céljául az NI Hungary Kft. hálózatának megismerését, tesztelését, és továbbfejlesztésének tervezését tűztem ki. A hálózat felépítése és működése eleget tesz a modern elvárásoknak, és a mindennapos igényeknek. Látható, hogy igényesen és költséghatékonyan lett kialakítva, arra törekedve, hogy minden felmerülő igényt kiszolgáljon. Az elemzés részben láthattuk, hogy a telephely hálózata követi a klasszikus, jól bevált sémákat és ajánlásokat. Folyamatos fejlesztések mennek végbe a hálózaton (internet és WAN vonalak bővítése például). Minden fontos technológia és protokoll implementálva van, ami egy vállalat telephelyén feltétlenül szükséges (QoS, VoIP telefonhálózat, 801.X authentikáció RADIUS protokoll segítségével). A hálózati eszközök biztonságosan vannak menedzselve, monitorozva. A SolarWinds Orion platform segítségével hálózati eszközeink állapota és kapcsolataink terheltségének figyelése valós időben nagyon nagy előnyt jelent a meghibásodás detektálásánál és hibaelhárításnál. A tesztelések, mérések során igyekeztem olyan általános teszteléseket és méréseket végezni, amelyekkel feltárhatom a hálózat gyengepontjait. A hálózaton általánosságban, és a kapcsolatokon végzett mérések kimutatták, hogy képesek kiszolgálni a mindennapos igényeket. A biztonsági tesztelések rávilágítottak arra, hogy Layer 2-es szinten MAC elárasztásos támadás ellen nincs védve a hálózat. Ennek a javítását a szakdolgozat befejeztével elkezdhetjük tervezni. A továbbfejlesztési javaslatokban igyekeztem olyan javaslatokat tenni, amikkel még jobbá tehető a hálózat. Igyekeztem olyan szempontokat figyelembe venni, amivel jobbá lehet tenni a hálózat működését. Úgy érzem, a szakdolgozatom írása közben sikerült megismernem a hálózatot, és teljesítettem a szakdolgozat célját. Az írása közben elsajátított tudás és megszerzett tapasztalat a jövőben nagyon hasznos lesz számomra, hiszen ezzel szeretném folytatni szakmai karrieremet.
71
6. Köszönetnyilvánítás Ezúton szeretném megköszönni Dr. Almási Béla egyetemi docensnek az egyetemi éveim alatt nyújtott útmutatását, a szakdolgozatom lektorálását. Segítségével, értékes tanácsaival segített jobbá tenni szakdolgozatomat. Továbbá szeretném megköszönni Lázár Zsoltnak, Gui Vieironak, Varga Ferencnek, és Kiss Attilának a segítséget, a rám fordított türelmet, és energiát. A támogatásuk nagyon sokat számított a szakdolgozatom elkészülésében. Köszönöm továbbá barátaimnak, ismerőseimnek, családtagjaimnak a támogatást, amivel segítettek a szakdolgozat írása közben.
72
7. Irodalomjegyzék 7.1. Írott könyvek, tanulmányok, tananyagok [1] CCNP Routing and Switching v2.0: 300-115 SWITCH, David Hucaby, Cisco Press, 2014 ISBN-10 szám: 1-58720-560-2 Felhasználva: 2015.08.23 [2] CCNP Routing and Switching v2.0: 300-101 ROUTE, Kevin Wallace, Cisco Press, 2014 ISBN-10 szám: 1-58720-559-9 Felhasználva: 2015.08.25 [3] CCNP Routing and Switching v2.0: 300-135 TSHOOT, Raymond Lacoste, Kevin Wallace, Cisco Press, 2014 ISBN-10 szám: 1-58720-561-0 Felhasználva: 2015.08.29 [4] „Bevezetés a Cisco eszközök programozásába 1-2” órák jegyzetei, tanulmányai Felhasználva: 2015.09.21
7.2 RFC Dokumentumok [5] [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels" https://www.ietf.org/rfc/rfc2119.txt Letöltve: 2015.09.01. [6] [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing Encapsulation (GRE)" https://www.ietf.org/rfc/rfc1701.txt Letöltve: 2015.09.13. [7] [RFC2332] Luciani, J., Katz, D., Piscitello, D., Cole, B., and N. Doraswamy, "NBMA Next Hop Resolution Protocol (NHRP)" https://www.ietf.org/rfc/rfc2332.txt Letöltve: 2015.09.13.
73
[8] [RFC2408] Maughan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", https://www.ietf.org/rfc/rfc2408.txt Letöltve: 2015.09.13. [9] [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture” https://www.ietf.org/rfc/rfc3031.txt Letöltve: 2015.09.15. [10] [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines" https://www.ietf.org/rfc/rfc3580.txt Letöltve: 2015.09.28. [11] [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)" https://www.ietf.org/rfc/rfc2865.txt Letöltve: 2015.09.28. [12] [RFC2866] Rigney, C., "RADIUS Accounting" https://www.ietf.org/rfc/rfc2866.txt Letöltve: 2015.09.28. [13] [RFC768] Postel, J., "User Datagram Protocol" https://www.ietf.org/rfc/rfc768.txt Letöltve: 2015.09.28. [14] [RFC7130] Bhatia, M., Ed., Chen, M., Ed., Boutros, S., Ed., Binderberger, M., Ed., and J. Haas, Ed., "Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces" https://www.ietf.org/rfc/rfc7130.txt Letöltve: 2015.10.02. [15] [RFC1131] Moy, J., "OSPF specification" https://www.ietf.org/rfc/rfc1131.txt Letöltve: 2015.10.11.
74
[16] [RFC1492] Finseth, C., "An Access Control Protocol, Sometimes Called TACACS" https://www.ietf.org/rfc/rfc1492.txt Letöltve: 2015.10.14. [17] [RFC0793] Postel, J., "Transmission Control Protocol" https://www.ietf.org/rfc/rfc793.txt Letöltve: 2015.10.14. [18] [RFC3164] Lonvick, C., "The BSD Syslog Protocol" https://www.ietf.org/rfc/rfc3164.txt Letöltve: 2015.10.20. [19] [RFC5424] Gerhards, R., "The Syslog Protocol" https://www.ietf.org/rfc/rfc5424.txt Letöltve: 2015.10.20. [20] [RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction to Community-based SNMPv2" https://www.ietf.org/rfc/rfc1901.txt Letöltve: 2015.10.24.
7.3 Internetes hivatkozások [21]: ANSI/TIA/EIA 568-B: „Commercial Building Telecommunications Cabling Standard” http://www.csd.uoc.gr/~hy435/material/Cabling%20Standard%20-%20ANSI-TIAEIA%20568%20B%20%20Commercial%20Building%20Telecommunications%20Cabling%20Standard.pdf Felhasználva: 2015.08.27. [22] Cisco.com: „Power over Ethernet Solutions” http://www.cisco.com/c/en/us/solutions/enterprise-networks/power-over-ethernetsolutions/index.html Felhasználva: 2015.08.27.
75
[23] Cisco.com: Cisco Catalyst 4506-E, WS-C4506-E chassis adatlap http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-4500-seriesswitches/product_data_sheet0900aecd801792b1.html Felhasználva: 2015.09.04. [24] Cisco.com: Supervisor Engine II-Plus supervisor engine adatlap http://www.cisco.com/c/en/us/products/collateral/interfaces-modules/catalyst-4500-seriessupervisor-engine-ii-plus/product_data_sheet09186a0080197424.html Felhasználva: 2015.09.04. [25] Cisco.com: WS-X4548-GB-RJ45V bővítőkártya adatlap http://www.cisco.com/c/en/us/products/collateral/interfaces-modules/catalyst-4500-series-linecards/product_data_sheet0900aecd802109ea.html Felhasználva: 2015.09.05 [26] Juniper.net: Juniper EX4550 adatlap
http://www.juniper.net/us/en/local/pdf/datasheets/1000414-en.pdf Felhasználva: 2015.09.10. [27] Juniper.net: Juniper EX4500 adatlap
https://www.juniper.net/us/en/local/pdf/datasheets/1000322-en.pdf Felhasználva: 2015.09.10. [28] Cisco.com: Dynamic Multipoint VPN (DMVPN) http://www.cisco.com/c/en/us/products/security/dynamic-multipoint-vpn-dmvpn/index.html Felhasználva: 2015.09.13. [29] Etherspeak.com: „What is MPLS and its Benefits?” http://www.etherspeak.com/blog/what-is-mpls-and-its-benefits/ Felhasználva: 2015.09.15. [30] Cisco.com: „Understanding IP Telephony Protocols” http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/8_5_1/ccmsys/accm-851cm/a08procl.pdf Felhasználva: 2015.09.17.
76
[31] Cisco.com: „Tail End Hop Off Case Study: How Cisco Cuts the Cost of Voice Calls” http://www.cisco.com/web/about/ciscoitatwork/unified_comm/TEHO_web.html Felhasználva: 2015.09.17. [32] Wikipedia.org: A Softphone szoftver leírása https://en.wikipedia.org/wiki/Softphone Felhasználva: 2015.09.20. [33] Wikipedia.org: Az IEEE 802.11 protokoll család leírása https://en.wikipedia.org/wiki/IEEE_802.11 Felhasználva: 2015.09.24. [34] Radio-electronics.com: „Wi-Fi / WLAN Channels, Frequencies, Bands & Bandwidths” http://www.radio-electronics.com/info/wireless/wi-fi/80211-channels-number-frequenciesbandwidth.php Felhasználva: 2015.09.24. [35] Cisco.com: „Cisco 1000 Series Lightweight Access Points Data Sheet” http://www.cisco.com/c/en/us/products/collateral/wireless/aironet-1000-series-lightweightaccess-point/product_data_sheet0900aecd8025708a.html Felhasználva: 2015.09.26. [36] Blogs.cisco.com: „Wi-Fi Roaming 101” http://blogs.cisco.com/wireless/wi-fi-roaming-101 Felhasználva: 2015.09.28. [37] Cisco.com: „IEEE 802.1Q Tunneling” http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/122SX/configuration/guide/book/dot1qtnl.html Felhasználva: 2015.10.01. [38] Juniper.net: „Understanding Aggregated Ethernet Interfaces and LACP” http://www.juniper.net/documentation/en_US/junos13.2/topics/concept/interfaces-lagoverview.html Felhasználva: 2015.10.02.
77
[39] Cisco.com: „Understanding Multiple Spanning Tree Protocol (802.1s)” http://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/24248147.html Felhasználva: 2015.10.05 [40] Cisco.com: „Configuring IP Access Lists” http://www.cisco.com/c/en/us/support/docs/security/ios-firewall/23602-confaccesslists.html Felhasználva: 2015.10.10 [41] Cisco.com: „Configuring TACACS+” http://www.cisco.com/c/en/us/td/docs/ios/12_2/security/configuration/guide/fsecur_c/scftplus.ht ml Felhasználva: 2015.10.14. [42] Ciscopress.com: „An Overview of the syslog Protocol” http://www.ciscopress.com/articles/article.asp?p=426638 Felhasználva: 2015.10.20. [43] Wikipedia.org: Sendmail project https://en.wikipedia.org/wiki/Sendmail Felhasználva: 2015.10.22. [44] Ciscopress.com: „SNMP Concepts and Configuration” http://www.ciscopress.com/articles/article.asp?p=1730888 Felhasználva: 2015.10.24. [45] Wikipedia.org: Management Information Base leírás https://en.wikipedia.org/wiki/Management_information_base Felhasználva: 2015.10.24 [46] Techrepublic.com: „10 physical security measures every organization should take” http://www.techrepublic.com/blog/10-things/10-physical-security-measures-every-organizationshould-take/ Felhasználva: 2015.11.05.
78
[47] Ookla Speedtest sebességmérő oldal elérhetősége http://www.speedtest.net/ Felhasználva: 2015.10.30. [48] CiscoZine.org: „Protecting against MAC flooding attack” http://www.ciscozine.com/protecting-against-mac-flooding-attack Felhasználva: 2015.11.11. [49] Wikipedia.org: Rogue DHCP szerver működésének áttekintése https://en.wikipedia.org/wiki/Rogue_DHCP Felhasználva: 2015.11.12. [50] Juniper.net: „Understanding Rogue Access Points” http://www.juniper.net/techpubs/en_US/junos-space-apps/networkdirector2.0/topics/concept/wireless-rogue-ap.html Felhasználva: 2015.11.15. [51] Nmap.org: „Nmap Referencia Útmutató (Kézikönyv)” https://nmap.org/man/hu/index.html Felhasználva: 2015.11.20. [52] Cisco.com: „Hot Standby Router Protocol Features and Functionality” http://www.cisco.com/c/en/us/support/docs/ip/hot-standby-router-protocol-hsrp/9234hsrpguidetoc.html Felhasználva: 2015.11.27.
79
8. Mellékletek 8.1. Ábrák listája 8.1.1. ábra: A Három- és Kétrégetű Hálózti Modell. [saját ábra] 8.1.2. ábra: Teljes redundancia kialakítása a switch block segítségével. [saját ábra] 8.1.3. ábra: A 3-as épületben (BLD3) található switch block felépítése. [saját ábra] 8.1.4. ábra: A Core és Distribution rétegben található eszközeink topológiája. [saját ábra] 8.1.5. ábra: MPLS WAN Cloud kapcsolat illusztrációja a három telephelyünk között. [saját ábra] 8.1.6. ábra: Két WAN kapcsolatunk ábrája. [saját ábra] 8.1.7. ábra: A VoIP telefonhálózat felépítése Debrecenben. [saját ábra] 8.1.8. ábra: A 2,4 GHz-es frekvenciában a csatornák kiosztása. [forrás: https://en.wikipedia.org/wiki/IEEE_802.11#/media/File:2.4_GHz_WiFi_channels_(802.11b,g_WLAN).svg] 8.1.9. ábra: LWAP protokoll felépítése. [saját ábra] 8.1.10. ábra: VLAN hálózatok kiterjedésének szemléltetése. [saját ábra] 8.1.11. ábra: Az OSPF protokollban működő routerek szemléltetése. [saját ábra] 8.1.12. ábra: A tesztkörnyezet felépítése. [saját ábra] 8.1.13. ábra: a tesztkörnyezet módosított felépítése.
8.2. Képek listája 8.2.1. kép: Egy gyártósori területen elhelyezkedő kábelrendező szoba berendezései. 8.2.2. kép: Egy Access rétegben működő Cisco Catalyst 4506-E váz. 8.2.3. kép: Az általunk használt Juniper EX4550-es switch a Distribution rétegben. 8.2.4. kép: A Core rétegben használt Juniper EX4500-es switch. 8.2.5. kép: Egy standard ACL konfigurálása és alkalmazása a Gi0/1 interfészen. 8.2.6. kép: Egy extended ACL konfigurálása és alkalmazása a Gi1/1 interfészen. 8.2.7. kép: Két Filter List konfigurálása és alkalmazása a ge-1/3/0 interfészen. 8.2.8. kép: Az eszközön futó IOS verzió és képfájl ellenőrzése. 8.2.9. kép: RSA kulcs generálása és az SSH protokoll aktiválása konfigurációs módban. 80
8.2.10. kép: A 0-4-es VTY vonalakon az SSH protokoll aktiválása, majd tesztelés után kikapcsolása; és az 5-15-ös VTY vonalak deaktiválása (konfigurációs részlet). 8.2.11. kép: A fent alkalmazott SSH konfigurációk alkalmazása Juniper eszközökön. 8.2.12. kép: Az Orion Syslog Viewer program valós időben érzékelt syslog üzenetekkel. 8.2.13. kép: A WLAN hálózat teszteléséhez használt eszközök. 8.2.14. kép: AirMagnet Spectrum XT RF spektrum analizátor USB adaptere 8.2.15. kép: Az Orion NTA moduljának a kezdőoldalon elhelyezett áttekintő doboza. 8.2.16. kép: Az NTA modul által generált NetFlow gráf az egyik MPLS vonalunkról. 8.2.17. kép: 3.5.1.-es biztonsági tesztelésnél használt switch specifikációja. 8.2.18. kép: A teszteléshez használt vezeték nélküli router – TP-Link WR841ND 8.2.19. kép: A 3.5.1.-es és 3.5.4.-es fejezetekben használt Xubuntu operációs rendszer specifikációja. 8.2.20. kép: BLD1-ben a mérés során rögzített adatok, grafikonok. 8.2.21. kép: BLD2-ben a mérés során rögzített adatok, grafikonok. 8.2.22. kép: BLD3-ban a mérés során rögzített adatok, grafikonok. 8.2.23. kép: A gyártósor területén a mérés során rögzített adatok, grafikonok. 8.2.24. kép: A tesztelés előtt elérhető MAC címek száma a switchen - 8090. 8.2.25. kép: A MAC elárasztásos parancs futása, kimenettel együtt (részlet). 8.2.26. kép: A tesztelés után elérhető MAC címek száma a switchen - 0. 8.2.27. kép: A felhasználói switch portok biztosítása MAC Flooding támadás ellen. 8.2.28. kép: A Rogue DHCP szerveren látható üzenet, a DHCPNAK válasz kiküldésekor. 8.2.29. kép: A switch által érzékelt és eldobott DHCPNAK válasz, syslog üzenet formában. 8.2.30. kép: A Rogue AP-ról az AirWave által készített profil. 8.2.31. kép: A Rogue AP-ról az AirWave által vezetett Felfedezési Napló. 8.2.32. kép: Az AirWave által érzékelt Rogue AP helye. Az X jelöli a pontos helyét. 8.2.33. kép: Port letapogatás az alapértelmezett átjárón, a Distribution rétegbeli switchen.
81
8.3. Táblázatok listája 8.3.1. táblázat: Category 5e és 6 típusú kábelek főbb specifikációjának összehasonlítása. 8.3.2. táblázat: TIA/EIA-568B bekötési szabvány színkódokkal szemléltetve. 8.3.4. táblázat: A belső vezetékes hálózaton mért letöltési és feltöltési sebességek. 8.3.5. táblázat: az első napon munkaidőben és munkaidőn kívül mért sebességek. 8.3.6. táblázat: az második napon munkaidőben és munkaidőn kívül mért sebességek. 8.3.7. táblázat: Az első WAN vonalon (deb-gw-mpls-bld1) végzett mérések, két napon, délelőtt és délutáni időszakban. 8.3.8. táblázat: A második WAN vonalon (deb-gw-mpls-bld3) végzett mérések.
8.4. Jelmagyarázat
Layer 2 switch
Layer 3 switch
Router
Voice Gateway
GSM modul
Unified Communications Manager (UCM)
Wireless LAN Controller (WLC)
Lightweight Access Point (LWAP)
82
Cloud
MPLS WAN Cloud
PC
Laptop
VoIP telefon
Telephely
83