Informatika | Informatikai biztonság » Feltörés kontra védelem

Feltörés kontra védelem Előszó Kedves Olvasó, Tulajdonképpen mennyire biztonságos az Ön PC-je? Használ BIOS-jelszót, amely védi az adatait? Bonyolult, alfanumerikus kóddal kérdezi le az e-mail-jeit, vagy kedvenc háziállata nevével? Most ne nevessen, hiszen a PC-k elleni legtöbb támadás csak azért lehet sikeres, mert a felhasználók nem célszerűen használják a rendelkezésükre álló védelmi lehetőségeket. Ez a könyv talán befolyásolni fogja a biztonságérzetét és a magatartását is. Bepillantást nyerhet ugyanis a színfalak mögé, gondolkodásmódokat és stratégiákat ismerhet meg. Olyanokat, amelyek talán kamaszosak, ettől azonban nem kevésbé veszélyesek. És azt is meg fogja tudni, hogy a legveszélyesebb dolgok nem igényelnek különösebb tudást - egy makro vírust valójában mindenki meg tud írni. A könyv autentikus. Szerzője éveken át tevékenykedett ezen a területen, és jól ismeri a dolgok menetét. Egy német nagybankba

történt látványos betörés tette ismertté a nevét, amelynek a során másfél millió ügyféladatot kémleltek ki. „Egy pár számlát leüríthettünk és leléphettünk volna."-mondta a team egyik tagja Ehelyett nyilvánosságra hozták a támadást, és ez által új megvilágításba került az On-line banki szolgáltatás témája. Hogy ez valójában mennyire biztonságos manapság, azt csak akkor lehet majd megmondani, ha sikerült meghiúsítani néhány ilyen támadást. A számítógépek és a hálózatok megtámadásának bemutatott módjai a gyakorlatban többszörösen kipróbáltak. Azonban ma már nem minden itt leírt támadás vezetne feltétlenül célra. A gyártók és a szolgáltatók folyamatosan tökéletesítik a rendszereiket - főleg azután, ha egy biztonsági rés ismertté válik. Ebből a könyvből sokat meg fog tudni résekről és lyukakról, sőt, a végén még akár makrovírust is tud majd írni. A Microsoft nem fogja

megváltoztatni a makronyelvét, Ön azonban az aktuális biztonsági állapotokhoz igazíthatja a magatartását. Mi, akik hónapokon át foglalkoztunk ezzel a könyvvel, már egy új képernyőkímélőt sem töltünk le, és persze ismeretlen feladók csatolt fájljait sem nyitjuk meg. Ez a könyv helyenként olvasható krimiként, de semmi esetre sem regény. Esetenként technikai alapismeretekkel és programkódokkal szembesítjük olvasóinkat - mindkettőnek megvan a maga értelme. Hiszen ha eddig nem is érdeklődött a TCP/IP iránt, akkor is tudnia kell, milyen támadási lehetőségeket kínál ez a protokoll. A programkódok nem az Ön elrettentésére szolgálnak, hanem többnyire kommentárként. Egy vírust, mint amilyen az ILOVEYOU, a szeme láttára boncol fel alkotórészeire, és magyaráz el a szerző. Ez jelentősen megkönnyíti a kockázatok felmérését. Aki nem működtet webszervert - és ezzel a többség így van -, annak tulajdonképpen alig kell

törődnie az internetes támadásokkal. Legkésőbb azonban akkor válik a téma érdekessé, ha az irodája már nem tud maileket fogadni, vagy kiesik a szolgáltató szervere. Ezért erről is megtalálja a legfontosabb tényeket ebben a könyvben. Olvassa el belőle egyszerűen azt, ami érdekli Ont. Sok esetben előfordulhatnak fogalmak vagy technikai alapismeretek, amelyekkel esetleg nincsen tisztában. A legfontosabb eljárásokat ezért külön fejezetek tárgyalják, hogy ne ismétlődjenek állandóan. Ezekben viszont kimerítő magyarázatokat találhat. Fontos megjegyeznünk, hogy ez a könyv nem használati utasítás a ha-ckeléshez - még ha az egyik vagy a másik információt fel is lehetne használni ilyesmihez. Aki védekezni akar a betörő ellen, az ne az ajtózárral legyen elfoglalva, miközben a pinceablak a leggyengébb pont. Ahhoz azonban, hogy ezt valaki fel tudja ismerni, a betörő szemével kell néznie a házat. Ez a könyv segíthet abban, hogy

élesebb legyen a szeme, felfedezhesse a gyenge pontokat, és jelentősen csökkenthesse a kockázatokat. Ha a szerzőnek és a szerkesztőknek az elmúlt hónapokban végzett munkája csak egyszer is megkíméli Önt az adatvesztéstől, nekünk már megérte. Ebben a szellemben kívánunk tanulságos olvasmányt! Tartalom 1. A BANK-HACKELÉS 1.1 A feladat 1.11 Feltételek 1.12 A megoldáshoz vezető út 1.2 Hozzáférési út - információszerzés a Social Engineering módszerrel 1.3 A megfelelő cél keresése 1.31 Takarékpénztárak - túl sok szerverellenőrzés 1.32 Kutatás: IIS szerver kerestetik 1.33 Az operációs rendszer és a tranzakciós szoftver 1.34 Hogyan védik a szervert? 1.35 Nincsenek logfájlok - ezt biztosan az OFX irányítja 1.36 Adatátadás scriptekkel 1.37 Az adatletöltés 1.4 Utóirat a bank-hackeléshez 1.5 Összefoglalás 1.6 Sajtóbeszámolók 1.7 Tapasztalatok más bankoknál 1.71 Forgatókönyv a takarékpénztár-területen 2. A

WINDOWS-RENDSZEREK (9X, NT, 2000) GYENGE PONTJAI 2.1 A hackeren túl - merevlemez-fejreállás, adatbetekintés vagy lopás 2.11 Különbségek a Windows 9x, az NT és utódai között 2.12 A fizikai támadás 2.13 Képernyővédő - jelszó - a bennfenteseknek nem okoz problémát 2.14 Automatikus lejátszás - a betörés előkészítése CDvel 2.2 A jelszavak kikémlelése 2.21 Érdekes jelszavak szinte mindenütt akadnak 2.22 A jelszófájlok 2.23 Jelszavak a Windows 2000 alatt 2.3 A távoli elérésű támadás - internet- vagy hálózati felhasználók, vigyázat! 2.31 A fájl- és nyomtatómegosztás - veszélyes biztonsági rések 2.32 Mik azok a szkennerek, és hogyan működnek? 2.33 Milyen lehetőségeik vannak a betolakodóknak? 2.34 2.35 Jelszóval védett megosztások BruteForce-rohamok a megosztási jelszavak ellen 2.36 Óvintézkedések 2.4 További támadási technikák 3. ALAPOK 3.1 Az anonim Internetezés csökkenti a kockázatot 3.11 A legtöbb

felhasználó sokat elárul 3.12 Névtelenül 3.2 A TCP/IP 3.21 Mi a TCP/IP? 3.22 Különböző protokollok a rétegekben 3.3 Néhány alkalmazás és protokoll használata és a biztonságosságuk 3.31 A Telnet 3.32 Az FTP 3.33 Az IRC 3.34 Az IP-címzés 3.4 Aportokról 4. A TRÓJAIAK 4.1 A történelmi minta 4.2 Miből áll egy trójai? 4.21 A szerver kiosztása 4.22 A kliens otthon marad, és vezérli a szervert 4.23 Hogyan szerzik meg a hackerek az IP-t? 4.3 így álcázzák és terjesztik a trójaiakat 4.31 A trójaiakat fájlokba integrálják 4.32 Álcázás a WinZip-pel 4.33 A trójaiakat az ICQ-val is tovább lehet adni 4.34 Elég egy CD és az automatikus lejátszás funkció 4.35 A lemezek majdnem ugyanígy működnek 4.36 További terjesztési stratégiák 4.37 Mit csinálnak a hobby-hackerek a trójaiakkal? 4.4 Sub7 - egy trójai rémisztő lehetőségekkel 4.41 Támad a Sub7 4.5 BackOrifice 2K - Hálózati eszköz vagy támadás a Microsoft ellen 4.51 A BO2K és

összetevői 4.6 így ismerjük fel a trójait a rendszerünkben 4.61 Vírus- és trójai-szkenner 4.62 AutoRun bejegyzések 4.63 Windows-Registry - ez már izgalmas 4.64 Módszerek az Explorerexe-vel a C: meghajtóra 4.65 5. A runonce.exe kicserélése VÍRUSOK - VESZÉLYES FÁJLOK 5.1 Alapok 5.11 Defektes cluster mint álcázás 5.12 Miről ismeri fel a vírusvizsgáló a vírust? 5.13 Videokártyák - az elvetemült támadók búvóhelyei? 5.2 A vírus felépítése 5.3 Hogyan fertőz meg a vírus egy fájlt? 5.31 így fertőznek a bootszektor vírusok 5.32 A dropper vírust helyez el 5.4 A legfontosabb vírustípusok rövid áttekintése 5.41 Bootszektor vírusok 5.42 Companion vírusok 5.43 Killerprogramok 5.44 Logikai bombák 5.45 Makrovírusok 5.46 Hálózati vírusok 5.47 Polimorf vírusok 5.48 Stealth vagy rejtőzködő vírusok 5.49 A TSR fájlvírusok 5.410 Update vírusok 5.411 Férgek - az ILOVEYOU és társai 5.412 Időzítők 5.5 Word makrovírus írása 5.51 Minden

ténykedés központja - a Normaldot fájl 5.52 Modul vagy osztálymodul? 5.53 Vírusok kontra ServiceRelease 5.54 Modul makrók 5.55 Ilyet is lehet: a vírus egy Payload-ot hív meg 5.56 A vírus fájltulajdonságokat vagy szövegtartalmakat változtat meg 5.57 A vírus jelszóval védi a fájlt 5.6 Megfertőzött osztálymodulok 5.7 ILOVEYOU 5.71 Mi az a féreg? 5.72 A működési mód 5.73 Hogyan tudott a féreg elterjedni? 5.74 A forrás - kommentárokkal 5.8 Hogyan működnek a vírusvizsgálók? 5.81 Szkennermodul 5.82 Víruspajzs 5.83 „Fertőtlenítő" 5.84 A vírusvédő program kiválasztásának a szempontjai 6. SZKENNELÉS - A RÉSEK KERESÉSE 6.1 A szkenner 6.2 Szkennelési eljárások 6.21 Szkennelés teljes TCP-kapcsolattal 6.22 Félig nyitott TCP-szkennelés 6.23 6.24 6.25 6.26 6.27 6.28 6.29 7. 7.1 7.2 7.3 7.31 7.32 7.4 7.41 7.42 7.43 7.44 7.45 TCP-FIN-Scan Fragmentált szkennelés UDP-lCMP-Port-Unreachable szkennelés UDP-Recvfrom-And-Write

szkennelés ICMP-echo-scanning/ping-szkennelés A nyitott portok csak a kezdetet jelentik A portszkennelés elleni védelem JELSZÓFELTÖRÉS Hackelt security-site - jelszófeltöréssel ez is lehetséges Mire kell ügyelni a felhasználói oldalról? A jelszófeltörők Ismert felhasználói nevek jelszavainak a kitalálása A beállítások egy áttekintésben Jelszavak megfejtése a John the Ripperrel Single Mode A szólista módszer Incremental mód Extemal mód A John legfontosabb parancsai 7.46 A jelszófájl 8. TÁMADÁSOK AZ INTERNET-FELHASZNÁLÓK ELLEN 8.1 E-mail-támadások 8.11 Mailbombák - túlcsordul a postafiók 8.12 A fájlmelléklet kitömése 8.13 A ConCon bug 8.2 ICQ - praktikus és veszélyes 8.21 Az ICQ - biztonsági kockázat? 8.22 Milyen biztonsági rések vannak? 9. SNIFFER 9.1 Mi az a sniffer? 9.2 Hogyan működik egy sniffer? 9.3 A sniffer veszélyei 9.4 Mit lehet tenni a snifferek ellen? 10. A DENIAL OF SERVICE TÁMADÁS 10.1 Az IP-spoofing mint

előfeltétel 10.2 Out-of-Band csomagok - a „nuken" 10.3 Large Packet-támadások avagy a Ping of Death 10.4 Land támadások 10.5 TCP-Syn-Flooding 10.6 Ping-Flodding 10.7 Smurf 10.8 DDoS - Distributed Denial of Service támadások 10.9 Védelem a DoS-támadások ellen 11. BUFFER-OVERFLOW 11.1 Az operációs rendszer memóriakezelése 11.11 Szöveg 11.12 Adatok 11.13 Astack (magyarul: halom/rakás) 11.2 A Buffer-Overflow-támadások 11.21 Hogyan lehet ezt kihasználni? 11.22 Hogyan működik? 11.23 Minek kell a Shellcode változónál állnia? 11.3 Áldozat a Buffer-Overflow-kért 11.4 Honnan lehet felismerni a Buffer-Overflow-t? 11.5 Milyen védelmi mechanizmusok vannak? 11.51 Összefüggés a CPU és a Buffer-Overflow között 11.52 A Buffer-Overflow-k és a tűzfalak 12. BIZTONSÁG A WEBEN 12.1 CGI-scriptek biztonságossága 12.11 A CGI további ismert gyenge pontjai 12.12 Látogatásszámláló résekkel - countcgi 12.2 Védelem 12.3 BBS biztonság 12.4 Jelszóval védett

webterületek megtámadása 12.41 Védelem 12.42 Hitelkártya fake-ek 12.5 Defacement - a „script kidek" nemzeti sportja 12.6 Hogyan védhetjük meg a webszervert? 13. TŰZFALAK 13.1 A tűzfal feladatai 13.11 A tűzfal biztonsági szempontból fontos összetevői 13.12 A tűzfalak kategóriái 13.13 Tűzfal-koncepciók 13.14 Hogyan ismeri fel a támadó a tűzfalat? 13.2 Desktop tűzfalak 13.21 Egy desktop tűzfal megtámadása 13.22 Védelem a desktop tűzfallal 1. fejezet - Tartalom A feladat.16 1.11 Feltételek16 1.12 A megoldáshoz vezető út17 Hozzáférési út - információszerzés a Social Engineering módszerrel 18 A megfelelő cél keresése. 20 1.31 Takarékpénztárak-túl sok szerverellenőrzés20 1.32 Kutatás: IIS szerver kerestetik 21 1.33 Az operációs rendszer és a tranzakciós szoftver 22 1.34 Hogyan védik a szervert?23 1.35 Nincsenek logfájlok - ezt biztosan az OFX irányítja 26 1.36 Adatátadás scriptekkel 26 1.37 Az adatletöltés 28

Utóirat a bank-hackeléshez 29 Összefoglalás.29 Sajtóbeszámolók.30 Tapasztalatok más bankoknál.33 1.71 Forgatókönyv a takarékpénztár-területen33 1 A bank-hackelés Rövid ideig az érdeklődés középpontjába került egy különös támadás egy németországi bankszerver ellen, amelyről ebben a fejezetben írunk. A támadás visszhangja a könyv szerzőjére nézve mindenképpen pozitív volt, csak a bank jött ki rosszul az ügyből. Az érintett intézmény a „betörés" hatására ugyan változtatott online banking rendszerén, így a támadás ennek a könyvnek a megjelenésekor már nem ismételhető meg, ám mivel a potenciálisan fenyegető károk még most is jelentősek lehetnek, a bank nevét a szerzők - jogi megfontolásokból letakarták. 1.1 A feladat 2001 júniusában érdekes feladatot kapott egy fiatal hackercsoport: banki rendszereket és elektronikus kártyákat kellett tesztelniük, s az ARD Technikai Tanácsadó műsor keretében

kellett ellenőrizni, mennyire biztonságos manapság az online banki ügyintézés Németországban. A biztonság kérdését kétféleképpen lehetett megközelíteni: « Mennyire védettek az ügyfelek adatai, vannak-e lehetőségek betörni egy banki szerverbe? • Mennyire biztonságosak a tranzakciók, amelyeket a homebanking során végrehajtanak? Van-e lehetőség, adatokat lekérdezni, manipulálni, átirányítani stb.? 1.11 Feltételek A feladat természetesen bizonyos feltételekhez volt kötve. Ezek közé tartoztak: « Egyeden ügyfelet sem érhet kár. Ez azt jelentette, hogy egyetlen tranzakciót sem lehetett úgy manipulálni vagy hamisítani, hogy az végrehajthatatlanná váljon. • A bank online rendszerét nem lehetett sem zavarni, sem korlátozni a működésében. • Mindennek észrevétlenül kellett történnie, nehogy az érintett bank az adás sugárzása előtt ideiglenes intézkedéseket tegyen, hogy megakadályozza a hiányosság nyilvánosságra

kerülését. 1.12 A megoldáshoz vezető út A dolog a következőképpen zajlott: 1. Meg kellett találni a hozzáférési utat az adatokhoz vagy a szerverhez. 2. Be kellett törni a rendszerbe, és fel kellett deríteni a manipulációs lehetőségeket. 3. Ki kellett kémlelni az adatokat 4. Manipulálni kellett a tranzakciókat Két lehetséges indítás jutott a csoport eszébe: • Az intézmény webszerverének a megtámadása; • Trójai elhelyezése a homebanking-ügyfeleknél, és ezt követően a banki szerver megtámadása a kikémlelt ügyféladatokkal. Az egyszerűbb természetesen a régi jó trójaihoz való visszanyúlás lett volna: néhány PC-t kikémlelni, majd a megfelelő pillanatban, amikor az ügyfél online intézi banki ügyeit, lecsapni. Néhány terepkísérlet után azonban ez a lehetőség a hajánál előrángatottnak tűnt. Ügyfeleket kell találni, át kell játszani nekik egy trójai vírust, installálni kell a trójait stb. Ráadásul egy

ilyen indítást állandóan felügyelni is kell, hiszen a kikémlelés után várni kell az első homebanking tranzakcióra. S ha egy ilyen akció kitudódna, annak olyan sajtóviszhangja lenne, hogy aligha lehetne végrehajtani a tulajdonképpeni tesztet. A megfelelő lehetőséget tehát csak egy pénzintézet webszerverének a feltörése jelenthette. Ez természetesen heves vitákat váltott ki, nem utolsósorban a (német) Btk. 202 és 263 §aira való tekintettel Végülis arra a döntésre jutottak, hogy egyszer azért megpróbálkoznak vele, hiszen talán csak kisebb hiányosságokra bukkannak, amelyeket nyugodtan fel lehet mutatni. Természetesen egyik résztvevőnek sem volt pontos koncepciója, és azt sem tudták, hogyan is néznek ki pontosan a banki rendszerek. Először tehát információkat kellett gyűjteniük 1.2 Hozzáférési út - információszerzés a Social Engineering módszerrel Mindenekelőtt személyes kapcsolatokon keresztül próbáltak információkat

szerezni a bankszerverről. Azonban a saját ügyféltanácsadót kérdezgetni bankja szerverének részleteiről nem túl szerencsés, hiszen többnyire maga sem tud róla semmit, vagy pedig gyanút fog. Más megoldást kellett tehát találni Először tájékozódni kellett a banki struktúráról. Több banknak emailt írtak, amelyben ügyfélnek adták ki magunkat, aki hallott egy másik bank webszerverét ért hackertámadásról, és most tudni akarja a saját bankjáról, hogy valójában mennyire van biztonságban ennek az intézménynek a pénze, illetve védett-e az online banki szolgáltatása. A mailt úgy kellett megírni, hogy a felépítése miatt ne tudjanak egy szabvány ügyfélszolgálati szöveggel válaszolni rá. Éppen ezért hálózattech-nikailag jártasnak mutatták magunkat, és végezetül szenvtelenül megkérdezték, hogyan is védi a bank az online ügymenetet és az ügyfelek adatait. Ezt a mailt elküldték 10 nagy német pénzintézetnek, amelyek

online portált működtetnek. Körülbelül 5 nap és 9 „Aggodalomra semmi ok, a pénze sehol sincs nagyobb biztonságban, mint nálunk. Az ÖN XY bankja" típusú szabványmail után, a szerzőket is meglepve, az alábbi mail érkezett. 1. Az infrastruktúra Az XY bank online banki rendszerének infrastruktúrája a következők szerint van kiépítve: Valamennyi online banking megkeresés egy Cisco routeren keresztül érkezik, amely csak a 443-as portot (HTTPS-kódolású adatátvitel SSL-lel) bocsátja rendelkezésre, és csak az exkluzíván az online banki rendszer elé kapcsolt plug-gateway-en, integrált tűzfallal, enged át kéréseket, Így az ügyfelek banki adatainak az átvitele az online banking oldal betöltésétől kezdve biztonságos és kódolt. A Cisco router mögött még egy exkluzíván az XY bank számára installált, Intrusion Detection System is található, amely naplózza, jelzi és vissza is veri a rendszer elleni támadásokat. A plug-gateway,

amely a Cisco router és a bank szervere között található, a következő feladatokat látja el: Az internetkapcsolat és a webszerverhez kapcsolódás fizikai szétválasztása: egy külső rendszertől induló kapcsolat felépítésénél átveszi a kapcsolatot, és az internetről jövő kapcsolattól fizikailag elválasztott kapcsolatot állít elő a webszerverhez úgy, hogy semmilyen visszacsatolás nem lehetséges kívülről a külső rendszerre. A plug-gateway tűzfala minden csomagot analizál, és csak a szűrőszabályok (csak HTTPS elérések engedélyezettek) teljesülése esetén továbbítja az online banki rendszer webszerverére. Továbbá az adatbázis szerver fizikailag el van választva a webszervertől és az alkalmazástól, így az adatbázist egyáltalán nem lehet közvetlenül elérni az internetről. 2. Biztonság Az infrastruktúra (hardver és rendszerszoftver szinten) megfelelő védettsége érdekében még a következő biztonsági intézkedéseket

tettük az online banki ügyintézésnél: A kliens és a szerver közötti kapcsolat 128 bites maximális kódolással épül fel. Ez a szabvány az internetes tranzakcióknál biztonságos. A PIN-ek kódolva vannak tárolva az adatbázisban, és semmilyen visszacsatolást nem engednek meg a valójában felhasznált PIN-re. 3. Az adminisztrátor 200106 havi biztonsági analízise A rendszeradminisztrátor 2001. 06 hóban maga hajtott végre szkennelést a nyitott internetfellépés és a bank online rendszere ellen. Mint várható, az online banki rendszer csak HTTPS-en keresztül (443. port) a 128 bites kódolású, biztonságos interneteléréssel érhető el A kísérlet, hogy további információkat tudjunk meg a rendszerről (hardver, operációs rendszer, szerver stb.), nem sikerült. Ez egy jól sikerült példa volt a Social Engineeringre, arra a módszerre amelynek révén részletes bepillantást nyerhettek a banki webszerver biztonsági intézkedéseibe. A részletes

információk szkennelése - finommunkák Ami a mail-bői nem derült ki, azonban néhány szkennelés (közelebbit ld. később) eredményeként már világos volt: minden bank különböző pénzügyi szoftvereket használ, például az OFX-et (Open Financial Exchange). Ezek gondoskodnak a számlaszámok és a PIN-ek belépő ellenőrzéséről, és kezelik a további ügyfélinformációkat. Miután ezekről a szerver-kliens szoftverekről csak szűkös információkat találtak, világossá vált a számukra, hogy csak egy bank login oldaláról juthatnak hozzá az ügyfelek adataihoz. Még ha lehetséges is lenne adatokhoz jutni az OFX-adatbázisból, továbbra is tisztázatlan, hogy nincsenek-e esetleg kódolva ezek stb. 1.3 A megfelelő cél keresése Az ötlet tehát az volt, hogy keresnek egy nagyobb bankot, amelynek a szervere közvetlenül csatlakozik az online bankinghez, és ott úgy változtatják meg a login-oldalakat, hogy minden bevitel egy log-fájlba vándoroljon.

A kérdés csak az volt, melyik bank legyen az? 1.31 Takarékpénztárak - túl sok szerverellenőrzés A német takarékpénztárak az infrastruktúrára vetett rövid pillantás után kiestek. Az volt ugyanis a probléma velük, hogy ugyan majdnem minden takarékszövetkezetnek van saját weboldala, ám az onlinebanking egy számítógépközponton keresztül zajlik. Itt van példának a www.ostspade Ennek az oldalnak a szervere Schwerinben van, de a tulajdonképpeni oldal, ahol az ügyfelek a számlájukhoz férnek, a következő cím alatt fut: https://ww2.hotnebanking-mecklenburgvorpde/cgi/anfangcgi/Ostseespk Rostock, miközben ez a szerver a DVG-nél, Hannoverben található. Egy támadás itt egy kicsit melegnek tűnt, mert például Hannoverben majdnem minden takarékpénztárat Észak-Németországból hostolnak, és ki lehetett indulni abból, hogy az adminek „a gépen ülnek", és már egy tesztcélú szkennelés is figyelmet keltene. 1.32 Kutatás: US-szerver

kerestetik így tehát inkább a nagyobb bankokra kellett összpontosítani. Mivel a keresett formátumból tulajdonképpen nem sok volt, azzal kezdhettek, hogy minden egyes bankot megvizsgáltak. A hackeléshez tulajdonképpen csak egy Microsoft HS-szerver jöhetett szóba. Szkenneltek néhány bankot, hogy lássák a szervereiket. Részletek a szerverekről Itt láthatók az infók a felhasznált szerverekről A szkennelő program segítségével különböző bankportálokat vizsgáltak, hogy megtalálják a betörésre alkalmas rendszert. A program szállította a legfontosabb információkat az egyes bankok és takarékpénztárak webszer-vereiről. (A szkennelés témájáról a 6. fejezetben részletesen is olvashatnak) Napokig tartó szkennelés után találták meg a ••• oldalt, egy portált, amelyen keresztül úgy a bank, mint egy leányvállalat, a ••• ügyfelei be tudtak login-olni. A cél ismertetőjegyei - az előkészítés feltételei A cél

optimálisnak tűnt, mert e bank ügyfeleinek egész Németországban erről a portálról kellett bejelentkezniük, így az oldal elérési számainak is magasnak kellett lenniük. Utólagos becslések szerint az említett szám 5000 és 9000 között mozgott óránként. Egy további érv, amely e bank mellett szólt, a szerver tervezett átépítése volt, úgy az oldalé, mint magáé a rendszeré. Tehát abból indulhattak ki, lehetséges, hogy sikerrel járnak. A bank minden szakembere az új projekten dolgozik, és a még futó régi rendszert „elhanyagolják", így a webszerver megtámadásának az időpontja több mint ideális. A támadáshoz a következő lépéseket kellett végrehajtani: 1. Feltérképezni az operációs rendszert és a tranzakciókhoz használt szoftvert. 2. Ellenőrizni a védelmi mechanizmusokat 3. Ellenőrizni, hogy vannak-e logfájlok információkkal 4. Kikutatni az adatátvitelt 5. Hitelesíteni 6. Tesztelni az exploitokát 1.33 Az

operációs rendszer és a tranzakciós szoftver Egy NT-webszerver IIS 4.0-val, Tivoli Management Software-rel karbantartva (amelynek a hibáiról lehetett már hallani)! De ezt ezen a szerveren nem ellenőrizték, mert egy végzetes rés a IIS-en, amely a parancsok dekódolását érintette, tökéletesen elegendő volt. 1.34 Hogyan védik a szervert? Úgy tűnt, a szervert tűzfal védi, mert nem válaszolt a pingekre, és kapcsolatokat sem engedett meg kifelé. A szkennelések során nem derült ki pontosan, milyen tűzfalról volt szó, és azt sem lehetett megmondani, hogy a webszolgáltatón (80. port) és a HTTPS-en (443. port) kívül más portok elérése is megengedett-e, de ezt kizárni sem lehetett, mert a netstat-jelentés 4:00 óra körül kapcsolatokat mutatott a 4966/4967 portra. Mivel a távoli számítógépet egy komputernévvel jelölték, intranet kapcsolatból indulhattak ki. Íme a netstat-jelentés: Prot. Helyi címek TCP TCP TCP TCP TCP TCP TCP TCP TCP

0.000:135 0.000:135 0.000:161 0.000:512 0.000:1027 0.000:1031 0.000:1037 0.000:2867 0.000:2874 Távoli címek Állapot 0.000:0 0.000:0 0.000:0 0.000:0 0.000:0 0.000:0 0.000:0 0.000:0 0.000:0 LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP 0.000:2882 0.000:3037 0.000:3038 0.000:3111 0.000:3125 0.000:3128 0.000:3168 0.000:3489 0.000:3697 0.000:4487 0.000:4796 0.000:5044 TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP 127.001:1025 127.001:1025 127.001:1026 127.001:1028 127.001:1031 1 72.24 152xx: 137 172.24 152xx:138 1 72.24 152xx: 139 1 72.24 152xx: 1029 172.241 52 xx:3038 1 72.24 152xx:31 11 172.24 152 xx:3125 172.24152xx:3126 172.24152xx:3127 193.158209xx:80 193.158209xx:80 193.1 58 209xx:80 193.158209xx:80 193.158209xx:80 193.158209xx:80 193.1 58 209xx:80 193.158209xx:80 193.158209xx:80

193.158209xx:80 193.158209xx:137 193.158209xx:138 193.158209xx:139 193.158209xx:443 193.158209xx:443 193.158209xx:443 193. 158209 xx:443 193.158209xx:443 193.158209xx:443 193.158209xx:443 193.158209xx:443 TC P Prot. TCP TCP Helyi címek 193.158209xx:443 193.1 58 209xx:443 0.000:0 0.000:0 0.000:0 0.000:0 0.000:0 0.000:0 0.000:0 0.000:0 0.000:0 0.000:0 0.000:0 0.000:0 LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING LISTENING 0.000:0 127.001:1031 0.000:0 0.000:0 127.001:1025 0.000:0 0.000:0 0.000:0 0.000:0 172.241534:80 172.241534:80 172.241535:1435 172.241535:1435 172.241535:1435 0.000:0 62.27xx63:1036 62.46166,211:4232 62.46166211:4233 62.xx6 133236:57480 193.10144:1557 212.197145191:1042 212.19715761:1119 212.197158144:1073 217.2206133:4233 0.000:0 0.000:0 0.000:0 0.000:0 62.27130213:1182 62.27130213:1233 62.27130213:1234 62.27130213:1235 62.27130213:1236 62.27130213:1237 62.27130213:1238 Távoli címek 62.27130213:1240

62.27130213:1241 LISTENING LISTENING ESTABLISHED LISTENING LISTENING ESTABLISHED LISTENING LISTENING LISTENING LISTENING ESTABLISHED TIME WAIT ESTABLISHED TIME WAIT TIME WAIT LISTENING TIME WAIT TIME WAIT ESTABLISHED ESTABLISHED ESTABLISHED ESTABLISHED ESTABLISHED ESTABLISHED ESTABLISHED LISTENING LISTENING LISTENING LISTENING CLOSING TIME WAIT TIME WAIT TIME WAIT TIME WAIT TIME WAIT TIME WAIT Állapot TIME WAIT TIME WAIT TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP TCP UDP 193.158209xx:443 193.158209xx:443 193.158209xx:443 193.1 58 209xx:443 193.158209xx:443 193.1 58209 xx:443 193.158209xx:443 193.158209xx:443 193.158209xx:443 193.1 58209 xx:443 193.158209xx:443 193.158209xx:443 193.158209xx:443 193.158209xx:443 193.158209xx:443 193.158209xx:443 193.158209xx:443 193.158209xx:443 193.158209xx:443 193.158209xx:443 193.158209xx:443 193.158209xx:443 193.158209xx:443 193.1 58 209xx:443 1 93.1 58 209xx: 1030 193.158209xx:3128

0.000:135 62.27130213:1242 62.27130213:1243 62.27130213:1244 62.27130213:1245 62.27130213:1246 62.27130213:1247 62.27xx63:1037 62.27xx63:1038 62.27xx63:1039 62.27xx63:1040 62.27xx63:1041 62.27xx63:1042 62.27xx63:1043 62.27xx63:1044 62.5456xx: 11 94 62.15319xx:1182 62.15319xx:1184 62.15319xx:1185 62.15319xx:1186 62.xx6165xx:2326 63.1156 xx:1277 193.158 209xx:3121 193.158209xx:3128 209. 15459xx: 1202 0.000:0 193.158209xx:443 *: UDP 0.000:161 *: DP 172.24 152xx:137 *: UDP 172.24152xx:138 *: UDP 1 72.24 152xx: 1029 *: UDP 193.158209xx:137 *: UDP 193.24152xx:138 *: UDP 193.24152xx:1030 *: 1.35 Nincsenek logfájlok ezt biztosan az OFX irányítja TIME WAIT TIME WAIT TIME WAIT TIME WAIT TIME WAIT TIME WAIT TIME WAIT TIME WAIT TIME WAIT TIME WAIT TIME WAIT TIME WAIT TIME WAIT ESTABLISHED CLOSING TIME WAIT TIME WAIT TIME WAIT TIME WAIT TIME WAIT CLOSING TIME WAIT ESTABLISHED CLOSING LISTENING ESTABLISHED IIS logfájlokat egyáltalán nem találtak, sem a C:WINNT

system32LogFiles könyvtárban, sem máshol. Találtak viszont OFX-szoftver-jelentéseket, amelyek azonban nem adtak információt a kapcsolatokról. Feltételezték, hogy vagy a tűzfal log-okat értékelik ki, vagy teljesen lemondanak a loggolásról! Az OFX-ről A szerveren sem folyószámla-adatokat, sem adatbázis-jelszavakat vagy hasonlókat nem találtak. Ebből továbbra is arra következtettek, hogy ezeket központilag tárolják egy számítógépen, és ezt éri el, illetve kezeli az OFX szoftver. Az OFX-et az ASP-oldalakról - amelyek szokatlan módon nem VB scripteket, hanem JAVA scripteket használnak - vezérlik, és az adatokat nem lokálisan ellenőrzik; a felhasználói adatokat egy adatbázisba küldik, és ott hasonlítják össze. Tehát a tranzakcióknál a tranzakciók számai, a PIN és a felhasználó által megadott TAN az OFX-hez továbbítódik, amely aztán visszaadja a hibakódokat. 1.36 Adatátadás scriptekkel A szkennelés után világos lett,

milyen módon lehetne megtámadni a szervert. Természetesen pontosan megnézték, hogyan is fogadja és továbbítja a rendszer az adatokat bejelentkezéskor. Előkészületek (hozzáférés megszerzése) A megfelelő URL megadásával elérték a hozzáférést. A parancsfordító CMD.EXE-t a webszerver rendszerkönyvtárából a script-könyvtárba másolták, hogy működőképesen legyen kezelhető a böngészőből. Azonosítás és kapcsolat A weboldalakhoz vezető útvonal így nézett ki: C:InetpubRootBank. Ebben a könyvtárban volt egy alkönyvtár, amelybe csak egy kódolt kapcsolattal lehet bejutni. Ebben a könyvtárban volt azoknak a fájloknak a nagy része, amelyeket az online banki szolgáltatás használ. Az ügyfeleket felkérik, hogy gépeljék be 6- vagy 10-jegyű online számukat, PIN kódjukat, és a kívánt bankot (a •••-t vagy a •••-t). Ezeket az adatokat aztán egy Session Cookie-ban (kódolt, az SSL miatt) tárolja a rendszer. A szerver

támadhatóságának tesztelése A webszerver egy fatálisán szabványos exploitra volt érzékeny: http://www.de/scripts/%c255winnt/system32/cmdexe Itt egy hibáról volt szó egy átadott parancs dekódolásánál és legitimációjánál, ami végrehajtáshoz vezet. Megjegyzés: az adminisztrátor ezt a könyvtárat könyörtelelnül törölhette volna, mivel a bank scriptjei nem hajtanak végre bináris fájlokat, illetve nincs szükségük ilyenekre. Az IIS „sípolta" a konzolfájlok kiadását, például a CMD.EXE-t, ezért egyfajta shellt kaptak a böngészőn keresztül, ha a CMD.EXE-t a /c paraméterrel (egyedüli parancs) futtatták Tiltott kimenő kapcsolatok Az első terv az volt, hogy egyszerűen féltőkének egy trójait, ami azután kényelmes olvasási és írási elérést kínálna. Ez azonban meghiúsult azon, hogy tiltva voltak a kimenő kapcsolatok. Tehát engedélyezett kapcsolatból kellett olvasni és írni. Az olvasási elérés nem volt probléma:

az olvasandó fájlokat a webkönyvtárba másolták, letöltötték, majd törölték. A bökkenő az írás volt. Alapvetően az echo DOS-paranccsal lehet fájlokba írni A szövegkarakterekkel nem is volt gond, viszont bináris adatokat és metakaraktereket, mint pl.: <, l ,> nem lehetett írni A támadási tervről Bináris fájlokat ASP-scripttel írnak, illetve töltenek fel. Az ASPscriptet, amely szövegkarakterekből áll, meg lehet írni a CMD.EXE-vel Mivel azonban az ASP-hez és a HTML-hez is metakarakterek szükségesek, és a sorok „komplex" módon épülnek fel, ezeket nem lehetett a böngészőn keresztül bevinni, mivel a sornak URL kódoltnak kellett lennie, a sok nem alfanumerikus karakter miatt, és ezért a legrosszabb esetben háromszor olyan nagy lehetett volna. A sorokat tehát cookie-ként küldték el Az adatok, mint például a HTTP AGENT vagy a Remote-IP minden kérdésnél, környezeti változóként tárolódnak, és ezzel felhasználhatók más

alkalmazások számára is, amelyeknek a webszerver a környezete. A cookie-t mint HTTP COOKIE-t tárolták, és ezután az echo+%HTTP COOKIE% -val egyszerűen lehetett írni. Az utolsó és legnagyobb dobás az volt, hogy a metakaraktereket idézőjelekbe csomagolva a szintakszisnak megfelelően írták (az ASP-scripthez). Amint a feltöltő-script a szerveren volt, át lehetett írni a bejelentkező-scriptet úgy, hogy a bejelentkező adatok a felhasználói űrlapról közvetlenül egy logfájlba vándoroljanak. 1.37 Az adatletöltés A megváltoztatott scriptek a C:Temp 000043FA.ini könyvtárban tárolják a bank ügyfeleinek folyószámlaszámát, PIN-jét és IP-jét. Hogy ezt a fájlt le lehessen tölteni, ahhoz először a webkönyvtárba kellett másolni, majd egy hiperhivat-kozáson keresztül lehetett letölteni. Végül a fájlt törölni kellett, hogy ez a folyamat ne legyen olyan könnyen felfedezhető. Figyelembe kellett venni, hogy az első lépés már el volt

intézve, és ezért itt már nem kellett foglalkozni vele! A Bank.dat képernyője A logfájlokból kapott adatokkal most már be lehetett jelentkezni az ügyfelek folyószámlájára. Egy folyószámla képernyője Egy részvény-portfólió képernyője S még arra is nyílt lehetőség, hogy egy pillantást vessenek az ügyfelek részvényletétjére. 1.4 Utóirat a bank-hackeléshez A logfájlok áthúzása 2001.0804-től 2001 0831-ig folyt Ebben az időben több mint 1,5 millió adatot (online számokat, pineket, IP-címeket) mentettek le. Az adatokat végül az NDR jogi osztályának adták át, ahol bezárták egy széfbe ezeket. A •• bank a Hamburgi Területi Bíróságon 2001.1004-én elérte, hogy Ideiglenes Intézkedést adjanak ki, amelyben úgy ítéltek, hogy minden adatot vissza kell szolgáltatni nekik. Az NDR bizonyítékként csak egy másolatot tartott meg, amelyet egy semleges közjegyzőnek adtak át Hamburgban, és ott egy széfbe zárták. 1.5

Összefoglalás Az említett eseményeket követően a könyv szerzője elbeszélgetett az ismert német biztonsági szakértővel, Marc Riief-fel, a bankok biztonsági problematikájáról. Ruef pontosan ismeri a gondot, mivel néhány nagy bank biztonsági tanácsadója. A következőket mondta: „Sok bank webes fellépése megosztott. Ezzel azt akarom mondani, hogy van egy nyilvános rész, amelyet mindenki elérhet (WWW/HTTP). Azután van egy félig nyilványos terület, az e~banking, ahová csak az ügyfelek léphetnek be megfelelő azonosítást követően (WWW/SSL/SHTTP/ jelszóvédelem). A nyilvános részt elhanyagolhatják, ami gyakran így is történik (nem viszik túlzásba a biztonsági mechanizmusokat és irányvonalakat). Az e-banking területet védeni kell, és ez meg is történik (a legújabb patchek, biztosított rendszer, erős irányvonalak, megfelelő biztonsági intézkedések). A megfelelő szoftver és hardver a naplózáshoz és a biztonsághoz (pl.

tűzfalelemek és Intrusion Detection System) a pénzügyi szektorban aránylag gyakran a rendelkezésre áll (ellentétben más terület hálózati kapcsolattal működő cégeivel). Ezeknek az adminisztrációja is többnyire jó - de sajnos nem nagyon jó kezekben van. Szerintem a bökkenő a kiértékelésnél van Az erre hivatott rendszeradminisztrátorok, biztonsági megbízottak vagy auditorok nem tudnak mit kezdeni a biztonsági rendszer logfájljaival, mivel nincs meg a szükséges háttértudásuk. Öszszességében azt kell, hogy mondjam: vannak ilyenek és olyanok is. Láttam már olyan banki számítógépeket, hogy a legszívesebben abban a minutumban mondtam volna fel a folyószámlámat. És persze vannak olyan intézmények is, amelyek kitűnő kompetenciával tűnnek ki. Nem szabad valamennyit egy kalap alá venni. Mindenesetre bőven van még tennivaló" 1.6 Sajtóbeszámolók A bank-hackelés világszerte nagy visszhangot keltett. Számtalan újság és

rádióállomás számolt be az akcióról. Ebben az összefüggésben újra és újra előkerült a biztonság kérdése, íme két érdekes vélemény. A www.newsbytescom és a wwwwashingtonpostcom tudósításai Német tv-s hackerek bankszervert törtek fel per van kilátásban Ned Stafford, Newsbytes MÜNCHEN, NÉMETORSZÁG 2001. szept 17, du 4:51 ••••, Németország egyik legnagyobb bankja, a bank szóvivője szerint jogi lépéseket tervez egy népszerű fogyasztói high-tech tvshow ellen, amely hackereket szerződtetett, hogy feltörjék a bank online banking szerverét. Cornelia Klaila, a ••• müncheni szóvivője, ezt nyilatkozta a Newsbytes-nak: „Amit tettek, az törvénytelen. Nagyon törvénytelen. Az „ők", akikre utalt, a Technikai Tanácsadó nevű tv-show, amelyet az ARD, Németország két közszolgálati tévéhálózatának egyike gyárt. A Technikai Tanácsadó augusztusban felfogadott néhány fiatalembert, hogy betörjenek a •••

online banki szerverébe, és információkat töltsenek le az ügyfelek számláiról. Az információk neveket, számlaszámokat, PIN-számokat és internetes IP-számokat tartalmaztak, amelyek fontosak a biztonságos online banki szolgáltatáshoz. A sztorit vasárnap este közvetítették. Bernd Leptihn, a Technikai Tanácsadó (Ratgeber Technik) hírszerkesztő csoportjának hamburgi vezetője azt nyilatkozta a Newsbytes-nak, hogy nem aggódik a ••• perindítása miatt. Leptihn, aki 27 éve a Technical Adviser frontembere, de most a kamera mögött dolgozik, így ékelődött: „Tudják, én 30 éve csinálok törvénytelen dolgokat. Voltak pereim ezelőtt is, de mostanáig soha nem vesztettem el egyetlen ügyet sem." Azt mondta, hogy az ARD jogi részlege szerint az ilyesfajta oknyo-mozó újságírást megengedi a német jog, ha az „a köz érdekét szolgálja". Leptihn szerint, aki amúgy jól ismert személyiség Németországban, a nyilvánosság

informálása a ••• számítógépének hiányosságairól nagyon is a köz érdekében történt. „A (bankszámla) információkkal, amelyeknek a birtokába jutottunk, most akárhol is lehetnénk a világban, millió és millió euró birtokában" mondta. Leptihn arra is utalt, hogy a kutatás megmutatta, hogy a ••• banknál bizony van néhány nagy biztonsági rés. A bank a Microsoft Internet Information Serverét (IIS 4.0) használta A Technikai Tanácsadó megbízott egy négytagú hackercsapatot. Azt nem árulta el, hogy mennyit fizettek nekik, de ez „nem volt sok". A fiatal hackerek inkább abban voltak érdekeltek, hogy publicitást nyerjenek induló internetes biztonsági tanácsadó cégüknek - mondta. Négyük közül az egyik Stephan Weide, 22 évesen a Multimedia Network Systems cég ügyvezetője Leinefeldében. Weide azt nyilatkozta a Newsbytes-nak, hogy a betörés a ••• számítógépébe csak két-három napot vett igénybe, és

„igazán nem volt gond, bárki meg tudta volna tenni." Miután a Technikai Tanácsadó vasárnap éjszaka a tévében megszellőztette az ügyet, Weide azt mondta, hogy ő és a csapata részt vettek egy telekonferenciás hívásban a ••• technikai személyzetével, hogy megmondják nekik, hogyan tudják befoltozni a réseket. Mikor megkérdeztük, hogy a technikaiak hangot adtak-e haragjuknak a hackelés miatt, azt mondta: „Nem mondtak csúnya szavakat. Azt hiszem, féltek, hogy elveszítik az állásukat." Weide és Leptihn elmondták, hogy a ••• online banking oldala vasárnap késő éjjeltől kezdve úgy hat órára leállt. Klaila, a bank szóvivője, ezt nyomatékosan kétségbe vonta, s azt állította, hogy a weboldalt a szokásos rendszeres karbantartás és nem a biztonsági rések kijavítása miatt állították le. Azt is jelezte, hogy a ••• bank ezen a nyáron egy új online weboldalt helyezett üzembe, és hogy ez az oldal state-of-theart

rendszer, ami biztonságos. Augusztus hónap folyamán mint mondta -mindkét oldal, a régi és az új is online-ban voltak, és a hackerek a régi weboldalra, és nem az újra törtek be. A régi weboldalt szeptember elején offline-ba helyezték Leptihn viszont vitatta, hogy az új oldal az utolsó éjszaka előtt biztonságos lett volna. „A hackereink ismét próbálkoztak az új site-on, és sikerrel jártak" -állította. Klaila azt mondta, hogy bűntetőjogi és polgári peres kártérítési per is lehetséges a Technikai Tanácsadó ellen. „Még el kell döntenünk, mit is akarunk tenni." - vélekedett A zdnet.de News tudósítása ARD: Online banki szolgáltatásbeli hiányosságokat lepleztek le PIN-eket és TAN-eket olvastak ki bekapcsolt kamera előtt. 2001. szeptember 17, 08:46 óra Thüringiai hackerek a Ratgeber: Technik ARD-magazin megbízásából, működő kamera előtt törték fel a ••• biztonsági mechanizmusait, így a szerkesztőknek és

a szakértőknek a műsor adatai szerint lehetővé vált néhány napon belül 1,5 millió online könyvelési akciót megszerezni, beleértve titkos kódokat (PIN), az online-számokat (TAN) és az IP-címeket. Ahogy az ARD a továbbiakban közölte, a hackereknek dispokredit adatokat is sikerült elérniük, s így, a számlákat a kimerítésig terhelhették volna. Behatolásuk bizonyítására a betolakodók csupán egy 100 márkás könyvelésre „korlátozták magukat". A tévéadó komputeres szakemberei ismételten óvtak a trójaiktól, amelyek értelmetlenné teszik a pénzintézet kódolási eljárását. Még egy laptoppal és egy adatátvitelre alkalmas mobiltelefonnnal is gond nélkül lehet jogosulatlanul pénzt átutalni. Miután a magazin figyelmeztette a •••-t központi számítógépének a hiányosságaira, egy új log-in redszert vezettek be. Az adó által felfogadott hackerek azonban ebben az átdolgozott programban is találtak réseket. A Ratgeber

szerkesztősége szerint azért a •••.t választották, mert ez a bank különösen „lukacsosnak" bizonyult a jogosulatlan hozzáférésekkel szemben. De elvileg sok más banknál és takarékpénztárnál is lehetséges lenne egy virtuális betörés. 1.7 Tapaszatalatok más bankoknál Nem csak a ••• nincs felvértezve a támadások ellen, más bankoknál is csak félig-meddig sikeresek a szerverük védelmére irányuló intézkedések. 1.71 Forgatókönyv a takarékpénztár-területen 2001 októberében a szerző újabb megkeresést kapott valakitől, aki a különböző bankok visszásságainak a feltárására tararékpénztárak biztonsági auditjával bízta meg. A tapasztalatokból, amelyeket az előző akciókból gyűjtöttek, a következő terv született. Nyíltszívűen - a kleinmusterhauseni takarékpénztár Ennek a tararékpénztárnak olyan az internetes megoldása, mint a legtöbbnek Németoszágban: két részből áll. Van a nyilvános

rész, amelyben az ügyfél az illető tararékpénztárról információt szerezhet, és amelyen keresztül egy linkkel a folyószámlájához jut. Ez általában egészen egyszerű felépítésű. Többnyire egy helyben lévő vagy szolgáltatón keresztül kezelt szerverről van szó, amely csak nagyon egyszerűen védett, és a rendszergazda is szívesen elhanyagolja. Ezen a webszerveren gyakran tisztán reprezentatív célokból futnak olyan alkalmazások, amelyek nagyon támadhatóvá teszik a szervert. A második terület a tulajdonképpeni e-banking. Ezt a takarékpénztáraknál gyakran számítóközpontok kezelik. A szerverek többnyire jól védettek, és ki lehet indulni abból, hogy egy támadás ez ellen a számítógép ellen semmiféle sikerrel sem járna. Bepillantás egy német tararékpénztár jelszó-fájljába, egy maghatározott URL begépelésével Itt az átmenet a home-bankinghoz A támadási terv Először egy biztonsági rést próbáltak keresni,

amely lehetővé teszi az illető bank, illetve takarékpénztár nyilvános szerverének az elérését. Ez ebben az esetben egy script-hiba vagy egy hibás FTPszerver lenne, amelyen többnyire HBCI-eszközök meghajtóit vagy különböző online banking szoftverek frissítéseit tárolják. A betörés után megváltoztattak minden oldalt, amelyek a számítóközpontban elhelyezett tulajdonképpeni e-banking gépre mutattak. Isten hozta a tararékpénztárnál -csak az URL-nek kell a megfelelőnek lenni Példa egy tararékpénztári oldal forrásszövegére megfelelő linkeléssel a számítógép-központhoz A hamisítvány veszi át a szerepet A megfelelő oldal külleméről és működési módjáról rendelkezésre álló információk alapján hozzákezdtek egy hamisítvány felépítéséhez. Ez a hamisítvány a tuljdonképpeni e-banking számítógépet „tükrözné", tehát az ügyfeleket a helyi tararékpénztár prezentációjáról a megváltoztatott

Folyószámla vagy Onlinebanking link közvetlenül a hamisítványra vezeti. Az ügyfél ugyanazokat az információkat és opciókat látja maga előtt, mint a valódi e-banking gépen. Ha most egy átutaláshoz beírja az adatokat, ezek az adatok egy logfájlban landolnak. Mivel a tranzakciók egyike sem lesz végrehajtva, hanem csak a logfájlba vándorol, a tranzakciószámok továbbra is érvényben maradnak. „A kockázatokról és mellékhatásokról kérdezze banki tanácsadóját!" 3. fejezet - Tartalom 3.1 Az anonim internetezés csökkenti a kockázatot . 3.11 A legtöbb felhasználó sokat elárul312 Névtelenül 3.2 A TCP/IP 3.21 Mi a TCP/IP? 3.22 Különböző protokollok a rétegekben 3.3 Néhány alkalmazás és protokoll használata és a biztonságosságuk . 3.31 A Telnet 3.32 Az FTP 3.33 Az IRC 3.34 Az IP-címzés 3.4 A portokról 3 Alapok don szörfözünk a neten. Hogy ezeknek a részleteknek a nyilvánosságra kerülését hogyan

akadályozhatjuk meg, arról természetesen szintén itt olvashatunk. 3.11 A legtöbb felhasználó sokat elárul Aki szeretne többet megtudni a hackerek tevékenységéről, stratégiáiról és támadási lehetőségeiről, annak az internet alapjaival is közelebbi ismeretségbe kell kerülnie. Különben bizonyos támadási lehetőségek aligha követhetőek Ez a fejezet röviden bemutatja a legfontosabb információkat, amelyek a „hacker alapismeretek" és egyben a védekezés alapismeretei közé is tartoznak. Így némi bepillantás nyerhető a technikákba is, amelyek lehetővé tesznek bizonyos támadási módokat. Aki csak általában akar a hackerek tevékenységéről tájékozódni, annak ezt a fejezetet természetesen nem kell elolvasnia Így viszont sok minden messzemenően érthetetlen marad. 3.1 Az anonim internetezés csökkenti a kockázatot Ezt a fejezet az anonim szörfözésnek szenteltük. Ezzel akkor kell foglalkozni, ha nekikezdünk a háló

kémlelésének Az anonim szörfözés célja, hogy megakadályozzuk saját IP-címünk átadását másoknak. A jobb megértés kedvéért képzeljük el egyszer az IP-címet a következő összefüggésben: egy potencionális betörőnek - mert egy hacker nem jelent mást a PC-nk szempontjából - tudnia kell a pontos címet Csak ezután kezdhet hozzá, hogy kiderítse a lakásunk, illetve a házunk gyenge pontjait. E cím nélkül semmi sem történhet, de amint ez ismertté válik, igen jó rálátás kínálkozik az életkörülményeinkre és a szokásainkra. Az IP-cím nagyon pontos címzés, egy emelettel és lakásszámmal együtt megadott postacímhez hasonlít. Csak ennek az adatnak az ismeretében válik a nyitott konyhaablak - a PC-nk nyitott portjához hasonlóan - kockázattá. Először lássuk a legfontosabbakat a névtelen szörfözésről - hiszen a névjegykártyánkat sem osztogatjuk mindenütt. Ennek a fejezetnek az első része azt is megmutatja, milyen

információkat kaphatnak rólunk mások, ha „normál" mó- Egy szituáció, amelyben öntudatlanul is feladjuk az anonimitásunkat, eddig valószínűleg a legkevésbé tűnt fel. A kis web-bugokról van szó, illetve a clear GIF-ekről. Mindkettő hasonlít a talán már ismert cookie-khoz A web-bug egy parányi GIF-képecske (egy pixel méretű), amely valahol a weboldalba van integrálva, és a nézőnek egyáltalán nem tűnik fel, mivel egészen kicsi. Azonban átadja egy szervernek az IP-címet, a felkeresett oldal URL-jét, a web-bug GIFek URL-jét, az időpontot, amikor a web-bugot megnézték, a böngészőtípust, valamint egy korábban elhelyezett cookie információit. Ha egy oldalon, amely tartalmaz ilyen „bogárkát", személyes adatokat adunk meg, akkor ezeket a bugID-vel együtt lehet tárolni, és gyakorlatilag úgy működik, mint egy cookie csak ebből semmit nem lehet észrevenni, és kikapcsolni sem lehet! Tehát a legfontosabb, amit az anonim

szörfözésnél el kell titkolni, az az aktuális IP-cím, amelyet minden számítógép az internetre lépéskor kap. Az interneten megtett utat, amint az a lenti példából is látható, nagyon könnyen követni lehet az IP-címek segítségével. Mindenhol hagyunk hátra nyomokat, amelyek alapján hackerek figyelhetnek fel ránk, és ezáltal lehetőségük lesz pontosan kideríteni az identitásunkat, és esetleg károkat is okozhatnak nekünk. Az IP-cim minden alkalommal átmegy az adatokkal együtt, a mail-ékben, az IRC, ICQ vendégkönyvekben és a nyílt fórumokon. A „normál" és az anonim szörfözés közötti különbséget a http://privacy.net/anonymizer oldal teszi világossá Információk az Anonymizernél Úgy az IP, mint a teljes útvonal is felismerhető, amelyet a számítógép egy oldalhoz választott. Ha ezt az oldalt most egy anonymizeren keresztül keressük fel, csak annak a weboldalak az információi kerülnek ki, amelyről erre az oldalra

mentünk. Az IP-cím és az útvonal mellett előfordulhat, hogy a következő adatok mindegyike, vagy legalábbis néhány közülük ugyancsak láthatóvá válik idegenek számára: • Az IP-hez tartozó domain név. • Az oldal URL-je, amelyről az oldal linkjére kattintottunk (HTTPReferer). Egy rövidítés a használt webböngészőhöz, például Mozilla/4.7 [en] (X11; I; Linux 2.212 i686) a Netscape-hez (angol verzió) Ebből a rövidítésből mellesleg az is kiderül, hogy milyen operációs rendszer melyik verzióját használjuk, itt például Linux 2.212-t egy Intel PC-n • Sok böngésző az e-mail-címeket és/vagy a login neveket is továbbítja, amennyiben a böngésző ismeri ezeket (az e-mail-címet a böngésző jelszó ként is átadhatja egy anonim FTP-szerverhez való hozzáféréshez, vagy aktív tartalmakon keresztül, mint a JavaScript és hasonlók). • Cookie-k (ezek egy táblát akasztanak ránk, hogy: „Megint itt vagyok!") Irányok az

interneten, és az ott tartózkodás ideje. Talán már a fentiekből is világossá válhat, hogy mégiscsak meg kell őrizni valamennyire az anonimitást az internetes szörfözéskor. Hogy ez hogyan lehetséges, azt mindjárt kiderül 3.12 Névtelenül A cél tehát az, hogy titkosítsuk a saját IP-címünket, egy másikat vagy semmilyet se mutassunk, és lehetőség szerint minden egyéb adatunkat is elrejtsük. Egy előzetes megjegyzés: a saját IP-címünk egy internet-szolgáltatón keresztül történő szörfözéskor rendszerint dinamikus, tehát a szolgáltató minden újabb betárcsázáskor egy új, másik IP-t oszt ki - de természetesen ezt is ki lehet újból olvasni, mint minden más, fent nevezett információt. Azonban több lehetőség is van arra, hogy védekezzünk Íme, néhány ezek közül: s A legegyszerűbb, ahogy az előbb már említettük, az Anonymizer & Co. használata, például a http://anonsurf.de vagy a klasszikus http://www anonymizer.com Az

ilyen oldalak működési módja: az adatokat egy proxy-szerver többé-kevésbé szűri. Egy másik egyszerű módszer egy anonim proxy-szerveren keresztül konfigurálni a saját böngészőnk kapcsolatát. Ehhez egy kis magyarázat: A proxyk, hardverként vagy szoftverként, a kliens és a host szerver közé vannak kapcsolva, és a hostnak a proxy IP-t, és nem a dinamikus kliensIP-t mutatják. A kliens tehát össze van kötve a hosttal, a host azonban azt „hiszi" (az IP alapján), hogy csak (!) a proxy-szerverrel van összeköttetésben. Tehát a proxy képviseli a számítógépünket Hogy most megfelelően konfiguráljuk a böngészőnket, csak a szerver címét és a portot kell a böngésző Internet-beállításainál (legjobb, ha minden protokollhoz) megadni. Az aktuális proxy-szerverekről és csatlakozásaikról a http://www. cyberarmy.com/lists/proxy/ címen találunk listát Vannak még proxykeresőgépek is és hasonlók Magunk is beszerezhetünk egy

proxy-programot vagy egy scriptet, például a http://proxys4all.cginet címről Mostanában a Junkbuster program jött divatba (közelebbi információk a www.junkbistercom címen) A kezdőknek kicsit nehezebb ennek a szoftvernek a telepítése, cserébe viszont kedvezőbbek a lehetőségek, mert egyéni igények szerint konfigurálható. Így például le tudja nyomni a weboldalakon található reklámot • Egy további eszköz a jelenleg csak kevesek számára elérhető Mix-System, amely több állomásból áll, s ezekről üzeneteket küldenek. A koncepciót Dávid Chaum eredetileg e-mail küldéshez fejlesztette, azonban más háló szolgáltatásokra is átvihető. Minden Mix gyűjti a bejövő üzeneteket, szét válogatja, és egy bizonyos idő után továbbküldi. Így nem lehet összefüg gést teremteni a bejövő és a kimenő üzenetek között. Ha csak egyeden Mix is megbízhatóan működik, az egész rendszer megbízható, vagyis a felhasználó anonim marad. A

kommunikáció a Mixen belül kódolt, és így lehallgatni sem lehet. A Mix hátránya, hogy nagy hálózati terheltséget gerjeszt. A Mixek még nem állnak nyilvánosan rendelkezésre, csak egyes pilotprojekteket lehet találni. • A következő eszköz, amely az anonimitásról gondoskodhat, a Webwasher. Ez a szoftver Windows 95/98/NT/2000-hez és a Macintosh-hoz is meg jelent. Elsősorban arra szolgál, hogy kiszűrje a weboldalakról a reklámbannereket, az animált képeket és a pop-up menüket. Mindez a magánszféra védelmét szolgálja, mert megakadályozza az olvasó „zavará sát" a számtalan reklámbannerrel. A mi szempontunkból azonban inkább más tulajdonságai érdekesek: a Webwasherrel megakadályozható a HTTP-Referer küldése, azé az URL-é, amelyről az oldalra kattintottak. Ráadásul megadhatunk egy URL-listát, amelyet minden esetben ki kell szűrni, vagy át kell engedni. A Webwasher, user agentként, a valóban a webböngésző által elküldött

sztringeket küldi el. Alapértelmezésként ez egy bővítést kap, hogy a Webwashert használja, ezt azonban lekapcsol hatjuk. A Webwasher magáncélra ingyenes, és megtalálható a http://www.webwasherde címen • Azoknak, akiknek egy kicsit több idejük van és Linux-pártiak, a WWWoffle program lehet érdekes. A WWWoffle Unix/Linux rendszerek és Windows NT alatt fut. Létezik ugyan egy verziója Windows 95-höz is, ez azonban nem működik hibátlanul. Ez a proxy elsősorban cache-elő proxy-szerverként működik, és lehetővé teszi, hogy hálózati kapcsolat nélkül lehessen navigálni ebben a cache-ben. Az oldalakat, amelyekre rá kattintunk, de még nincsenek a cache-ben, feljegyzi egy listára, majd az online üzemre váltáskor kérésre automatikusan betölti. A cachetartalomban különböző kritériumok szerint közlekedhetünk, kilistáztathatjuk például az összes, vagy a legutóbbi kapcsolódás során meglátoga tott oldalt, esetleg minden oldalt, amelyeket a

következő online kapcso- latnál fog betölteni és hasonlókat. A cache-tartalmon belüli kereséshez kiegészítésképpen saját keresőgépet is lehet telepíteni Természetesen az is konfigurálható, hogy mi kerüljön a cache-be. A programot a webböngészőből lehet kezelni, beleértve az online és az offline módok közötti váltást is A mi szempontunkból a WWWoffle főleg azért lehet érdekes, mert a Junkbusterhez hasonlóan, itt is célzottan lehet definiálni a HTTPheadert. Pontosan megadhatjuk, hogy milyen fajta webdokumentumok és milyen HTML-kódba integrált scriptek megengedettek. Ezzel például letilthatjuk a frame-ek vagy a képek letöltését, vagy kiköthetjük, hogy távolítsa el a HTML-kódból a Java- vagy a JavaScript-elemeket. A WWWoffle-t FTP-proxyként is lehet használni, ilyenkor pontosan megadhatjuk, hogy milyen felhasználói névvel jelentkezzen be egy anonim FTP-szerverre, és nem kell ezt a véletlenre vagy a webböngészőbe beépített

alapértelmezésre bízni. • A proxy-knál még egy fontos szempontra kell ügyelni, amiről sokan telje sen megfeledkeznek. A JavaScript utólag mégis áthúzhatja a számításain kat. Még ha valóban anonim proxykat is használunk, egy weboldal mű ködtetője egy JavaScripten keresztül továbbra is le tudja kérdezni az IPcímeket. Sajnos a JavaScript funkciókat minden böngészőnél másképpen lehet célzottan inaktiválni, ezért ennek a leírásáról itt lemondunk. • Egy további kis anonimitási rés csak az Internet Explorer felhasználókra érvényes: ezek az Active Channelek. Ez a technológia először a Microsoft Internet Explorer 4.0-s verzióban jelent meg Hogy meghatározott információkhoz juthassunk, a böngészőben általában külső URL-ekre kell kattintani vagy be kell gépelni ezeket Az Active Channelekkel kiválaszthatunk egyet egy webszerver-üzemeltető ajánlatából (kezdőlap), amely a böngésző vagy az internetre kapcsolódás indításakor

betöltődik (tehát betárcsázáskor vagy állandó kapcsolat esetén a számítógép indításakor). Az egyént fenyegető veszély itt is az, hogy a csatorna előfizetője már nem anonim tölt le adatokat egy szerverről, hanem minden elérésnél újból felismerhetővé válik Az érdeklődési köre a kiválasztott channel(ek) alapján meghatározható. Az Active Channel technológia a már említett cookie-k személyre szabását használja. Tehát: ha nincs rá feltétlenül szükségünk, inkább kapcsoljuk ki • Ha egy hacker valami nagyobbat tervez, akkor beszerez magának néhány shell-accountot, és ezek után minden jogosultságot tesztel (pl. Loops) Sok szolgáltató kínál ingyenes shell-account-okat (ezek azonban jól ellen- őrzőttek), vagy vannak hackeroldalak, amelyeken frissen feltört accountok és login-ek vannak, amelyeket használni lehet. Sőt, a hackerek többnyire olyan rendszereket használnak platformként más rendszerek megtámadásához,

amelyeket már a hatalmukban tartanak, de a normális (legális) szörfözéshez az említett lehetőségek is teljesen elegendőek. Ha azonban valaki, a fenti tanácsokat megfogadva, elrejtette az IP-címét, akkor a kémprogram csak a proxy-szerverről gyűjthet „személyre szabott" információkat, amivel nekünk, felhasználóknak, nem sokat árthat. Hogyan működnek a protokollok? A két protokoll, a protokollok egymásra rétegződésén, „halmán" (angolul stack) keresztül működik. A protocol stack az az út, amelyet az adatoknak meg kell tenniük ahhoz, hogy az egyik számítógépből a másikba jussanak. A halom, amelynek a rétegei közül a TCP/IP csak kettőt, nevezetesen a 3. és 4 réteget használja, a következőképppen van felosztva: Réteg Leírás Alkalmazási réteg Az alkalmazási réteg képezi a csatolófelületet az alkalmazások között, amelyekkel a felhasználó parancsokat küld illetve fogad egy hálózaton keresztül.

Megjelenítő réteg 3.2 A TCP/IP Ebben a szakaszban néhány protokollt szeretnénk megismertetni, amelyeket a hálón használnak. A legfontosabbak közé tartozik a Transmission Control Protocol (TCP) és az Internet Protocol (IP). A most következő részben a protokolloknak azok a funkciói szerepelnek, amelyek nélkülözhetetlenek a későbbi célokhoz, így ennek a könyvnek a használatához az itt közölt tudás tökéletesen elegendő. Sajnos a téma olyan komplex, hogy a teljes kifejtése messze meghaladná e könyvnek a kereteit 3.21 Mi a TCP/IP? A megjelenítő rétegben a másik számítógép rendszerétől függően felhasználás-specifikus formattálások történnek. Session réteg Ez a réteg gondoskodik arról, hogy az alkalmazások között megszakadt kapcsolatok újból felálljanak és - az adatvesztés megakadályozása miatt - részben ugyanazon a helyen is folytatódjanak. Transzport réteg Ez a réteg gondoskodik a megbízható adatátvitelről a

két számítógép között, és gyakran csatolófelületként is szolgál a fölé rendelt alkalmazási rétegek és az alá rendelt hálózati rétegek között. Hálózati/ Ebben a rétegben folyik az optimális út (routing) keresése az kapcsolati réteg adatátvitelhez. A protokollt itt már a fölé rendelt rétegektől függetlenül ki lehet választani (pl.: IP) Adatbiztonsági réteg Ez a réteg arról gondoskodik, hogy lehetőleg ne legyenek hibás átvitelek, és ha mégis lennének, akkor az adatok helyre legyenek állítva. Fizikai réteg Ez a réteg felelős a fizikai kapcsolat létrehozásáért az adatok fogadásakor, illetve küldésekor. A TCP/IP két hálózati protokoll neve, amelyeket az interneten és a modern hálózatokban használnak: • Transmission Control Protocol (TCP) és Internet Protocol (IP). l A TCP és az IP azonban csak két protokoll-fajta a TCP/IP protokoll-családból. A TCP/IP protokoll-család a háló minden szolgáltatását elvégzi,

ide tartozik az e-mailek küldése, az adatok átvitele, hozzáférés a World Wide Webhez és az üzenetek szállítása a usenet-en keresztül. A TCP IP-protokollhalom rétegei az OSI-modell szerint Az adatok a számítógépből kifelé tartva az ábrázolt sorrendben futnak keresztül ezeken a rétegeken, és fordított sorrendben mennek befelé a célrendszerbe. Minden réteg tud adatokat küldeni a szomszédos rétegnek, illetve adatokat fogadni attól. Valamennyi réteg protokollokkal van összekötve, amelyek különböző szolgáltatásokat nyújtanak 3.22 Különböző protokollok a rétegekben Most már talán valamivel érthetőbb, hogyan történik a protokollhalmon keresztül az adatok küldése, illetve fogadása. Most megnézzük egy kicsit közelebbről a különböző rétegek legfontosabb protokolljait Parancs Leírás Chown Megváltoztatja a tulajdonost és a csoportot, amelyhez egy könyvtár és/vagy egy fájl tartozik. joe Egy egyszerű

szövegszerkesztő. A legfontosabb Telnet-parancsok Alkalmazási réteg Ez az a réteg, amelyben a felhasználó közvetlenül egy alkalmazásba írhatja be a parancsait, hogy kapcsolatot nyisson egy számítógéppel, vagy megfelelő parancsokat adjon ki. Fordított értelemben tehát az alkalmazási réteg az a réteg is, amelyből egy alkalmazás az A számítógépen a B számítógéptől is megkaphatja a parancsait. Ebben a rétegben egész sereg protokoll van, és ezeket felülről nem is határolja semmi Bizonyos alkalmazások itt más alkalmazásokra is épülhetnek. Ilyen például a HP egy SNMP-re épülő programja, az OpenView Most azonban nézzük ennek a rétegnek az alkalmazásait! Telnet A 80-as évek elején még nem voltak igazi hálózatok. Voltak viszont nagygépek, amelyekre terminálokat csatlakoztattak Egy terminál akkoriban csak kábelerdőn keresztül tudott adatot cserélni a nagygéppel, a további terminálokkal pedig egyáltalán nem kommunikálhatott.

Hogy egy újabb kábelrengeteg létesítését elkerüljék, szoftveres megoldásra volt szükség Így jött létre a Telnet, amely lehetővé tette a felhasználóknak, hogy úgy tudjanak adatokat szerkeszteni stb., mintha maguk ülnének a másik gép shell-je (DOS promptja) előtt. A felhasználó ilyenkor közvetlenül az alkalmazásnak kiadott paranccsal nyitott meg egy kapcsolatot. A legfontosabb Telnet-parancsokat az alábbi táblázat tartalmazza A Fik Transfer Protocol egy szolgáltatás, amely minden operációs rendszeren belül lehetővé teszi az adatok átvitelét és azoknak a mindenkori fájlformátumban mentését. Mint tudjuk, a legtöbb operációs rendszer különböző fájlformátumokat használ A Unix és a Unix-klónok gyakran NFS-t (Network File System) használnak, az OS/2 általában HPFS-t (High Performance File System), a DOS/Windows pedig kizárólag FAT-et (File Allocation Table) vagy FAT32-t, a Windows 2000 és az XP ezenkívül még az NTFS-t is

segítségül hívhatja. Az FTP-n keresztüli kommunikáció, akárcsak a Telnet, a kliens-szerver modellre épül, de valamivel komplexebb. Ebbe nem akarunk részletesebben belemenni, azonban a következő pontokat megemlítjük: A kommunikáció öt fázisra osztható: Fázis 1. fázis: Leírás A kliens kérdést küld a számítógépnek, hogy a szolgáltatás rendelke- Kapcsolatfelépítés zésre áll-e, az pedig megerősítést küld, hitelesíti a felhasználót és a jelszót, és átküldi az átviteli opciókat és a fájlnev(ek)et. 2 fázis: Leírás cd A paraméterként megadott könyvtárra vált. cd ~ bejelentkezett user home-könyvtárára vált. Mkdir New Az aktuálisan Létrehozza a New nevű Törli a New néven létrehozott könyvtárat. Is -l Megmutatja az aktuális könyvtárban található összes fájlt. chmod a hozzáférési jogokat a fájlokhoz és/vagy könyvtárakhoz. Megváltoztatja Kicserélik a portra vonatkozó információkat, és

előkészítik a tulajdon-Adatátviteli kap- képpeni adatátvitelt. Miután ezt rögzítették, elkezdődhet a tulajdon-csolat létesítése adatátvitel. 3 fázis: formában, aho-Adatátvitel Parancs könyvtárat. Rmdir New FTP gyan azt már leírtuk. 4 fázis: átadja a teljes állomány utolsó adatait, a kliens vissza-Az átvitel végének ezeknek a fájloknak a fogadását. Most a szervergép Close bevezetése küld a kliensnek, amely veszi a parancsot, és elfogadja. 5 fázis: adateljárás mutatja a kontrolleljárásának (21. port) az átvi-Az átvitel bezárul. A kliens-adateljárás szintén terminál, a kontroli-lezárása azonban aktívan hagyja a további átvitelekhez. Az öt kommunikációs fázis az FTP-nél képpeni Az adatátvitel az FTP-n keresztül történik, abban a A számítógép igazolja parancsot A szervertel végét, és eljárást Az FTP alatt rendelkezésre álló közel 60 parancsból itt csak a legfontosabbakat szeretnénk felsorolni:

Parancs Leírás ftp host Ezzel indul az FTP-kapcsolat a hosthoz. open host Ha egy hosthoz még nincs kapcsolat, a felhasználó azonban már az FTP környezetben található, az open host paranccsal lehet felépíteni az említett kapcsolódást. user user Ha már fennáll a kapcsolat a hosttal, a felhasználó azonban még nincs bejelentkezve, a user paranccsal loggolhat be utólag. ascii ASCII-re állítja az adatátviteli módot. binary Binárisra állítja az adatátviteli módot. bell akusztikus jel. cr szükség, ahol lemez nélküli munkaállomásokat (diskless-workstations) üzemeltetnek, mert ezek nem tudják tárolni a logikai címüket. Bootolás alatt itt nem a tulajdonképpeni indítást értik, hanem csak a fontos konfigurációs adatok átvételét. Minden fájltranszfer után elhangzik egy Kapcsoló: ha a cr be van kapcsolva (default), akkor a RETURN/LINEFEED karakterek LINEFEED-re módosulnak. prompt Kapcsoló: ha a prompt be van kapcsolva (default),

akkor több fájl átvitelénél minden fájl után egy interaktív lekérdezés következik. SMTP A Simple Mail Transfer Protocol alighanem a legtöbbet használt protokoll az interneten. Az SMTP már a kezdet kezdetén a Unix-rendszerekre rendezkedett be, és időközben a normál PC-ken is megtalálta a helyét A felhasználó itt kezeli a mail-szoftverét, és itt készít elő egy üzenetet. Ha ezután elküldi az üzenetét, akkor ez annyi időre kerül a köztes tárba, amíg a TCP a teljes üzenetet (az OSI modell keretei között) átviszi. A kliensnek és a szervernek itt is egy sor parancs, illetve reakció áll a rendelkezésére, amelyeket most nem sorolunk fel. Helyette a szerver és a kliens közti kis párbeszédet mutatjuk be (közben a szerver részéről mindig pozitív válaszból indulunk ki): • A kliens session-t épít fel a szerverhez. A legfontosabb FTP-parancsok TFTP A Trivial Fik Transfer Protocol nem a TCP-re épül, mint az előbb tárgyalt FTP,

hanem az UDP-re (User Datagram Protocol). Bár ez is adatok átvitelét szolgálja, de nem a végfelhasználó számára készült, mivel a kapcsolat biztosítatlan. Ezeknél az átviteleknél nincsen jelszólekérdezés, csak a forrás-IP marad hátra, hogy rendelkezésre álljon a szükséges tartomány. A legfontosabb parancsok itt a connect, a mode, a get, a put, a verbose és a quit Most csak néhány szó arról, hogyan is folyik itt az adatátvitel. A TFTP ugyancsak a kliens-szerver elvre épül. A kliens egy kérést küld a szervernek, az nyugtázza, és megkezdődik az adatátvitel. Minden adatrekord 512 bájtos, és a szerver nyugtázza. A kliens akkor tételezi fel automatikusan az átvitel végét, ha a fogadott rekord 512 bájtnál rövidebb. BOOTP A Boot Protocol is az UDP-re (Use Datagram Protocol) épül, és tulajdonképpen csak arra fejlesztették, hogy boot-folyamatokat aktiváljon. Erre csak ott van • A szerver megerősíti a szervizek rendelkezésre

állását. • A kliens azonosítja magát. • A szerver azonosítja magát. • A kliens átadja a tulajdoképpeni parancsot, amely mail-küldést jelent be. • A szerver a beleegyezését adja • A kliens átküldi a címzettet. • A szerver válaszol: a postafiók elérhető. • A kliens inicializálja az adatátvitelt. • A szerver felveszi az adatokat, és a befejezéshez kéri a <crlf><crlf> paran csot. • A kliens az átvitel befejezése után, ahogy megállapodtak, elküldi a <crlf><crlf> -et. • A kliens a megfelelő paranccsal befejezi a kapcsolatot. • A szerver erre service closing-gal felel. Mikor a 80-as években más mail-rendszereket is bevezettek, kompatibilitási problémák léptek fel. Az átmenetekkel nem volt könnyű megbirkózni, így nagyon körülményes konvertereket kellett alkalmazni 1992 óta nagyjából csak a MIME-t (Multipurpose Internet Mail Extensions) használják, amely már nem korlátozódik csak a tiszta

szövegküldésre, hanem a legkülönbözőbb adattípusokat, mint grafika, audió stb. is át lehet küldeni vele RPC A Remote Procedure Calls-t akkor használják, ha több különböző kapacitású számítógép áll rendelkezésre, és olyan feladatot kell elvégezni, amely nagyon nagy rendszererőforrásokat igényelne. Az RPC-vel a részfeladatokat specifikusan az arra legjobban kvalifikált számítógéphez lehet rendelni, így a különböző számítógépek, mondhatni, egy multikomputerré olvadnak össze. Ez az eljárás egyébként mostanában egyre nagyobb figyelmet vívott ki magának a nagyvállalatoknál és a kutatóintézeteknél. A pontosabb felépítésébe itt nem megyünk bele A transzport rétegnek a következő feladatokat kell ellátnia: • Lehetővé tenni az adatátvitelt dedikált transzportkapcsolatokon keresztül. • A kapcsolatokat ellenőrzötten kell felépíteni és bezárni. Multiplexing: egy kommunikációs csatorna felépítése, amelyet több

jel egyidejű átvitelére lehet használni. • Ellenőrzés, hibafelismerés és folyamatvezérlés a kapcsolat alatt. • Optimalizált adatfolyam - Windowing-nak is nevezik. • Az adatfolyamok priorizálása, vagyis az adatfolyam prioritások szerinti elküldése. A transzport rétegben két protokoll található, a már említett TCP és az UDP (User Datagram Protocol). Transmission Control Protocol (TCP) NIS A Network Information Services műveletek biztonsági objektumok és elérési jogok kezelésére szolgálnak. Ez a rendszer, amelyet eredetileg a SUN fejlesztett (akkoriban Yellow Pages volt a neve), lehetővé teszi a decentralizált userID-k, GroupID-k és jelszavak központi adminisztrációját. A NIS működtetéséhez a következő komponensekre van szükség: • A NIS-adatbázis egy túlméretezett /etc/passwd-fájlt jelenít meg a hálózat számára. • A NIS-Master-Server a megfelelő domainekkel kezeli a NIS-adatbázist. • A NIS-Slave-Server az adatbázis

egy biztonsági másolatát tartalmazza a master-szerver kiesésének az esetére. • Transzport réteg A NIS-domain a NIS-adatbázisban leképezett számítógépek csoportja. • A NIS-Client egy számítógép, amely a szervertől kap adatokat, de nem tudja megváltoztatni ezeket. A TCP a következőkre képes: • Adatfolyam-átvitel • Virtuális full-duplex kapcsolatok • Adatfolyam-vezérlés • Hibafelismerés • Prioritásvezérlés A TCP az egyik fő protokoll, és a protokoll-család más tagjaival szemben, valamennyi adat megbízható átvitelét garantálja. Ebben a hibaellenőrzés átfogó funkciói segítenek, gondoskodva arról, hogy a fogadott adatok ugyanabban az állapotban és sorrendben érkezzenek meg, amelyben azokat elküldték. Így például minden elküldött csomaghoz egy numerikus értéket generál Ennek az értéknek a segítségével a két egymással összeköttetésben álló számítógép minden csomagot azonosít. A címzett minden

fogadott csomagról egy üzenetet küld a feladónak, s ez igazolja az átvitel tökéletességét. Ha egyszer mégis hiba fordulna elő az adatátvitelben, a címzett ennek megfelelő üzenetet küld a feladónak, és újrakéri az érintett csomagot. A TCP azt is felügyeli, hogy nem lépett-e fel súlyos hiba az adatátvitelben, és ebben az esetben automatikusan megszakítja a kapcsolatot a másik számítógéppel. Ismételten átküldi az adatokat, ha a célszámítógép egy bizonyos idő alatt nem küld megerősítést a fogadásukról. Ebből látszik, hogy a TCP teljes mértékben megfelel a hírének, miszerint biztonságos átviteli protokoll. Egy alkalmazás, mint például az Internet Explorer, a TCP-re bízhatja a kapcsolat felépítését; ehhez persze még más fontos protokollokra is szükség van. Ezt a kapcsolatot egy három részből álló folyamat vezeti be, amelyet three-wayhandshake-nek neveznek. 1. A kérdező számítógép, illetve a kliens elküldi a

kapcsolatra irányuló ké rést, és megad egy portot, amellyel a távoli számítógéphez, illetve a szerverhez szeretne kapcsolódni. 2. A szerver megerősítéssel és egy várakozási listával (a kapcsolathoz) válaszol 3. A kliens megerősítéssel válaszol, és a kapcsolat felépül A kapcsolat megnyitása után mindkét irányba áramolhatnak az adatok. User Datagram Protocol (UDP) 111 Szolg.: SUN RPC DNS 53 161 69 SNMP TFTP 25 SMTP 32 FTP 23 80 TELNET HTTP Protokoll User Datagram Protocol (UDP) Transmission Control Protocol (TCP) Szolgáltatások és az UDP/TCP Internet Protocol (IP) Az Internet Protocol felelős az adatcsomagok átviteléért a TCP/IP valamennyi protokolljánál. Az Internet Protocol egy headerből és az azt követő adatblokkból áll, amely többek között az adatcsomagok fragmentálásáért is felelős. A fragmentálás itt azt jelenti, hogy egy adatcsomag legfeljebb 65535 bájt méretű lehet. Ha egy csomag ennél nagyobb, az

lefagyaszthatja a PC-t. Ezt nevezik puffer túlcsordulásnak (Buffer Owerflow), amelyről később, a DoS-támadásokról szóló fejezetben többet mondunk Hogy ezt elkerüljék, a csomagot részcsomagokra darabolják A elküldött csomagokat a célrendszerben újból egyesítik Az összerakás reassembly néven ismertebb. Ezt a bonyolult folyamatot megpróbáljuk egy header-modell segítségével megmagyarázni: Version Az UDP biztosítatlan protokoll, amely a TCP-nél említett tulajdonságok egyikével sem dicsekedhet. Ugyanúgy biztosítatlan, mint azok a protokollok, amelyeket a transzportréteg alatti rétegek tartalmaznak. Az ok, amiért az UDP mégis az átviteli réteghez tartozik: az IP ugyan elő tud állítani kapcsolatokat, azonban nem tud adatokat továbbítani az alkalmazásoknak. Az UDP ezt ugyanúgy tudja, mint a TCP. Az UDP azonban nem kéri a fogadás megerősítését Az UDP tehát, mondhatni, egy alkalmazáscsatoló-felület az IP-hez A UDP-header is roppant

rövidre fogott: információkat tartalmaz a kiinduló portról, a célportról, az adatok hosszáról, és közli a UDP-header adatainak az ellenőrzőszámát. A következő kis táblázat példákat mutat arra, hogy milyen szolgáltatások érhetők el az UDP-vel, illetve a TCP-vel. Port: Hálózati réteg Ez a réteg különböző protokollokat fog össze, amelyek aktívan vesznek részt az adatok átvitelében, például: Flags | HL Type of Service Totál Length Indentification Fragment Offset TTL Protocol Header Checksum Source Address Destination Address Options Padding Data Version: az IP-verziót jelöli. Az interneten pillanatnyilag még a 4 verziót használják, azonban közeledik a váltás a 6. verzióra, amelyet néhány helyi hálózatban (LAN) már használnak IHL vagy HL (Internet Header Length): az IP-header hossza 32 bites blokkokban van megadva. Type of Service: minden bitnek csak ajánlókaraktere van. A Precedence lehetőséget nyújt a

vezérlőinformációk előnyben részesítésére Totál Lenght: az adatcsomag teljes hossza bájtban (max. 64 Kbájt) Identification: egy adatcsomag egyértelmű ismertetőjele. Ennek a mezőnek és a Source Address-nek a segítségével ismerhető fel a töredékadatok összetartozósága. Ezek és a két következő mező vezérlik a reassembly-t (ld feljebb) Flags: a két bitnek a következő a jelentése: • Dont fragment: olyan hostokhoz, amelyek nem támogatják a fragmentálást. • More fragments: hogy kiderüljön, hogy egy adatcsomag minden fragmentumát fogadta-e. Fragment Offset: egy adatcsomag adatbájtjait számozza, és kiosztja a fragmentumoknak. Az első fragmentum offset O-t kap, minden továbbinál egy fragmentum adatmezőjének a hosszával növekszik az érték Ennek az értéknek a segítségével tudja a címzett megállapítani, hogy hiányoznak-e töredékek. Time-to-Life (TTL): Minden csomagnak van egy előre megadott maximális élettartama, amit itt

lehet megadni. Routolási hibánál, például huroknál, az adatcsomag valamikor el lesz távolítva a hálózatról. Mivel az időmérés meglehetősen problematikus a hálózatban, és a headerben nincs feljegyezve indulási idő, minden router úgy dekrementálja (kicsinyíti) a csomagot átfutáskor, hogy az egyszer 0 értékre csökkenjen. Ekkor a következő router már nem veszi fel Protocol: Mivel a különböző protokollok az IP-re támaszkodnak, meg kell adni a fölérendelt ULP (Upper Layer Protocol) protokollt. A fontos ULP-k: ULP Leírás 1 ICMP (Internet Control Message Protocol) 3 GGP (Gateway-to-Gateway Protocol) 6 (Transmission Control Protocol) 8 (Exterior Gateway Protocol) 17 TCP EGP UDP (User Datagram Protocol) A legfontosabb ULP-k Header Checksum: az IP-header ellenőrzőszáma. Mivel a TTL-érték (Time to Life) és esetleg a flag és a flag offset értékei is minden routernél változnak, ennek megfelelően kell alakítani az ellenőrzőszámot.

Ezáltal teljesül a 1 6 bites hosszúságparitás. A felesleges késleltetések elkerülése érdekében a header ellenőrzőszámára korlátozódik Source Address: a forrásállomás internetcíme. Itt van feljegyezve a küldő számítógép IP-címe Destination Address: a célállomás internetcíme. Itt van feljegyezve a fogadó számítógép IP-címe. Options: opcionális mező további információknak. Sok kódot már a jövőbeli kiegészítésekhez terveztek. Az opciók mindenekelőtt a hálózati vezérlést, a hibakeresést és a méréseket szolgálják A legfontosabbak: • Record Route: naplózza az adatcsomag útját. • Loose Source Routing: a küldőállomás előír néhány közbeeső állomást. • Strict Source Routing: a küldőállomás minden közbeeső állomást előír. • Timestamp Option: az IP-címe helyett, akárcsak a record route-nál, minden gateway a feldolgozás időpontját jegyzi be. • Padding: kitöltő bitek. A padding feladata, hogy

bináris nullákkal 32 bitesre egészítse ki a frame-et Mint látjuk, az internetprotokoll igazán komplex, de mindez együtt csakis az adatok átvitelét szolgálja. Address Resolution Protocol (ARP) Egy hálózatban minden számítógépnek van egy, a firmware által előre definiált fizikai címe. A számítógépes kommunikációhoz azonban nem fizikai, hanem logikai címet használnak, amelyet például az interneten találunk A hálózati meghajtó egymagában nem képes arra, hogy a logikai címén szólítsa meg a számítógépet, mivel semmilyen módon nem áll összeköttetésben a vezérlő hardvercímével. Tehát a logikai címet a fizikai címre kell cserélni Erre szolgál az ARP. Ez egy headerből és az ARP-csomagból áll, és tartalmazza a szükséges adatokat a logikai forrás-protokollcímhez és a fizikai címhez is. Reverse Address Resolution Protocol (RARP) A RARP az ARP-vel ellenkező irányban működik. Ahelyett, hogy a logikai címből állítaná elő a

fizikait, a host egy RARP-kérést küld a fizikai címmel, amire azután a RARP-szerverek a hálózatban átnézik a saját referencia-táblázataikat, és egy RARP-választ küldenek vissza, amely tartalmazza a logikai címet. Ezt a módszert tulajdonképpen csak olyan számítógépeknél használják, amelyeknek nincs olyan adathordozójuk, amelyben tartós, logikai címet tudnának tárolni, és ezért mindig csak a fizikai cím ismeretével bootolnak a hálózatba. Internet Control Message Protocol (ICMP) Az ICMP feladata az üzenetek, például a hibaüzenetek közvetítése. Ugyanúgy használja az IP-t, mintha maga is egy fölérendelt protokoll lenne, azonban az IP szoros alkotórésze. Lista a hibaüzenetekről, amelyeket az ICMP küld: Szám 3 Leírás Destination unreachable: a célállomás nem érhető el. 4 Source quench: puffer-erőforrások elhasználva. 5 Redirect: útvonal-elterelés. 11 lefutott. 12 Time exceeded: a timer Paraméter Problem:

Paraméter-probléma. 3.31 A Telnet A Telnetet az RFC 854 (Request for Comment, az internetfejlesztők egy munkafeljegyzése, http://www.ietforg/) a következőképpen definiálja: A Telnet protokoll célja egy általános, mindkét irányra kiterjedő, 8 bit/bájt-orientált kommunikációs lehetőséget nyújtani. A fő cél egy szabványos módszer létrehozása a végkészülékeken alapuló folyamatok összekötésére A Telnet tehát lehetővé teszi a felhasználóknak, hogy távoli számítógépekre jelentkezzenek be az interneten, és parancsokat hajtassanak végre ezeken a számítógépeken. Sőt, a Telneten keresztül programokat is el lehet indítani távoli rendszereken, ehhez a Telnet egy terminált szimulál (szöveg, grafika nélkül). Windows alatt egy Telnet-kapcsolat a következők szerint épülhet fel: Az ICMP hibaüzeneteinek listája s És egy lista az információs üzenetekről: Szám Leírás 0 Echo reply 8 Echo request 13 Timestamp 14 Time stamp

reply 15 1. Windows 95/98 (és magasabb verzió) alatt kattintsunk a Start/Futtatásra, mire megjelenik egy kis párbeszédablak. 2. Gépeljük be a telnetexe sort 3. Kattintsunk az OK-ra, a Telnet elindul 4. A szokásos módon tárcsázzunk be a szolgáltatónkhoz 5. Váltsunk vissza a Telnet-re Information request 16 6. Kattintsunk a Hálózati rendszer kapcsolatra Megjelenik egy párbeszédablak Information reply 17 7. Beírjuk a következőket: Adress mask request 18 Adress mask reply Az ICMP információs üzeneteinek a listája Az IP ezután megfelelően módosul, és az adatok visszajönnek a számítógépre. 3.3 Néhány alkalmazás és protokoll használata és a biztonságosságuk Ezeknek a protokolloknak a használata és a lehetséges biztonságosságuk fontos előfeltételei a hackerek cselekményeinek. • Hostnév: meine-domain.de • Csatlakozás: telnet • terminál típus: vt 100 8. Kattintsunk a Kapcsolatra 9. Most megjelenik: Welcome, a szerver

üdvözöl, és készen áll 10. Adjuk meg a login-nevünket Ez az a név, amelyet az FTP-nél is haszná lunk (ld. lejjebb) 11. Ezután nyomjuk le az Enter-t 12. Most a szerver a jelszót akarja tudni Ez ugyanaz a folyamat, mint az FTP-nél. 13. Ne zavartassuk magunkat, amiért nem látjuk, amit írunk, a jelszó beírása nem látható. A CuteFTP felülete 14. Üssük le még egyszer az Enter-t 15. Most kapcsolatban vagyunk a szerverrel A parancssort lehet látni, pl bubis$ bubis2$, b3$ stb. 16. Most be lehet írni a parancsokat Felépül a Telnet-kapcsolat A Telnettel az az egy gond van, hogy minden adatot kódolatlan szövegként visz át. Mivel a Telnet felhasználóazonosítást kíván (loginnév, jelszó), egy betolakodó, ha beleolvas a hálózati forgalomba, nagyon könnyen megszerezheti a fiókadatokat. 3.32 Az FTP Az FTP a távoli rendszerek közötti adatátvitel egyik módszere. Az FTP-t az RFC (Request for Comments, biztonsági kézikönyv) így mutatja be: Az

FTP feladata 1. adatok (programok és/vagy adatok) közhaszmú átvitele, 2 távoli számítógépek indirekt vagy implicit (programokon keresztüli) használatának az elősegítése, 3. a különböző rendszerek fájlrendszerei közötti strukturális különbségekből adódó vesződségek megspórolása és 4. adatok megbízható és hatékony átvitele Bár az FTP-t egy terminálon közvetlenül is lehet használni, elsősorban programokon keresztüli használatra fejlesztették. Az FTP-s adatátvitel egy FTP kliensen keresztül történik, ilyen például a CuteFTp vagy a WS FTP. A kliens egy kérdést küld a távoli számítógép FTP szerverének. Ezt a kérdést a 21 porton keresztül teszi fel Egy kapcsolat létrehozásához, FTP-szervernek, illetve FTP daemonnak kell futnia a célszámítógépen. Az FTP-nek két fajtája van: a User-FTP és az Anonymus-FTP. A user-FTPnél a felhasználónak a login-nevével és a jelszavával kell a szerverre bejentkeznie. Az Anonymus

FTP-nél bárki bejelentkezhet a szerverre Loginnévként többnyire Anonymus-t, és jelszóként egy e-mail-címet kell beírni Ezzel az FTP-szerver nyilvános részéhez kapunk hozzáférést Az Anonymus-FTP fontos szolgáltatás az interneten, mert általa a programok vagy a dokumentációk minden internet-felhasználó számára elérhetők. Az FTP biztonsága Az FTP nem túl biztonságos protokoll, s különbözőképpen támadható. Íme a legfontosabb támadási formák. Jelszótámadások Az FTP igen alkalmas a jelszavak kipróbálására, mivel a szabvány konfigurációban nincs korlátozás a jelszavak beírására, tehát akárhányszor meg lehet adni a jelszót. Ezt a támadást Brute Force-rohamnak is nevezik Egyes FTPszervereknél ki lehet találni az érvényes login-neveket Ha valaki érvénytelen login-nevet ad meg, akkor a szerver hibakóddal válaszol. Paket-Sniffing Mivel az FTP kódolatlan szövegként továbbítja az adatokat, ha egy betörő beleolvas a

hálózati forgalmakba, felhasználói adatok birtokába juthat. Erről a snifferekről szóló fejezetben további részleteket tudhatnak meg. Szoftverfeltöltés Sok FTP-szerverre lehet Anonymus-belépéssel szoftvert feltölteni (upload). Egy támadó ezen a módon manipulált szoftvert helyezhet el a szerveren (vírus, trójai). 3.33 Az IRC Az IRC (Internet Relay Chat) az e-mail mellett az egyik legkedveltebb szolgáltatás az interneten. Többrésztvevős valós idejű konferenciákat tesz lehetővé Az IRC-nél a felhasználók, szervertől függően (IRC szerver, pl. irceuircnet), a legkülönbözőbb csatornákon (channels) lehetnek. A beszélgetésekhez ma már a számos IRC kliens valamelyikét használják. A legismertebbek közé tartoznak a mIRC, a BitchC és a pIRCh. IRC-felület jelszófájlt. De az IRC-parancsokból is sok információt tudhat meg egy hacker a felhasználóról, amelyek a segítségére lehetnek a további támadásoknál. További veszélyt

jelenthet a fájlcsere is, ahol mindig szívesen küldenek trójaiakat és vírusokat (ld. a trójaiaknál) A legnagyobb veszélyt azonban maguk a kliens- illetve a szerverprogramok jelentik A rosszul konfigurált kliensprogramok gyakran több elérést engednek meg a szervereknek a helyi erőforrásokra (pl. fájlokra), mint amennyi tanácsos volna. 3.34 Az IP-címzés A címzés az interneten az IP-címzésen alapul. Az interneten minden erőforrás egy egyértelmű számmal, az IP-címmel érhető el Az IP-címek kiosztása hierarchikus, ami azt jelenti, hogy egy ügyfél a szolgáltatójától kapja meg a szükséges IP-címet, a szolgáltató megintcsak a hálózattól kölcsönzi az IP-címeit, amelyre csatlakozik, miközben a hálózatok üzemeltetői időbeli korlátozás nélkül, blokkokban kölcsönzik IP-címeiket, az IP Numbering Authorities-től. Európában a RIPE (http://wwwripenet/) felelős az IP-címek kiosztásáért Hogyan néz ki egy IP-cím? A jelenleg

használt IP-protokoll az IPv4. Minden IP-cím 32 bitből áll Mivel az ilyen számkombinációk igen körülményesek, többnyire a pontozott tizedes írásmódot használják, amelynél a 32 bit 8 bitekre van felosztva, és ezeket decimális számként írják le. Eszerint egy IP-cím négy bájtból áll: 11000010 194 Pl: 11000010 128 1 1 1 0 0 0 1 Az IRC kiválóan alkalmas a Social Engineering-re. Leginkább az újoncok vehetők rá arra, hogy bizonyos parancsokat, amelyeket a chat-en mondott nekik valaki, végrehajtsanak. Egy támadó elküldetheti például e-mailben magának a 01001101 77 64 32 01111100 124 16 8 00100011 35 4 2 0 Minden kvadráns egy 0 és 255 közti számot reprezentál, így ezzel a négy szegmenssel elméletileg több mint négymilliárd (pontosan: 4 294 967 296) címet lehet kezelni. IP hálózati osztályok Időközben kiderült, hogy négymilliárd IP-címet nagyon nehezen tud egyetlen intézmény kezelni. A tehermentesítés céljából az

InterNIC, amely a 90-es évek elején átvette az IP-címek kezelését, az egyes IP-címterek kezelését nemzeti NIC-eknek és nagyvállalatoknak adta át, amelyek, az InterNIC-től függetlenül, önállóan oszthatták ki a hozzájuk utalt címtartományokat. Így jöttek létre a hálózati osztályok (pl aaabbbxx), amelyekben csak az első negyedet határozza meg egy NIC, a maradék háromnegyedet szabadon lehet kiadni. Ennek megfelelően a négymilliárd IP-címet ismét három osztályba sorolták, az A-, B- és C-osztályú hálózatokba. Címek Leírás x.xx0 és Minden IP-címben a negyedik szegmensben a 0 és 255 értékek a rend- x.xx255 szertől függően zárolva vannak; a 0 a subnet megnevezésére szolgál (0 alatt a negyedik negyedben minden gépet értünk 1 -254-ig), a 255 a negyedik negyedben broadcast-címként szolgál (ezzel az értékkel érhető el egy subnet minden számítógépe). 127.xxxx Minden IP-cím, amelynek ez az első szegmense, TCP/IP

visszacsatolási hurokként szolgál. TCP/IP-installációk tesztelésére szolgálnak a számítógépeken (egy pinggel egy tetszőleges 127-es címre). 10xxx Ez az A-osztályú hálózat egy internetre kapcsolódó intranet helyi gépei számára van fenntartva. Ezen az A-osztályú hálózaton belüli IP-címeket csak az intraneten belül lehet routolni. 17216xx Ez a 16 Címek Leírás B-osztályú hálózat ugyancsak egy internetre kapcsolódó intranet 172.31xx-ig aaa.xxx Az A-osztályú hálózatok az első negyedben 1 és 126 közötti értékeket gépei számára van fenntartva. E B-osztályú hálózatokon belüli IP-címeket csak az tartalmaznak. Az A-osztályú hálózatok tulajdonosai az InterNIC-től (ami most is minden A- intraneten belül lehet routolni. 192168 osztályú hálózatot kezel) kapják az első negyedet, és az IP-cím fennmaradó 24 bitjét internetre kapcsolódó intra-00192.168 maguk adhatják ki. Az A-osztályú hálózatokat azonban mára

már mind kiosztották, C-osztályú hálózatokon 255.255-ig így nem lehet újat létesíteni az interneten. aaabbbxx routolni. 224xxx239 A B-osztályú hálózatok első helyi Ez a 256 C-osztályú hálózat ugyancsak egy net helyi gépei számára van fenntartva. Ezeken a belüli IP-címeket csak az intraneten belül lehet Az 1. negyed értékek 224-239-ig a multicast-címek, amelyek negyedében 128-191-ig vannak értékek, és a második negyedben van a 0-255-ig egyetlen x.xx-ig terjedő teljes értékterület. A B-osztályú hálózatok tulajdonosai a két első negyedet biztosítják az adatcsomagok egyidejű átvitelét. Ezeket időnként D-osztálynak is nevezik (aaa.bbbxx) készen kiosztva kapják, és a maradék 16 bitet adhatják ki maguk (ez 240.xxx255 A jövőbeli fejlesztésekhez zárolva vannak még az 1. szegmens értékei 248- matematikailag 65536 különböző IP-címet jelent egy B-osztályú hálózaton belül). x.xx-ig 254-ig. így a

négymilliárd elméletileg rendelkezésre álló IP-címnek a végén aaa.bbbcccx már csak egy „töredéke" marad. Már ma is szűkösen megy a B- és C- osztályú hálózati A C-osztályú hálózatok első negyedében 192-223-ig vannak értékek, és meghatározott hálózatot sem definiálnak és több címzettnek a maradék három kvadránsban megint a teljes értékterület tartozik 0-255-ig. A C- címek kiadása, mivel a szabad számkészlet mindig kisebb lesz. Ezért van beharangozva osztályú hálózatok tulajdonosainak az első három szegmenst (aaa.bbbcccx) az Ipv6 IP-címzési rendszer, amelyben egy IP-cím a mostani 32 bit helyett 128 bitből fog osztják ki, és a negyedikről szabadon rendelkezhetnek (ez kiszámolva 256 különböző állni. IP-címet jelent). A-, B- és C-osztályú hálózatok Foglalt IP-címek Sok IP-cím van, amelyet a szolgáltatók nem oszthatnak ki, mert más célokat szolgálnak. Foglalt IP-címek 3.4 Aportokról Ebben a

könyvben gyakran találkozunk a port fogalmával, ezért most egy kis magyarázat következik, amely a további szövegek jobb megértését szolgálja. A port egy csatolófelület, amelyre információk tudnak bejönni és róla kimenni. Néhány ilyen csatolófelületet biztosan minden felhasználó ismer, ilye- nekre csatlakozik például az egér és a billentyűzet mint adatbeviteli eszközök. A kimenetet azután a monitor vagy a nyomtató jelenti. Egy szerverrendszer szintén különféle portokat kínál az internetfelhasználónak a különböző szolgáltatásokhoz. Itt azonban nem fizikai, hanem virtuális szoftverportokról van szó. Portjai minden olyan operációs rendszernek vannak, amely támogatja a TCP/IP-t, tehát vannak a Linuxnak, a Windowsnak, a Unixnak és a BeOs-nak is. Ezeket a portokat számokkal jelölik Pontosan 65536 port van. Az 1-1023-ig portok a standard, illetve statikus portok vagy a Well known portok. Ezek a közkedvelt szervizeknek vannak

fenntartva, és rendszerint csak az arra jogosult felhasználók érhetik el őket így például a böngésző egy weboldal letöltésekor automatikusan kapcsolatot létesít a megfelelő szerver 80. számú portjával Ez a port bocsátja rendelkezésre a World Wide Webhez szükséges HTTP kommunikációs protokollt. A mindenkori protokollok megfelelő porthoz rendelésével kapcsolatos információkat a transzportréteg tartalmazza. E-maileket például a Simple Mail Transfer Protocol- (SMTP)-on keresztül küldünk. A mail-szolgáltatás ennek megfelelően, a Well known portok szabványa szerint, a 25 portszámról megy A Regisztrált portok az 1024-49151 portok, és gyakran bizonyos szervizekhez is vannak tervezve, de rendszerint mindenki használhatja őket. A nagyobb számmal jelölt portokat dinamikus vagy privát portoknak nevezik, ezeket más programok, a saját készítésűek is, használhatják. Egy port akkor nyitott, ha egy program ezen a porton egy kérésre (request),

illetve egy kérdésre vár. Ha egy FTP szervert telepítünk a rendszerre, akkor ez a szerver a 21. porton vár kérdésre, ez a port tehát nyitott Sajnos portok/ról/on káros adatcsomagok, illetve rossz szándékú támadások is küldhetők vagy fogadhatók. Megfelelő védőmechanizmusok nélkül az ilyen csomagok többnyire a számítógép lefagyásához vezetnek. A manipulált adatcsomagok küldéséhez általában adott portokat használnak, s a megfelelő szolgáltatások programhibáira építenek A nyitott portok komoly biztonsági hiányosságokat is jelentenek a rendszereken. Ezeken a portokon keresztül az avatott hackerek be tudnak törni az érintett rendszerbe. Ezért ajánlatos a rendszer gyakori vizsgálata egy portszkennerrel - ilyen például a 7tf Sphere (www.hackerzbookde) -, és az esetleg nyitott portok lezárása egy tűzfallal. Egy portszkennelés eredménye A következő táblázat néhány fontos portot ír le: Port Leírás 21 FTP (File Transfer

Protocol) 23 25 SMTP (mailküldéshez, Simple Mail Transfer Protocol) 43 (utánanézni, kié egy weboldal) 53 kereséséhez) 66 Telnet (Service, nem program!) Domain Name Server (DNS nevek SQL * Net (SQL Server Port) 79 Finger (információk egy felhasználóról, például hogy vannak-e mail-jei) 80 (World Wide Web) 110 jeinket 137 Who is WWW POP3 (Post Office Protocol 3); itt kérjük le a mail- Netbios Name Service (hálózati PC-k nevei) 138 Netbios Datagramm Service (Adatforgalom a hálózatban) 139 Netbios Session Service (a nukerek is ezt használják) A legfontosabb portok áttekintése Valamennyi port listája a http://www.ianaorg/assignments/portnumbers weboldalon található A portokat a trójaiak is használják, ezért most felsoroljuk a legismertebb trójaiak legfontosabb portjait. Port Trójai 2140 Deep Throat 6670 Deep Throat 6771 Throat 30129 Paradise 5400 12361 Deep Masters Blade Runner Whack A Mole 20034 Netbus 2 Pro 21544 12345 Girlfriend

Netbus 31337 Régi Back Orifice (BO) 1243 Régi Sub 7 27374 30100 Sub7 Netsphere 456 Hackers Paradise A trójai portok Az összes ismert trójai portról a http://www.unsecurede címen kapunk pontos listát