Hálózatbiztonság

A Unix/Linux szerverek üzemeltetése wikiből
A lap korábbi változatát látod, amilyen KornAndras (vitalap | szerkesztései) 2012. április 11., 13:50-kor történt szerkesztése után volt.

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

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.

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.
  • 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.

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.

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ű.

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.

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.

2.5 Néhány konkrét titkosító- és kivonatképző algoritmus

(Csak nagyon röviden.)

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.

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ú.

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.

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.

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).

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).
    • Emiatt új kriptográfiai rendszerekben nem szabad használni.

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).

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).

3 Tanúsítványok

A tanúsítvány lényegében nem más, mint egy nyilvános kulcs, egy érvényességi idő, plusz a tulajdonos neve (vagy hosztneve, IP-címe, emailcíme stb.), digitálisan aláírva (hiszen amúgy bárki állíthatná, hogy ő teszemazt az OTP Bank, és a nyilvános kulcsa a mellékelt kulcs). Az aláírás készítője az aláírás elkészítésével azt jelenti ki, hogy meggyőződött arról: a nyilvános kulcs valóban a tanúsítványban megnevezett entitáshoz tartozik.

A tanúsítvány-alapú hitelesítés tehát legfeljebb annyira jó, amennyire az aláírások készítői alaposak -- amennyire (hihető, hogy) lehetetlen olyan aláírt tanúsítvány birtokába jutni, amely valaki másnak a nevére szól.

Arra, hogy az aláírást ki készíti, két elterjedt modell van:

  1. Web of Trust (bizalmi háló). A kulcstulajdonosok egymás tanúsítványait hitelesítik (egy tanúsítványt tipikusan egynél több aláírással is ellátnak).
    • Ha Katona Anna, Varga Bence, Pór Jutka, Fazekas Marci, Fazekas Eszter, Domokos Matyi, Vas Pista, Pengő Gyöngyi, Fodor Dávid és Kovács Vicu egybehangzóan állítja (és saját digitális aláírásával megerősíti), hogy a mellékelt nyilvános kulcs Vackoré, a piszén-pisze kölyökmackóé, akkor ezt hajlamosak lehetünk elhinni (míg ha csak a közismerten szeleburdi Pór Jutka és az iszákos, ufóhívő Vas Pista állítja, akkor esetleg nem).
      • Mindennek persze csak akkor van értelme, ha amúgy már más hiteles forrásból ismerjük az aláírók legalább egy részének a nyilvános kulcsát, és feltételezzük róluk, hogy ők maguk meggyőződtek arról, hogy a szóban forgó kucls tényleg Vackoré -- pl. Vackor maga mondta nekik.
      • Tehát a legnagyobb gond: minél több kulcs valódiságáról saját magunknak kell meggyőződnünk, hogy utána a velük készült aláírásokat elfogadhassuk.
      • Bárki könnyen csinálhat magának 5000 aláírással ellátott tanúsítványt (elég hozzá 5000 automatikusan generált kulcspár); a bizalmat nem (csak) az aláírások száma, hanem a minősége alapozza meg.
      • A bizalmi gráf sűrűségének fokozására aláíró-rendezvényeket szoktak tartani, ahová az adott városban tartózkodó, kulcspárral rendelkező emberek elmehetnek, és hitelesíthetik egymás tanúsítványait -- miután meggyőződtek a másik személyazonosságáról.
        • Gond: emberi tényező. Sokan egy Balaton szeletért bármit hitelesítenek. Az ismeretlen személyek aláírásai már csak emiatt sem érnek semmit, arra viszont világméretű rendszer esetében kevés az esély, hogy egy véletlenszerűen kiválasztott résztvevő tanúsítványát hitelesítette valamelyik megbízhatónak gondolt ismerősöm.
          • Az ilyen értelemben vett megbízhatóságnak nagyon kevesen vannak birtokában: gondosan ügyelni kell(ene) arra, hogy az aláírandó tanúsítványban tényleg a kulcspárt birtokló személy vagy szervezet neve legyen, ne egy ahhoz megtévesztésig hasonló név (Kovács vs. Kováts, Sípos vs. Sipos, OTP Bank NyRt. vs. Országos Takarékpénztár, Gáz Géza vs. dr. Gáz Géza stb.).
        • Névváltozáskor új tanúsítványra van szükség; újra össze kell gyűjteni elegendő számú és minőségű aláírást, ami nem egyszerű.
          • A cégek neve "naponta" változik (Pannon GSM -> Pannon -> Telenor; Matávnet -> Axelero -> T-Home stb.).
          • A személyek új címeket vesznek fel a nevükbe, férjhez mennek, megnősülnek stb.
  2. Központi hitelesítés. Van egy vagy néhány definíció szerint megbízható hitelesítőközpont (vagy hitelesítő/hitelesítési hatóság: CA, Certification Authority), és minden tanúsítványt ezek valamelyike hitelesít (többnyire jó pénzért).
    • A tanúsítványok pontosan annyira megbízhatóak, amennyire az őket aláíró hitelesítőközpont az.
    • Ezt a modellt használja az SSL (és így a https).
      • A világméretű hitelesítő hatóságok tanúsítványai (nyilvános kulcsai) be vannak építve a böngészőkbe (és egyéb alkalmazásokba) -- szintén jó pénzért (amit a CA fizet a böngésző gyártójának; neki megéri, mert a böngészők támogatása teszi eladhatóvá a szolgáltatását).
        • Így a böngészők tudják ellenőrizni a CA-k által aláírt tanúsítványok (www.otpbank.hu, mail.google.com stb.) hitelességét -- vagyis el tudják dönteni, hogy a tanúsítványt valamelyik általuk ismert CA írta-e alá.
      • 2012-ben ezres nagyságrendű ilyen (a böngészők által elismert) hitelesítőközpont van.
      • Ezek megbízhatósága... "ellentmondásos megítélésű". Egymást érik a botrányok, és elég, ha az egyik nem elég szigorú, máris kérdésessé válik az egész rendszer biztonságossága.
        • Az egyik CA hitelesített egy olyan, a Microsoft nevére szóló, kód-aláírásra szolgáló tanúsítványt, amely nem a Microsofté volt (röviddel később visszavonták).
        • Forgalomban vannak nem globálisan egyedi nevekre szóló tanúsítványok (pl. "localhost", "mail").
        • Némelyik hitelesítőközpont joker-tanúsítványokat adott cégeknek vagy kormányoknak azért, hogy az általuk felügyelt hálózaton lebonyolított SSL-el védett forgalom könnyedén lehallgatható legyen.
          • Pl. Irán 2011. júliusától augusztusáig egy "hamis" (elismert CA által hitelesített) tanúsítvány segítségével lehallgatta állampolgárai és a Google között zajló titkosított kommunikációt. Nem zárható ki, hogy ez ellenzékiek szabadságába vagy akár életébe került.
        • Lehetséges (volt?) a nullás ASCII-kódú karaktert tartalmazó névre szóló tanúsítványt kérni és kapni. Pl: "www.otpbank.hu\000.akarmi.cn". A böngészők jelentős része a nullás karaktert a sztring végeként értelmezte.
        • Előfordult, hogy úgy hitelesítették a tanúsítványt kérőt, hogy megnézték, képes-e levelet fogadni pl. a root@ címen a választott domainben; ha igen, elhitték, hogy ez az ő domainje, és kapott tanúsítványt. Csakhogy számos web-alapú email-szolgáltatónál a "root" usernevet nem kezelik speciálisan; a felhasználók nyugodtan regisztrálhatják.
      • A rendszer célja eredetileg az volt, hogy a felhasználók hitelkártya-adatait megvédje a bűnözőktől. Ma arra is használják, hogy a felhasználók magánszféráját megvédjék az abba behatolni próbáló állami szervektől, és erre nem biztos, hogy alkalmas.

Jelenleg az ún. X.509-es típusú tanúsítványok a legelterjedtebbek (az SSL ilyeneket használ). Ezek a következő adatokat tartalmazzák:

  • sorozatszám (a CA rendeli hozzá);
  • érvényességi idő;
  • a kiállító CA neve;
  • a tanúsítvány tulajdonosának neve;
  • a tulajdonos nyilvános kulcsa;
  • "basic constraints": használható-e a tanúsítvány más tanúsítványok hitelesítésére, ill. a maximális úthossz a hitelesítési láncban a gyökér és a levelek között;
  • opcionális egyéb mezők;
  • a CA titkos kulcsával készített, a fentiek kivonatára (hash-ére) vonatkozó aláírás.
    • Kb. 2009-ig számos CA MD5 hasht használt erre a célra. Így lehetségessé vált az alábbi támadás:
  1. Keressünk egy olyan CA-t, amely MD5-öt használ kivonatképzésre.
  2. Vizsgáljuk meg az általa kiadott tanúsítványok sorozatszámait. Véletlenszerűek? Ha igen, nehezebb dolgunk lesz, úgyhogy keressünk másik CA-t.
  3. Ha a sorozatszámok megjósolhatók (pl. egyesével növekednek), akkor állítsunk elő két tanúsítványt:
    • Az egyik legyen egy közönségesnek látszó website-tanúsítvány, amelynek a nyilvános kulcsa azonban a CA számára észlelhetetlen értelemben speciális (úgy választjuk meg, hogy a második tanúsítványunknak ugyanaz legyen az MD5 hash-e, mint ennek). Mivel sejtjük, milyen sorozatszámot fog kapni a tanúsítvány a CA-tól, az egész aláírandó adathalmazt ismerjük, vagyis tudjuk, milyen MD5 hash-hez fog aláírást készíteni a CA.
    • A másik tanúsítványunk egy CA-tanúsítvány, amelynek az aláírandó része ugyanazzal az MD5 hash-sel rendelkezik, mint az első tanúsítványé.
  4. Írassuk alá az első tanúsítványt a CA-val.
  5. Az aláírást másoljuk át a másik tanúsítványra (amelyre az MD5 hash azonos volta miatt szintén érvényes lesz).
    • Így a CA -- anélkül, hogy tudta volna -- kibocsátott egy olyan tanúsítványt, amely alkalmas további tanúsítványok hitelesítésére.
  6. Az új CA-tanúsítványunkkal felvértezve tetszőleges névre szóló, érvényesnek látszó tanúsítványokat állíthatunk ki.
    • A sikeres támadáshoz a CA által generált tanúsítvány/aláírás érvényességi idejét is másodpercre pontosan meg kell jósolni. A valóságban ez könnyűnek bizonyult.
    • Az ütköző hash-ű tanúsítványok előállítása kb. 3 napba telt 2009-ben (200 darab PS3-as játékkonzolon), tehát 3 napra előre meg kellett tudni jósolni, milyen sorozatszámú tanúsítványokat fog kiadni a CA. Az idézett cikk szerzőinek megoldása:
      1. Néhány mintavétel (tanúsítvány-vásárlás) segítségével megállapították, hogy csütörtök estétől vasárnap estig kb. 800-1000 tanúsítványt állított ki a CA.
      2. Csütörtök este vásároltak egy tanúsítványt, hogy megtudják, éppen hol tart a számláló.
      3. Ehhez hozzáadtak 1000-et, arra számítva, hogy vasárnap este (amikorra elkészülnek a két, az érdemi támadásban felhasznált tanúsítványok) a számláló ezt az értéket még nem éri el.
      4. Az első támadó-tanúsítvány megvásárlásának ideje kötött (mivel előre meg kellett tippelni az érvényességi időt, a CA által beállított idő pedig a vásárlás időpontjától függött). Vasárnap este elkezdtek tanúsítványokat vásárolni, hogy a kiszemelt utolsó vásárlás előtti 30. másodpercben legyen a számláló értéke eggyel kisebb, mint a kívánt érték.
      5. A megfelelő pillanatban megrendelték a speciális tanúsítványt, abban a reményben, hogy az utolsó fél percben már senki nem vásárolt újabb tanúsítványt.
        • Ez a negyedik hétvégén sikerült; addigra 657 dollárt (kb. 130.000 Ft-ot) költöttek el tanúsítványokra.

3.1 Kitérő: Mennyire elterjedt a https?

  • 2010-ben kb. 16 millió nyilvános IP-cím nyújtott szolgáltatást a 443-as porton.
  • Ebből kb. 11,5 millió 443-as portján volt SSL-es szolgáltatás.
  • Kb. 4,3 milliónak volt érvényes tanúsítványa.
  • Kb. másfélmillió egyedi érvényes tanúsítvány volt.
  • Kb. 1500(!), az Internet Explorer vagy a Firefox által elismert CA van.
    • Ezeket kb. 650 szervezet üzemelteti, a Föld 52 országában.
      • Kb. 200 közülük német felsőoktatási intézmény. A Deutsche Telekom root CA az NIIF Intézet hely megfelelőjének, a Deutsches ForschungsNetz Vereinnek adott CA-tanúsítványt, az pedig hitelesítette az egyetemek CA-inak tanúsítványait. Így most pl. egy német főiskola CA-ja elvileg simán hitelesíthetné az otpbank.hu tanúsítványát.
        • Van erről egy Mozilla hibajegy; abban azzal nyugtatják meg a kedélyeket, hogy a DFN-Verein maga üzemelteti az összes általa hitelesített CA-t, tehát az adott CA-k titkos kulcsai nincsenek az érintett egyetemeknél, a DFN pedig ellenőrzi, hogy az egyetemek által kért tanúsítványok az adott egyetemhez tartozó domainek valamelyikével kapcsolatosak-e.
      • A Deutsche Telekom és minden gyermeke együtt is csak kb. 4000 https-tanúsítványt hitelesített; egy-egy CA-ra csak kb. 16 tanúsítvány jut. Felmerül a kérdés, érdemes-e ezért fenntartani ennyi elvileg globális hatókörű CA-t?
        • (Elvileg elképzelhető, hogy a 4000 https-tanúsítvány mellett még van sokezer személyre szóló tanúsítvány is, vagy hogy sokkal több https-tanúsítvány van, csak azok nem látszanak San Franciscóból, ahol a felmérés készült.)
    • Jó részük "intermediate CA": a tanúsítványa nincs benne a böngészőben, de olyan CA írta alá, amelyik benne van. Tehát nem is egyszerű képet kapni arról, milyen tanúsítványokat is fogad el a böngészőnk.
    • Az újabb Windows- és IE-verziók már nem (kizárólag) bedrótozott listákkal dolgoznak; ha új CA-val találkoznak, a Microsoft szerverétől kérdezik meg, meg kell-e bízni benne.

3.2 További gondok az X.509-es tanúsítványokkal és az SSL-lel

  • ITU-T szabvány a '80-as évekből (a web előttről, tehát nem igazodik a web sajátosságaihoz).
  • Nincs pontosan meghatározva, milyen mezőknek kell benne lenni egy tanúsítványban, ezekben milyen adatnak kell szerepelnie és azt hogyan kell értelmezni.
    • Emiatt nagyon nehéz olyan szoftvert írni, amely helyesen dolgoz fel X.509-es tanúsítványokat.
    • Vannak önellentmondó tanúsítványok (egyszerre mondja, hogy nem CA-tanúsítvány és hogy használható más tanúsítványok hitelesítésére).
  • Rengeteg CA van.
  • A CA-k mindegyikének globális a hatóköre (nincs a DNS-ben látott autoritativitáshoz hasonló dolog, ami mondjuk egy kínai CA-t megakadályozna abban, hogy magyar domainre vonatkozó tanúsítványt bocsásson ki).
    • Emiatt az SSL egésze, globálisan ki van téve mindenféle nemzeti törvényhozások szeszélyeinek.
  • 2010-ben még mindig kb. 30.000 webszerver használt triviálisan kitalálható kulcsú tanúsítványt (Debian SSL bug); ezek közül 500-nak érvényes, globális CA által készített aláírása is volt.
    • Pl.: yandex.ru, diplomatie.be.
  • Nincs jó módszer arra, hogy egy CA-nak szóljunk, hogy valamelyik tanúsítványt vissza kellene vonnia.
    • A visszavonásról szóló információ terjesztése szintén problémás, és a böngészők alapértelmezés szerint gyakran nem foglalkoznak vele.
  • Az "Extended Validation" tanúsítványok (amikor zöld az URL-mező a böngészőben) elvileg sokkal szigorúbb feltételeknek kellene, hogy eleget tegyenek: nagyobb kulcshossz, gondosabb hitelesítési folyamat stb. Csakhogy: a CA-k ezt nem tartják be.
    • Létezik pl. localhost névre szóló EV tanúsítvány;
    • vagy olyan, 1024 bites RSA kulcsot használó tanúsítvány, amely 2010 december 31-e után jár le, pedig elvileg ezeknek már 2048 bites kulcsot kellett volna tartalmazniuk.
      • Sőt, még egy 512 biteset is találtak, ami csak 2012-ben fog lejárni.
    • Elvileg szintén tilos lenne joker-tanúsítványt (*.domain.tld-re szólót) kiállítani EV folyamattal, mégis léteznek ilyenek.
    • Szintén létezik 192.168.x.y-os IP-re szóló EV-tanúsítvány.

3.3 Alternatívák, részleges segítség

  • Perspectives ill. "Convergence" -- figyelmeztet, ha egy site tanúsítványa nem az, amit más felhasználók láttak ugyanott.
    • Ezzel lényegében elkerültük a CA-kat, és P2P alapokra helyeztük a hitelesítést.
  • Certificate Patrol -- figyelmeztet, ha egy site tanúsítványa megváltozott a legutóbbi látogatásunk óta (akkor is, ha az új tanúsítvány is hitelesnek látszik).
  • A Google Chrome-ba bedrótozhatók site-ok ismert tanúsítványai, így a böngésző ezeken a site-okon akkor sem fogad el más tanúsítványt, ha az amúgy hitelesnek tűnik. Kétélű fegyver.

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 felhasnzá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 NTLMv2.

4.1 Ajánlott irodalom

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?
    • 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ózon 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ó.

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:
    1. "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.
    2. Célcím (6 byte);
    3. Forráscím (6 byte);
    4. Hálózati rétegbeli protokoll azonosítója (2 byte; pl. IP, IPX, Decnet stb.);
    5. Adatok (max. 1500 byte);
    6. Ellenőrző összeg (CRC, 4 byte).

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.
      • 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).

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?

  1. Redundancia (ha valamelyik link, esetleg valamelyik switch kiesik, ne essen szét a hálózat).
  2. 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.
  • 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.

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.
  • 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: 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.

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.
  • 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.
Személyes eszközök