Fulajtár Pál, fooly@sztaki.hu

1. Forgalommérés IP hálózaton?

A vonalakon állandóan jelen van bizonyos forgalom az üzemképesség ellenőrzése miatt, amelyet a menedzsment rendszer generál, gondoljunk csak egyszerűen a ping parancsra. Ez a hasznos kis programocska minden operációs rendszer alatt megtalálható és nagyszerűen ellenőrizhető vele a távoli gépek elérhetősége. Egyszerűsége rejti magában a legnagyobb veszélyt is, miszerint ha valakit elkezdek pingetni, akkor az Ő vonalán forgalmat generál és ha Neki a letöltött adatmennyiség után fizetnie kell, akkor bizony komoly károkat lehet ezzel okozni az illetőnek. Tegyük fel, hogy egy intézmény, vagy cég vásárolt magának egy 64 kbps sebességű bérelt vonali Internet hozzáférést és olyan szerződése van, amely szerint a letöltött adatmennyiség után fizetnie kell. Ennek szokásos díja ma Magyarországon 80 - 100 Ft/MB. Nem is kell hozzá rossz szándék, csak valaki állandóan tudni akarja, hogy ennek a cégnek a WWW szervere állandóan elérhető-e és emiatt másodpercenként 64 byte-os csomagokkal pingeti. Mit is jelent ez egy hónap alatt:

Ennyi kárt okozott ez az egy ember a cégnek egy hónap alatt. Könnyen ki lehet találni, hogy mekkora károkat lehet okozni ezen a módon, ha valaki ezt szándékosan teszi, mondjuk csak 10%-ig kiterhelve a vonalat, amit még feltehetőleg senkinek sem tűnik fel. Az ilyen módon átvitt adatmennyiség már több mint 2 GB, amelynek az ára 198 eFt.

Adott a tágabban értelmezett HBONE mag, amelynek az alábbi routerek a tagjai:

Ezek a routerek mind kapcsolódnak egymáshoz valamilyen módon, illetve minden külső kapcsolat ezen eszközök valamelyikébe fut be.

A tervezés során két nagyon fontos szempontra kellett ügyelni.

A forgalom számlálása viszonylag egyszerűen megoldható volt azzal, hogy igénybevettük a Cisco routereink azon szolgáltatását, hogy a kimenő csomagokat az interfészeken számlálni képes. A kiolvasott adatok tartalmazzák a

• forrás IP címet
• cél IP címet
• az átvitt adatmennyiséget a forrás és a célcímek között byte, valamint csomagszám alapján.

A beállításnál ügyelni kell arra, hogy azokat az interfészeket amelyek a mag routereket kötik össze a számlálásból ki kell hagyni, elkerülendő a kettős regisztrálást.

Ezt egy példával illusztrálnám:

Tegyük fel, hogy van két intézmény a JPTE és a VEIN, amelyek más-más routerekbe futnak be jelen esetben ezek a VHJ és a VHG. Ha a JPTE egyik számítógépe küld egy csomagot a VEIN egyik gépére, akkor ez a HBONE magon kersztül a következőképpen zajlik le: (1. ábra)

• A VHJ router egyik soros interfészén fogadja a csomagot (itt nem számolunk, mert befelé jött)
• A csomagot a VHJ Ethernet interfészén keresztül átküldi a VHG routernek (itt nem szabad számolni, mert a csomag nem hagyja el a magot)
• A VHG az Ethernet interfészén fogadja a csomagot (nem számolunk, mert a csomag befelé jött a routerben)
• A VHG router a VEIN-hez tartozó soros interfészén keresztül kiküldi a csomagot. (itt kell számolni, mert a csomag kifelé megy a routerből és egyben elhagyja a magot is.)

1. ábra

A magon keresztül egy átlagos hétköznapon kb. 30-35 ezer számítógép forgalmaz. Ez hérvégén kevesebb, szombaton 5-8 ezer, vasárnap pedig 16-20 ezer gép átlagosan. A mért adatok 1 nap pontossággal bármikor visszakereshetők, de az aktuális nap statisztikája mindig perc pontosságú. Ez azért fontos, mert csak így biztosítható, hogy az rész napi adatok összevethetőek legyen más teljes napi adatokkal. Könnyen belátható tehát, hogy itt egy elég nagy adatmennyiségről van szó, amely naponta 5-35 ezer rekorddal gyarapszik. Ahhoz, hogy az adatok gyorsan feldolgozhatók és visszakereshetők legyenek ki kellett választani a megfelelő tárolási módot. Nagyon egyszerű lett volna a dolog, ha minden nap felsoroljuk egy táblázatban az összes a HUNGARNET közösségbe tartozó számítógép címét és ehhez kapcsolva tároljuk az információkat. Ez nem bizonyult járható útnak, mivel több százezer címről van szó a fent említett aktív kb. 35000 hosttal szemben, ezen kívül ez a módszer nem biztosítja a gyors lekérdezhetőséget és különféle paraméterek szerinti rendezést. Azaz így rengeteg tároló helyet áldoznánk fel a tárolás egyszerűsége miatt. Ennek kiküszöbölésére az adatokat egy SQL adatbázisban tároltuk el. Az adatbázis kezelő megvalósítja a gyors beillesztési, visszakeresési feladatokat és a saját fejlesztésű rendszer felé egy szabványos interfészt nyújt. Az SQL adatbázis kezelő lehetővé teszi azt is, hogy ODBC-n keresztül mások is hozzákapcsolódhassanak az adatbázishoz és az adatokban lekérdezéseket, gyűjtéseket végezhessenek olyan különleges estekre is, amelyeket az alaprendszerbe nem építettünk bele, vagy csak éppen nem lenne célszerű, hogy ha feldolgozó gép processzorát terhelnénk olyan összetett összefüggések kiértékelésével, amelyek a napi felhasználásban érdektelenek. Így elérhető lett, hogy az adatgyűjtést és az alapvető kiértékelési feladatokat egy PC végezze el, amely emellett még más feladatokat is ellát a HBONE üzemeltetésében. Csak érdekességképpen a PC kiépítettsége: Intel Pentium 100MHz CPU, 32MB RAM, 1GB SCSI HDD, Linux OS.

A rendszer a felhasználók felé egy WWW alapú felületet biztosít, amelyen keresztül a különféle lekérdezési paraméterek megadhatók. A lekérdezések vonatkoztathatók a teljes HBONE-ra, vagy a hálózat egy tetszőleges nagyságú darabjára, így a teljes hálózathoz mérten elenyésző forgalmú, de helyileg kirívó esetek is pontosan vizsgálhatók. A forgalmi adatok grafikonon is ábrázolódnak, így nagyon könnyen felfedezhetők az olyan hirtelen változások a forgalomban, amelyek az esetek többségében valamilyen rendellenességre utalnak.

Ezek a következők lehetnek: Figyelhető, hogy egy számítógép milyen más gépekkel létesített kapcsolatot, kinek mennyi adatot küldött és kitől mennyit fogadott. Lehetséges a protokoll szerinti elemzés is, amikor az adatok típusáról is szeretnénk információhoz jutni. Erre akkor van szükség ha feltételezhető, hogy valaki rendszeresen nagy mennyiségű, a kutatási profilba nem illő, illegális, szerzői jogot sértő adatokat továbbít vagy terjeszt. Vagy egyszerűen csak a forgalom protokollok szerinti megoszlásáról szeretnénk pontosabb képet kapni.

A rendszer 1997 november elsejei indulása óta már többször is bizonyította hasznosságát, olyan esetekben is amelyekben nem is számítottunk rá, hogy hasznos lehet.

Legfontosabb felhasználási terület mint említettem a HUNGARNET AUP-ben foglaltak betartásának ellenőrzése. Szerencsére jellemző, hogy azokat az anyagokat, amelyek nem illeszkednek a kutatói célú felhasználásba sokkal intenzívebben látogatják, így az ezeket tároló számítógépek forgalma is kirívóan megnő. Volt rá példa, hogy egy közismert feltört játékokat terjesztő gép forgalma olyan magas volt, maga mögé utasította a több mint 30000 felhasználóval rendelkező helka.iif.hu gépet vagy a napi több mint 1 GB news forgalmat bonyolító almos.vein.hu-t. Ugyancsak kirívó eset volt, amikor az egyik nagy vidéki regionális központ 512kbps sávszélességű vonalának 96%-át egy szerző jogvédett anyagokat illegálisan szolgáltató gép vitte el, ezzel gyakorlatilag lehetetlenné téve rendeltetésszerű használatot. Természetesen nem csak ilyen példákkal demonstrálható a rendszer működése. A lemma.math.bme.hu gépet figyelve pontosan látható az új linux disztribúciók megjelenésének az ideje, mivel ekkor a letöltések száma nagyon megnövekszik.

A rendszer nagyon hasznosnak bizonyult, az utóbbi időszak legnagyobb számítógépes betöréssorozatának kivizsgálása során, amikor a HUNGARNET CERT-et segítette rendszer azzal, hogy pontosan végigkövette, ahogyan a támadó végigpásztázza az általunk üzemeltetett hálózatok gépeit.

A virtuális ATM interfészek forgalma nem mérhető, mivel a CISCO 4000-es routerekhez jelenleg nincs olyan szoftver, ami ezt támogatná.

Ennek a problémának az áthidalására a megoldást kidolgoztuk, sajnos a jelenleg használt routerek nem elegendőek ennek az elvégzésére.

Ezek a problémák hasonlóan az előzőhöz nagyobb teljesítményű routerek alkalmazásával, illetve a topológia részleges megváltoztatásával orvosolhatók illetve orvosolva is lesznek.

Ami miatt ez nem jelent különösebb problémát azaz, hogy általában sehol sem a letöltött adatmennyiség szokta jelenteni a problémát, hanem szolgáltatott tartalom. Ezek mérésében pedig sokkal kevésbé okoznak gondot a fentebb leírt problémák.