IP-alapok

A lap 2006. szeptember 14., 12:40-kori változata

Itt most az IPv4-ről lesz szó. Az IPv6-tal nem foglalkozunk.

1 A protokollcsaládról

• Az IP egy protokollcsalád

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

• • ARP (később)
  • 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)
    • 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
  • 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 (l. lejjebb is):
      • SYN
      • SYN+ACK
      • ACK
    • port fogalma ("lokális multiplexelés")
  • 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
    • Használja:
      • DNS
      • streaming
      • VPN-ek
      • játékok
      • p2p (peer to peer)
  • stb.

1.1 ARP

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

1.2 Path MTU Discovery

Az IP-csomagok maximális mérete 65535 bájt (64K) lehet, ez az elméleti maximális csomagméret, amit az alkalmazott fizikai hálózat technológiája jelentősen lecsökkenthet; pl. az Ethernetet alkalmazva maximálisan 1500 bájtos csomagokat tudunk átjuttatni a hálózaton, mert egy Ethernet-keretbe nem fér több adat.

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.

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.

1.3 Részletesebben a TCP-ről

Kicsit emlékezzünk meg a TCP néhány olyan jellemzőjéről, amire nem biztos, hogy mindenki emlékszik korábbi tanulmányaiból.

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

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

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.

Ebbe itt most nem megyünk bele; az Interneten megtalálható (ill. persze kidolgozhatja valaki, ha van kedve).

Hasonló probléma a blind connection reset.

A kapcsolat felépítését a kliens egy olyan ACK csomaggal zárja le, amelyben a szerver ISN-jét nyugtázza.

1.3.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 megtelhet, és a szerver a legitim kapcsolatokkal sem tud foglalkozni; l. a Wikipedian is: [1].

Ez ellen a támadás ellen védekezhetünk pl. a Syncookies algoritmus használatával. Az algoritmus lényege az, hogy minden megjegyezndő adatot vagy belekódolunk a szerveroldali ISN-be (amit majd visszakapunk az utolsó 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.)

2 Statikus routing

• Minden gépnek van egy routing-táblája, ilyesmi bejegyzésekkel:

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

2.1 A routing-tábla karbantartása

• 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

2.2 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

• Red Hat Linuxon:

?

• SuSE Linuxon:

?

• FreeBSD-n:

?

• Solarison:

?

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