Hálózatbiztonság

A Unix/Linux szerverek üzemeltetése wikiből
(Változatok közti eltérés)
a (tematika-aktualizálás)
a (a felderítés csak olvasmány)
8. sor: 8. sor:
 
** Szállítási réteg: [[IP-alapok#TCP_(Transmission_Control_Protocol)|TCP]], [[IP-alapok#UDP_(User/Unreliable_Datagram_Protocol)|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: [[A DNS működése|DNS]], [[Az SMTP működése|SMTP]], [[FTP]], SSL
 
** Alkalmazási réteg: [[A DNS működése|DNS]], [[Az SMTP működése|SMTP]], [[FTP]], SSL
** [[Felderítés]], [[Portscan]]
+
** [[Felderítés]] (olvasmány), [[Portscan]]
 
** [[Tűzfalak]]
 
** [[Tűzfalak]]
 
** [[NetFlow]]
 
** [[NetFlow]]

A lap 2012. április 4., 15:58-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

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

2.7 Tanúsítványok

A tanúsítvány lényegében nem más, mint egy nyilvános kulcs, 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).

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.
      • 2012-ben százas nagyságrendű ilyen hitelesítőközpont van.
      • Ezek megbízhatósága... "ellentmondásos megítélésű". Egymást érik a botrányok.
        • Az egyik 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").
        • 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 ({ábra}).


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

3.1 Ajánlott irodalom

4 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ó.

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

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

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

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

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