Hálózatbiztonság
a (→Kriptográfiai alapok:  typo)  | 
			a (→Jelszó-alapú hitelesítés:  typo)  | 
			||
| (egy szerkesztő 17 közbeeső változata nincs mutatva) | |||
| 4. sor: | 4. sor: | ||
* Elterjedt protokollok működése, hozzájuk kapcsolódó biztonsági problémák, klasszikus támadások  | 
  * Elterjedt protokollok működése, hozzájuk kapcsolódó biztonsági problémák, klasszikus támadások  | 
||
** ISO/OSI hálózati referenciamodell  | 
  ** ISO/OSI hálózati referenciamodell  | 
||
| − | ** Fizikai és adatkapcsolati réteg: Ethernet, WiFi  | 
  + | ** Fizikai és adatkapcsolati réteg: [[Hálózatbiztonság#Ethernet|Ethernet]]  | 
| − | ** Hálózati réteg: IP, ICMP, ARP  | 
  + | ** Hálózati réteg: [[IP-alapok|IP]], [[IP-alapok#ICMP_(Internet_Control_Message_Protocol)|ICMP]], [[IP-alapok#ARP_(Address_Resolution_Protocol)|ARP]]  | 
| − | ** Szállítási réteg: TCP, UDP  | 
  + | ** Szállítási réteg: [[IP-alapok#TCP_(Transmission_Control_Protocol)|TCP]], [[IP-alapok#UDP_(User/Unreliable_Datagram_Protocol)|UDP]]  | 
| − | ** Alkalmazási réteg: SMTP, FTP, HTTP (és webalkalmazások), SSL, SSH  | 
  + | ** Alkalmazási réteg: [[A DNS működése|DNS]], [[Az SMTP működése|SMTP]], [[FTP]], [[SSL]]  | 
| − | * Vírusok, férgek, botnetek  | 
  + | ** [[Felderítés]] (olvasmány), [[Portscan]]  | 
| − | * Single Sign On  | 
  + | ** [[Tűzfalak]]  | 
| + | ** [[NetFlow]]  | 
||
| − | == Hitelesítés ==  | 
  + | == Mi is a hálózatbiztonság? ==  | 
| − | === Kriptográfiai alapok ===  | 
  + | Elvárások:  | 
| + | |||
| + | * ''integrity'' (integritás): a címzett győződhessen meg arról, hogy az általa vett üzenet megegyezik a feladó által feladott üzenettel (vagyis senki sem módosította azt a továbbítás során).  | 
||
| + | * ''authentication'' (hitelesítés): a kommunikáló felek győződhessenek meg arról, hogy a másik fél valóban az, akinek mondja magát.  | 
||
| + | * ''confidentiality'' ("titkosság", "bizalmasság"): az átvitt üzenetek tartalmát a feladón kívül csak a címzett ismerhesse meg.  | 
||
| + | ** Ha nem zárható ki az üzenet lehallgatása, ez csak kriptografikus titkosítással biztosítható.  | 
||
| + | ** Ennél tágabban is értelmezhető a ''confidentiality'': lehet, hogy pusztán az a tény, hogy X üzenetet küldött Y-nak, szintén titok; ill. az is lehet bizalmas, hogy X mikor és hány üzenetet küldött egyáltalán.  | 
||
| + | * "''operational security''" (üzembiztonság): rosszindulatú felhasználó ne legyen képes a hálózat erőforrásaival visszaélni, pl. lehetőleg ne legyen képes:  | 
||
| + | ** üzenetek lehallgatására;  | 
||
| + | ** lehallgatott üzenetek visszajátszására (ill. ha mégis képes rá, a visszajátszott üzenetek felismerhetőek legyenek);  | 
||
| + | ** más (létező vagy nem létező) felhasználók/végpontok megszemélyesítésére, a nevükben üzenetek küldésére;  | 
||
| + | ** arra, hogy másoktól megtagadja a hálózat szolgáltatásait (pl. a véges erőforrások elhasználásával);  | 
||
| + | ** más felek egymásnak küldött üzenetei tartalmának módosítására, vagy üzenetek eltüntetésére.  | 
||
| + | |||
| + | Ezek a célok jelenleg általában nem vagy csak a használhatóság rovására, életszerűtlen kompromisszumok árán érhetők el maradéktalanul; azonban a hálózatok tervezőinek, üzemeltetőinek döntései, módszerei megnehezíthetik (vagy éppen megkönnyíthetik) a támadók dolgát.  | 
||
| + | |||
| + | == Kitérő: kriptográfiai alapok ==  | 
||
Alapfogalmak:  | 
  Alapfogalmak:  | 
||
| 143. sor: | 143. sor: | ||
* Széles körben elterjedt.  | 
  * Széles körben elterjedt.  | 
||
* 128 bites hasht állít elő.  | 
  * 128 bites hasht állít elő.  | 
||
| − | * 2005-ben hibát találtak benne: aránylag könnyű ütközést generálni (másik olyan üzenetet találni, amelyhez ugyanaz a hash tartozik).  | 
  + | * 2005-ben hibát találtak benne: aránylag könnyű ütközést generálni (másik olyan üzenetet találni, amelyhez ugyanaz a hash tartozik). 2007-re reálissá vált a hibán alapuló támadás indítása.  | 
** Emiatt új kriptográfiai rendszerekben nem szabad használni.  | 
  ** Emiatt új kriptográfiai rendszerekben nem szabad használni.  | 
||
| + | * Érdekesség: a [http://en.wikipedia.org/wiki/Flame_%28malware%29 Flame] kémprogram egyes részeit egy olyan hamis CA-val (l. később) írták alá, amely látszólag a Microsofté volt; [http://www.cwi.nl/news/2012/cwi-cryptanalist-discovers-new-cryptographic-attack-variant-in-flame-spy-malware ezt szintén az MD5 gyengesége tette lehetővé].  | 
||
==== SHA-1 ====  | 
  ==== SHA-1 ====  | 
||
| 153. sor: | 154. sor: | ||
* Biztonságosnak számít.  | 
  * Biztonságosnak számít.  | 
||
* Vetélytársai: RIPEMD-160 (OpenPGP), Tiger (ez 192 bites; főleg fájlcserélők használják).  | 
  * Vetélytársai: RIPEMD-160 (OpenPGP), Tiger (ez 192 bites; főleg fájlcserélők használják).  | 
||
| + | |||
| + | === Kriptográfiai támadások ===  | 
||
| + | |||
| + | Az alapján, hogy milyen információk birtokában van a támadó, ill. mire van lehetősége, a következő nagyobb csoportokba sorolhatók az általa egy kriptográfiai rendszer ellen végrehajtható támadások:  | 
||
| + | |||
| + | * ''ciphertext-only attack'' (csak a titkosított szöveg birtokában végrehajtott támadás). Ilyenre akkor kerül sor, ha a támadó csak egy (vagy több) titkosított üzenetnek van a birtokában, és azok tartalmáról semmilyen ismerettel nem rendelkezik. Egyszerűbb (tehát nem modern) titkosítások esetében statisztikai analízis segítségével jó eredmények érhetők el. A modern titkosítókkal szemben elvárás, hogy egy ilyen támadás nagyjából annyira nehéz legyen, mint az összes lehetséges kulcs végigpróbálgatása.  | 
||
| + | * ''known plaintext attack'' (a titkosított szöveg birtokában végrehajtott támadás, ha a támadó sejti vagy tudja, mit tartalmazhat az üzenet). Példák:  | 
||
| + | ** Elfogott titkosított időjárás- vagy helyzetjelentés hadszíntéren. Az üzenet tartalmából sokminden sejthető (helynevek, személynevek).  | 
||
| + | ** Hitelkártya-adatok átvitele az Interneten. Sejthető, hogy van az üzenetben egy kb. 10-15 betűből álló név és kb. 20 számjegy.  | 
||
| + | *** Egy jó titkosítóalgoritmus esetében a nyílt szöveg bizonyos részeinek vagy akár egészének ismerete sem teszi lehetővé a kulcs egyszerű rekonstruálását (és így további titkosított üzenetek visszafejtését).  | 
||
| + | * ''chosen plaintext attack'' (a támadó képes az általa választott nyílt szöveg titkosíttatására). Példák:  | 
||
| + | ** Digitálisan aláírt email. A partnerünk, amikor válaszol nekünk, idézi a saját levelünket és azt -- saját üzenete részeként -- titkosítja a saját titkos kulcsával.  | 
||
| + | ** Merevlemez-titkosítás. Ha egy támadó ellop egy működő notebookot, amelynek a merevlemeze titkosítva van, megkísérelheti úgy feltörtni a titkosítást, hogy ismert tartalmú fájlokat ment el rá.  | 
||
| + | *** Egy jó titkosítóalgoritmus esetében ez a fajta támadás sem elegendő a kulcs visszafejtéséhez (tehát a fenti esetben sem vagyunk sokkal közelebb a levelezőpartner titkos kulcsának megszerzéséhez).  | 
||
| + | |||
| + | == Tanúsítványok ==  | 
||
| + | |||
| + | L. az [[SSL]]-ről szóló szócikket.  | 
||
| + | |||
| + | == Jelszó-alapú hitelesítés ==  | 
||
| + | |||
| + | * Ha egy szolgáltatást csak nevesített felhasználóknak akarunk nyújtani, valahogyan meg kell tudnunk, ki próbálja igénybe venni a szolgáltatást.  | 
||
| + | ** A hitelesítés és a hozzáférésvezérlés két különböző dolog: lehet, hogy egy szolgáltatást bárki használhat, csak tudnunk kell, kicsoda (pl. bankszámlát akárki nyithat, de többnyire csak névvel).  | 
||
| + | |||
| + | Hogyan állapítsuk meg, ki a felhasználó?  | 
||
| + | |||
| + | * Kézenfekvő, egyszerű megoldás: felhasználónév+jelszó.  | 
||
| + | ** A jelszó önmagában kevés: hozzáférésvezérléshez elegendő, hitelesítéshez viszont csak akkor, ha az üzemeltető osztja ki a garantáltan egyedi jelszavakat a felhasználóknak.  | 
||
| + | ** Ha a felhasználó magának választhatja a jelszót, akkor a jelszó egyedisége nem garantált, tehát kell egy egyedi azonosító is; ez a felhasználónév.  | 
||
| + | ** Aki egy adott {felhasználónév, jelszó} párost ismer, arról általában elhisszük, hogy az a személy, akihez az adott felhasználónév tartozik.  | 
||
| + | *** A ''hozzáférésvezérlés'' szempontjából ez persze nem feltétlenül elegendő: lehet, hogy csak adott helyről vagy adott időablakban engedjük hozzáférni a szolgáltatáshoz.  | 
||
| + | |||
| + | Nehézségek a jelszó-alapú hitelesítésnél:  | 
||
| + | |||
| + | * A jelszavak a hálózaton lehallgathatók lehetnek. Lehetséges megoldások:  | 
||
| + | ** titkosított protokoll használata;  | 
||
| + | ** egyszer használatos jelszavak (OTP, one-time password) használata.  | 
||
| + | *** Ezzel vigyázzunk; ha a támadó képes karakterenként lehallgatni a jelszót, az utolsó karakter felhasználó általi leütése előtt próbálgatásos támadást indíthat az utolsó karakter kitalálására.  | 
||
| + | ** Challenge-response ("kihívás-válasz") alapú hitelesítés.  | 
||
| + | *** Lényege: a jelszót nem utaztatjuk a hálózaton; a hitelesítő a jelszóra vonatkozó, kriptográfián alapuló "találós kérdést" ad fel a kliensnek, amely a jelszó birtokában tud rá helyesen válaszolni.  | 
||
| + | **** Ez a viszonthitelesítést is lehetővé teszi: megoldható, hogy csak az tudjon érvényes találós kérdést feltenni, aki maga is ismeri a jelszót.  | 
||
| + | **** Egyszerű példa: "itt van ez a véletlenszerűen generált sztring; fűzd össze a jelszóval és képezz belőle hash-t, majd a hash-t küldd vissza".  | 
||
| + | *** Hátrány: sok challenge-response protokoll plaintext jelszó tárolását igényli.  | 
||
| + | * Márpedig ha a jelszavakat titkosítás nélkül tároljuk a szerveren, onnan egy menetben ellopható az összes.  | 
||
| + | ** Ráadásul az emberek gyakran ugyanazt a jelszót több helyen is használják.  | 
||
| + | ** Lehetséges megoldások:  | 
||
| + | *** Jelszavak "titkosított" tárolása.  | 
||
| + | **** A sima titkosítás nem sokkal jobb, mint a plaintext, hiszen a hitelesítéshez dekódolni kell a titkosított jelszót, ha pedig a hitelesítő képes erre, akkor még mindig ellopható az összes jelszó.  | 
||
| + | **** A jelszó helyett csak egy hash-t tárolunk.  | 
||
| + | ***** Gond: két azonos jelszó hash-e is meg fog egyezni;  | 
||
| + | ***** ha valaki már egy csomó szótári szó hash-ét meghatározta, a tőlünk ellopott hash-ek között jó eséllyel talál olyat, amelyhez ismer jelszót.  | 
||
| + | ***** Jobb "megsózni" jelszót hash-elés előtt: kiegészíteni egy véletlen sztringgel, és azzal együtt hash-elni, majd a hash mellett ezt a sztringet is tárolni.  | 
||
| + | * A hash-elt jelszótárolás és a kihívás-válasz alapú hitelesítés elvileg ötvözhető; így működik pl. az [http://en.wikipedia.org/wiki/NTLM#NTLMv2 NTLMv2].  | 
||
| + | |||
| + | === Ajánlott irodalom ===  | 
||
| + | |||
| + | * [http://www.tomshardware.com/news/imperva-rockyou-most-common-passwords,9486.html Your Top 20 Most Common Passwords] -- 32 millió kiszivárgott jelszó vizsgálata.  | 
||
| + | * [http://www.troyhunt.com/2011/07/science-of-password-selection.html Hogyan választanak jelszót az emberek?]  | 
||
| + | * [http://www.openwall.com/john/ John the Ripper] -- Az egyik legelterjedtebb szótáralapú jelszótörő (képes a szótár szavait szabályok segítségével átírni, kombinálni, és az így nyert szavakkal is próbálkozni).  | 
||
| + | * [http://www.baekdal.com/insights/password-security-usability egy cikk arról, mennyire könnyű "biztonságos" jelszót kitalálni], [http://www.troyhunt.com/2011/04/bad-passwords-are-not-fun-and-good.html és cáfolata].  | 
||
| + | * [http://www.unixwiz.net/techtips/iguide-crypto-hashes.html An Illustrated Guide to Cryptographic Hashes] -- Jó, tömör és szemléletes cikk a kriptográfiában használt hash-ekről.  | 
||
| + | * [http://www.infoworld.com/t/data-security/amazon-ec2-enables-brute-force-attacks-the-cheap-447 Amazon EC2 enables brute-force attacks on the cheap] -- Az Amazon felhőjén néhány dollárért másodpercenként 400.000 jelszót próbálhatunk egy hash-re illeszteni.  | 
||
| + | * [http://www.troyhunt.com/search/label/Passwords http://www.troyhunt.com/search/label/Passwords] -- Jó cikksorozat a jelszavakról általában.  | 
||
| + | * [http://www.troyhunt.com/2011/03/only-secure-password-is-one-you-cant.html The only secure password is the one you can’t remember]  | 
||
| + | * [http://xkcd.com/936/ webképregény] arról, hogyan válasszunk nehezen feltörhető, de könnyen megjegyezhető jelszót, [http://www.troyhunt.com/2011/08/im-sorry-but-were-you-actually-trying.html és cáfolata] (konklúzió: használjunk véletlenszerű jelszavakat és ezeket tároljuk tikosítva úgy, hogy egyetlen erős jelszót kelljen csak megjegyezni ahhoz, hogy hozzájuk férhessünk).  | 
||
| + | * [http://xkcd.com/792/ webképregény] arról, hogyan lehet visszaélni azzal, hogy az emberek sok helyen ugyanazt a jelszót használják.  | 
||
| + | * [http://xkcd.com/538/ webképregény] arról, mennyire mindegy lehet, milyen erős titkosítást használunk - fizikai erőszakkal általában nem nehéz a jelszavak birtokába jutni.  | 
||
| + | * Tömör, bár kissé felületes [http://www.weblap.ro/milyen-a-jo-jelszo cikk arról, mennyire gyorsan törhetők a hosszú jelszavak is, próbálgatással is] (az adatok helyességét nem ellenőriztem -- emellett számomra nem volt nyilvánvaló, milyen hasht feltételez, ami a másodpercenként végrehajtható próbálkozások száma szempontjából nem mindegy).  | 
||
| + | |||
| + | == Az adatkapcsolati (és fizikai) réteg; Ethernet ==  | 
||
| + | |||
| + | Fogalmak:  | 
||
| + | |||
| + | * ''Csomópont'': olyan eszköz, amelynek van olyan interfésze, amellyel az adatkapcsolati rétegben kommunikálni tud; például hoszt vagy router.  | 
||
| + | * ''Kapcsolat'': fizikai összeköttetés két vagy több fizikai interfész között.  | 
||
| + | * ''Keret'': adatkapcsolati szintű adatcsomag; magasabb rétegbeli protokollok (pl. IP) csomagjait szállít(hat)ja egy ''kapcsolat''nyi távolságra.  | 
||
| + | ** Általában egy keretre jut egy magasabb szintű adatcsomag, de szükség lehet arra, hogy egy-egy csomagot több keretre bontsunk szét.  | 
||
| + | * ''Adatkapcsolati protokoll'': meghatározza a ''keret''ek formátumát és azt, hogyan kezelik őket ill. a ''kapcsolat''okat a ''csomópont''ok.  | 
||
| + | ** Garantál megbízhatóságot?  | 
||
| + | *** Csomag (keret) kézbesítését, integritását?  | 
||
| + | **** Hibadetektálás vagy hibajavítás.  | 
||
| + | **** Nyugtázás, újraküldés.  | 
||
| + | *** QoS-t?  | 
||
| + | *** Az átvitt adatokban?  | 
||
| + | *** Az infrastruktúrát illetően?  | 
||
| + | ** Broadcast vagy pont-pont?  | 
||
| + | *** Hogyan működik a címzés?  | 
||
| + | *** Közeghozzáférés-vezérlés (MAC: medium access control)? Módszerek:  | 
||
| + | **** Csatorna-felosztás (pl. frekvenciaosztásos vagy kódosztásos multiplexelés);  | 
||
| + | **** véletlen hozzáférés (pl. Ethernet)  | 
||
| + | ***** (carrier sensing, collision detection);  | 
||
| + | **** felváltva adás (pl. Token Ring).  | 
||
| + | ** Folyamszabályozás: a küldő ne küldjön gyorsabban, mint ahogy a fogadó fel tudja dolgozni.  | 
||
| + | ** Duplexitás (half duplex, full duplex).  | 
||
| + | |||
| + | '''Az adatkapcsolati réteg feladata: adatkeretek szállítása két szomszédos (közvetlenül összekapcsolt) csomópont között.'''  | 
||
| + | Az adatkapcsolati réteg fölött elhelyezkedő ''hálózati réteg'' már egymástól távoli csomópontok között szállít adatcsomagokat;  | 
||
| + | az útvonalon elhelyezkedő csomópontok (routerek) közötti szakaszokon más-más adatkapcsolati rétegbeli protokollt (vagyis hálózati technológiát) is használhatunk.  | 
||
| + | Ideális esetben a hálózati rétegben működő programok semmit sem tudnak (és semmit sem kell, hogy tudjanak) az adatkapcsolati réteg sajátosságairól.  | 
||
| + | |||
| + | : Analógia: ha Budapestről az Orkney-szigetekre akarunk eljutni (mi vagyunk a hálózati adatcsomag analógiája), akkor először eltaxizunk a reptérre (a taxi egy adatkapcsolati és fizikai rétegbeli protokoll); aztán repülővel elmegyünk mondjuk Edinburgh-ba; onnan vonattal Invernessbe; ott autót bérlünk és elautózunk John o' Groats-ig; itt pedig az autóval felhajtunk a kompra, ami autóstul elvisz Burwickbe.  | 
||
| + | : Ez már az Orkney-szigetek egyikén található, vagyis célba értünk. Az utolsó szakaszon ''enkapszuláció'' is történt: az egyik adatkapcsolati rétegbeli keretet (az autót, benne a hálózat csomaggal, vagyis velünk) egy az egyben beraktuk egy másik technológiájú adatkapcsolati rétegbeli keretbe (a kompba).  | 
||
| + | : A komp-vonal két végpontja között a belső keret (az autó) változatlan formában utazott; a távoli végpontnál kicsomagoltuk a külső keretből a belsőt, amely folytatta útját, és végül célba juttatta a hálózati csomagot (az utast).  | 
||
| + | |||
| + | Néhány elterjedt adatkapcsolati rétegbeli protokoll:  | 
||
| + | |||
| + | * Ethernet ([http://en.wikipedia.org/wiki/IEEE_802 IEEE 802.3*])  | 
||
| + | * 802.11 WLAN (WiFi);  | 
||
| + | * Token Ring (ritka);  | 
||
| + | * FDDI (elavult);  | 
||
| + | * PPP (Point to Point protocol);  | 
||
| + | * [http://en.wikipedia.org/wiki/LAPB LAPB] (az X.25 adatkapcsolati rétegbeli protokollja);  | 
||
| + | * [http://en.wikipedia.org/wiki/DOCSIS DOCSIS] (a kábeltévés internetszolgáltatás fizikai és adatkapcsolati rétege);  | 
||
| + | * [http://en.wikipedia.org/wiki/HDLC HDLC] (egy ősprotokoll; a LAPB pl. ennek a leszármazottja);  | 
||
| + | * [http://en.wikipedia.org/wiki/ARCnet ARCnet].  | 
||
| + | |||
| + | Az adatkapcsolati rétegbeli protokoll megvalósítása általában hardveres, és a hálózati kártyában található.  | 
||
| + | |||
| + | === Ethernet ===  | 
||
| + | |||
| + | "''Ethernet, n:'' a device used to catch the etherbunny."  | 
||
| + | |||
| + | * Majdnem biztosan a legelterjedtebb adatkapcsolati rétegbeli protokoll (és fizikai közeg).  | 
||
| + | * Minden csomópontnak (pontosabban: minden hálózati interfésznek) elvileg globálisan egyedi hatbájtos ''MAC-címe'' van.  | 
||
| + | ** Notációk: aa:bb:cc:dd:ee:ff (Unix); AA-BB-CC-DD-EE-FF (Windows); aabb.ccdd.eeff (Cisco).  | 
||
| + | ** A hardvergyártó állítja be, de ma már szinte mindig átírható szoftverből.  | 
||
| + | ** A címek strukturálatlanok (nincs pl. a hálózat topológiájából adódó hierarchia).  | 
||
| + | *** Mindazonáltal az első 24 bit azonosítja a gyártót.  | 
||
| + | * Broadcast ("üzenetszórásos") elven működik.  | 
||
| + | ** Minden, az adott ''szegmensben'' levő kártya ("adapter") minden keretet megkap; a címzés alapján dönti el, kell-e vele foglalkoznia.  | 
||
| + | ** Speciális cím: ff:ff:ff:ff:ff:ff (csupa egyes): mindenkinek szóló üzenet.  | 
||
| + | ** Szoftverből utasítható az adapter arra, hogy a nem neki szóló kereteket is olvassa el ("hallgassa le"): ''sniffing''.  | 
||
| + | * Szigorúan véve nem Ethernet-specifikus, de ide tartozik: [[IP-alapok#ARP_.28Address_Resolution_Protocol.29|ARP]] (IP címhez keres MAC-címet).  | 
||
| + | * Keretformátum kb:  | 
||
| + | *# "Preamble" (a fizikai réteg sajátosságain alapul; könnyen észlelhető "keret eleje"-jelzés, 8 byte). A két végpont óráinak (órajelének) szinkronizálást is segíti.  | 
||
| + | *# Célcím (6 byte);  | 
||
| + | *# Forráscím (6 byte);  | 
||
| + | *# Hálózati rétegbeli protokoll azonosítója (2 byte; pl. IP, IPX, Decnet stb.);  | 
||
| + | *# Adatok (max. 1500 byte);  | 
||
| + | *# Ellenőrző összeg (CRC, 4 byte).  | 
||
| + | |||
| + | ==== Eszközök (hub, bridge, switch stb.) ====  | 
||
| + | |||
| + | * Repeater: két fizikai szegmenst köt össze bit-szinten.   | 
||
| + | ** Ha az egyik interfészén megjelenik egy bit, azt kiküldi a másik interfészén.  | 
||
| + | ** Lényegében egy erősítő: a csillapított jel helyett egy szép új jel jelenik meg a másik interfészen.  | 
||
| + | ** A két fizikai szegmens egyetlen logikai szegmenst (collision domaint) alkot: nem adhat egyszerre két csomópont akkor sem, ha a repeater két oldalán vannak és a címzettjeik is a velük azonos oldalon találhatóak.  | 
||
| + | ** Ha a repeater különböző fizikai, de azonos adatkapcsolati réteget használó szegmens között van, akkor médiakonverternek is hívják.  | 
||
| + | * Hub: sokportos repeater.  | 
||
| + | * Bridge: két fizikai szegmenst köt össze keretek szintjén.   | 
||
| + | ** Az egyik interfészen bejövő keretet megismétli a másik interfészen.  | 
||
| + | ** Megtanulja, melyik MAC-címek melyik interfész felé vannak, és csak akkor adja tovább a keretet, ha szükséges (a címzett a másik oldalon van, vagy broadcast keretről van szó).  | 
||
| + | ** Két különböző, de alapvetően Ethernet-szerű hálózat közé is tehető bridge: pl. vezetékes Ethernet és WiFi vagy Token Ring.  | 
||
| + | *** Ilyenkor a bridge kénytelen bizonyos mértékű protokoll-átalakítást is végezni, ami nem mindig tud 100%-os lenni (pl. ha az egyik hálózatban van QoS, a másikban pedig nincs).  | 
||
| + | ** Ha a keretformátum azonos (és csak a fizikai réteg különbözik, pl. 10BASE-T és 100BASE-FX), nem kell protokoll-átalakítás sem.  | 
||
| + | * Switch: sokportos bridge.  | 
||
| + | ** A végpontok számára transzparens (a kereteket nem a switchnek, hanem egymásnak címzik).  | 
||
| + | ** Minden porton csak azokat a kereteket küldi ki, amelyek az adott portra kapcsolt állomások valamelyikének szólnak.  | 
||
| + | *** A portokhoz nemcsak végpontok, hanem további switchek is csatlakoztathatók; így egy porthoz sok végpont is tartozhat.  | 
||
| + | *** A switch egy ún. ''MAC-táblában'' tartja nyilván, melyik MAC-című állomás melyik portra csatlakozik.  | 
||
| + | **** Szintén nyilvántartja, melyik MAC-port párost mikor "tanulta meg"; a hosszú ideig inaktív MAC-eket kidobálja a táblából.  | 
||
| + | ***** Lehetséges anomália-észlelés: ha ugyanaz a MAC "egyszerre" van jelen két porton is, a switch gyanakodhat hurokra vagy hamisításra és küldhet riasztást.  | 
||
| + | *** A táblában nem szereplő MAC-címeknek szóló csomagokat minden porton kénytelen kiküldeni (kivéve azon, amelyiken bejöttek).  | 
||
| + | *** Természetesen a broadcast kereteket is minden interfészen kiküldi.  | 
||
| + | *** Ha a cél-MAC azon a porton van, amelyiken a keret bejött, a switch nem továbbítja.  | 
||
| + | *** Előfordulhat, hogy egy porton egyszerre több keretet is ki kellene küldeni (mert két másik portról is beesett egy-egy erre a portra tartó keret). Emiatt minden porthoz tartozik egy kimenő puffer, amiben a keretek várják, hogy ki lehessen küldeni őket.  | 
||
| + | **** (Nyilván szintén várni kell, ha ütközés van a kimenő porton.)  | 
||
| + | ** Olyan hálózatban, amelyben nincs hub, csak switch, sosincs ütközés (mivel csak full duplex pont-pont kapcsolatok léteznek).  | 
||
| + | ** Mivel a switch kereteket másol (hiszen nem más, mint egy sokportos bridge), kiválóan alkalmas különböző sebességű (és fizikai réteget használó) Ethernet-szegmensek összekapcsolására.  | 
||
| + | *** Pl. gyakori, hogy egy-egy switchnek van mondjuk 24 100mbites és 4 gigabites portja.  | 
||
| + | ** A switch könnyedén leválaszthatja a hálózatról a hibás (pl. folyamatosan adó) csomópontokat.  | 
||
| + | ** Switchelt hálózatban egy kábelszakadás csak egyetlen végpontot érint (a hagyományos busz-topológiájú Ethernetnél az egész hálózat használhatatlanná válik, ha a busz megszakad).  | 
||
| + | |||
| + | === STP, RSTP, MSTP ===  | 
||
| + | |||
| + | (Spanning Tree Protocol, Rapid Spanning Tree Protocol, Multiple Spanning Tree Protocol.)  | 
||
| + | |||
| + | Forrás: [http://splash.eik.bme.hu/papers/stp.pdf Jákó András: Spanning Tree Protocol, 2004.].  | 
||
| + | |||
| + | Fontos fogalom: '''collision domain''' (már volt róla szó). Az Ethernet-hálózatok olyan összefüggő részei, amelyek csak passzív alkatrészeket, repeatereket és/vagy hubokat tartalmaznak, egyetlen collision domaint ("ütközési tartományt") alkotnak.  | 
||
| + | |||
| + | * Általában szeretnénk, hogy a collision domainek minél kisebbek legyenek.  | 
||
| + | ** Minél több végpont van ugyanabban a collision domainben, annál valószínűbb, hogy lesz köztük legalább kettő, amelyik egyszerre akar beszélni és így ütközés jön létre.  | 
||
| + | ** Az ütközés rontja a hatékonyságot (az ütközés résztvevői elhallgatnak, várnak egy kicsit, aztán újra megpróbálnak adni). Minél több az ütközés, az időnek annál kisebb részében továbbít a hálózat hasznos adatot.  | 
||
| + | ** Egy collision domaint általában switch beiktatásával vágnak fel több collision domainre (legfeljebb annyira, ahány portja a switchnek van).  | 
||
| + | |||
| + | <BR>  | 
||
| + | |||
| + | Másik fontos fogalom: '''broadcast domain''' (szintén volt már róla szó). Az Ethernet-hálózatok olyan összefüggő részei, amelyek switchek vagy bridge-ek segítségével összekapcsolt collision domainekből állnak, egy broadcast domain ("üzenetszórási tartományt") alkotnak.  | 
||
| + | |||
| + | * Egy broadcast domainen belül az állomások MAC-cím alapján meg tudják egymást címezni; az FF:FF:FF:FF:FF:FF MAC-címre küldött keretek pedig minden állomáshoz eljutnak.  | 
||
| + | ** Így pl. az ARP segítségével működik az IP is, router nélkül.  | 
||
| + | * Korábban a szervezetek általában arra törekedtek, hogy az egész hálózatuk lehetőleg egyetlen broadcast domaint alkosson; ez ma már nem annyira jellemző.  | 
||
| + | * A törekvés okai:  | 
||
| + | ** Lehetőleg ne kelljen route-olni a közvetlenül az Ethernetre épülő protokollokat (pl. IPX).  | 
||
| + | ** Működjön a Windows Network Neighborhood ("Hálózati Helyek") - kb. a Windows 2000-ig erősen épült az Ethernet broadcastra.  | 
||
| + | * A nagy broadcast domain hátránya, hogy ha nagy a broadcast-forgalom (pl. mert sok a windowsos munkaállomás), megnő a hálózat terhelése.  | 
||
| + | ** A broadcastok olyan szegmensekbe is eljutnak, ahol igazából nincs is rájuk szükség -- pl. mert nincs ott Windows.  | 
||
| + | * Ma a Windows fájlmegosztó/névfeloldó protokollcsaládja már broadcast nélkül is tud jól működni, az IPX pedig lényegében kihalt, így egyre kevesebb a motiváció a nagy, összefüggő broadcast domainek fenntartására.  | 
||
| + | ** Pl. a BME 152.66.0.0/16-os hálózata is számos routert tartalmaz, és csak az egyes tanszékek belső hálózatai alkotnak egy-egy (vagy némely esetben több) broadcast domaint.  | 
||
| + | |||
| + | <BR>  | 
||
| + | |||
| + | : '''Mi történik, ha egy Ethernetben kör van?'''  | 
||
| + | |||
| + | * Ha pl. A, B és C switchek, és van A-B, B-C és C-A kapcsolat, a keretek elvileg az idők végezetéig járnak körbe-körbe.  | 
||
| + | ** Az Ethernet-keretben nincs TTL mező, mint az IP-ben.  | 
||
| + | ** Esélytelen nyilvántartani, melyik keretet láttuk már (hogy azt ne küldjük tovább újra).  | 
||
| + | ** Vagyis nincs semmilyen automatikus mechanizmus a körbe-körbe menő csomagok megállítására.  | 
||
| + | * '''Broadcast Storm''': amikor egy broadcast (vagy ismeretlen) címre küldött keret vég nélkül kering a hálózatban.  | 
||
| + | ** Ha több hurok van, többszöröződik is.  | 
||
| + | * Járulékos gond: mivel az adott forráscímről jövő csomagok esetleg hol az egyik, hol a másik porton jutnak el egy switchbe, a MAC-táblát is folyton frissíteni kell, és az adott MAC-nek szóló keretek, ha épp rosszkor esnek be, esetleg nem a megfelelő irányba mennek ki.  | 
||
| + | |||
| + | Na de miért lenne hurok (kör) a hálózatban egyáltalán?  | 
||
| + | |||
| + | # Redundancia (ha valamelyik link, esetleg valamelyik switch kiesik, ne essen szét a hálózat).  | 
||
| + | # Véletlenül (rossz helyre dugunk egy kábelt).  | 
||
| + | |||
| + | Mivel az Ethernet hurokmentessége nem garantálható, és a hurkok katasztrofális hatásúak, szükség van egy olyan mechanizmusra, amely felismeri és automatikusan kiiktatja őket. Az STP (és továbbfejlesztései) ezt a feladatot oldják meg.  | 
||
| + | |||
| + | Kapcsolódó szabványok:  | 
||
| + | |||
| + | * Spanning Tree Algorithm and Protocol: 802.1D-1998, 802.1t-2001  | 
||
| + | * Rapid Spanning Tree Algorithm and Protocol: 802.1w-2001 (802.1D-2004)  | 
||
| + | * Multiple Spanning Tree Protocol: 802.1s-2002, 802.1Q-2003  | 
||
| + | |||
| + | Az STP működését l. Jákó András [http://splash.eik.bme.hu/papers/stp.pdf előadásában] (figyelem: sokkal részletesebb, mint amennyire itt most szükséges).  | 
||
| + | |||
| + | * Az RSTP az STP felgyorsítása.  | 
||
| + | * Az MSTP több feszítőfát használ, hogy ha ugyanazokon a switcheken több VLAN forgalma bonyolódik le, az egyes VLAN-ok forgalma más-más útvonalakon haladjon (ahol lehet).  | 
||
| + | |||
| + | : '''Biztonsági vonatkozások'''  | 
||
| + | |||
| + | * Hamis BPDU-kkal a feszítőfa-építés folyamata megzavarható:  | 
||
| + | ** Közepes számú, gyakran változtatott hamis üzenettel megakadályozható konzisztens állapot kialakulása.  | 
||
| + | *** Főként, ha ezeket a hálózat több pontján egyszerre injektáljuk.  | 
||
| + | ** Ha egy támadó egyszerre több switchhez is képes csatlakozni (akár több mobil eszközzel, amelyek mondjuk 3G-n vagy wifin kommunikálnak), megpróbálhat egy olyan feszítőfát kikényszeríteni, amelyben minden olyan collision domain között, amelyben jelen van, az ő eszköze a designated bridge (ill. ő a root bridge is); így a collision domainek közti forgalom őrajta halad át, vagyis lehallgathatja, módosíthatja stb.  | 
||
| + | * Védekezés: a switcheken be kell állítani, hogy melyik portjuk néz másik saját switch felé. A többiről nem fogadnak el BPDU-t (sőt: ha jön, egy időre deaktiválják a portot).  | 
||
| + | ** Utóbbi, ha nemcsak egy-egy gép lóg egy-egy switchporton, DoS-ra ad lehetőséget: az áldozatot is tartalmazó collision domainből BPDU-kat kezdünk küldeni, így a switch leválasztja a portot, az áldozatnak pedig megszűnik az Internet-kapcsolata.  | 
||
| + | |||
| + | === VLAN ===  | 
||
| + | |||
| + | Lényege: több virtuális Ethernet kialakítása ugyanazon a fizikai switch-halmazon.  | 
||
| + | |||
| + | Vonatkozó szabvány: IEEE802.1Q/802.1p.  | 
||
| + | |||
| + | * Működés alapja: a switchnek megmondjuk, melyik port hányas számú VLANba tartozik.  | 
||
| + | * Ha minden port csak egyetlen VLANnak része, ennyi elég is -- feldaraboltuk a switch(ek)et több virtuális switchre.  | 
||
| + | * De: két switch között miért kelljen két kábel?  | 
||
| + | ** Megoldás: "trunk port". Négybájtos fejléc-kiegészítés (''VLAN tag'') az Ethernet-keret elején, amelyből 12 bit a VLAN-azonosító (hányas számú VLANba szól a keret).  | 
||
| + | *** Vigyázat: a HP például az EtherChannelt (amikor több párhuzamos kábelt egyetlen virtuális kábelként használunk) hívja trunk-nak. A hálózati eszközök gyártóinak terminológiája a feltétlenül szükségesnél lényegesen változatosabb.  | 
||
| + | ** Jobb oprendszerek is támogatják, így nemcsak két hálózati eszköz között használható, hanem pl. switch és szerver között is -- a szerver pedig több Ethernetnek szolgáltathat egyszerre, egyetlen fizikai hálózati interfészen.  | 
||
| + | * Switcheken általában portonként beállítható:  | 
||
| + | ** a port "jellege" (gyártónként változik a terminológia és a megközelítés):  | 
||
| + | *** ''access'' -- csak végpontok vannak rajta. Nincs VLAN tag (és remélhetőleg a bejövő kereteken sem fogadja el). A port általában csak egyetlen VLANnak része (és a bejövő kereteket automatikusan ebbe a VLANba szólónak tekintjük).  | 
||
| + | *** ''trunk'' -- másik hálózati eszköz van rajta. Minden keretet taggel látunk el. Általában több VLANnak része a port, és csak VLAN taggel ellátott kereteket hajlandó fogadni.  | 
||
| + | *** ''hybrid'' -- a port több VLAN része. Külön beállíthatjuk, melyik VLANokba menő forgalmat kell tagelni és melyikeket nem. A bejövő jelöletlen kereteket általában egy meghatározott VLANba szólónak tekintjük.  | 
||
| + | *** (Előfordulhat egy további típus, aminél VLAN tagelt keretek kapnak további VLAN taget.)  | 
||
| + | ** a port VLAN-tagságai (melyik VLANokba szóló kereteket kell kiküldeni rajta);  | 
||
| + | *** ezek közül melyeket tagelve és melyeket tag nélkül;  | 
||
| + | ** legyen-e "''ingress filtering''", vagyis eldobja-e azokat a kereteket, amik ezen a porton jönnek be és olyan VLANba szólnak, amelynek a port nem tagja;  | 
||
| + | ** melyik VLANba szólónak tekintsük a bejövő tag nélküli kereteket.  | 
||
| + | ** a másik végpont regisztrálhasson-e dinamikusan újabb VLAN-tagságokat.  | 
||
| + | * Bizonyos switchek képesek MAC-cím vagy egyéb forgalmi jellemző alapján más-más VLANba sorolni az ugyanarról a portról bejövő kereteket.  | 
||
| + | * Jobb WiFi hozzáférési pontok képesek több SSID-t ("hálózat-azonosítót") is hirdetni, és a végpontok forgalmát saját Ethernet-interfészükön más-más VLANba sorolni aszerint, hogy az adott végpont melyik SSID-ra kapcsolódott.  | 
||
| + | |||
| + | : '''Biztonsági vonatkozások'''  | 
||
| + | |||
| + | Forrás: [http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper09186a008013159f.shtml#wp39042 Cisco].  | 
||
| + | |||
| + | * A támadó küldhet olyan VLAN taggel ellátott keretet, amely VLANnak a felé néző port nem része.  | 
||
| + | * A támadó küldhet két VLAN taggel ellátott keretet. Ha ezt a switch olyan porton küldi ki, amelyen a konfiguráció szerint az első tag-re nincs szükség (az adott portnak ez a "natív" VLANja és nem kértünk tagelést), akkor így azon a porton a második VLAN-tagben megadott VLANba szóló keret fog kimenni.  | 
||
| + | * Ha lehetséges a [http://en.wikipedia.org/wiki/Multiple_Registration_Protocol VLAN-tagságok dinamikus regisztrációja], a támadó egyszerűen beléphet az őt érdeklő VLANokba.  | 
||
| + | |||
| + | === További támadások switchek ill. switchelt Ethernet ellen ===  | 
||
| + | |||
| + | * Switchelt hálózatban nehéz sniffelni (a támadó felé néző porton csak a neki szóló keretek jelennek meg).  | 
||
| + | ** Ha viszont a támadó elárasztja hamis forrás-MAC-címekkel a switchet, kiszoríthatja a valódi MAC-eket a MAC-táblából és elérheti, hogy a switch a legtöbb keretet broadcastolja. Védekezés:  | 
||
| + | *** 802.1x -- switchport-szintű autentikáció (viszont így egy switchporton csak egy végpont lóghat).  | 
||
| + | *** A jobb switchekben korlátozható, hogy egy-egy porthoz legfeljebb hány MAC-cím tartozhat.  | 
||
| + | ** Kifinomultabb támadó csak egyetlen MAC-et (pl. egy szervert) támad: ha a szerver magától nem nagyon forgalmaz, a switch a támadó portját jegyzi be az adott MAC-hez, és a támadó kapja meg a szervernek szánt csomagokat.  | 
||
| + | * A switch átengedi (továbbítja) az Ethernet broadcastokat. Ha sok broadcastot küldünk, az egész hálózatot megbéníthatjuk.  | 
||
| + | ** Jobb switchekben van "broadcast storm protection", ami pl. a gyanúsan nagy rátával üzenetszóró végpontok felé néző portokat kikapcsolja.  | 
||
| + | * A támadó összekapcsolhat két switchportot úgy, hogy kiszűri a forgalomból az STP működéséhez szükséges BPDU-kat, így a switchek számára észlelhetetlen hurkot hozva létre.  | 
||
| + | ** A két érintett port közül bármelyiken megjelenő forgalom a végtelenségig fog keringeni és terheli a két érintett switchet.  | 
||
A lap jelenlegi, 2013. szeptember 24., 10:28-kori változata
Miről lesz szó? (Hozzávetőleges tematika)
- Elméleti alapok: hitelesítés, hozzáférésvezérlés stb.
 - Elterjedt protokollok működése, hozzájuk kapcsolódó biztonsági problémák, klasszikus támadások
 
Tartalomjegyzék | 
[szerkesztés] 1 Mi is a hálózatbiztonság?
Elvárások:
- integrity (integritás): a címzett győződhessen meg arról, hogy az általa vett üzenet megegyezik a feladó által feladott üzenettel (vagyis senki sem módosította azt a továbbítás során).
 - authentication (hitelesítés): a kommunikáló felek győződhessenek meg arról, hogy a másik fél valóban az, akinek mondja magát.
 -  confidentiality ("titkosság", "bizalmasság"): az átvitt üzenetek tartalmát a feladón kívül csak a címzett ismerhesse meg.
- Ha nem zárható ki az üzenet lehallgatása, ez csak kriptografikus titkosítással biztosítható.
 - Ennél tágabban is értelmezhető a confidentiality: lehet, hogy pusztán az a tény, hogy X üzenetet küldött Y-nak, szintén titok; ill. az is lehet bizalmas, hogy X mikor és hány üzenetet küldött egyáltalán.
 
 -  "operational security" (üzembiztonság): rosszindulatú felhasználó ne legyen képes a hálózat erőforrásaival visszaélni, pl. lehetőleg ne legyen képes:
- üzenetek lehallgatására;
 - lehallgatott üzenetek visszajátszására (ill. ha mégis képes rá, a visszajátszott üzenetek felismerhetőek legyenek);
 - más (létező vagy nem létező) felhasználók/végpontok megszemélyesítésére, a nevükben üzenetek küldésére;
 - arra, hogy másoktól megtagadja a hálózat szolgáltatásait (pl. a véges erőforrások elhasználásával);
 - más felek egymásnak küldött üzenetei tartalmának módosítására, vagy üzenetek eltüntetésére.
 
 
Ezek a célok jelenleg általában nem vagy csak a használhatóság rovására, életszerűtlen kompromisszumok árán érhetők el maradéktalanul; azonban a hálózatok tervezőinek, üzemeltetőinek döntései, módszerei megnehezíthetik (vagy éppen megkönnyíthetik) a támadók dolgát.
[szerkesztés] 2 Kitérő: kriptográfiai alapok
Alapfogalmak:
- Plaintext: titkosítás nélküli szöveg vagy adat.
 - Ciphertext: titkosított szöveg vagy adat.
 - Cipher: titkosítóalgoritmus (a titkosítás valamely konkrét módszere).
 -  Kód és cipher közötti különbség (noha a hétköznapi nyelvben összemosódik a két fogalom):
-  a kód jelentésekhez rendel valamilyen jelsorozatot, általában egy kódkönyv segítségével
- (pl. a "hajnalban támadunk"-hoz tartozhat mondjuk az "ARVSA5" kód);
 
 - a titkosítóalgoritmus egyedi jelekhez vagy jelsorozatokhoz rendel másik jelet vagy jelsorozatot.
 -  Számítógépes környezetben a titkosítóalgoritmusok használata általában előnyösebb, mert
- a kódok leginkább csak szöveg kódolására alkalmasak (titkosítani pedig digitalizált képet, hangot vagy mozgóképet is lehet);
 - a kódok töbnnyire csak véges sok különböző jelentést tudnak kódolni;
 - ügyesen megválasztott titkosítóalgoritmusokat a számítógépek rendkívül gyorsan tudnak futtatni.
 
 
 -  a kód jelentésekhez rendel valamilyen jelsorozatot, általában egy kódkönyv segítségével
 -  Kulcs: egy titkosítóalgoritmus alkalmazása során felhasznált (általában titkos) adat, amely a plaintexttel együtt meghatározza a ciphertextet.
- Formálisabban: ciphertext = F(plaintext, kulcs).
 
 -  Szimmetrikus kulcsú titkosítás: a titkosítás és a visszafejtés ugyanazzal a kulccsal történik. Formálisabban:
- ciphertext = F(plaintext, kulcs)
 - plaintext = F'(ciphertext, kulcs)
 - (Bizonyos titkosítások esetében F és F' ugyanaz a függvény, de ennek nem muszáj így lennie.)
 - A ciphertext és a plaintext között adott szimmetrikus kulcs mellett kölcsönösen egyértelmű a leképezés.
 
 -  Aszimmetrikus vagy nyilvános kulcsú titkosítás:
-  mindenkinek két kulcsa van: egy nyilvános és egy titkos.
- Ezeket nem tetszőlegesen választjuk; valamilyen matematikai kapcsolat van közöttük és speciális feltételeknek felelnek meg.
 
 - Amit az egyikkel titkosítunk, azt a másikkal lehet visszafejteni.
 - A nyilvános kulcsokat elvileg mindenki ismerheti (és kívánatos is, hogy ismerje).
 - Ha valakinek olyan üzenetet akarunk küldeni, amelyet csak ő tud elolvasni, az ő nyilvános kulcsával titkosítjuk; a csak általa ismert titkos kulccsal tudja olvashatóvá tenni.
 - Ha azt akarjuk, hogy bizonyítható legyen, hogy egy üzenetet mi küldtünk, a saját titkos kulcsunkkal titkosítjuk; ha a mi nyilvános kulcsunk segítségével dekódolható, abból következik, hogy a mi titkos kulcsunkkal lett titkosítva, és mivel azt csak mi ismerjük, ebből az is következik, hogy mi küldtük.
 - Nyilván fontos, hogy algoritmuselméleti értelemben nehéz legyen egy adott nyilvános kulcshoz tartozó titkos kulcsot előállítani.
 
 -  mindenkinek két kulcsa van: egy nyilvános és egy titkos.
 
[szerkesztés] 2.1 Klasszikus és modern titkosítóalgoritmusok
Klasszikus titkosírás pl. az ABC-eltolás (A helyett D-t írunk, B helyett E-t s.í.t.), vagy saját ABC használata. Itt nem válik el élesen az algoritmus és a kulcs: a titkosított üzenet csak akkor van biztonságban, ha a titkosítás módszerét nem fedjük fel.
A modern titkosítóalgoritmusokat úgy alkotják meg, hogy a titkosított üzeneteket akkor se lehessen a kulcs ismerete nélkül visszafejteni, ha a támadó ismeri az algoritmust. Az algoritmus tehát nyilvános; csak a kulcsot kell titokban tartani. Ha jó az algoritmus, a támadó dolgát nem könnyíti meg az algoritmus ismerete. A támadóról általában feltételezzük, hogy pontosan ismeri azt a titkosítóalgoritmust, amellyel az általa elolvasni kívánt rejtjelezett üzenetet titkosították.
[szerkesztés] 2.2 Mitől jó egy titkosítás?
- A próbálgatásnál (brute force) ne legyen hatékonyabb módszer a kulcs előállítására.
 -  Várhatóan annyi ideig tartson a kulcs próbálgatásos előállítása a támadónak, hogy mire végez, minden olyan titkos üzenet, amelyhez így hozzáfér, aktualitását veszítse.
- Méretezési kérdés, milyen erőforrások birtoklását feltételezzük a támadó(k)ról.
 - Egy jó szimmetrikus kulcsú titkosítóval manapság legalább 128 bites kulcsot illik használni;
 - nyilvános kulcsú titkosításnál nagyobb (RSA-nál minimum 2048 bites) kulcshosszra van szükség.
 
 -  Létezik elvileg is feltörhetetlen titkosítás (a one-time pad).
- Itt a kulcs legalább olyan hosszú, mint az üzenet, és minden szakasza csak egyszer hasznosítható.
 
 -  Lavina-effektus: két, akár csak egyetlen bitben különböző plaintexthez gyökeresen eltérő ciphertext tartozik.
- Vagyis: ránézésre lehetetlen megállapítani, hogy két elfogott titkosított üzenet tartalma hasonló.
 
 - Teljesség: a ciphertext minden bitje a plaintext minden bitjétől függ.
 - Hatékonyság: a kulcs birtokában a titkosítás és a visszafejtés is legyen gyors és kicsi memóriaigényű.
 
[szerkesztés] 2.3 Blokktitkosító, folyamtitkosító
-  A blokktitkosítók fix méretű blokkokat képeznek le egymásra.
- Ha a plaintext hossza nem osztható a blokkmérettel, ki kell egészíteni valahogyan.
 - Általában blokkszinten adott a lavina-effektus és a teljesség.
 
 -  A folyamtitkosító bitenként vagy bájtonként titkosít.
-  Kulcsfolyamra van szükség hozzá.
- Hosszú kulcs használata nehézkes; gyakori cél rövid kulcsból hosszú kulcsfolyamot generálni.
 
 
 -  Kulcsfolyamra van szükség hozzá.
 
[szerkesztés] 2.4 Hash (kivonat)
Cél: olyan rövid (96-512 bites) számot előállítani egy üzenetből, amelyre teljesül, hogy
- algoritmuselméleti értelemben nehéz az üzenetet úgy módosítani, hogy a hash értéke ne változzon.
 - Nehéz adott H hash-hez olyan üzenetet találni, amelyre a hash-függvény a H értéket adja.
 - A véletlen ütközések esélye rendkívül csekély.
 
[szerkesztés] 2.5 Néhány konkrét titkosító- és kivonatképző algoritmus
(Csak nagyon röviden.)
[szerkesztés] 2.5.1 Vernam-kód
- Egyfajta one-time pad, vagyis folyamtitkosító.
 - Az amerikai hadsereg számára fejlesztette 1917-ben Gilbert Vernam.
 - Lényege: a kommunikáló feleknek rendelkezésére áll egy titkos, véletlen bitekből álló bitsorozat, amelyet kulcsként használhatnak.
 -  Üzeneteiket valahogyan bitekké alakítják, és rendre hozzáadják az üzenetek bitjeihez a kulcs-bitsorozat bitjeit.
- (Mod2 összeadással, vagyis 0+0=0, 0+1=1, 1+0=1, 1+1=0.)
 
 - A visszafejtés ugyanígy történik: ugyanazt a kulcs-bitfolyamot ugyanúgy hozzá kell adni a bejövő ciphertexthez, és visszakapjuk a plaintextet.
 - Shannon 1949-ben bizonyította be, hogy a Vernam-kód feltörhetetlen.
 - Nehézség: nagyon nagy kulcs kell, amit előre meg kell osztani egymással és folyamatosan titokban kell tartani.
 
[szerkesztés] 2.5.2 DES
- 1976-os USA szabvány ("Digital Encryption Standard").
 - Blokktitkosító, 64 bites blokkokkal, 56 bites kulccsal.
 - Mára nem megfelelő; viszonylag olcsó hardverrel is mindössze órák (vagy legfeljebb napok) alatt feltörthető.
 -  Kísérlet a feljavítására: 3DES.
- Háromszor egymás után alkalmazza a DES-t, többféle kulccsal.
 - Az effektív kulcshossz így 80-168 bit aszerint, hány különböző kulcsot használunk és milyen módon.
 - Egyelőre megfelelő biztonságot nyújt, de lassú.
 
 
[szerkesztés] 2.5.3 AES
- Lánykori nevén Rijndael.
 - A DES-t váltó szabvány (2001-ben fogadták el).
 - 128 bites blokkokat titkosít 128, 192 vagy 256 bites kulccsal.
 - Gyors és egyelőre elegendően biztonságos.
 
[szerkesztés] 2.5.4 RSA
Az egyik legelterjedtebb nyilvános kulcsú titkosítóalgoritmus.
- Rivest, Shamir és Adleman nevéhez fűződik, holott egy Clifford Cocks nevű brit már 1973-ban kitalálta - de a britek titkosították és nem használták fel.
 - Rivest, Shamir és Adleman néhány évvel később publikálta saját, lényegében azonos algoritmusát.
 -  Feltörésének nehézsége azon alapul, hogy bizonyos számelméleti problémákra (mint pl. nagy egészek prímtényezős felbontására) nem ismertek gyors módszerek.
- De: ez nem jelenti azt, hogy nincsenek is ilyenek.
 
 -  Az elliptikus görbéken alapuló titkosítás jobbnak számít.
- Kisebb kulcshosszt igényel az RSA-nál és gyorsabb is.
 
 
[szerkesztés] 2.5.5 RC4
- Folyamtitkosító.
 - 1987-ben dolgozta ki Rivest; 1994-ben szivárgott ki a leírása.
 - Előnye, hogy nagyon egyszerű és gyors.
 - Széles körben elterjedt.
 -  Ésszel kell használni, mert különben nem ad jó eredményt.
- Az RC4 helytelen használata tette sebezhetővé pl. a WEP szabványt (részletesebben később).
 
 
[szerkesztés] 2.5.6 MD5
- 1990-ben megjelent hash algoritmus.
 - Széles körben elterjedt.
 - 128 bites hasht állít elő.
 -  2005-ben hibát találtak benne: aránylag könnyű ütközést generálni (másik olyan üzenetet találni, amelyhez ugyanaz a hash tartozik). 2007-re reálissá vált a hibán alapuló támadás indítása.
- Emiatt új kriptográfiai rendszerekben nem szabad használni.
 
 - Érdekesség: a Flame kémprogram egyes részeit egy olyan hamis CA-val (l. később) írták alá, amely látszólag a Microsofté volt; ezt szintén az MD5 gyengesége tette lehetővé.
 
[szerkesztés] 2.5.7 SHA-1
- 1993-ban publikált hash algoritmus.
 - Széles körben elterjedt.
 - 160 bites hasht állít elő.
 - Biztonságosnak számít.
 - Vetélytársai: RIPEMD-160 (OpenPGP), Tiger (ez 192 bites; főleg fájlcserélők használják).
 
[szerkesztés] 2.6 Kriptográfiai támadások
Az alapján, hogy milyen információk birtokában van a támadó, ill. mire van lehetősége, a következő nagyobb csoportokba sorolhatók az általa egy kriptográfiai rendszer ellen végrehajtható támadások:
- ciphertext-only attack (csak a titkosított szöveg birtokában végrehajtott támadás). Ilyenre akkor kerül sor, ha a támadó csak egy (vagy több) titkosított üzenetnek van a birtokában, és azok tartalmáról semmilyen ismerettel nem rendelkezik. Egyszerűbb (tehát nem modern) titkosítások esetében statisztikai analízis segítségével jó eredmények érhetők el. A modern titkosítókkal szemben elvárás, hogy egy ilyen támadás nagyjából annyira nehéz legyen, mint az összes lehetséges kulcs végigpróbálgatása.
 -  known plaintext attack (a titkosított szöveg birtokában végrehajtott támadás, ha a támadó sejti vagy tudja, mit tartalmazhat az üzenet). Példák:
- Elfogott titkosított időjárás- vagy helyzetjelentés hadszíntéren. Az üzenet tartalmából sokminden sejthető (helynevek, személynevek).
 -  Hitelkártya-adatok átvitele az Interneten. Sejthető, hogy van az üzenetben egy kb. 10-15 betűből álló név és kb. 20 számjegy.
- Egy jó titkosítóalgoritmus esetében a nyílt szöveg bizonyos részeinek vagy akár egészének ismerete sem teszi lehetővé a kulcs egyszerű rekonstruálását (és így további titkosított üzenetek visszafejtését).
 
 
 -  chosen plaintext attack (a támadó képes az általa választott nyílt szöveg titkosíttatására). Példák:
- Digitálisan aláírt email. A partnerünk, amikor válaszol nekünk, idézi a saját levelünket és azt -- saját üzenete részeként -- titkosítja a saját titkos kulcsával.
 -  Merevlemez-titkosítás. Ha egy támadó ellop egy működő notebookot, amelynek a merevlemeze titkosítva van, megkísérelheti úgy feltörtni a titkosítást, hogy ismert tartalmú fájlokat ment el rá.
- Egy jó titkosítóalgoritmus esetében ez a fajta támadás sem elegendő a kulcs visszafejtéséhez (tehát a fenti esetben sem vagyunk sokkal közelebb a levelezőpartner titkos kulcsának megszerzéséhez).
 
 
 
[szerkesztés] 3 Tanúsítványok
L. az SSL-ről szóló szócikket.
[szerkesztés] 4 Jelszó-alapú hitelesítés
-  Ha egy szolgáltatást csak nevesített felhasználóknak akarunk nyújtani, valahogyan meg kell tudnunk, ki próbálja igénybe venni a szolgáltatást.
- A hitelesítés és a hozzáférésvezérlés két különböző dolog: lehet, hogy egy szolgáltatást bárki használhat, csak tudnunk kell, kicsoda (pl. bankszámlát akárki nyithat, de többnyire csak névvel).
 
 
Hogyan állapítsuk meg, ki a felhasználó?
-  Kézenfekvő, egyszerű megoldás: felhasználónév+jelszó.
- A jelszó önmagában kevés: hozzáférésvezérléshez elegendő, hitelesítéshez viszont csak akkor, ha az üzemeltető osztja ki a garantáltan egyedi jelszavakat a felhasználóknak.
 - Ha a felhasználó magának választhatja a jelszót, akkor a jelszó egyedisége nem garantált, tehát kell egy egyedi azonosító is; ez a felhasználónév.
 -  Aki egy adott {felhasználónév, jelszó} párost ismer, arról általában elhisszük, hogy az a személy, akihez az adott felhasználónév tartozik.
- A hozzáférésvezérlés szempontjából ez persze nem feltétlenül elegendő: lehet, hogy csak adott helyről vagy adott időablakban engedjük hozzáférni a szolgáltatáshoz.
 
 
 
Nehézségek a jelszó-alapú hitelesítésnél:
-  A jelszavak a hálózaton lehallgathatók lehetnek. Lehetséges megoldások:
- titkosított protokoll használata;
 -  egyszer használatos jelszavak (OTP, one-time password) használata.
- Ezzel vigyázzunk; ha a támadó képes karakterenként lehallgatni a jelszót, az utolsó karakter felhasználó általi leütése előtt próbálgatásos támadást indíthat az utolsó karakter kitalálására.
 
 -  Challenge-response ("kihívás-válasz") alapú hitelesítés.
-  Lényege: a jelszót nem utaztatjuk a hálózaton; a hitelesítő a jelszóra vonatkozó, kriptográfián alapuló "találós kérdést" ad fel a kliensnek, amely a jelszó birtokában tud rá helyesen válaszolni.
- Ez a viszonthitelesítést is lehetővé teszi: megoldható, hogy csak az tudjon érvényes találós kérdést feltenni, aki maga is ismeri a jelszót.
 - Egyszerű példa: "itt van ez a véletlenszerűen generált sztring; fűzd össze a jelszóval és képezz belőle hash-t, majd a hash-t küldd vissza".
 
 - Hátrány: sok challenge-response protokoll plaintext jelszó tárolását igényli.
 
 -  Lényege: a jelszót nem utaztatjuk a hálózaton; a hitelesítő a jelszóra vonatkozó, kriptográfián alapuló "találós kérdést" ad fel a kliensnek, amely a jelszó birtokában tud rá helyesen válaszolni.
 
 -  Márpedig ha a jelszavakat titkosítás nélkül tároljuk a szerveren, onnan egy menetben ellopható az összes.
- Ráadásul az emberek gyakran ugyanazt a jelszót több helyen is használják.
 -  Lehetséges megoldások:
-  Jelszavak "titkosított" tárolása.
- A sima titkosítás nem sokkal jobb, mint a plaintext, hiszen a hitelesítéshez dekódolni kell a titkosított jelszót, ha pedig a hitelesítő képes erre, akkor még mindig ellopható az összes jelszó.
 -  A jelszó helyett csak egy hash-t tárolunk.
- Gond: két azonos jelszó hash-e is meg fog egyezni;
 - ha valaki már egy csomó szótári szó hash-ét meghatározta, a tőlünk ellopott hash-ek között jó eséllyel talál olyat, amelyhez ismer jelszót.
 - Jobb "megsózni" jelszót hash-elés előtt: kiegészíteni egy véletlen sztringgel, és azzal együtt hash-elni, majd a hash mellett ezt a sztringet is tárolni.
 
 
 
 -  Jelszavak "titkosított" tárolása.
 
 - A hash-elt jelszótárolás és a kihívás-válasz alapú hitelesítés elvileg ötvözhető; így működik pl. az NTLMv2.
 
[szerkesztés] 4.1 Ajánlott irodalom
- Your Top 20 Most Common Passwords -- 32 millió kiszivárgott jelszó vizsgálata.
 - Hogyan választanak jelszót az emberek?
 - John the Ripper -- Az egyik legelterjedtebb szótáralapú jelszótörő (képes a szótár szavait szabályok segítségével átírni, kombinálni, és az így nyert szavakkal is próbálkozni).
 - egy cikk arról, mennyire könnyű "biztonságos" jelszót kitalálni, és cáfolata.
 - An Illustrated Guide to Cryptographic Hashes -- Jó, tömör és szemléletes cikk a kriptográfiában használt hash-ekről.
 - Amazon EC2 enables brute-force attacks on the cheap -- Az Amazon felhőjén néhány dollárért másodpercenként 400.000 jelszót próbálhatunk egy hash-re illeszteni.
 - http://www.troyhunt.com/search/label/Passwords -- Jó cikksorozat a jelszavakról általában.
 - The only secure password is the one you can’t remember
 - webképregény arról, hogyan válasszunk nehezen feltörhető, de könnyen megjegyezhető jelszót, és cáfolata (konklúzió: használjunk véletlenszerű jelszavakat és ezeket tároljuk tikosítva úgy, hogy egyetlen erős jelszót kelljen csak megjegyezni ahhoz, hogy hozzájuk férhessünk).
 - webképregény arról, hogyan lehet visszaélni azzal, hogy az emberek sok helyen ugyanazt a jelszót használják.
 - webképregény arról, mennyire mindegy lehet, milyen erős titkosítást használunk - fizikai erőszakkal általában nem nehéz a jelszavak birtokába jutni.
 - Tömör, bár kissé felületes cikk arról, mennyire gyorsan törhetők a hosszú jelszavak is, próbálgatással is (az adatok helyességét nem ellenőriztem -- emellett számomra nem volt nyilvánvaló, milyen hasht feltételez, ami a másodpercenként végrehajtható próbálkozások száma szempontjából nem mindegy).
 
[szerkesztés] 5 Az adatkapcsolati (és fizikai) réteg; Ethernet
Fogalmak:
- Csomópont: olyan eszköz, amelynek van olyan interfésze, amellyel az adatkapcsolati rétegben kommunikálni tud; például hoszt vagy router.
 - Kapcsolat: fizikai összeköttetés két vagy több fizikai interfész között.
 -  Keret: adatkapcsolati szintű adatcsomag; magasabb rétegbeli protokollok (pl. IP) csomagjait szállít(hat)ja egy kapcsolatnyi távolságra.
- Általában egy keretre jut egy magasabb szintű adatcsomag, de szükség lehet arra, hogy egy-egy csomagot több keretre bontsunk szét.
 
 -  Adatkapcsolati protokoll: meghatározza a keretek formátumát és azt, hogyan kezelik őket ill. a kapcsolatokat a csomópontok.
-  Garantál megbízhatóságot?
-  Csomag (keret) kézbesítését, integritását?
- Hibadetektálás vagy hibajavítás.
 - Nyugtázás, újraküldés.
 
 - QoS-t?
 - Az átvitt adatokban?
 - Az infrastruktúrát illetően?
 
 -  Csomag (keret) kézbesítését, integritását?
 -  Broadcast vagy pont-pont?
- Hogyan működik a címzés?
 -  Közeghozzáférés-vezérlés (MAC: medium access control)? Módszerek:
- Csatorna-felosztás (pl. frekvenciaosztásos vagy kódosztásos multiplexelés);
 -  véletlen hozzáférés (pl. Ethernet)
- (carrier sensing, collision detection);
 
 - felváltva adás (pl. Token Ring).
 
 
 - Folyamszabályozás: a küldő ne küldjön gyorsabban, mint ahogy a fogadó fel tudja dolgozni.
 - Duplexitás (half duplex, full duplex).
 
 -  Garantál megbízhatóságot?
 
Az adatkapcsolati réteg feladata: adatkeretek szállítása két szomszédos (közvetlenül összekapcsolt) csomópont között. Az adatkapcsolati réteg fölött elhelyezkedő hálózati réteg már egymástól távoli csomópontok között szállít adatcsomagokat; az útvonalon elhelyezkedő csomópontok (routerek) közötti szakaszokon más-más adatkapcsolati rétegbeli protokollt (vagyis hálózati technológiát) is használhatunk. Ideális esetben a hálózati rétegben működő programok semmit sem tudnak (és semmit sem kell, hogy tudjanak) az adatkapcsolati réteg sajátosságairól.
- Analógia: ha Budapestről az Orkney-szigetekre akarunk eljutni (mi vagyunk a hálózati adatcsomag analógiája), akkor először eltaxizunk a reptérre (a taxi egy adatkapcsolati és fizikai rétegbeli protokoll); aztán repülővel elmegyünk mondjuk Edinburgh-ba; onnan vonattal Invernessbe; ott autót bérlünk és elautózunk John o' Groats-ig; itt pedig az autóval felhajtunk a kompra, ami autóstul elvisz Burwickbe.
 - Ez már az Orkney-szigetek egyikén található, vagyis célba értünk. Az utolsó szakaszon enkapszuláció is történt: az egyik adatkapcsolati rétegbeli keretet (az autót, benne a hálózat csomaggal, vagyis velünk) egy az egyben beraktuk egy másik technológiájú adatkapcsolati rétegbeli keretbe (a kompba).
 - A komp-vonal két végpontja között a belső keret (az autó) változatlan formában utazott; a távoli végpontnál kicsomagoltuk a külső keretből a belsőt, amely folytatta útját, és végül célba juttatta a hálózati csomagot (az utast).
 
Néhány elterjedt adatkapcsolati rétegbeli protokoll:
- Ethernet (IEEE 802.3*)
 - 802.11 WLAN (WiFi);
 - Token Ring (ritka);
 - FDDI (elavult);
 - PPP (Point to Point protocol);
 - LAPB (az X.25 adatkapcsolati rétegbeli protokollja);
 - DOCSIS (a kábeltévés internetszolgáltatás fizikai és adatkapcsolati rétege);
 - HDLC (egy ősprotokoll; a LAPB pl. ennek a leszármazottja);
 - ARCnet.
 
Az adatkapcsolati rétegbeli protokoll megvalósítása általában hardveres, és a hálózati kártyában található.
[szerkesztés] 5.1 Ethernet
"Ethernet, n: a device used to catch the etherbunny."
- Majdnem biztosan a legelterjedtebb adatkapcsolati rétegbeli protokoll (és fizikai közeg).
 -  Minden csomópontnak (pontosabban: minden hálózati interfésznek) elvileg globálisan egyedi hatbájtos MAC-címe van.
- Notációk: aa:bb:cc:dd:ee:ff (Unix); AA-BB-CC-DD-EE-FF (Windows); aabb.ccdd.eeff (Cisco).
 - A hardvergyártó állítja be, de ma már szinte mindig átírható szoftverből.
 -  A címek strukturálatlanok (nincs pl. a hálózat topológiájából adódó hierarchia).
- Mindazonáltal az első 24 bit azonosítja a gyártót.
 
 
 -  Broadcast ("üzenetszórásos") elven működik.
- Minden, az adott szegmensben levő kártya ("adapter") minden keretet megkap; a címzés alapján dönti el, kell-e vele foglalkoznia.
 - Speciális cím: ff:ff:ff:ff:ff:ff (csupa egyes): mindenkinek szóló üzenet.
 - Szoftverből utasítható az adapter arra, hogy a nem neki szóló kereteket is olvassa el ("hallgassa le"): sniffing.
 
 - Szigorúan véve nem Ethernet-specifikus, de ide tartozik: ARP (IP címhez keres MAC-címet).
 -  Keretformátum kb:
- "Preamble" (a fizikai réteg sajátosságain alapul; könnyen észlelhető "keret eleje"-jelzés, 8 byte). A két végpont óráinak (órajelének) szinkronizálást is segíti.
 - Célcím (6 byte);
 - Forráscím (6 byte);
 - Hálózati rétegbeli protokoll azonosítója (2 byte; pl. IP, IPX, Decnet stb.);
 - Adatok (max. 1500 byte);
 - Ellenőrző összeg (CRC, 4 byte).
 
 
[szerkesztés] 5.1.1 Eszközök (hub, bridge, switch stb.)
-  Repeater: két fizikai szegmenst köt össze bit-szinten. 
- Ha az egyik interfészén megjelenik egy bit, azt kiküldi a másik interfészén.
 - Lényegében egy erősítő: a csillapított jel helyett egy szép új jel jelenik meg a másik interfészen.
 - A két fizikai szegmens egyetlen logikai szegmenst (collision domaint) alkot: nem adhat egyszerre két csomópont akkor sem, ha a repeater két oldalán vannak és a címzettjeik is a velük azonos oldalon találhatóak.
 - Ha a repeater különböző fizikai, de azonos adatkapcsolati réteget használó szegmens között van, akkor médiakonverternek is hívják.
 
 - Hub: sokportos repeater.
 -  Bridge: két fizikai szegmenst köt össze keretek szintjén. 
- Az egyik interfészen bejövő keretet megismétli a másik interfészen.
 - Megtanulja, melyik MAC-címek melyik interfész felé vannak, és csak akkor adja tovább a keretet, ha szükséges (a címzett a másik oldalon van, vagy broadcast keretről van szó).
 -  Két különböző, de alapvetően Ethernet-szerű hálózat közé is tehető bridge: pl. vezetékes Ethernet és WiFi vagy Token Ring.
- Ilyenkor a bridge kénytelen bizonyos mértékű protokoll-átalakítást is végezni, ami nem mindig tud 100%-os lenni (pl. ha az egyik hálózatban van QoS, a másikban pedig nincs).
 
 - Ha a keretformátum azonos (és csak a fizikai réteg különbözik, pl. 10BASE-T és 100BASE-FX), nem kell protokoll-átalakítás sem.
 
 -  Switch: sokportos bridge.
- A végpontok számára transzparens (a kereteket nem a switchnek, hanem egymásnak címzik).
 -  Minden porton csak azokat a kereteket küldi ki, amelyek az adott portra kapcsolt állomások valamelyikének szólnak.
- A portokhoz nemcsak végpontok, hanem további switchek is csatlakoztathatók; így egy porthoz sok végpont is tartozhat.
 -  A switch egy ún. MAC-táblában tartja nyilván, melyik MAC-című állomás melyik portra csatlakozik.
-  Szintén nyilvántartja, melyik MAC-port párost mikor "tanulta meg"; a hosszú ideig inaktív MAC-eket kidobálja a táblából.
- Lehetséges anomália-észlelés: ha ugyanaz a MAC "egyszerre" van jelen két porton is, a switch gyanakodhat hurokra vagy hamisításra és küldhet riasztást.
 
 
 -  Szintén nyilvántartja, melyik MAC-port párost mikor "tanulta meg"; a hosszú ideig inaktív MAC-eket kidobálja a táblából.
 - A táblában nem szereplő MAC-címeknek szóló csomagokat minden porton kénytelen kiküldeni (kivéve azon, amelyiken bejöttek).
 - Természetesen a broadcast kereteket is minden interfészen kiküldi.
 - Ha a cél-MAC azon a porton van, amelyiken a keret bejött, a switch nem továbbítja.
 -  Előfordulhat, hogy egy porton egyszerre több keretet is ki kellene küldeni (mert két másik portról is beesett egy-egy erre a portra tartó keret). Emiatt minden porthoz tartozik egy kimenő puffer, amiben a keretek várják, hogy ki lehessen küldeni őket.
- (Nyilván szintén várni kell, ha ütközés van a kimenő porton.)
 
 
 - Olyan hálózatban, amelyben nincs hub, csak switch, sosincs ütközés (mivel csak full duplex pont-pont kapcsolatok léteznek).
 -  Mivel a switch kereteket másol (hiszen nem más, mint egy sokportos bridge), kiválóan alkalmas különböző sebességű (és fizikai réteget használó) Ethernet-szegmensek összekapcsolására.
- Pl. gyakori, hogy egy-egy switchnek van mondjuk 24 100mbites és 4 gigabites portja.
 
 - A switch könnyedén leválaszthatja a hálózatról a hibás (pl. folyamatosan adó) csomópontokat.
 - Switchelt hálózatban egy kábelszakadás csak egyetlen végpontot érint (a hagyományos busz-topológiájú Ethernetnél az egész hálózat használhatatlanná válik, ha a busz megszakad).
 
 
[szerkesztés] 5.2 STP, RSTP, MSTP
(Spanning Tree Protocol, Rapid Spanning Tree Protocol, Multiple Spanning Tree Protocol.)
Forrás: Jákó András: Spanning Tree Protocol, 2004..
Fontos fogalom: collision domain (már volt róla szó). Az Ethernet-hálózatok olyan összefüggő részei, amelyek csak passzív alkatrészeket, repeatereket és/vagy hubokat tartalmaznak, egyetlen collision domaint ("ütközési tartományt") alkotnak.
-  Általában szeretnénk, hogy a collision domainek minél kisebbek legyenek.
- Minél több végpont van ugyanabban a collision domainben, annál valószínűbb, hogy lesz köztük legalább kettő, amelyik egyszerre akar beszélni és így ütközés jön létre.
 - Az ütközés rontja a hatékonyságot (az ütközés résztvevői elhallgatnak, várnak egy kicsit, aztán újra megpróbálnak adni). Minél több az ütközés, az időnek annál kisebb részében továbbít a hálózat hasznos adatot.
 - Egy collision domaint általában switch beiktatásával vágnak fel több collision domainre (legfeljebb annyira, ahány portja a switchnek van).
 
 
Másik fontos fogalom: broadcast domain (szintén volt már róla szó). Az Ethernet-hálózatok olyan összefüggő részei, amelyek switchek vagy bridge-ek segítségével összekapcsolt collision domainekből állnak, egy broadcast domain ("üzenetszórási tartományt") alkotnak.
-  Egy broadcast domainen belül az állomások MAC-cím alapján meg tudják egymást címezni; az FF:FF:FF:FF:FF:FF MAC-címre küldött keretek pedig minden állomáshoz eljutnak.
- Így pl. az ARP segítségével működik az IP is, router nélkül.
 
 - Korábban a szervezetek általában arra törekedtek, hogy az egész hálózatuk lehetőleg egyetlen broadcast domaint alkosson; ez ma már nem annyira jellemző.
 -  A törekvés okai:
- Lehetőleg ne kelljen route-olni a közvetlenül az Ethernetre épülő protokollokat (pl. IPX).
 - Működjön a Windows Network Neighborhood ("Hálózati Helyek") - kb. a Windows 2000-ig erősen épült az Ethernet broadcastra.
 
 -  A nagy broadcast domain hátránya, hogy ha nagy a broadcast-forgalom (pl. mert sok a windowsos munkaállomás), megnő a hálózat terhelése.
- A broadcastok olyan szegmensekbe is eljutnak, ahol igazából nincs is rájuk szükség -- pl. mert nincs ott Windows.
 
 -  Ma a Windows fájlmegosztó/névfeloldó protokollcsaládja már broadcast nélkül is tud jól működni, az IPX pedig lényegében kihalt, így egyre kevesebb a motiváció a nagy, összefüggő broadcast domainek fenntartására.
- Pl. a BME 152.66.0.0/16-os hálózata is számos routert tartalmaz, és csak az egyes tanszékek belső hálózatai alkotnak egy-egy (vagy némely esetben több) broadcast domaint.
 
 
- Mi történik, ha egy Ethernetben kör van?
 
-  Ha pl. A, B és C switchek, és van A-B, B-C és C-A kapcsolat, a keretek elvileg az idők végezetéig járnak körbe-körbe.
- Az Ethernet-keretben nincs TTL mező, mint az IP-ben.
 - Esélytelen nyilvántartani, melyik keretet láttuk már (hogy azt ne küldjük tovább újra).
 - Vagyis nincs semmilyen automatikus mechanizmus a körbe-körbe menő csomagok megállítására.
 
 -  Broadcast Storm: amikor egy broadcast (vagy ismeretlen) címre küldött keret vég nélkül kering a hálózatban.
- Ha több hurok van, többszöröződik is.
 
 - Járulékos gond: mivel az adott forráscímről jövő csomagok esetleg hol az egyik, hol a másik porton jutnak el egy switchbe, a MAC-táblát is folyton frissíteni kell, és az adott MAC-nek szóló keretek, ha épp rosszkor esnek be, esetleg nem a megfelelő irányba mennek ki.
 
Na de miért lenne hurok (kör) a hálózatban egyáltalán?
- Redundancia (ha valamelyik link, esetleg valamelyik switch kiesik, ne essen szét a hálózat).
 - Véletlenül (rossz helyre dugunk egy kábelt).
 
Mivel az Ethernet hurokmentessége nem garantálható, és a hurkok katasztrofális hatásúak, szükség van egy olyan mechanizmusra, amely felismeri és automatikusan kiiktatja őket. Az STP (és továbbfejlesztései) ezt a feladatot oldják meg.
Kapcsolódó szabványok:
- Spanning Tree Algorithm and Protocol: 802.1D-1998, 802.1t-2001
 - Rapid Spanning Tree Algorithm and Protocol: 802.1w-2001 (802.1D-2004)
 - Multiple Spanning Tree Protocol: 802.1s-2002, 802.1Q-2003
 
Az STP működését l. Jákó András előadásában (figyelem: sokkal részletesebb, mint amennyire itt most szükséges).
- Az RSTP az STP felgyorsítása.
 - Az MSTP több feszítőfát használ, hogy ha ugyanazokon a switcheken több VLAN forgalma bonyolódik le, az egyes VLAN-ok forgalma más-más útvonalakon haladjon (ahol lehet).
 
- Biztonsági vonatkozások
 
-  Hamis BPDU-kkal a feszítőfa-építés folyamata megzavarható:
-  Közepes számú, gyakran változtatott hamis üzenettel megakadályozható konzisztens állapot kialakulása.
- Főként, ha ezeket a hálózat több pontján egyszerre injektáljuk.
 
 - Ha egy támadó egyszerre több switchhez is képes csatlakozni (akár több mobil eszközzel, amelyek mondjuk 3G-n vagy wifin kommunikálnak), megpróbálhat egy olyan feszítőfát kikényszeríteni, amelyben minden olyan collision domain között, amelyben jelen van, az ő eszköze a designated bridge (ill. ő a root bridge is); így a collision domainek közti forgalom őrajta halad át, vagyis lehallgathatja, módosíthatja stb.
 
 -  Közepes számú, gyakran változtatott hamis üzenettel megakadályozható konzisztens állapot kialakulása.
 -  Védekezés: a switcheken be kell állítani, hogy melyik portjuk néz másik saját switch felé. A többiről nem fogadnak el BPDU-t (sőt: ha jön, egy időre deaktiválják a portot).
- Utóbbi, ha nemcsak egy-egy gép lóg egy-egy switchporton, DoS-ra ad lehetőséget: az áldozatot is tartalmazó collision domainből BPDU-kat kezdünk küldeni, így a switch leválasztja a portot, az áldozatnak pedig megszűnik az Internet-kapcsolata.
 
 
[szerkesztés] 5.3 VLAN
Lényege: több virtuális Ethernet kialakítása ugyanazon a fizikai switch-halmazon.
Vonatkozó szabvány: IEEE802.1Q/802.1p.
- Működés alapja: a switchnek megmondjuk, melyik port hányas számú VLANba tartozik.
 - Ha minden port csak egyetlen VLANnak része, ennyi elég is -- feldaraboltuk a switch(ek)et több virtuális switchre.
 -  De: két switch között miért kelljen két kábel?
-  Megoldás: "trunk port". Négybájtos fejléc-kiegészítés (VLAN tag) az Ethernet-keret elején, amelyből 12 bit a VLAN-azonosító (hányas számú VLANba szól a keret).
- Vigyázat: a HP például az EtherChannelt (amikor több párhuzamos kábelt egyetlen virtuális kábelként használunk) hívja trunk-nak. A hálózati eszközök gyártóinak terminológiája a feltétlenül szükségesnél lényegesen változatosabb.
 
 - Jobb oprendszerek is támogatják, így nemcsak két hálózati eszköz között használható, hanem pl. switch és szerver között is -- a szerver pedig több Ethernetnek szolgáltathat egyszerre, egyetlen fizikai hálózati interfészen.
 
 -  Megoldás: "trunk port". Négybájtos fejléc-kiegészítés (VLAN tag) az Ethernet-keret elején, amelyből 12 bit a VLAN-azonosító (hányas számú VLANba szól a keret).
 -  Switcheken általában portonként beállítható:
-  a port "jellege" (gyártónként változik a terminológia és a megközelítés):
- access -- csak végpontok vannak rajta. Nincs VLAN tag (és remélhetőleg a bejövő kereteken sem fogadja el). A port általában csak egyetlen VLANnak része (és a bejövő kereteket automatikusan ebbe a VLANba szólónak tekintjük).
 - trunk -- másik hálózati eszköz van rajta. Minden keretet taggel látunk el. Általában több VLANnak része a port, és csak VLAN taggel ellátott kereteket hajlandó fogadni.
 - hybrid -- a port több VLAN része. Külön beállíthatjuk, melyik VLANokba menő forgalmat kell tagelni és melyikeket nem. A bejövő jelöletlen kereteket általában egy meghatározott VLANba szólónak tekintjük.
 - (Előfordulhat egy további típus, aminél VLAN tagelt keretek kapnak további VLAN taget.)
 
 -  a port VLAN-tagságai (melyik VLANokba szóló kereteket kell kiküldeni rajta);
- ezek közül melyeket tagelve és melyeket tag nélkül;
 
 - legyen-e "ingress filtering", vagyis eldobja-e azokat a kereteket, amik ezen a porton jönnek be és olyan VLANba szólnak, amelynek a port nem tagja;
 - melyik VLANba szólónak tekintsük a bejövő tag nélküli kereteket.
 - a másik végpont regisztrálhasson-e dinamikusan újabb VLAN-tagságokat.
 
 -  a port "jellege" (gyártónként változik a terminológia és a megközelítés):
 - Bizonyos switchek képesek MAC-cím vagy egyéb forgalmi jellemző alapján más-más VLANba sorolni az ugyanarról a portról bejövő kereteket.
 - Jobb WiFi hozzáférési pontok képesek több SSID-t ("hálózat-azonosítót") is hirdetni, és a végpontok forgalmát saját Ethernet-interfészükön más-más VLANba sorolni aszerint, hogy az adott végpont melyik SSID-ra kapcsolódott.
 
- Biztonsági vonatkozások
 
Forrás: Cisco.
- A támadó küldhet olyan VLAN taggel ellátott keretet, amely VLANnak a felé néző port nem része.
 - A támadó küldhet két VLAN taggel ellátott keretet. Ha ezt a switch olyan porton küldi ki, amelyen a konfiguráció szerint az első tag-re nincs szükség (az adott portnak ez a "natív" VLANja és nem kértünk tagelést), akkor így azon a porton a második VLAN-tagben megadott VLANba szóló keret fog kimenni.
 - Ha lehetséges a VLAN-tagságok dinamikus regisztrációja, a támadó egyszerűen beléphet az őt érdeklő VLANokba.
 
[szerkesztés] 5.4 További támadások switchek ill. switchelt Ethernet ellen
-  Switchelt hálózatban nehéz sniffelni (a támadó felé néző porton csak a neki szóló keretek jelennek meg).
-  Ha viszont a támadó elárasztja hamis forrás-MAC-címekkel a switchet, kiszoríthatja a valódi MAC-eket a MAC-táblából és elérheti, hogy a switch a legtöbb keretet broadcastolja. Védekezés:
- 802.1x -- switchport-szintű autentikáció (viszont így egy switchporton csak egy végpont lóghat).
 - A jobb switchekben korlátozható, hogy egy-egy porthoz legfeljebb hány MAC-cím tartozhat.
 
 - Kifinomultabb támadó csak egyetlen MAC-et (pl. egy szervert) támad: ha a szerver magától nem nagyon forgalmaz, a switch a támadó portját jegyzi be az adott MAC-hez, és a támadó kapja meg a szervernek szánt csomagokat.
 
 -  Ha viszont a támadó elárasztja hamis forrás-MAC-címekkel a switchet, kiszoríthatja a valódi MAC-eket a MAC-táblából és elérheti, hogy a switch a legtöbb keretet broadcastolja. Védekezés:
 -  A switch átengedi (továbbítja) az Ethernet broadcastokat. Ha sok broadcastot küldünk, az egész hálózatot megbéníthatjuk.
- Jobb switchekben van "broadcast storm protection", ami pl. a gyanúsan nagy rátával üzenetszóró végpontok felé néző portokat kikapcsolja.
 
 -  A támadó összekapcsolhat két switchportot úgy, hogy kiszűri a forgalomból az STP működéséhez szükséges BPDU-kat, így a switchek számára észlelhetetlen hurkot hozva létre.
- A két érintett port közül bármelyiken megjelenő forgalom a végtelenségig fog keringeni és terheli a két érintett switchet.