IP-alapok
Pala (vitalap | szerkesztései) (→A protokollcsaládról) |
a (→ARP (Address Resolution Protocol)) |
||
(4 szerkesztő 38 közbeeső változata nincs mutatva) | |||
1. sor: | 1. sor: | ||
− | Itt most az IPv4-ről lesz szó. Az IPv6-tal nem foglalkozunk. |
+ | Itt most az IPv4-ről lesz szó. Az IPv6-tal nem foglalkozunk (talán megérdemelne egy külön tantárgyat). |
== A protokollcsaládról == |
== A protokollcsaládról == |
||
− | * Az IP egy protokollcsalád |
+ | * Az Internet Protocolra gondolhatunk úgy, mintha az OSI modell hálózati rétegében helyezkedne el, noha az IP és az ISO/OSI referenciamodell között nem feltétlenül egyszerű bijekciót létesíteni. Csomagkapcsolt hálózatot valósít meg, ami annyit jelent, hogy nem épít fel semmilyen kapcsolatot a forrás és a cél között, hanem minden egyes csomagot külön juttat célba (route-ol). Megoszlanak a vélemények arról is, hogy a TCP/IP protokollcsaládnak egészen pontosan melyik protokollok is a részei és melyek nem, de ilyen finomságokkal és filozófiai mélységekkel itt nem foglalkozunk. |
− | : Az Internet Protocol az OSI modell hálózati rétegében helyezkedik el. Csomagkapcsolt hálózatot valósít meg, ami annyit jelent, hogy nem épít fel semmilyen kapcsolatot a forrás és a cél között, hanem minden egyes csomagot külön juttat célba (route-ol). |
+ | * Az IP-vel kapcsolatos főbb protokollok: |
− | ** ARP (később) |
+ | ** ARP (Address Resolution Protocol) |
** IP (Internet Protocol) |
** IP (Internet Protocol) |
||
− | *** hálózati rétegbeli |
||
− | *** datagramm-alapú |
||
− | *** fejléc: |
||
− | **** forráscím |
||
− | **** célcím |
||
− | **** TTL (Time To Live) |
||
− | **** magasabb szintű protokoll azonosítója |
||
− | **** egyéb (pl: DF, Don't Fragment, PMTU discoveryhez) |
||
** ICMP (Internet Control Message Protocol) |
** ICMP (Internet Control Message Protocol) |
||
− | *** hiba- és státuszüzenetek, pl: |
||
− | **** Echo Request |
||
− | **** Echo Reply |
||
− | **** Destination Unreachable |
||
− | ***** Network Unreachable |
||
− | ***** Host Unreachable |
||
− | ***** Protocol Unreachable |
||
− | ***** Port Unreachable |
||
− | ***** Fragmentation Needed |
||
− | ***** Communication Administratively Prohibited |
||
− | **** Time To Live Exceeded |
||
− | **** és még jó pár, ritkábban látott másik |
||
** TCP (Transmission Control Protocol) |
** TCP (Transmission Control Protocol) |
||
− | *** összeköttetés-alapú |
||
− | *** garantálja a csomagok helyes sorrendjét |
||
− | *** újraküldi a csomagokat, ha kell |
||
− | *** torlódásvezérelt |
||
− | *** kapcsolatfelépítés: |
||
− | **** SYN |
||
− | **** SYN+ACK |
||
− | **** ACK |
||
− | *** port fogalma ("lokális multiplexelés") |
||
** UDP (User/Unreliable Datagram Protocol) |
** UDP (User/Unreliable Datagram Protocol) |
||
− | *** itt is van port |
+ | |
− | *** nincs nyugta |
+ | === IP (Internet Protocol) === |
− | *** nincs torlódásvezérlés |
+ | |
− | *** a folyam csomagjai elveszhetnek, ill. megjöhetnek rossz sorrendben |
+ | * hálózati rétegbeli |
+ | * datagramm-alapú |
||
+ | * néhány mező a fejlécből: |
||
+ | ** forráscím |
||
+ | ** célcím |
||
+ | ** TTL (Time To Live) |
||
+ | ** magasabb szintű protokoll azonosítója |
||
+ | ** egyéb (pl: DF, Don't Fragment, PMTU discoveryhez) |
||
+ | * klasszikus támadások: |
||
+ | ** flood (bármilyen protokollal lehet, nem IP-specifikum), |
||
+ | ** spoofing (címhamisítás), |
||
+ | ** teardrop (egymást átfedő fragmentumok), |
||
+ | ** [http://en.wikipedia.org/wiki/Ping_of_death ping of death] (64k-nál nagyobbnak tűnő csomag, nem csak ICMP lehet). |
||
+ | |||
+ | === ICMP (Internet Control Message Protocol) === |
||
+ | |||
+ | * hiba- és státuszüzenetek, pl: |
||
+ | ** Echo Request (''ping'') |
||
+ | ** Echo Reply (''ping'' válasz) |
||
+ | ** Destination Unreachable; altípusai pl: |
||
+ | *** Network Unreachable (nincs route az adott hálózat felé) |
||
+ | *** Host Unreachable (az adott gép nem elérhető, pl. nem válaszol ARP-re) |
||
+ | *** Protocol Unreachable (Az IP 1 bájton kódolja, milyen magasabb szintű protokollt szállít. Ilyen ICMP hibaüzenetet kapunk, ha a megszólított gép az adott magasabb szintű protokollt nem támogatja.) |
||
+ | *** Port Unreachable (Az adott UDP porton nincs szolgáltatás.) |
||
+ | *** Fragmentation Needed (l. lejjebb a PMTU discoverynél.) |
||
+ | *** Communication Administratively Prohibited |
||
+ | ** Time To Live Exceeded |
||
+ | ** és még jó pár, ritkábban látott másik |
||
+ | * klasszikus támadások pl.: |
||
+ | ** flood, |
||
+ | ** smurf, |
||
+ | ** ... |
||
+ | |||
+ | === TCP (Transmission Control Protocol) === |
||
+ | |||
+ | * összeköttetés-alapú |
||
+ | * garantálja a csomagok helyes sorrendjét |
||
+ | * újraküldi a csomagokat, ha kell |
||
+ | * torlódásvezérelt |
||
+ | * port fogalma ("lokális multiplexelés") |
||
+ | ** "nyitott" vs. "zárt" port |
||
+ | ** bind(), majd listen() |
||
+ | * kapcsolatfelépítés (l. lejjebb is): |
||
+ | ** SYN |
||
+ | ** SYN+ACK |
||
+ | ** ACK |
||
+ | * klasszikus támadások: |
||
+ | ** SYN flooding (l. lejjebb), |
||
+ | ** connection spoofing, |
||
+ | ** session hijacking, |
||
+ | ** "LAND" (azonos forrás- és célcím), |
||
+ | ** ... |
||
+ | |||
+ | === UDP (User/Unreliable Datagram Protocol) === |
||
+ | |||
+ | * itt is van port |
||
+ | * nincs nyugta |
||
+ | * nincs torlódásvezérlés |
||
+ | * a folyam csomagjai elveszhetnek, ill. megjöhetnek rossz sorrendben |
||
+ | * cserébe "könnyűsúlyú" protokoll |
||
+ | ** nem kell hozzá állapotgép, nincs kapcsolatfelépítés => gyorsabb adatküldés |
||
+ | ** kisebb fejléc |
||
+ | * Használja: |
||
+ | ** DNS |
||
+ | ** VoIP |
||
+ | ** streaming |
||
+ | ** VPN-ek |
||
+ | ** játékok |
||
+ | ** p2p (peer to peer) |
||
** stb. |
** stb. |
||
+ | * klasszikus támadások: |
||
+ | ** fraggle (kb. mint a smurf, udp echo ellen), |
||
+ | ** ... |
||
− | === ARP === |
+ | === ARP (Address Resolution Protocol) === |
− | * Az IP hálózati rétegbeli protokoll |
+ | |
− | * A hálózati szint alatt még van egy adatkapcsolati és egy fizikai réteg |
+ | * Az IP egy hálózati rétegbeli protokoll. |
− | * Az adatkapcsolatiban is kellhet címzés |
+ | * A hálózati szint alatt még van egy adatkapcsolati és egy fizikai réteg. |
+ | * Az adatkapcsolatiban is kellhet címzés. |
||
* Honnan tudjuk a másik fél adatkapcsolati címét? |
* Honnan tudjuk a másik fél adatkapcsolati címét? |
||
− | * Az IP alatt gyakran van Ethernet, vagy ahhoz hasonló broadcast médium |
+ | * Az IP alatt gyakran van Ethernet, vagy ahhoz hasonló broadcast médium. |
* Ötlet: ha nem tudjuk a címet, kérdezzük meg! |
* Ötlet: ha nem tudjuk a címet, kérdezzük meg! |
||
<pre> |
<pre> |
||
56. sor: | 30. sor: | ||
00:f0:0d:d0:0d:00 > 00:de:ad:be:ef:00, ethertype ARP (0x0806), length 60: arp reply 1.2.3.4 is-at 00:f0:0d:d0:0d:00 |
00:f0:0d:d0:0d:00 > 00:de:ad:be:ef:00, ethertype ARP (0x0806), length 60: arp reply 1.2.3.4 is-at 00:f0:0d:d0:0d:00 |
||
</pre> |
</pre> |
||
− | * Egy darabig megjegyezzük az ARP-táblánkban |
+ | * Egy darabig (nagyságrend: percek) megjegyezzük az ARP-táblánkban. |
* Igen ám, de nem vagyunk mindenkivel egy fizikai hálózaton - a többiek MAC-címét honnan fogjuk megtudni? |
* Igen ám, de nem vagyunk mindenkivel egy fizikai hálózaton - a többiek MAC-címét honnan fogjuk megtudni? |
||
− | * Sehonnan, mert nem is kell. |
+ | * Sehonnan, mert nem is kell => routing. |
− | * => routing |
+ | * ARP-alapú visszaélések: |
+ | ** ARP spoofing (hamis választ küldünk) |
||
+ | *** Ezen keresztül lehallgatás, man-in-the-middle, DoS |
||
+ | ** ARP flooding (pl. a Solaris egyes régi verziói lefagynak tőle) |
||
+ | * ProxyARP pseudobridge: |
||
+ | ** A végpontok higgyék azt, hogy ''egy'' fizikai hálózaton vannak |
||
+ | ** A köztük levő routerek válaszolnak mindenki helyett az ARP-re |
||
+ | |||
+ | ProxyARP bekapcsolása linuxon: |
||
+ | |||
+ | <pre> |
||
+ | # echo 1 >/proc/sys/net/ipv4/conf/interfaceneve/proxy_arp |
||
+ | </pre> |
||
+ | |||
+ | === Path MTU Discovery === |
||
+ | |||
+ | * Az IP-csomagok maximális mérete 65535 bájt (1 bájt híján 64K) lehet. |
||
+ | * Ez egy elméleti maximális csomagméret, amit az alkalmazott fizikai hálózat jellemzőiből adódó korlátok jelentősen csökkenthetnek; pl. az Ethernetet alkalmazva maximálisan 1500 bájtnyi hasznos terhet szállító IP-csomagokat tudunk átjuttatni a hálózaton, mert egy Ethernet-keretbe nem fér több adat. (Kivéve, ha jumbo frame-eket használunk, de itt most nem ez a lényeg.) |
||
+ | |||
+ | * Mivel a különböző helyeken sokféle technológiákat alkalmazhatnak, ezért a nagy csomagokat fel kell darabolni, hogy egy adott hálózati útvonal minden szakaszán átférjenek. |
||
+ | * Azt a jellemzőt, hogy egy adott fizikai interfészen legfeljebb mekkora IP-csomag küldhető ki, MTU-nak (Maximum Transmission Unit) nevezzük. |
||
+ | * Az ennél nagyobb csomagokat a routerek automatikusan fragmentálják, ami több szempontból sem jó: |
||
+ | ** Ha egy töredék elvész, az egész csomagot újra kell küldeni. |
||
+ | ** Nagyobb az overhead (mind a hálózati, mind a processing-). |
||
+ | ** A butább tűzfalak minden töredezett IP-csomagot kiszűrnek, mert |
||
+ | *** korábban érvénytelen csomagtöredékekkel DoS-t lehetett megvalósítani és |
||
+ | *** mert csak az első töredék tartalmazza a magasabb szintű protokoll fejlécét, ami alapján a tűzfal szűrni tud. |
||
+ | ** Talán érdemes itt megemlíteni, hogy az IPv6-ban már a végpontok feladata a fragmentálás, a routerek semmiképpen nem foglalkoznak vele. |
||
+ | |||
+ | Annek a kiderítésére, hogy egy teljes útvonalon mi a legkisebb MTU, használható a [http://alive.znep.com/~marcs/mtu/ Path MTU Discovery] algoritmus. |
||
+ | Az algoritmus úgy működik, hogy a célállomásnak először akkora csomagot próbál küldeni, amekkora a saját MTU-ja azon az interfészen, amelyen az adott cél felé a routing-táblája alapján a csomagokat ki kell küldenie; ezeken a csomagokon beállítja a DF (Don't Fragment) bitet. |
||
+ | Ha útközben valamelyik routeren ez a csomag "nem fér át", akkor a router [http://en.wikipedia.org/wiki/Internet_Control_Message_Protocol ICMP] Fragmentation Needed hibaüzenetet küld a forrásnak, és a csomagot eldobja. |
||
+ | Az okosabb routerek azt is megmondják, mekkora lenne az MTU a következő routerig, így a forrás megtudja, mekkora csomaggal próbálkozzon legközelebb. |
||
+ | Ha az adott router nem okos, akkor a forrás pl. bináris kereséssel találhatja meg a PMTU-t. |
||
+ | |||
+ | === Részletesebben a TCP-ről === |
||
+ | |||
+ | Kicsit foglalkozzunk a [http://en.wikipedia.org/wiki/Transmission_Control_Protocol TCP] néhány olyan jellemzőjével, amire nem biztos, hogy mindenki emlékszik korábbi tanulmányaiból. |
||
+ | |||
+ | ==== Nyugtázás ==== |
||
+ | |||
+ | Egy adatcsomag egyben nyugta is lehet; ha be van billentve a fejlécében az ACK bit, akkor amellett, hogy esetleg szállít adatot is, nyugtázza a korábban megkapott adatokat is. |
||
+ | * Hogy melyikeket, az a nyugtaszámból derül ki. |
||
+ | * Minden elküldött bájtnak van egy sorszáma, amit a kapcsolat során nem nullától, hanem egy ISN-től (Initial Sequence Number) kezdenek számolni. |
||
+ | * A nyugták ezeket a szekvenciaszámokat nyugtázzák. |
||
+ | * Ha tehát az én oldalamon 42 volt az ISN, és kapok egy 100-as sorszámú nyugtát, akkor az azt jelenti, hogy a 42-99-es sorszámú bájtokat a túloldal sikeresen átvette, és most nekem a 100-as sorszámú bájttal kell majd folytatnom az adást. |
||
+ | |||
+ | ==== Kapcsolatfelépítés ==== |
||
+ | |||
+ | A TCP-kapcsolat felépítése úgy történik, hogy a kliens kitalál egy ISN-t, és egy ezt tartalmazó TCP SYN üzenetet küld a szervernek (olyan TCP-csomagot, amelyben a SYN bit be van állítva). |
||
+ | A SYN csomag tehát az alábbi információkat tartalmazza biztosan: |
||
+ | * forrás IP-címe (az IP-fejlécből); |
||
+ | * cél IP-címe (szintén); |
||
+ | * forrásport (a TCP-fejlécből); |
||
+ | * célport (szintén); |
||
+ | * kliensoldali ISN. |
||
+ | |||
+ | A szerver erre egy olyan csomaggal válaszol, amelyben a SYN és az ACK bitek vannak beállítva (ezért szokás ezt a csomagot SYNACK vagy SYN+ACK csomagnak hívni); ez a csomag tehát nyugtacsomag, az ACK-kal nyugtázzuk a kliensoldali ISN-t, a SYN mellé pedig mellékeljük azt az ISN-t, amit mi találtunk ki ehhez a kapcsolathoz. |
||
+ | |||
+ | A kapcsolat felépítését a kliens egy olyan ACK csomaggal zárja le, amelyben a szerver ISN-jét nyugtázza. |
||
+ | |||
+ | * Az ISN-t azért nem nullától célszerű számolni, mert ha kiszámítható ISN-eket választunk, akkor azzal egy támadónak lehetősége nyílik az ún. ''blind connection spoofing'' támadásra. Lényege: |
||
+ | ** ''A'' gép megbízik ''B'' gépben (tehát pl. ''B''-ről szabad kapcsolódni ''A''-ra). |
||
+ | ** A támadó elérhetetlenné teszi ''B'' gépet. |
||
+ | ** A támadó ''B'' forráscímével SYN csomagot küld ''A''-nak. |
||
+ | ** ''A'' ''B''-nek válaszol, így a válaszcsomagot a támadó nem kapja meg, de mivel ismeri az ISN-t, úgy tehet, mintha megkapta volna a SYNACKot, és küldhet azt nyugtázó ACK-ot (még mindig ''B'' nevében). |
||
+ | ** Így ''A'' azt hiszi, ''B'' kapcsolódott hozzá, a támadó pedig ''B'' nevében tetszőleges adatokat/parancsokat küldhet ''A''-nak; az egyetlen nehézség az, hogy nem látja a választ (ha erről más módon nem gondoskodik). |
||
+ | * Védekezés: |
||
+ | ** Nehezen kitalálható ISN-nel; |
||
+ | ** reverse path filteringgel (l. később). |
||
+ | * Hasonló támadás a blind connection reset: |
||
+ | ** ha a támadó tudja, hol tart a nyugtaszámláló egy kapcsolatban, küldhet olyan csomagot, ami lezárja a kapcsolatot valamelyik fél nevében (vagy akár mindkét fél nevében, kölcsönösen). |
||
+ | * Általában is: ha egy támadó tudja, mi egy TCP-kapcsolatban a következő szekvenciaszám, és tudja hamisítani a forráscímét, akkor a hamis forráscím nevében csomagokat tud beszúrni a kapcsolatba; pl. egy telnet-kapcsolatba az "rm -rf /\n" tartalmú adatcsomagot. |
||
+ | ** Ezért is jó az SSH, nemcsak a lehallgatásbiztossága miatt. |
||
+ | |||
+ | ===== [http://en.wikipedia.org/wiki/SYN_attack SYN-támadás] ===== |
||
+ | |||
+ | A szervernek normális esetben a SYNACK csomag kiküldésével egyidőben memóriát kell allokálnia, amiben megjegyzi a kapcsolat paramétereit: a kliens címét, portszámokat, ISN-eket stb. |
||
+ | Ha a kliens nem fejezi be a kapcsolat felépítését, akkor a szerver néhányszor újra elküldi a SYNACK csomagot (hátha az első elveszett), aztán időtúllépés miatt eldobja a kapcsolatot; addig viszont valamennyi memóriát lefoglalva tart. |
||
+ | Ha egy támadó sok kapcsolatot kezd el, de egyiket se fejezi be, akkor az erre a célra fenntartott memóriaterület (a tcp backlog queue) megtelhet, és a szerver a legitim kapcsolatokkal sem tud foglalkozni; l. [http://en.wikipedia.org/wiki/SYN_attack a Wikipédián is]. |
||
+ | |||
+ | Ez ellen a támadás ellen védekezhetünk pl. a [http://en.wikipedia.org/wiki/Syncookies Syncookie] algoritmus használatával. |
||
+ | Az algoritmus lényege az, hogy minden megjegyzendő adatot vagy belekódolunk a szerveroldali ISN-be (amit majd visszakapunk a kliens ACK üzenetben), vagy figyelmen kívül hagyunk (mert nem kritikus a kapcsolat létrejötte szempontjából). |
||
− | === Az első óra rövid összefoglalása === |
+ | Arra vigyázni kell, hogy ne lehessen könnyen olyan szekvenciaszámot kitalálni, amely alapján a szerver felépít egy érvényes kapcsolatot, mert akkor egy támadó SYN-csomag küldése nélkül tudna kapcsolatot felépíteni a szerverrel, ami ''Rossz, értem?''. |
− | Az TCP/IP csomagok maximális mérete 65535 bájt(64K) lehet, ez az elméleti maximális csomagméret, amit az alkalmazott technológia jelentősen lecsökkenthet. Például az Ethernet-et alkalmazva maximálisan 1500 bájtos csomagokat tudunk átjuttatni a hálózaton. |
+ | (Főleg régebbi tűzfalak a SYN-csomag alapján azonosítják az új kapcsolatokat; ha SYN nélkül is lehetne kapcsolatot nyitni, akkor ezzel meg lehetne kerülni a tűzfalat.) |
− | Mivel a különböző helyeken sokféle technológiákat alkalmazhatnak, ezért a nagy csomagokat fel kell darabolni, hogy a bizonyos hálózatokon átférjenek. Ezt a jellemzőt MTU-nak (Maximum Transmission Unit) nevezzük. Ennek az értéknek a kiderítésére használható a Path MTU Discovery Algoritmus, ami megfelelően nagy csomagokkal próbálkozik, amíg az a hálózaton át nem fér. Ha olyan csomagot próbálunk továbbítani, amely nem fér át a célhálózaton akkor egy ICMP-n [http://en.wikipedia.org/wiki/Internet_Control_Message_Protocol] (Internet Control Message Protocol) |
||
− | keresztül kapunk egy Fragmentation Indeed kérést, melyben benne van a maximális csomagméret is. |
||
− | Az Echo Request és az Echo Reply szintén az ICMP protokollt használja. |
||
− | A TCP/IP 1 bájton kódolja a felette futó protokollokat. Ha nincs az elküldött kódú protokoll regisztrálva a rendszeren akkor egy Protocol Unreachable hibaüzenetet kapunk. |
||
− | Egy adatcsomag egyben nyugta is lehet, minden elküldött bájtnak van egy szekvencia száma (ISN, Initial Sequence Number). A SYN támadások azon alapulnak, hogy ha csak töredezett csomagokat kapunk, akkor ezeknek bizonyos adatait (ISN-ek ISNc, ISNs, forrás-cél IP-k, Portszám) el kell tárolnunk ahhoz, hogy a csomagot később össze tudjuk rakni, és mivel soha nem tudjuk összerakni egy idő múlva elfogy a memóriánk. Ez ellen a SYN cookies használatával védekezhetünk, ami úgy működik, hogy az ISNs-be belekódoljuk az eltárolni kívánt adatokat, és ezeket a nyugtával visszakapjuk ezért nem kell őket eltárolni. |
||
− | Connection Proofing Attack, csak egy Ack(ISNs)-t küldünk és ebből már felépülhet a kapcsolat |
+ | A Syncookie algoritmus hátrányai: |
− | Az UDP egy összeköttetés mentes protokoll, álltalában különböző streaming, illetve a DNS használja. Az UDP is ugyanúgy rendelkezik portokkal. |
||
− | Az ARP(Address Resolution Protocol) Ahhoz, hogy a hálózaton kommunikálni tudjuk, ismernünk kell a cél MAC címét is, ezt tudjuk megszerezni az ARP segítségével. |
+ | * Korlátozza a kapcsolatok paramétereit (bővebben l. a [http://en.wikipedia.org/wiki/Syncookies Wikipédián]); |
− | A routing tábla karban tartását a route vagy az ip parancsok segítségével tudjuk megtenni. |
+ | * ha a háromutas kézfogás utolsó csomagja (az ACK) nem ér célba, a szerver sosem küldi újra a SYNACK-ot (hiszen nem jegyezte meg, hogy van egy félig nyitott kapcsolata), így a kliens nem tudja meg, hogy az ACK csomagja elveszett. Ha az alkalmazásszintű protokoll olyan, hogy az első üzenetet a szervernek kellene küldenie (ilyen pl. az [[Az SMTP működése|SMTP]]), akkor a kliens csak állni fog és várni (abban a boldog, ám téves hitben, hogy érvényes TCP-kapcsolata van a szerverrel), a szerver pedig minderről nem sejt semmit. Persze egy ésszerű idő után az alkalmazás ''valószínűleg'' nem vár tovább, de nem árt ezzel a hibalehetőséggel tisztában lennünk, ha TCP-alapú hálózati protokollt, vagy azt megvalósító alkalmazást készítünk. |
+ | * Bejövő SYNfloodra kimenő SYNACK-flooddal válaszolunk; |
||
+ | ** ez pl. ADSL-nél nyilván nagyon nem jó... |
||
+ | * lepattintható rólunk egy SYN-áradat, ha hamis forráscímmel küldik. |
||
== Statikus routing == |
== Statikus routing == |
||
95. sor: | 69. sor: | ||
| 1.2.3.42 |
| 1.2.3.42 |
||
| eth0 |
| eth0 |
||
− | | a 3.4.5.128/25-ös hálózat a 3.4.5.128 című routeren át érhető el, "amögött" van |
+ | | a 3.4.5.128/25-ös hálózat a 1.2.3.42 című routeren át érhető el, "amögött" van |
|- |
|- |
||
| 0.0.0.0 |
| 0.0.0.0 |
||
105. sor: | 79. sor: | ||
|} |
|} |
||
+ | '''Fontos szabály:''' Mindig a leghosszabb illeszkedő prefixű bejegyzés "nyer". Pl. ha van route-unk a 10.0.0.0/8 felé az eth1-en át és a 10.0.0.0/24 felé az eth0-án át, és a 10.0.0.1-et akarjuk megszólítani, az eth0-án próbálkozunk. |
||
Ha egy adott konkrét A.B.C.D IP-címmel akarunk kommunikálni, a következők szerint járunk el: |
Ha egy adott konkrét A.B.C.D IP-címmel akarunk kommunikálni, a következők szerint járunk el: |
||
− | * Megnézzük, az IP-cím része-e valamelyik helyi hálózatnak a cím/maszk párok alapján |
+ | * Megnézzük, az IP-cím része-e valamelyik helyi hálózatnak a cím/maszk párok alapján ("helyi" az a hálózat, amihez nincs gateway a routing-táblában) |
** Ha igen, ARP queryt küldünk |
** Ha igen, ARP queryt küldünk |
||
*** A válaszban benne lesz a MAC-cím |
*** A válaszban benne lesz a MAC-cím |
||
118. sor: | 93. sor: | ||
***** Vagyis: ARP who-has IP-of-gateway |
***** Vagyis: ARP who-has IP-of-gateway |
||
**** Ha nem, akkor nem tudjuk, merre kell küldeni a csomagot, "network unreachable" ("no route to host") |
**** Ha nem, akkor nem tudjuk, merre kell küldeni a csomagot, "network unreachable" ("no route to host") |
||
+ | |||
+ | === Reverse path filtering === |
||
+ | |||
+ | Egyszerű, de sok esetben hatásos védekezés a hamisított forráscímű (''spoof''olt) csomagok ellen: |
||
+ | |||
+ | * Ha bejön egy csomag ''x'' feladóval az ''i'' interface-en: |
||
+ | ** Nézzük meg, hogy a routing-tábla szerint, ha ''x''-nek akarnánk csomagot küldeni, az ''i'' interface-en küldenénk-e ki; |
||
+ | ** Ha igen, jó; |
||
+ | ** Ha nem, ''x'' "valójában" nem is "arra van", úgyhogy a csomag "biztos" hamis. |
||
+ | * Aszimmetrikus routingnál nem működik. |
||
+ | |||
+ | Bekapcsolása linuxon: |
||
+ | |||
+ | <pre> |
||
+ | # echo 1 >/proc/sys/net/ipv4/conf/interfaceneve/rp_filter |
||
+ | </pre> |
||
=== A routing-tábla karbantartása === |
=== A routing-tábla karbantartása === |
||
+ | |||
+ | Linuxon: |
||
+ | |||
* route parancs: |
* route parancs: |
||
** route add -net 1.2.3.0/24 dev eth0 |
** route add -net 1.2.3.0/24 dev eth0 |
||
148. sor: | 142. sor: | ||
* Red Hat Linuxon: |
* Red Hat Linuxon: |
||
− | ? |
+ | : /etc/sysconfig/network-scripts/route-<interface-name>-be: |
+ | :: ADDRESSn=<network> |
||
+ | :: NETMASKn=<network/prefix mask> |
||
+ | :: GATEWAYn=<next-hop router/gateway IP address> |
||
* SuSE Linuxon: |
* SuSE Linuxon: |
||
157. sor: | 151. sor: | ||
* Solarison: |
* Solarison: |
||
− | ? |
+ | : Default routerek: |
+ | :: /etc/defaultrouter-be IP cím vagy hostname |
||
+ | : Nem default routerek: |
||
+ | :: /etc/gateways-be: |
||
+ | ::: host ''destination'' gateway ''gateway'' metric ''hops'' , vagy |
||
+ | ::: net ''destination'' gateway ''gateway'' metric ''hops'' |
||
+ | : Ha mindenáron hoszt nevet akarunk megadni, akkor csak olyat, ami benne van az /etc/inet/hosts-ban! |
||
* OpenBSD-n: |
* OpenBSD-n: |
||
173. sor: | 167. sor: | ||
: Jó tudni, hogy az alapértelmezés DHCP. Azaz ha nem adunk meg semmit, de DHCP klienst futtatunk, akkor azzal próbálkozik a rendszer. |
: Jó tudni, hogy az alapértelmezés DHCP. Azaz ha nem adunk meg semmit, de DHCP klienst futtatunk, akkor azzal próbálkozik a rendszer. |
||
--[[User:TechyZoltan|TechyZoltan]] 2006. szeptember 12., 20:55 (CEST) |
--[[User:TechyZoltan|TechyZoltan]] 2006. szeptember 12., 20:55 (CEST) |
||
+ | |||
+ | == VLAN == |
||
+ | |||
+ | Írta: [[User:RostásAttila|Rostás Attila]]. |
||
+ | |||
+ | '''VLAN a Linux-on, Debian alatt''' |
||
+ | |||
+ | ''Mi is az a VLAN?'' |
||
+ | A VLAN (Virtual Local Area Network) az IEEE 802.1Q szabványban definiált. |
||
+ | VLAN segítségével a hálózatok fizikai kialakításától függetlenül definiálhatunk logikai (szoftveresen létrejövő) broadcast hálózatokat az egy ugyanazon VLAN hálózatban szereplő host-ok között. A VLAN megvalósítása az OSI modell 2. rétegében, a adatkapcsolati rétegben történik. Gyakorlatilag a hálózati csomagok kapnak még egy 4 bájtos (*) fejlécet amelyben definiálva van egy 12 bites VLAN Identifier (VID), mely 4096 külön logikai hálózatot tenne lehetővé egy ugyanazon hálózati interface-n, vagy kábelen. Ennél a gyakorlatban – implementációtól függően – valamelyest kevesebb érhető el. A 0. és a 4095. VLAN a szabvány szerint foglaltak. Az 1. VLAN pedig a mindenki számára látható forgalmat jelenti. (Átlátszó VLAN.) |
||
+ | A VLAN hálózatokban két eszköz akkor van azonos logikai közegben, ha a VID-jük megyegyezik. Különböző VID-ű hálózatok között a kommunikációt az erre kijelölt eszköz (pl. egy router, vagy switch…) végezheti el a 3. – hálózati - rétegben. Egy switch egy portja tartozhat egy vagy több VLAN-hoz. Amennyiben egyhez tartozik, lehetőség van rá, hogy a switch elrejtse a porton keresztül kapcsolódó eszköz (leginkább egy számítógép hálózati interface-e) elől, hogy ő valójában egy VLAN-ban van. Amennyiben egy porthoz több VLAN van megengedve, vagy egy VLAN, de nem cél az elrejtése, akkor a portra csatlakozó eszköznek ismernie kell, hogy ő melyik VLAN-ban van és ennek megfelelő VID-et kell a kiküldött csomagjai elé tennie illetve a kapott csomagok tag-jében találnia. Biztonsági szempontból ajánlatos lehet MAC címhez, vagy valamilyen authentikációhoz kötni a VLAN-t, ebben az esetben az adott számítógép csak a neki szánt VID-(ek)en tud kommunikálni. |
||
+ | A VLAN témakör részletes mindenre kiterjedő ismertetésére kitérni nincs lehetőség, a forrásjegyzékben szereplő irodalmakból azonban jól megismerhető. |
||
+ | |||
+ | === Linux alatt === |
||
+ | |||
+ | ''VLAN kernel támogatás:'' |
||
+ | A 802.1Q szabvány a kernel 2.4.21-es verziója óta a kernel része, 8021q a modul neve. |
||
+ | A VLAN támogatáshoz a hálózati kártya driverének is támogatnia kell az esetlegesen nagyobb, mint 1500 bájt-os MTU-t. (Tapasztalataim alapján a szabvány Debian 2.6.8 kernel e1000 és e100 moduljai tökéletesen működnek. Azért nem a 2.4-es kernel széria lett a kiválasztott, mert ott a VLAN-ok fölötti bridge építése iptables tűzfalas szűréssel nem lehetséges. ld. később ) |
||
+ | |||
+ | === VLAN utility-k és használatuk === |
||
+ | |||
+ | A VLAN hálózatok létrehozása a vconfig programmal lehetséges a következő szintaxis szerint: |
||
+ | <pre> |
||
+ | vconfig add interface_name VID |
||
+ | </pre> |
||
+ | És ekkor létrejön az interface_name.VID interface, amely már a VID hálózatban képes kommunikálni. |
||
+ | |||
+ | Pl. az eth0 interface feletti 150-es VLAN létrehozása a következőféleképpen lehetséges: |
||
+ | |||
+ | <pre> |
||
+ | vconfig add eth0 150 |
||
+ | </pre> |
||
+ | |||
+ | Ekkor a következő interface jelenik meg: |
||
+ | |||
+ | <pre> |
||
+ | eth0.150 Link encap:Ethernet HWaddr 00:02:A5:CE:61:CC |
||
+ | inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0 |
||
+ | inet6 addr: fe30::212:a3ff:fdce:61cd/64 Scope:LinkUP |
||
+ | BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 |
||
+ | RX packets:406783997 errors:0 dropped:0 overruns:0 frame:0 |
||
+ | TX packets:444927484 errors:0 dropped:0 overruns:0 carrier:0 |
||
+ | collisions:0 txqueuelen:0 |
||
+ | RX bytes:2283210879 (2.1 GiB) TX bytes:2212731126 (2.0 GiB) |
||
+ | </pre> |
||
+ | |||
+ | Egy ilyen virtuális eszköz eltávolítása a |
||
+ | <pre> |
||
+ | vconfig rem interface_name.VID |
||
+ | </pre> |
||
+ | -rel lehetséges. |
||
+ | |||
+ | Esetünkben: |
||
+ | <pre> |
||
+ | vconfig rem eth0.150 |
||
+ | </pre> |
||
+ | |||
+ | Debian alatt lehetséges a /etc/network/interfaces fájl használata a VLAN-ok definiálására. |
||
+ | A fenti példa így nézhetne ki: |
||
+ | |||
+ | <pre> |
||
+ | iface eth0.150 inet static |
||
+ | address 192.168.1.1 |
||
+ | netmask 255.255.255.0 |
||
+ | </pre> |
||
+ | vagy |
||
+ | <pre> |
||
+ | iface vlan150 inet static |
||
+ | vlan-raw-device eth0 |
||
+ | address 192.168.1.1 |
||
+ | netmask 255.255.255.0 |
||
+ | </pre> |
||
+ | vagy |
||
+ | <pre> |
||
+ | iface eth0.0150 inet static |
||
+ | address 192.168.1.1 |
||
+ | netmask 255.255.255.0 |
||
+ | </pre> |
||
+ | vagy |
||
+ | <pre> |
||
+ | iface vlan0150 inet static |
||
+ | vlan-raw-device eth0 |
||
+ | address 192.168.1.1 |
||
+ | netmask 255.255.255.0 |
||
+ | </pre> |
||
+ | |||
+ | A négyféle módszer mind ugyanazt az eredményt éri el; ekvivalensek. |
||
+ | |||
+ | Az iptables működik - a szokásos szintaxissal - a virtuális interface-ekre. |
||
+ | |||
+ | === Bridge VLAN fölött Debian Linuxon === |
||
+ | |||
+ | ''Kernel támogatás bridge-hez:'' |
||
+ | Patch-ként a 2.4-es szériához is elérhető, de a 2.6-os kernel széria része a bridge képesség, a bridge modul által. |
||
+ | Nagy különbség a két változat között, hogy a 2.4-ben nincs lehetőség a bridge-elt forgalom tűzfalazására, ugyanis a bridge-ben nem kerül kibontásra a 4 bájttal megnövelt (beágyazott) csomag, így az iptables nem ismeri fel. |
||
+ | A 2.6.1-től kezdve azonban van lehetőség tűzfalazásra. |
||
+ | |||
+ | A /proc/sys/net/bridge/-ben levő kapcsolók állításával: |
||
+ | * bridge-nf-call-arptables - pass (1) or don't pass (0) bridged ARP traffic to arptables' FORWARD chain. |
||
+ | * bridge-nf-call-iptables - pass (1) or don't pass (0) bridged IPv4 traffic to iptables' chains. |
||
+ | * bridge-nf-call-ip6tables - pass (1) or don't pass (0) bridged IPv6 traffic to ip6tables' chains. |
||
+ | * bridge-nf-filter-vlan-tagged - pass (1) or don't pass (0) bridged vlan-tagged ARP/IP traffic to arptables/iptables |
||
+ | |||
+ | === Bridge-ek létrehozása === |
||
+ | |||
+ | Linuxon a brctl programmal lehet létrehozni bridge-eket az interface-ek között. |
||
+ | |||
+ | <pre> |
||
+ | brctl addbr brX |
||
+ | </pre> |
||
+ | -el létre lehet hozni bridge-eket. Ezekhez ifconfiggal akár IP-cím és routing tábla is |
||
+ | |||
+ | létrehozható. |
||
+ | <pre> |
||
+ | brctl addif brX device |
||
+ | </pre> |
||
+ | utasítással pedig interface-ket adhatunk a bridge-hez. |
||
+ | |||
+ | brctl paraméterezhetősége: |
||
+ | <pre> |
||
+ | addbr <bridge> add bridge |
||
+ | delbr <bridge> delete bridge |
||
+ | addif <bridge> <device> add interface to bridge |
||
+ | delif <bridge> <device> delete interface from bridge |
||
+ | setageing <bridge> <time> set ageing time |
||
+ | setbridgeprio <bridge> <prio> set bridge priority |
||
+ | setfd <bridge> <time> set bridge forward delay |
||
+ | sethello <bridge> <time> set hello time |
||
+ | setmaxage <bridge> <time> set max message age |
||
+ | setpathcost <bridge> <port> <cost> set path cost |
||
+ | setportprio <bridge> <port> <prio> set port priority |
||
+ | show show a list of bridges |
||
+ | showmacs <bridge> show a list of mac addrs |
||
+ | showstp <bridge> show bridge stp info |
||
+ | stp <bridge> <state> turn stp on/off |
||
+ | </pre> |
||
+ | |||
+ | Debian alatt lehetséges a /etc/network/interfaces fájl használata a bridge-ek definiálására. |
||
+ | |||
+ | <pre> |
||
+ | auto br0 |
||
+ | iface br0 inet static |
||
+ | address 192.168.0.1 |
||
+ | netmask 255.255.255.0 |
||
+ | gateway 192.168.0.1 |
||
+ | bridge_ports eth0 eth1 |
||
+ | bridge_stp on |
||
+ | </pre> |
||
+ | |||
+ | Amennyiben VLAN interface-k fölött szeretnénk bridge-et létrehozni, egyszerűen a következő szintaxis használható: |
||
+ | |||
+ | <pre> |
||
+ | auto br0 |
||
+ | iface br0 inet static |
||
+ | address 192.168.1.1 |
||
+ | netmask 255.255.255.0 |
||
+ | gateway 192.168.1.1 |
||
+ | bridge_ports eth0.150 eth1.150 |
||
+ | bridge_stp on |
||
+ | </pre> |
||
+ | |||
+ | Nincs szükség külön VLAN interface definiálásra; elvégzi automatikusan a rendszer. |
||
+ | |||
+ | A létrehozott bridge-ek állapotának lekérdezése: |
||
+ | <pre> |
||
+ | brctl show |
||
+ | |||
+ | bridge name bridge id STP enabled interfaces |
||
+ | br0 8000.0002a5ce61cc yes eth0.150 |
||
+ | eth1.150 |
||
+ | br1 8000.0002a5ce61cc yes eth0.154 |
||
+ | eth1.154 |
||
+ | </pre> |
||
+ | |||
+ | A számítógép elérhető marad távolról, ugyanis a bridge örökli az egyik interface MAC address-ét és ehhez mint felül látszik IP cím is rendelhető. |
||
+ | |||
+ | Így Linuxszal létrehozhatunk switch-eket, routereket, átlátszó tűzfalakat VLAN, ill. nem VLAN fölött. |
||
+ | |||
+ | === Felhasznált irodalom === |
||
+ | * Andrew S. Tanenbaum: Számítógép hálózatok |
||
+ | * Karen Webb: Building Cisco Multilayer Switched Networks (103. oldal *) |
||
+ | * http://en.wikipedia.org/wiki/VLAN |
||
+ | * http://ebtables.sourceforge.net/brnf-faq.html |
||
+ | * man vlan-interfaces |
||
+ | * google.com |
||
+ | |||
+ | == Potenciális zh-kérdések == |
||
+ | |||
+ | * Hogyan működik a statikus routing? Rajzoljon folyamatábrát arra az esetre, ha adott a következő routing-tábla: [...] és az 1.2.3.4-es géppel szeretnénk kommunikálni! |
||
+ | * Mire való a PMTU discovery és hogyan működik? |
||
+ | * Hogyan működik a SYN támadás? |
||
+ | * Hogyan működik a syncookie mechanizmus? |
||
+ | * Hogyan működik a smurf támadás, és hogy lehet megakadályozni? (A tűzfalas órán mondtam el.) |
||
+ | * Soroljon fel legalább négy mezőt az IP-fejlécből (ami nem azonos a TCP-fejléccel)! |
||
+ | * Soroljon fel legalább öt ICMP-üzenettípust! Mikor keletkeznek ilyen üzenetek? |
||
+ | * Mire való az ARP? Milyen üzenetei vannak? Milyen visszaélésekre ad lehetőséget? Ezek hogyan működnek, mi a hatásuk? |
||
+ | * Hogyan működik az FTP-ben az aktív, és hogyan a passzív mód? |
||
+ | * Hogyan működik a „blind TCP connection spoofing” támadás, és hogyan lehet ellene védekezni? |
A lap jelenlegi, 2012. február 29., 13:29-kori változata
Itt most az IPv4-ről lesz szó. Az IPv6-tal nem foglalkozunk (talán megérdemelne egy külön tantárgyat).
Tartalomjegyzék
|
[szerkesztés] 1 A protokollcsaládról
- Az Internet Protocolra gondolhatunk úgy, mintha az OSI modell hálózati rétegében helyezkedne el, noha az IP és az ISO/OSI referenciamodell között nem feltétlenül egyszerű bijekciót létesíteni. Csomagkapcsolt hálózatot valósít meg, ami annyit jelent, hogy nem épít fel semmilyen kapcsolatot a forrás és a cél között, hanem minden egyes csomagot külön juttat célba (route-ol). Megoszlanak a vélemények arról is, hogy a TCP/IP protokollcsaládnak egészen pontosan melyik protokollok is a részei és melyek nem, de ilyen finomságokkal és filozófiai mélységekkel itt nem foglalkozunk.
- Az IP-vel kapcsolatos főbb protokollok:
- ARP (Address Resolution Protocol)
- IP (Internet Protocol)
- ICMP (Internet Control Message Protocol)
- TCP (Transmission Control Protocol)
- UDP (User/Unreliable Datagram Protocol)
[szerkesztés] 1.1 IP (Internet Protocol)
- hálózati rétegbeli
- datagramm-alapú
- néhány mező a fejlécből:
- forráscím
- célcím
- TTL (Time To Live)
- magasabb szintű protokoll azonosítója
- egyéb (pl: DF, Don't Fragment, PMTU discoveryhez)
- klasszikus támadások:
- flood (bármilyen protokollal lehet, nem IP-specifikum),
- spoofing (címhamisítás),
- teardrop (egymást átfedő fragmentumok),
- ping of death (64k-nál nagyobbnak tűnő csomag, nem csak ICMP lehet).
[szerkesztés] 1.2 ICMP (Internet Control Message Protocol)
- hiba- és státuszüzenetek, pl:
- Echo Request (ping)
- Echo Reply (ping válasz)
- Destination Unreachable; altípusai pl:
- Network Unreachable (nincs route az adott hálózat felé)
- Host Unreachable (az adott gép nem elérhető, pl. nem válaszol ARP-re)
- Protocol Unreachable (Az IP 1 bájton kódolja, milyen magasabb szintű protokollt szállít. Ilyen ICMP hibaüzenetet kapunk, ha a megszólított gép az adott magasabb szintű protokollt nem támogatja.)
- Port Unreachable (Az adott UDP porton nincs szolgáltatás.)
- Fragmentation Needed (l. lejjebb a PMTU discoverynél.)
- Communication Administratively Prohibited
- Time To Live Exceeded
- és még jó pár, ritkábban látott másik
- klasszikus támadások pl.:
- flood,
- smurf,
- ...
[szerkesztés] 1.3 TCP (Transmission Control Protocol)
- összeköttetés-alapú
- garantálja a csomagok helyes sorrendjét
- újraküldi a csomagokat, ha kell
- torlódásvezérelt
- port fogalma ("lokális multiplexelés")
- "nyitott" vs. "zárt" port
- bind(), majd listen()
- kapcsolatfelépítés (l. lejjebb is):
- SYN
- SYN+ACK
- ACK
- klasszikus támadások:
- SYN flooding (l. lejjebb),
- connection spoofing,
- session hijacking,
- "LAND" (azonos forrás- és célcím),
- ...
[szerkesztés] 1.4 UDP (User/Unreliable Datagram Protocol)
- itt is van port
- nincs nyugta
- nincs torlódásvezérlés
- a folyam csomagjai elveszhetnek, ill. megjöhetnek rossz sorrendben
- cserébe "könnyűsúlyú" protokoll
- nem kell hozzá állapotgép, nincs kapcsolatfelépítés => gyorsabb adatküldés
- kisebb fejléc
- Használja:
- DNS
- VoIP
- streaming
- VPN-ek
- játékok
- p2p (peer to peer)
- stb.
- klasszikus támadások:
- fraggle (kb. mint a smurf, udp echo ellen),
- ...
[szerkesztés] 1.5 ARP (Address Resolution Protocol)
- Az IP egy hálózati rétegbeli protokoll.
- A hálózati szint alatt még van egy adatkapcsolati és egy fizikai réteg.
- Az adatkapcsolatiban is kellhet címzés.
- Honnan tudjuk a másik fél adatkapcsolati címét?
- Az IP alatt gyakran van Ethernet, vagy ahhoz hasonló broadcast médium.
- Ötlet: ha nem tudjuk a címet, kérdezzük meg!
00:de:ad:be:ef:00 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 1.2.3.4 tell 1.2.3.1 00:f0:0d:d0:0d:00 > 00:de:ad:be:ef:00, ethertype ARP (0x0806), length 60: arp reply 1.2.3.4 is-at 00:f0:0d:d0:0d:00
- Egy darabig (nagyságrend: percek) megjegyezzük az ARP-táblánkban.
- Igen ám, de nem vagyunk mindenkivel egy fizikai hálózaton - a többiek MAC-címét honnan fogjuk megtudni?
- Sehonnan, mert nem is kell => routing.
- ARP-alapú visszaélések:
- ARP spoofing (hamis választ küldünk)
- Ezen keresztül lehallgatás, man-in-the-middle, DoS
- ARP flooding (pl. a Solaris egyes régi verziói lefagynak tőle)
- ARP spoofing (hamis választ küldünk)
- ProxyARP pseudobridge:
- A végpontok higgyék azt, hogy egy fizikai hálózaton vannak
- A köztük levő routerek válaszolnak mindenki helyett az ARP-re
ProxyARP bekapcsolása linuxon:
# echo 1 >/proc/sys/net/ipv4/conf/interfaceneve/proxy_arp
[szerkesztés] 1.6 Path MTU Discovery
- Az IP-csomagok maximális mérete 65535 bájt (1 bájt híján 64K) lehet.
- Ez egy elméleti maximális csomagméret, amit az alkalmazott fizikai hálózat jellemzőiből adódó korlátok jelentősen csökkenthetnek; pl. az Ethernetet alkalmazva maximálisan 1500 bájtnyi hasznos terhet szállító IP-csomagokat tudunk átjuttatni a hálózaton, mert egy Ethernet-keretbe nem fér több adat. (Kivéve, ha jumbo frame-eket használunk, de itt most nem ez a lényeg.)
- Mivel a különböző helyeken sokféle technológiákat alkalmazhatnak, ezért a nagy csomagokat fel kell darabolni, hogy egy adott hálózati útvonal minden szakaszán átférjenek.
- Azt a jellemzőt, hogy egy adott fizikai interfészen legfeljebb mekkora IP-csomag küldhető ki, MTU-nak (Maximum Transmission Unit) nevezzük.
- Az ennél nagyobb csomagokat a routerek automatikusan fragmentálják, ami több szempontból sem jó:
- Ha egy töredék elvész, az egész csomagot újra kell küldeni.
- Nagyobb az overhead (mind a hálózati, mind a processing-).
- A butább tűzfalak minden töredezett IP-csomagot kiszűrnek, mert
- korábban érvénytelen csomagtöredékekkel DoS-t lehetett megvalósítani és
- mert csak az első töredék tartalmazza a magasabb szintű protokoll fejlécét, ami alapján a tűzfal szűrni tud.
- Talán érdemes itt megemlíteni, hogy az IPv6-ban már a végpontok feladata a fragmentálás, a routerek semmiképpen nem foglalkoznak vele.
Annek a kiderítésére, hogy egy teljes útvonalon mi a legkisebb MTU, használható a Path MTU Discovery algoritmus. Az algoritmus úgy működik, hogy a célállomásnak először akkora csomagot próbál küldeni, amekkora a saját MTU-ja azon az interfészen, amelyen az adott cél felé a routing-táblája alapján a csomagokat ki kell küldenie; ezeken a csomagokon beállítja a DF (Don't Fragment) bitet. Ha útközben valamelyik routeren ez a csomag "nem fér át", akkor a router ICMP Fragmentation Needed hibaüzenetet küld a forrásnak, és a csomagot eldobja. Az okosabb routerek azt is megmondják, mekkora lenne az MTU a következő routerig, így a forrás megtudja, mekkora csomaggal próbálkozzon legközelebb. Ha az adott router nem okos, akkor a forrás pl. bináris kereséssel találhatja meg a PMTU-t.
[szerkesztés] 1.7 Részletesebben a TCP-ről
Kicsit foglalkozzunk a TCP néhány olyan jellemzőjével, amire nem biztos, hogy mindenki emlékszik korábbi tanulmányaiból.
[szerkesztés] 1.7.1 Nyugtázás
Egy adatcsomag egyben nyugta is lehet; ha be van billentve a fejlécében az ACK bit, akkor amellett, hogy esetleg szállít adatot is, nyugtázza a korábban megkapott adatokat is.
- Hogy melyikeket, az a nyugtaszámból derül ki.
- Minden elküldött bájtnak van egy sorszáma, amit a kapcsolat során nem nullától, hanem egy ISN-től (Initial Sequence Number) kezdenek számolni.
- A nyugták ezeket a szekvenciaszámokat nyugtázzák.
- Ha tehát az én oldalamon 42 volt az ISN, és kapok egy 100-as sorszámú nyugtát, akkor az azt jelenti, hogy a 42-99-es sorszámú bájtokat a túloldal sikeresen átvette, és most nekem a 100-as sorszámú bájttal kell majd folytatnom az adást.
[szerkesztés] 1.7.2 Kapcsolatfelépítés
A TCP-kapcsolat felépítése úgy történik, hogy a kliens kitalál egy ISN-t, és egy ezt tartalmazó TCP SYN üzenetet küld a szervernek (olyan TCP-csomagot, amelyben a SYN bit be van állítva). A SYN csomag tehát az alábbi információkat tartalmazza biztosan:
- forrás IP-címe (az IP-fejlécből);
- cél IP-címe (szintén);
- forrásport (a TCP-fejlécből);
- célport (szintén);
- kliensoldali ISN.
A szerver erre egy olyan csomaggal válaszol, amelyben a SYN és az ACK bitek vannak beállítva (ezért szokás ezt a csomagot SYNACK vagy SYN+ACK csomagnak hívni); ez a csomag tehát nyugtacsomag, az ACK-kal nyugtázzuk a kliensoldali ISN-t, a SYN mellé pedig mellékeljük azt az ISN-t, amit mi találtunk ki ehhez a kapcsolathoz.
A kapcsolat felépítését a kliens egy olyan ACK csomaggal zárja le, amelyben a szerver ISN-jét nyugtázza.
- Az ISN-t azért nem nullától célszerű számolni, mert ha kiszámítható ISN-eket választunk, akkor azzal egy támadónak lehetősége nyílik az ún. blind connection spoofing támadásra. Lényege:
- A gép megbízik B gépben (tehát pl. B-ről szabad kapcsolódni A-ra).
- A támadó elérhetetlenné teszi B gépet.
- A támadó B forráscímével SYN csomagot küld A-nak.
- A B-nek válaszol, így a válaszcsomagot a támadó nem kapja meg, de mivel ismeri az ISN-t, úgy tehet, mintha megkapta volna a SYNACKot, és küldhet azt nyugtázó ACK-ot (még mindig B nevében).
- Így A azt hiszi, B kapcsolódott hozzá, a támadó pedig B nevében tetszőleges adatokat/parancsokat küldhet A-nak; az egyetlen nehézség az, hogy nem látja a választ (ha erről más módon nem gondoskodik).
- Védekezés:
- Nehezen kitalálható ISN-nel;
- reverse path filteringgel (l. később).
- Hasonló támadás a blind connection reset:
- ha a támadó tudja, hol tart a nyugtaszámláló egy kapcsolatban, küldhet olyan csomagot, ami lezárja a kapcsolatot valamelyik fél nevében (vagy akár mindkét fél nevében, kölcsönösen).
- Általában is: ha egy támadó tudja, mi egy TCP-kapcsolatban a következő szekvenciaszám, és tudja hamisítani a forráscímét, akkor a hamis forráscím nevében csomagokat tud beszúrni a kapcsolatba; pl. egy telnet-kapcsolatba az "rm -rf /\n" tartalmú adatcsomagot.
- Ezért is jó az SSH, nemcsak a lehallgatásbiztossága miatt.
[szerkesztés] 1.7.2.1 SYN-támadás
A szervernek normális esetben a SYNACK csomag kiküldésével egyidőben memóriát kell allokálnia, amiben megjegyzi a kapcsolat paramétereit: a kliens címét, portszámokat, ISN-eket stb. Ha a kliens nem fejezi be a kapcsolat felépítését, akkor a szerver néhányszor újra elküldi a SYNACK csomagot (hátha az első elveszett), aztán időtúllépés miatt eldobja a kapcsolatot; addig viszont valamennyi memóriát lefoglalva tart. Ha egy támadó sok kapcsolatot kezd el, de egyiket se fejezi be, akkor az erre a célra fenntartott memóriaterület (a tcp backlog queue) megtelhet, és a szerver a legitim kapcsolatokkal sem tud foglalkozni; l. a Wikipédián is.
Ez ellen a támadás ellen védekezhetünk pl. a Syncookie algoritmus használatával. Az algoritmus lényege az, hogy minden megjegyzendő adatot vagy belekódolunk a szerveroldali ISN-be (amit majd visszakapunk a kliens ACK üzenetben), vagy figyelmen kívül hagyunk (mert nem kritikus a kapcsolat létrejötte szempontjából).
Arra vigyázni kell, hogy ne lehessen könnyen olyan szekvenciaszámot kitalálni, amely alapján a szerver felépít egy érvényes kapcsolatot, mert akkor egy támadó SYN-csomag küldése nélkül tudna kapcsolatot felépíteni a szerverrel, ami Rossz, értem?. (Főleg régebbi tűzfalak a SYN-csomag alapján azonosítják az új kapcsolatokat; ha SYN nélkül is lehetne kapcsolatot nyitni, akkor ezzel meg lehetne kerülni a tűzfalat.)
A Syncookie algoritmus hátrányai:
- Korlátozza a kapcsolatok paramétereit (bővebben l. a Wikipédián);
- ha a háromutas kézfogás utolsó csomagja (az ACK) nem ér célba, a szerver sosem küldi újra a SYNACK-ot (hiszen nem jegyezte meg, hogy van egy félig nyitott kapcsolata), így a kliens nem tudja meg, hogy az ACK csomagja elveszett. Ha az alkalmazásszintű protokoll olyan, hogy az első üzenetet a szervernek kellene küldenie (ilyen pl. az SMTP), akkor a kliens csak állni fog és várni (abban a boldog, ám téves hitben, hogy érvényes TCP-kapcsolata van a szerverrel), a szerver pedig minderről nem sejt semmit. Persze egy ésszerű idő után az alkalmazás valószínűleg nem vár tovább, de nem árt ezzel a hibalehetőséggel tisztában lennünk, ha TCP-alapú hálózati protokollt, vagy azt megvalósító alkalmazást készítünk.
- Bejövő SYNfloodra kimenő SYNACK-flooddal válaszolunk;
- ez pl. ADSL-nél nyilván nagyon nem jó...
- lepattintható rólunk egy SYN-áradat, ha hamis forráscímmel küldik.
[szerkesztés] 2 Statikus routing
- Minden gépnek van egy routing-táblája, ilyesmi bejegyzésekkel:
IP | netmask | gateway | interface | megjegyzés |
---|---|---|---|---|
1.2.3.0 | 255.255.255.0 | * | eth0 | ez egy fizikai helyi hálózat, az eth0-án lóg |
2.3.4.5 | 255.255.255.255 | 1.2.3.2 | eth0 | a 2.3.4.5-ös gépet az 1.2.3.2 című routeren át érjük el, "amögött" van |
3.4.5.128 | 255.255.255.128 | 1.2.3.42 | eth0 | a 3.4.5.128/25-ös hálózat a 1.2.3.42 című routeren át érhető el, "amögött" van |
0.0.0.0 | 0.0.0.0 | 1.2.3.254 | eth0 | Minden más ("az egész Internet") az 1.2.3.254 című routeren át érhető el |
Fontos szabály: Mindig a leghosszabb illeszkedő prefixű bejegyzés "nyer". Pl. ha van route-unk a 10.0.0.0/8 felé az eth1-en át és a 10.0.0.0/24 felé az eth0-án át, és a 10.0.0.1-et akarjuk megszólítani, az eth0-án próbálkozunk.
Ha egy adott konkrét A.B.C.D IP-címmel akarunk kommunikálni, a következők szerint járunk el:
- Megnézzük, az IP-cím része-e valamelyik helyi hálózatnak a cím/maszk párok alapján ("helyi" az a hálózat, amihez nincs gateway a routing-táblában)
- Ha igen, ARP queryt küldünk
- A válaszban benne lesz a MAC-cím
- MAC-szinten oda, IP-szinten A.B.C.D-nek címezzük a csomagot
- Ha nincs ARP-válasz, "host unreachable"
- Ha nem:
- Megnézzük, az IP-cím illeszkedik-e valamelyik más routing-bejegyzésünk cím/maszk párosára
- Ha igen, a csomagot MAC-szinten az adott gatewaynek, IP-szinten A.B.C.D-nek kell címeznünk
- Vagyis: ARP who-has IP-of-gateway
- Ha nem, akkor nem tudjuk, merre kell küldeni a csomagot, "network unreachable" ("no route to host")
- Ha igen, a csomagot MAC-szinten az adott gatewaynek, IP-szinten A.B.C.D-nek kell címeznünk
- Megnézzük, az IP-cím illeszkedik-e valamelyik más routing-bejegyzésünk cím/maszk párosára
- Ha igen, ARP queryt küldünk
[szerkesztés] 2.1 Reverse path filtering
Egyszerű, de sok esetben hatásos védekezés a hamisított forráscímű (spoofolt) csomagok ellen:
- Ha bejön egy csomag x feladóval az i interface-en:
- Nézzük meg, hogy a routing-tábla szerint, ha x-nek akarnánk csomagot küldeni, az i interface-en küldenénk-e ki;
- Ha igen, jó;
- Ha nem, x "valójában" nem is "arra van", úgyhogy a csomag "biztos" hamis.
- Aszimmetrikus routingnál nem működik.
Bekapcsolása linuxon:
# echo 1 >/proc/sys/net/ipv4/conf/interfaceneve/rp_filter
[szerkesztés] 2.2 A routing-tábla karbantartása
Linuxon:
- route parancs:
- route add -net 1.2.3.0/24 dev eth0
- route add -host 2.3.4.5 gw 1.2.3.2
- Az eth0 következik a gw címéből
- route add -net 3.4.5.128/25 gw 1.2.3.42
- route add default gw 1.2.3.254
- route -n
- ip parancs:
- ip ro add 1.2.3.0/24 dev eth0
- ip ro add 2.3.4.5/32 via 1.2.3.2
- ip ro add 3.4.5.128/25 via 1.2.3.42
- ip ro add default via 1.2.3.254
- ip ro sh
[szerkesztés] 2.3 Statikus route-ok automatikus felvétele
- Debianon és Ubuntun:
- /etc/network/interfaces-be:
- iface eth0 inet static
- address 1.2.3.1
- netmask 255.255.255.0
- broadcast 1.2.3.255
- network 1.2.3.0
- gateway 1.2.3.254
- up ip ro add 2.3.4.5/32 via 1.2.3.2
- up ip ro add 3.4.5.128/25 via 1.2.3.42
- iface eth0 inet static
- Red Hat Linuxon:
- /etc/sysconfig/network-scripts/route-<interface-name>-be:
- ADDRESSn=<network>
- NETMASKn=<network/prefix mask>
- GATEWAYn=<next-hop router/gateway IP address>
- SuSE Linuxon:
?
- FreeBSD-n:
?
- Solarison:
- Default routerek:
- /etc/defaultrouter-be IP cím vagy hostname
- Nem default routerek:
- /etc/gateways-be:
- host destination gateway gateway metric hops , vagy
- net destination gateway gateway metric hops
- /etc/gateways-be:
- Ha mindenáron hoszt nevet akarunk megadni, akkor csak olyat, ami benne van az /etc/inet/hosts-ban!
- OpenBSD-n:
?
- Gentoo Linuxon:
- A Gentoo a az /etc/init.d/net.lo-ra mutató symlinkekkel operál az ethn interfész felhúzásakor; így ha pl. eth0 és eth1 interfészeket akarunk használni, akkor ln -s net.lo net.eth0 illetve ln -s net.lo net.eth1 a használandó parancsok. Ezek automatikus felhúzása boot után az rc-update add net.eth0 default ill. rc-update add net.eth1 default parancsokkal lehetséges.
- Azt, hogy az egyes interfészeket hogyan szeretnénk alapesetben indítani, az /etc/conf.d/net fileban adhatjuk meg. A példa elég értelemszerű:
- config_eth0=("192.168.2.210 netmask 255.255.255.0")
- routes_eth0=("default gw 192.168.1.254")
- itt soroljuk fel a többit is
- Jó tudni, hogy az alapértelmezés DHCP. Azaz ha nem adunk meg semmit, de DHCP klienst futtatunk, akkor azzal próbálkozik a rendszer.
--TechyZoltan 2006. szeptember 12., 20:55 (CEST)
[szerkesztés] 3 VLAN
Írta: Rostás Attila.
VLAN a Linux-on, Debian alatt
Mi is az a VLAN? A VLAN (Virtual Local Area Network) az IEEE 802.1Q szabványban definiált. VLAN segítségével a hálózatok fizikai kialakításától függetlenül definiálhatunk logikai (szoftveresen létrejövő) broadcast hálózatokat az egy ugyanazon VLAN hálózatban szereplő host-ok között. A VLAN megvalósítása az OSI modell 2. rétegében, a adatkapcsolati rétegben történik. Gyakorlatilag a hálózati csomagok kapnak még egy 4 bájtos (*) fejlécet amelyben definiálva van egy 12 bites VLAN Identifier (VID), mely 4096 külön logikai hálózatot tenne lehetővé egy ugyanazon hálózati interface-n, vagy kábelen. Ennél a gyakorlatban – implementációtól függően – valamelyest kevesebb érhető el. A 0. és a 4095. VLAN a szabvány szerint foglaltak. Az 1. VLAN pedig a mindenki számára látható forgalmat jelenti. (Átlátszó VLAN.) A VLAN hálózatokban két eszköz akkor van azonos logikai közegben, ha a VID-jük megyegyezik. Különböző VID-ű hálózatok között a kommunikációt az erre kijelölt eszköz (pl. egy router, vagy switch…) végezheti el a 3. – hálózati - rétegben. Egy switch egy portja tartozhat egy vagy több VLAN-hoz. Amennyiben egyhez tartozik, lehetőség van rá, hogy a switch elrejtse a porton keresztül kapcsolódó eszköz (leginkább egy számítógép hálózati interface-e) elől, hogy ő valójában egy VLAN-ban van. Amennyiben egy porthoz több VLAN van megengedve, vagy egy VLAN, de nem cél az elrejtése, akkor a portra csatlakozó eszköznek ismernie kell, hogy ő melyik VLAN-ban van és ennek megfelelő VID-et kell a kiküldött csomagjai elé tennie illetve a kapott csomagok tag-jében találnia. Biztonsági szempontból ajánlatos lehet MAC címhez, vagy valamilyen authentikációhoz kötni a VLAN-t, ebben az esetben az adott számítógép csak a neki szánt VID-(ek)en tud kommunikálni. A VLAN témakör részletes mindenre kiterjedő ismertetésére kitérni nincs lehetőség, a forrásjegyzékben szereplő irodalmakból azonban jól megismerhető.
[szerkesztés] 3.1 Linux alatt
VLAN kernel támogatás: A 802.1Q szabvány a kernel 2.4.21-es verziója óta a kernel része, 8021q a modul neve. A VLAN támogatáshoz a hálózati kártya driverének is támogatnia kell az esetlegesen nagyobb, mint 1500 bájt-os MTU-t. (Tapasztalataim alapján a szabvány Debian 2.6.8 kernel e1000 és e100 moduljai tökéletesen működnek. Azért nem a 2.4-es kernel széria lett a kiválasztott, mert ott a VLAN-ok fölötti bridge építése iptables tűzfalas szűréssel nem lehetséges. ld. később )
[szerkesztés] 3.2 VLAN utility-k és használatuk
A VLAN hálózatok létrehozása a vconfig programmal lehetséges a következő szintaxis szerint:
vconfig add interface_name VID
És ekkor létrejön az interface_name.VID interface, amely már a VID hálózatban képes kommunikálni.
Pl. az eth0 interface feletti 150-es VLAN létrehozása a következőféleképpen lehetséges:
vconfig add eth0 150
Ekkor a következő interface jelenik meg:
eth0.150 Link encap:Ethernet HWaddr 00:02:A5:CE:61:CC inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe30::212:a3ff:fdce:61cd/64 Scope:LinkUP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:406783997 errors:0 dropped:0 overruns:0 frame:0 TX packets:444927484 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:2283210879 (2.1 GiB) TX bytes:2212731126 (2.0 GiB)
Egy ilyen virtuális eszköz eltávolítása a
vconfig rem interface_name.VID
-rel lehetséges.
Esetünkben:
vconfig rem eth0.150
Debian alatt lehetséges a /etc/network/interfaces fájl használata a VLAN-ok definiálására. A fenti példa így nézhetne ki:
iface eth0.150 inet static address 192.168.1.1 netmask 255.255.255.0
vagy
iface vlan150 inet static vlan-raw-device eth0 address 192.168.1.1 netmask 255.255.255.0
vagy
iface eth0.0150 inet static address 192.168.1.1 netmask 255.255.255.0
vagy
iface vlan0150 inet static vlan-raw-device eth0 address 192.168.1.1 netmask 255.255.255.0
A négyféle módszer mind ugyanazt az eredményt éri el; ekvivalensek.
Az iptables működik - a szokásos szintaxissal - a virtuális interface-ekre.
[szerkesztés] 3.3 Bridge VLAN fölött Debian Linuxon
Kernel támogatás bridge-hez: Patch-ként a 2.4-es szériához is elérhető, de a 2.6-os kernel széria része a bridge képesség, a bridge modul által. Nagy különbség a két változat között, hogy a 2.4-ben nincs lehetőség a bridge-elt forgalom tűzfalazására, ugyanis a bridge-ben nem kerül kibontásra a 4 bájttal megnövelt (beágyazott) csomag, így az iptables nem ismeri fel. A 2.6.1-től kezdve azonban van lehetőség tűzfalazásra.
A /proc/sys/net/bridge/-ben levő kapcsolók állításával:
- bridge-nf-call-arptables - pass (1) or don't pass (0) bridged ARP traffic to arptables' FORWARD chain.
- bridge-nf-call-iptables - pass (1) or don't pass (0) bridged IPv4 traffic to iptables' chains.
- bridge-nf-call-ip6tables - pass (1) or don't pass (0) bridged IPv6 traffic to ip6tables' chains.
- bridge-nf-filter-vlan-tagged - pass (1) or don't pass (0) bridged vlan-tagged ARP/IP traffic to arptables/iptables
[szerkesztés] 3.4 Bridge-ek létrehozása
Linuxon a brctl programmal lehet létrehozni bridge-eket az interface-ek között.
brctl addbr brX
-el létre lehet hozni bridge-eket. Ezekhez ifconfiggal akár IP-cím és routing tábla is
létrehozható.
brctl addif brX device
utasítással pedig interface-ket adhatunk a bridge-hez.
brctl paraméterezhetősége:
addbr <bridge> add bridge delbr <bridge> delete bridge addif <bridge> <device> add interface to bridge delif <bridge> <device> delete interface from bridge setageing <bridge> <time> set ageing time setbridgeprio <bridge> <prio> set bridge priority setfd <bridge> <time> set bridge forward delay sethello <bridge> <time> set hello time setmaxage <bridge> <time> set max message age setpathcost <bridge> <port> <cost> set path cost setportprio <bridge> <port> <prio> set port priority show show a list of bridges showmacs <bridge> show a list of mac addrs showstp <bridge> show bridge stp info stp <bridge> <state> turn stp on/off
Debian alatt lehetséges a /etc/network/interfaces fájl használata a bridge-ek definiálására.
auto br0 iface br0 inet static address 192.168.0.1 netmask 255.255.255.0 gateway 192.168.0.1 bridge_ports eth0 eth1 bridge_stp on
Amennyiben VLAN interface-k fölött szeretnénk bridge-et létrehozni, egyszerűen a következő szintaxis használható:
auto br0 iface br0 inet static address 192.168.1.1 netmask 255.255.255.0 gateway 192.168.1.1 bridge_ports eth0.150 eth1.150 bridge_stp on
Nincs szükség külön VLAN interface definiálásra; elvégzi automatikusan a rendszer.
A létrehozott bridge-ek állapotának lekérdezése:
brctl show bridge name bridge id STP enabled interfaces br0 8000.0002a5ce61cc yes eth0.150 eth1.150 br1 8000.0002a5ce61cc yes eth0.154 eth1.154
A számítógép elérhető marad távolról, ugyanis a bridge örökli az egyik interface MAC address-ét és ehhez mint felül látszik IP cím is rendelhető.
Így Linuxszal létrehozhatunk switch-eket, routereket, átlátszó tűzfalakat VLAN, ill. nem VLAN fölött.
[szerkesztés] 3.5 Felhasznált irodalom
- Andrew S. Tanenbaum: Számítógép hálózatok
- Karen Webb: Building Cisco Multilayer Switched Networks (103. oldal *)
- http://en.wikipedia.org/wiki/VLAN
- http://ebtables.sourceforge.net/brnf-faq.html
- man vlan-interfaces
- google.com
[szerkesztés] 4 Potenciális zh-kérdések
- Hogyan működik a statikus routing? Rajzoljon folyamatábrát arra az esetre, ha adott a következő routing-tábla: [...] és az 1.2.3.4-es géppel szeretnénk kommunikálni!
- Mire való a PMTU discovery és hogyan működik?
- Hogyan működik a SYN támadás?
- Hogyan működik a syncookie mechanizmus?
- Hogyan működik a smurf támadás, és hogy lehet megakadályozni? (A tűzfalas órán mondtam el.)
- Soroljon fel legalább négy mezőt az IP-fejlécből (ami nem azonos a TCP-fejléccel)!
- Soroljon fel legalább öt ICMP-üzenettípust! Mikor keletkeznek ilyen üzenetek?
- Mire való az ARP? Milyen üzenetei vannak? Milyen visszaélésekre ad lehetőséget? Ezek hogyan működnek, mi a hatásuk?
- Hogyan működik az FTP-ben az aktív, és hogyan a passzív mód?
- Hogyan működik a „blind TCP connection spoofing” támadás, és hogyan lehet ellene védekezni?