Elosztott
tűzfal rendszer a Debreceni Egyetemen
Gál Zoltán, zgal@cis.unideb.hu
Karsay Andrea,
kandrea@cis.unideb.hu
Debreceni Egyetem, Informatikai
Szolgáltató Központja
1. Bevezetés
Az egyetem HBONE/Internet
kapcsolata az elmúlt évben 2,5 Gbps-re bővült. Mivel a városban az
intézmény campusai között jelentősen megnőtt az adatforgalom,
szükségessé vált a felhordó hálózat 100/155 Mbps átviteli sebességről a
Gbps tartományba való emelése.
A sávszélesség bővülése, az
utóbbi időben tapasztalt vírustámadások és betörési próbálkozások
szükségessé tették az egész egyetemi hálózat számára védelmet nyújtó
tűzfal felállítását. A HBONE router és az egyetemi MAN közé elhelyezett
tűzfal egy IBM RS/6000 szerveren futó IBM Firewall szoftver [1]. Habár a
szerver gép gigabites interfészekkel rendelkezik, processzorának terheltsége és
a bonyolult szabályrendszer miatt tapasztalatunk szerint meglehetősen
leszűkült az intézmény Internet elérési sebessége.
Az cikk a Debreceni Egyetemen
több, mint egy tucat Gigabit/sec szintű Cisco L3 kapcsoló segítségével
kialakított elosztott tűzfal rendszer gyakorlati tapasztalatait mutatja
be. Jelen anyag az intézményi Gigabites felhordó hálózat védelmi rendszerrel
kibővített bővítési filozófiáját és technikai megoldásait részletezi.
A bemutatásra kerülő tapasztalatok lehetővé teszik, hogy más
intézmények is a gerinchálózati eszközeik egyébként szükséges bővítésénél
az Interneten jelenleg kritikus támadási problémakört hasonló módon hatékonyan
lekezeljék.
2. A Debreceni Egyetem
informatikai rendszerének rövid összefoglalása
A Debreceni Egyetem hallgatói, oktatói és dolgozói az intézmény hét
nagy campusán, illetve telephelyén, az intézményi adatátviteli hálózatra
kapcsolt számítógépekről férnek hozzá az informatikai rendszerekhez. A PC
kliens gépek nagyobb része Microsoft Windows operációs rendszer működik,
de egyre több esetben alkalmazzák a UNIX valamely ingyenes változatát (Linux,
Solaris) is. Előbbiek az irodai jellegű elektronikus munkafelületet,
utóbbiak inkább az alkalmazások szerver oldali funkcióját biztosítják. Az
egyetem központi erőforrás gépei VAX, Sparc, Apha és Risc architektúrán
VMS, illetve UNIX operációs rendszert futtatnak [2].
Az intézményi elektronikus
szolgáltatások a következők: elektronikus
levelezés, fájlszolgáltatás, szoftver lincensz és médiakezelés, web, cache,
proxy, NAT, telefonos behívás (dial-up), vezeték nélküli adatkapcsolat,
Internet cím-név összerendelés (DNS), nyilvános hallgatói termináltermek, IP
feletti telefon (VoIP), tűzfal, Névtár (LDAP), videokonferencia. Az egyetemi nagy
elektronikus rendszerek az alábbiak:
-
Könyvtári
rendszer (Aleph),
-
Gazdasági
rendszer (EcoMed),
-
Klinikai
rendszerek (MedSol),
-
Intézményi WWW
rendszer,
-
Intézményi
számítógép hálózati rendszer (UDNet)
Ezen alkalmazások
az alábbi hét campus számítógépiről érhetők el:
|
|
Campus |
Cím |
PC
gépek száma |
Szerver
gépek száma |
Hallgatók
létszáma |
|
1. |
Agrártudományi Centrum |
Debrecen, Böszörményi út
138. |
560 |
20 |
3340 |
|
2. |
Bölcsészettudományi Kar, Természettudományi Kar,
Konzervatórium |
Debrecen, Egyetem tér 1-2. |
2600 |
60 |
9246 |
|
3. |
Egészségügyi Főiskolai Kar |
Nyíregyháza,
Sóstói út 2. |
120 |
10 |
2842 |
|
4. |
Hajdúböszörményi Pedagógiai Főiskolai Kar |
Hajdúböszörmény, Désány I. u. 1-9. |
50 |
5 |
2587 |
|
5. |
Közgazdaságtudományi Kar, Jogi és Államtudományi Intézet |
Debrecen, Kassai út 26. |
60 |
5 |
2527 |
|
6. |
Műszaki Főiskolai Kar |
Debrecen, Ótemető utca
2-4. |
340 |
10 |
1972 |
|
7. |
Orvos- és Egészségtudományi Centrum |
Debrecen, Nagyerdei krt.
98. |
2050 |
90 |
2199 |
|
Összesen |
5780 |
200 |
24713 |
||
Debrecenben az egyetemi felhasználók Internet hozzáférési sebessége az
elmúlt tíz év alatt jelentősen megnőtt. Ezt mutatja az 1 és a 2. ábra
is. Megfigyelhető, hogy a többi vidéki nagy egyetem viszonylatához
hasonlóan a HBONE sávszélessége ma már megegyezik a nemzetközi vonalakéval.
Az intézmény különböző campusain az egyes épületek 10-, illetve
100 Megabit/sec sebességű Ethernet technológiával kapcsolódnak egymáshoz.
Ezen átviteli sebességek a 2002. január óta Budapest-Debrecen között
működő 2500 Megabit/sec-os értéknek csak 1/250-ed, illetve 1/25-öd
részét képezik. Az egyetem épületei nem elegendő sávszélességgel
kapcsolódnak az intézményi hálózatra. Emiatt az intézményi felhordó hálózat
telítetté vált, miközben a rendelkezésre álló Internet hozzáférési kapacitás
kihasználása nem éri el az optimális szintet. Jelenleg az egyetemi hálózatra
kapcsolt 5800 gép közül mindegyik Internet hozzáféréssel rendelkezik.
|
|
|
|
1.
ábra. Csomópontonkénti sávszélesség |
2.
ábra. Vonalak sávszélessége |
A megnőtt sávszélesség, az utóbbi időben tapasztalt
vírustámadások és a betörési próbálkozások szükségessé tették egy olyan
tűzfal rendszer felállítását, amely az egész egyetemi hálózat számára
védelmet nyújt. A belső címtartomány kibővítése privát IP címekkel
NAT technika útján történik és megoldja az egyetem számára egyre szűkebbé
váló IP címtartomány problémáját is. A Neptun szerver gépeket ezen
túlmenően egy további PC-s tűzfallal védjük, mivel az egyetemi
belső hálózatról is tapasztalhatók vírus és féreg programok fertőzési
kísérletéből származó támadások.
A Budapest-Debrecen közötti 2,5 Gigabit/sec-os HBONE vonal
előnyeit csak úgy tudja az intézmény kihasználni, hogy egyrészt a campusok
közötti kapcsolatokat, másrészt a campusokon belüli helyi hálózat gerincét
Gigabit Ethernet technológiával biztosítja. Ezáltal a jelenlegi szűk
keresztmetszetek megszűnnek és a hallgatók, oktatók, kutatók gyors
Internet hozzáféréshez jutnak. Az STM-1/ATM átviteltechnikáról Gigabit
Ethernetre történő migrációt az intézmény Informatikai Szolgáltató Központja
(DISZK) két lépésben tervezi. Az első lépés a campusok közötti GbE
kapcsolatokat kialakítása. Itt figyelembe kell venni, hogy az egyetemi
informatikai központ és ezzel együtt az intézmény csillag/fa topológiájú
hálózatának gyökere a jelenlegi templomépületből új épületbe költözik át. A
második lépés, pedig a campusokon belüli felhordó hálózat átviteli sebességének
egy-két nagyságrenddel való növelése.
|
|
|
|
3.
ábra. Az UDNet Internet kapcsolata |
4.
ábra. Az egyetem Neptun szerverei |
Az intézményi számítógépes hálózat Internet kijárata mellé egy GbE L3
kapcsoló elhelyezése szükséges. Ez csillag topológiában tudja összefogni az
egyes campusok GbE/FE L3 kapcsolóit. Az előbbinek csak SMF GbE interfészei
vannak, későbbi 10GbE bővítési lehetőséggel, míg az utóbbiak
esetében szükségesek az MMF GbE és az MMF FE interfészek is. A csillag
topológiájú ATM rendszert backup üzemmódban tervezzük megtartani, amely a GbE
gerinccel párhuzamosan fog működni. Ennek kialakíthatósága nagymértékben
függ az UDNet maradék, használatlan üvegszálainak darabszámától.
3. A Cisco típusú routerek és L3
kapcsolók IP szűrő listái
A Cisco L2 és L3 szintű
gerinchálózati eszközök operációs rendszere (Internetwork Operating System,
IOS) a 8.3 verziójától kezdődően lehetőséget biztosít a hálózati
forgalom szűrésére. Ehhez a csomagok engedélyezését vagy tiltását
eldöntő szabályokat (Access Control List, ACL) kell definiálni a konfigurációban.
Az ACL-ek első két változata az alap és a kiterjesztett
szűrőlista. Az alap ACL a csomag forrás IP címe alapján való
szűrésre ad lehetőséget, míg a kiterjesztett változat a forrás és
célcím, illetve a szállítási rétegben alkalmazott port és egyéb opciók szerinti
protokoll adatelem továbbításának engedélyezését vagy tiltást teszi
lehetővé [3].
A vizsgálni kívánt címtartomány
meghatározása az IP cím, illetve a hozzá tartozó un. wilcard maszk
(továbbiakban: illesztési maszk) segítségével történik. A minta szerepe
hasonlatos az IP alhálózatoknál alkalmazott un. subnet maszkhoz, de bizonyos
értelemben annak inverzeként tekinthető. A 32 bites alhálózati maszk
első része "1" biteket, második része "0" biteket tartalmaz. Az IP
alhálózati maszkban az "1" bitekkel rendelkező rész határozza meg a hálózat+alhálózat
azonosítót, vagyis a hálózati forgalom irányítás szempontjából lényeges részt.
A szűrő lista illesztési maszkja ennek inverzeként működik. Az
ACL-ben megadott forrás és cél IP címeknek az illesztési maszk "0" értékű bitpozícióiban
történik meg a routerbe érkező minden egyes csomag címének és az
előre definiált szabálymintának az összehasonlítása. Az "1" bitek által
meghatározott résznek a szűrés szempontjából nincs jelentősége. Az
ACL definícióban szereplő IP cím és az illesztési maszk együttesen
határozza meg a kijelölt címmintát.
Az ACL működése a
következő: egymás után felírt szabályok sorozata adja az összetett logikai
kifejezést. Működése szempontjából lényeges a szabályok sorrendisége. Az
IP csomag címmezője összehasonlításra kerül az első szabállyal, minek
eredményeként a csomag a fejrészben található forrás- és/vagy célcím alapján vagy
illeszkedik a címmintára, vagy sem. Azaz a forrás és/vagy célcím vagy beletartozik
a címminta által meghatározott tartományba, vagy sem.
-
Illeszkedés esetében a szabályban meghatározott esemény következik be. Tiltás
esetén a router a csomagot eldobja és nem veszi figyelembe a listában
szereplő további szabályokat. Engedélyezés esetén a csomag a
megfelelő irányba továbbításra kerül, az utána következő szabályok
figyelmen kívül hagyásával.
-
Ha a csomag nem illeszkedik a szabályra, a következő szabály szerint kerül
összehasonlításra, és így tovább.
A folyamat legkésőbb az utolsó szabály
eléréséig tart. Ez alapértelmezés szerint tiltó szabály minden címre, ami azt
jelenti, hogy ha a csomag egyetlen szabályra sem illeszkedik, a router a
csomagot eldobja, vagyis az utolsó szabály után automatikus, minden csomagra
érvényes tiltás érvényesül anélkül, hogy ezt az eszközben konfigurálni kellene.
A vizsgálat tehát csak az első illeszkedő szabályig tart, annak
megfelelően megtörténik a csomag továbbítása vagy eldobása. Fontos
észrevenni, hogy hálózati forgalomtól függően, célszerű a lista
elejére tenni azokat a szabályokat, melyekre a legtöbb csomag illeszkedik.
Ezzel a gerinchálózati eszköz processzorának terhelése és a processzálási idő
radikálisan csökkenthető.
Az ACL készítésénél, interfészhez
rendelésénél figyelembe kell venni néhány szabályt. Az ACL egymás után felírt
szabályok sorozata. Az ACL azonosítása két módon történhet, s ilyen szempontból
kétféle ACL-ről beszélhetünk: számmal, illetve névvel azonosított szűrőlista.
Ezek különböző tulajdonságokkal rendelkeznek. A számmal azonosított ACL
esetében a szám meghatározza a lista típusát. Az IP szűrőlistákat
azonosító számuk alapján az alábbiak szerint csoportosítjuk:
|
Azonosító szám |
IP ACL típus |
|
1-99 |
Alap IP szűrő lista |
|
101-199 |
Kiterjesztett IP szűrő lista |
|
1300-1399 |
Kibővített alap IP szűrő lista |
|
2000-2699 |
Kibővített kiterjesztett IP szűrő
lista, 12.0.1 IOS-től |
A számmal azonosított ACL fontos
tulajdonsága, hogy a listát alkotó szabályok közül törölni nem tudunk, csak a
teljes lista egyben törölhető. Az IOS 11.2 verziótól lehetőség nyílik
névvel azonosított ACL használatára, melyet alap és kiterjesztett változatban is
használhatunk. Ez beszédesebbé teszi a konfigurációs állományt, hisz a lista
nevéből azonosítható a szűrés célja. A névvel azonosított lista
további kedvező tulajdonsága, hogy a listában szereplő szabályok
közül egyesével lehet törölni, azaz egyetlen megszüntetni kívánt szabály miatt
nem kell törölni és újra beírni egy hosszabb listát. A későbbi Cisco IOS
verziókban használható speciális ACL típusok egy része kizárólag névvel
azonosított kiterjesztett IP ACL esetében használhatóak.
Számmal és névvel azonosított IP
ACL közös tulajdonsága, hogy a listába újabb szabályt csak a lista végére lehet
felvenni. Célszerű ezért a listába tartozó szabályokat, és azok sorrendjét
előre megtervezni, hiszen az illeszkedés vizsgálata az első
illeszkedő szabályig tart. Ha egy hosszabb listába utólag kell beszúrni új
szabályt, célszerű tftp szerverre tölteni a konfigurációs fájlt, ott
editor segítségével módosítani, majd visszamásolni a routerbe.
A szűrni kívánt IP cím tartomány
meghatározása a címminta (IP cím, és a hozzá tartozó illesztési maszk) segítségével
történik. A szűrendő tartomány meghatározásának két speciális esete
van: csak a forráscímre (alap ACL), illetve a forrás- és a célcímre (kiterjesztett
ACL) alkalmazott szabály. Alkalmazhatók a következő szabályok: az "x.x.x.x
0.0.0.0" cím-illesztési maszk páros azonos a "host x.x.x.x" formával, valamint minden
címre vonatkozó illesztésnél a "0.0.0.0 255.255.255.255" cím-illesztési maszk
páros az "any" kulcsszóval helyettesíthető. Mivel e két eset gyakran
használatos, ezek a kulcsszavak egyszerűsítik a szabályok felírását.
Kiterjesztett IP ACL esetében a
forrás és cél címtartomány meghatározásán túl OSI 4 szintű, port szerinti
szűrést is alkalmazhatunk. Ennek felírása egy operátor és port azonosító
megadásával történik. Az operátor port azonosítót vagy port tartományt határoz
meg. Operátorként használható az =, <, <=, >, >=, illetve tartomány
kijelöléshez a range kulcsszó. A portazonosító megadása történhet számmal (pl.:
23, 25, 80) vagy karaktersorozattal (pl: telnet, SMTP, WWW). A felírt
szabályokhoz különböző kapcsolókat rendelhetünk, melyek módosítják, vagy
kiegészítik a szabály szerepét. Így például lehetőség van a szabályra
illeszkedő csomagok számlálására (log). Szerepének jelentősége miatt
külön említést érdemel az "established" kapcsoló. Használatával lehetőség
nyílik arra, hogy egy adott porton csak egy irányból engedélyezzük TCP kapcsolat felépítését, de a már felépült
kapcsolat számára mindkét irányban lehetővé teszi az átvitelt [4].
Azzal, hogy az ACL-t beírjuk a
konfigurációs állományba, csak definiáljuk az engedélyezni vagy tiltani kívánt
forgalmat. A forgalom tényleges szűrése a router interfészeken történik,
azaz a felírt ACL-t hozzá kell rendelnünk a megfelelő interfészhez. Az
interfészen a szűrés két irányban konfigurálható (in, out):
-
In: a routerbe belépő csomagok illesztése, amelyek az adott
interfészen keresztül érkeznek be az eszközbe,
-
Out: a routerből távozó csomagok, melyek az adott interfészen
keresztül hagyják el az eszközt.
Korai IOS verziók nem követelik meg az irány
meghatározását, mivel az alapértelmezett out irány rendelődött az ACL-hez.
A későbbi verziókban már kötelezően meg kell adni az ACL-hez rendelt
irányt. Egy interfészen egy irányhoz csak egy ACL-t rendelhetünk.
További ACL típusok a következők:
a.) Lock and key - dinamikus ACL: A Cisco IOS 11.1 verziótól
létező lehetőség. Lényege, hogy az IP cím és port szerinti
szűrésen túl meghatározhatjuk azon felhasználók körét, akik számára a
forgalmazás engedélyezett. A felhasználók forgalmát egy kiterjesztett ACL
blokkolja mindaddig, míg a felhasználó telnet kapcsolattal be nem jelentkezik a
routerbe, és ott azonosítja magát. Amennyiben ez megtörtént, a telnet kapcsolat
megszakad, és a felhasználói azonosítótól függően a megfelelő szabály
dinamikusan hozzáadódik a meglevő kiterjesztett szűrőlistához.
Az így engedélyezett kapcsolathoz időkorlátokat rendelhetünk, meghatározva
annak inaktív és abszolút maximális időtartamát.
b.) Reflexive ACL: A Cisco IOS 11.3 verziótól létező
lehetőség, mely csak névvel azonosított, kiterjesztett IP szűrőlista
esetében használható. Alkalmazásával lehetőség nyílik viszony réteg szerinti
szűrésre, azaz csak olyan kapcsolatok engedélyezésére, amelyeket
belülről kezdeményeztek. Lényeges különbség a többi ACL-hez képest, hogy
csak ideiglenes szabályokat tartalmaz, melyek egy viszony felépülésekor
automatikusan létrejönnek, majd a lebomlással törlődnek. A viszony lebontása
történhet a végpont kezdeményezésére, illetve a szabályhoz rendelt
időtartam lejárta miatt. Bár a reflexive ACL szerepe hasonlít az
egyszerű kiterjesztett ACL "established" kapcsolójához, különbözik
tőle abban, hogy amíg az utóbbi esetében a szűrőlista az
interfészhez van rendelve, azaz megkötések mellett engedélyez, addig a
reflexive ACL csak a viszony időtartama alatt ad lehetőséget az adott
porton keresztül történő forgalmazásra. Ezzel fokozottabb biztonságot képes
nyújtani. További fontos különbség, hogy míg az "established" kulcsszót csak
TCP kapcsolat esetén használhatjuk, a reflexive ACL tetszőleges IP
kapcsolat esetén alkalmazható. Kapcsolat nélküli protokollok (pl. UDP) esetében
a viszony a szabályban meghatározott időkorlát lejárta után szűnik
meg.
c.) Commented IP ACL szabályok: A Cisco IOS 12.0.2.T verziótól
létező lehetőség, mely alap és kiterjesztett IP ACL esetében is
alkalmazható. A kommentárok alkalmazásával az ACL-t áttekinthetőbbé,
érthetőbbé teszi.
d.) Idő alapú IP ACL: A Cisco IOS 12.0.1.T verziótól létező
lehetőség, mellyel meghatározhatjuk, mely időszakokban engedélyezzük
az IP csomagok forgalmazását. Az engedélyezni vagy tiltani kívánt időszakot
névvel azonosíthatjuk a definíció során. Ez lehet a nap meghatározott része, a
hét adott napjai, stb. Az időzítés a router rendszeróráján alapul,
célszerű a gerinchálózati eszköz helyi órájának NTP (Network Time Protocol)
alapú szinkronizációja.
4. Az
intézményi elosztott tűzfal rendszer struktúrája
A belső gerinchálózat
forgalmát a központban elhelyezett Cisco Catalyst 6506 router, illetve a
campusokon elhelyezett Cisco Catalyst 3550, gigabit interfészekkel
rendelkező, L3 switchek biztosítják. A debreceni campusok közötti
gigabites kapcsolatokat több mint egy tucat L4 szinten szűrési
lehetőséggel rendelkező kapcsoló biztosítja. Ezen eszközök
terheltsége - tapasztaltunk szerint - a megnőtt forgalom ellenére is
alacsony. Ez lehetővé tette, hogy a tűzfal funkció számára szükséges védelmi
rendszert a célhálózatokhoz közelebb helyezzük, azaz a szűréseket a
campusok kapcsolódását biztosító switchek végezzék. Ezáltal az így kialakított
tűzfal rendszer nem egyetlen ponton védi az UDNet hálózatot az Internet
felől érzékelt támadásokkal szemben, hanem elosztott formában campusonként
fejti ki hatását.
Ez jelentősen csökkentette
az intézmény korábbi egyetlen tűzfal szerverének terheltségét, mivel ez
csak az intézmény gerinchálózati eszközeit védi. Ezáltal a szerver gép
áteresztő képessége lényegesen javul és lehetővé teszi a regionális
HBONE router közel 1 Gbps sebességű elérését. Ezen túlmenően az
elosztott tűzfal rendszer a campusok számára is nagyobb biztonságot nyújt,
mivel nem csak az Internet felől biztosít számukra védelmet, hanem a többi
campus irányából esetlegesen kezdeményezett támadásokat is kiszűri.
|
|
|
|
5.
ábra. Az UDNet tűzfal rendszere (2003. március 18.) |
6.
ábra. A központi GbE L3 kapcsoló terheltsége |
5. Az
elosztott tűzfal rendszer megvalósítása
Az elosztott tűzfal rendszer
megvalósítása több lépésben, a kapcsolódó intézmény helyzetétől
függően különböző formában történt. A helyben megvalósított
szűrésre csak azokon a campusokon, kapcsolódó intézményekben volt
lehetőség, amelyek kapcsolódását GbE L3 eszközök biztosítják. Ahol erre
nem volt lehetőség, az egység számára a szűrést a csillag topológia
közepét jelentő Cisco Catalyst 6506 router végzi. (5. ábra). Bár ez nem
eredményezett különösebb terheltség növekedést az eszközben, (6. ábra) célunk,
hogy a szűréseket a campusokon, a célhoz közel végezhessük, és a központi
routert szűrési feladatokkal ne terheljük [5][6].
Az elosztott tűzfal rendszer
megvalósítása a megfelelő L3 eszközökben az ACL konfigurálását, majd az IBM
tűzfal szűrőlistájának szűkítését jelentette. Az ACL-k definiálásánál segítséget
jelentettek az egyetemi tűzfalban már meglevő szabályok. Külön
figyelmet kellett fordítani a campusok, illetve épületek közötti forgalmak
szűrési beállításaira, hiszen közöttük eddig szűrés nélkül kerültek
továbbításra a csomagok. A szabályok sorrendjét a várható illeszkedési
gyakoriságnak megfelelően alakítottuk ki, a log kapcsolóval beállított
számláló segítségével ezek tényleges alakulása is nyomon követhető.
A campusok kapcsolódását
biztosító L3 eszközökben definiált ACL általános felépítése a következő:
ip access-list extended Tuzfal
permit tcp any any established log
remark -- MAN belso forgalom --
permit ip x.x.x.0 0.0.63.255 any log
permit ip y.y.0.0 0.0.255.255 any log
permit ip z.0.0.0 0.255.255.255 any log
remark -- UDP es ICMP minden --
permit udp any any log
permit icmp any any log
remark -- Szerver: x.x.x.a --
permit tcp any host x.x.x.a eq 21 log
permit tcp any host x.x.x.a eq 22 log
permit tcp any host x.x.x.a eq 25 log
permit tcp any host x.x.x.a eq 80 log
permit tcp any host x.x.x.a gt 1023 log
remark -- Szerver: x.x.x.b --
permit tcp any host x.x.x.b eq 22 log
permit tcp any host x.x.x.b eq smtp log
permit tcp any host x.x.x.b eq www log
permit tcp any host x.x.x.b eq 143 log
permit tcp any host x.x.x.b eq 443 log
permit tcp any host x.x.x.b eq 3306 log
6. Tapasztalatok,
összefoglalás
A szűrőlisták
áthelyezésének hatása többrétű. Az elsődlegesen kiküszöbölendő
probléma az egyetemi tűzfal terheltsége volt, mely meglehetősen
leszűkítette a külső kapcsolat hasznos sávszélességét. Az áthelyezések
után az addig közel 1000 szabály helyett néhány, az egyetemi gerincet védő,
csak layer 3 szintű szabály maradt a listában. Ezáltal jelentősen
csökkent a tűzfal szerver gép terheltsége, így megnőtt a forgalom
áteresztő képessége.
Ugyanakkor a L3 eszközök
terheltség növekedése minimális mértékű, köszönhető ez nagy
kapacitásuknak, illetve annak, hogy eszközönként a szabályok száma csak
töredéke az egyetemi tűzfalban korábban működő szabályok
számának. További előnye a megoldásnak, hogy míg az egyetemi tűzfal
csak a külső támadások ellen nyújtott védelmet, addig az elosztott
tűzfal rendszer campusonkénti, helyenként épületenkénti szűrési
lehetőséget biztosít, mely a hálózati forgalom biztonságának nagyfokú növekedését
eredményezi. Így a rendszer a korábbihoz képest megnövekedett biztonság mellett
gyorsabb kapcsolatokat eredményez.
Irodalom
[1] Gál Zoltán, Karsai Andrea: "Migráció Gigabit
Ethernetre és ennek hatásai", NetworkShop'2002 konferencia, Eszterházy
Károly Főiskola, Eger, 2002. március 26-28.
[2] Gál Zoltán, Agócs László, Ecsedi Kornél, Vass Tamás: "Integrált
Informatikai Szolgáltatások a Debreceni Egyetemen", Informatika a Felsőoktatásban 2002
konferencia, Debrecen, 2002. augusztus 28-30.
[3] Cisco Systems:
Configuring IP Access Lists, Cisco document ID: 23602, Aug 06, 2002.
[4] Cisco Systems: Cisco IOS Command References,
Release12.1 http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/ip_r/iprprt1/1rdip.pdf
[5] Cisco Systems: IP Access
Lists
[6] Cisco Systems: IP access
list violations, displaying