Chapter 29 Datalink Access

1. Chapter 29Datalink Access Tietoliikennetekniikan jatko-opintokurssi 2 Leo Rela

2. Datalink access • Nykyisissä käyttöjärjestelmissä ohjelmat pääsevat jo datalink-kerrokselle. • Yhdistettynä interfacen promiscuous mode -tilaan, tämä mahdollistaa esim. tcpdump:n ja reverse arp:n toiminnan normaaleina ohjelmina.

3. Datalink access • Kirjassa esiteltiin kolme tapaa, joilla ohjelmat pääsevät datalink –kerrokselle: • BSD Packet Filter (BPF) • SVR4 Datalink Provider Interface (DLPI) • Linux SOCK_PACKET (vanha) ja PF_PACKET (uusi)

4. BSD Packet Filter (BPF) • 4.4BSD ja moni BSD-pohjainen tukee. • Kernelissä ajuri kutsuu BPF:ää aina kun paketti on lähetetty tai vastaanotettu. • BPF:ää kutsutaan pakettia lähettäessä mahdollisimman myöhään ja vastaanottaessa mahdollisimman aikaisin jotta aikaleimat pysyisivät tarkkoina. • Ohjelmat antavat BPF:lle suodattimen (filter), jotta kernel voi kopioida ohjelmalle user spaceen vain halutut paketit.

5. BSD Packet Filter (BPF) Esimerkki-filteri: • tcp and port 80 and tcp[13:1] & 0x7 != 0 • (vain tcp segmentit joissa src/dst port 80, SYN, FIN tai RST lippu). • Lippujen luku: tcp[13:1] viittaa tcp headerin tavuun 1 kohdasta 13. • Filtereitä voidaan luoda BPF:n omalla konekielellä tai kääntää sellaisiksi asciista (kuten ylempi esimerkki)

6. BSD Packet Filter (BPF) • BPF vähentää overheadia: • filteröinti tapahtuu kernelissä • vain osa paketista välitetään ohjelmalle (snaplen) • data välitetään ohjelmalle puskuroituna, vajaa puskuri voidaan lähettää ohjelmalle kun timeout -arvo ylittyy. • esim RARP:lla timeout 0 jotta se voi lähettää vastauksen heti kun saa pyynnön. • toisaalta puskurin käyttö vähentää tehtävien systeemikutsujen määrää.

7. BSD Packet Filter (BPF) • BPF:ään voidaan lukea ja kirjoittaa. Kirjoittamista tarvitaan vain kun halutaan tehdä paketteja jotka eivät ole IP-datagrammeja. • BPF:ää käytetään avaamalla /dev/bpf0, jos tulee error EBUSY niin yritetään /dev/bpf1 jne. • ioctl:ää käytetään devicen konfigurointiin, esim. timeoutit ja puskurin asetus. Myös promiscous mode asetetaan tässä.

8. SVR4 Datalink Provider Interface (DLPI) • SVR4:ssä. • Voidaan käyttää: • Luetaan yhdestä devicestä, haluttu interface määrätään (DL_ATTACH_REQ) • Luetaan inteface-kohtaisesta devicestä. • Luettavaan streamiin liittyy kaksi moduulia: • pfmod (filtering) ja bufmod (puskurointi). • Molemmat toimivat saman tapaisesti kun BPF:n kohdalla, eli kernelissä.

9. SVR4 Datalink Provider Interface (DLPI) • Filteröinnin hoitava pseudokone pfmod filterissä on boolean puu. • BPF:n filter on suunnattu asyklinen graafi. • Kirjan lähteen mukaan jälkimmäinen on 3..20 kertaa nopeampi. • BPF:ssä filteröintipäätös tehdään ennenkö paketi kopioidaan, joissain DLPI toteutuksissa paketti saatetaan kopioida pfmod:lle jonka filteröinti hylkää sen.

10. Linux SOCK_PACKET (vanha) ja PF_PACKET (uusi) • Molemmissa vaaditaan oikeudet luoda raw socket (lähinnä root). • Uusissa toteutuksissa luodaan PF_PACKET -socket ja tyypiksi joko SOCK_DGRAM ("cooked" packets ilman linkkikerroksen headereita) tai SOCK_RAW täydelliselle linkkikerroksen lukemiselle.

11. Linux SOCK_PACKET (vanha) ja PF_PACKET (uusi) • Esim kaikki framet linkkikerrokselta saadaan sockeilta: • fd = socket(PF_PACKET, SOCK_RAW, htons(ETH_P_ALL)); • Jos halutaan esim vain IPv4 framet niin ETH_P_IP. Tämä voidaan asettaa myös esim ETH_P_ARP tai ETH_P_IPV4. • Jos datalink tukee promiscuous moodia (esim ethernetin tapauksessa) niin se on asetettava.

12. Linux SOCK_PACKET (vanha) ja PF_PACKET (uusi) • Kirjassa on listattu tämän eroja BPF:ään ja DLPI:hin: • Linuxissa ei kernel bufferia ja kernel filterin on vain uusimmissa toteutuksissa. Receive buf löytyy, mutta se voi käsitellä vain yhtä framea kerrallaan - luetan siis frame kerrallaan. Tämä lisää overheadia. • SOCK_PACKET (vanha) ei voi filteröidä interfacen/devicen perusteella, esim. jos ETH_P_IP tapauksessa saadaan kaikki paketit interfaceiltä, ppp:ltä, slipiltä jne. Recvfrom fktiolta saadaan kuitenkin sa_data jäsenenä devicen nimi, ja ohjelma voi itse käsitellä vain tietyt devicet.

13. libpcap Packet Capture Library • Tarjoaa toteutusriippumattoman apin alempien kerrosten lukemiselle, eli lähinnä linkkikerrokselle. • Tuki löytyy • BPF: BSD-kerneleille • DLPI: HP-UX ja Solaris 2.x:lle, • NIT:lle (SunOS 4.1.x) • Linuxille (SOCK_PACKET ja PF_PACKET)

14. libnet - Packet Creation and Injection Library • Provides an interface to craft and inject arbitrary packets into the network. • Tukee sekä raw socket että datalink. • Helpottaa IP, UDP ja TCP -otsikoiden käsittelyä.

15. UDP Checksum Field Luvun esimerkkiohjelma tekee dns-kyselyn (udp) ja lukee vastauksen käyttämällä libpcap:ia. Tarkoitus on tarkastaa, käyttääkö nimipalvelin udp tarkastussummaa. IPv4:ssä tarkastussumma on valinnainen ja nykyiset käyttöjärjestelmät käyttävät sitä oletuksena, mutta vanhemmat, esim SunOS 4.1 ei. Nimipalvelimissa tarkastusta pitäis käyttää, koska korruptoituneet datagrammit voivat korruptoida nimipalvelimen tietokannan. UDP tarkistussummaa ei voida saada selville normaalisti UDP socketista lukemalla tai raw socketista, vaan luetaan datagrammit linkkikerrokselta.

16. UDP Checksum Field Kuvissa 29.6-8 on pääohjelma. Parametrit: -l paikallinen (source) osoite datagrammille -i interface johon dns:n vastaus tulisi Source-osoite halutaan tietää, koska ohjelmassa luodaan itse IP ja UDP headerit. Ohjelma toteutetaan kolmessa funktiossa: open_output(); // open output, either raw socket or libnet open_pcal(); // open packet capture device test_udp(); // suorittaa itse DNS-testin

17. UDP Checksum Field Ohjelma suorittaa setuidin, koska raw socketin teko vaatii rootin oikeuksia. Lisäksi pääohjelmassa luodaan signal handlerit käyttäjän tekemää keskeyttämistä varten (TERM, INT, HUP). open_pcap –funktion: Jos käyttäjä ei antanut interfacea, ohjelma valitsee alimman ei-loopback –interfacen. Tämän jälkeen avataan device (pcap_open_live), jossa parametrina annetaan interface, snaplen, promiscuous mode, timout ja osoitin virheilmoarrayhyn. pcap_compile ottaa filter stringin ja kääntää sen filterin konekieleksi. Asetettu filteri päästää läpi vain halutut, eli DNS-vastaukset. pcap_setfilter lataa tehdyn filterin capture deviceen.

18. UDP Checksum Field Tämän jälkeen pääohjelma kutsuu test_udp. test_udp asettaa signal handlerin SIGALRM:lle timeoutia varten, eli kun ei olla saatu vastausta DNS:ltä vielä - ”ikinä”. Ensimmäisen timeoutin jälkeen suoritetaan DNS-kysely vielä max. 2 kertaa, timeout-arvoa tuplatessa: 3, 6 ja 12 s. Itse kysely lähetetään send_dns_query –funktiolla.

19. UDP Checksum Field send_dns_query –funktio (kuva 29.12) rakentaa UDP datagrammin. Datagrammissa oleva DNS-kysely kysyy nimen a.root-servers.net osoitteita. open_output funktio (kuva 29.13) luo raw-socketin ja asettaa sockoptiot: rawfd = Socket(dest->sa_family, SOCK_RAW, 0) Setsockopt(rawfd, IPPROTO_IP, IP_HDRINCL, &on, sizeof(on)); Sockoptioissa asetetaan IP_HDRINCL joka mahdollistaa oman IP –headerin teon.

20. UDP Checksum Field Kun raw-socket on luotu, udp_write –funktiolla rakennetaan lopulliset UDP ja IP headerit ja kirjoitetaan IP daragrammi luotuun raw-socketiin. udp_write on kuvassa 29.14. Funktiossa täytetään struct udpiphdr *ui ja struct ip *ip kun koko socketiin kirjoitettava data on char *buf. Riveillä 32-45 luodaan UDP checksum –arvo, joka luodaan UDP headerista ja datasta. Myös IP headerista otetaan kenttiä mukaan, jotta voidaan varmistua että datagram lähettiin oikeaan paikkaan. Riveillä 46-59 asetetaan IP headeriin arvot. Tämä pitää tehdä, koska sock opt IP_HDRINCL –asetettiin luotuun socketiin. Funktio käyttää lopussa Sendto –funktiota joka kirjoittaa luotuun socketiin luodun IP-datagrammin datan (char *buf)

21. UDP Checksum Field udp_read -funktio (kuva 29.15) Funktiossa on ikilooppi joka saa next_pcap –funktiolla pointerin kohtaan josta seuraava saatu IP datagrammi voidaan lukea. Koska datalink –tason header voi devicestä riippuen olla erilainen (lähinnä eri kokoinen), kutsutaan valintarakenteessa udp_check –funktio sen mukaisesti, mikä on devicen tyyppi. esim 10 ja 100 M ethernetille pcap_datalink antaa DLT_EN10MB.

22. UDP Checksum Field udp_check –funktio (kuva 29.19) tarkistaa UDP-headerin alkaen annetusta IP datagrammiin osoittavasta pointterista. Jos kaikki arvot ok, palautetaan osoitin struct udpiphdr *ui. Ajo palaa takaisinpäin aina test_udp –funktioon asti, jossa katsotaan structissa ui_sum –jäsenen arvoa. Jos 0 niin UDP checksummia ei ole, muutoin päällä. Käyttäjälle kerrotaan checksummin mahdollisesti olemisesta ja palataan pääohjelmaan jossa ohjelma lopetetaan.

23. UDP Checksum Field ja libnet Kirjassa esiteltiin äskeinen ohjelma niin, että käytetään libnet –kirjastoa. Libnetiä käytettäessä kirjassa esiteltiin uusi libnetiä käyttävä send_dns_query –funktio joka tekee DNS queryn sisältävän datagrammin ja lähettää sen. Libnetiä käyttävä send_dns_query ei kutsu udp_write –funktiota, joka kutsui taas useampaa ohjelmaan kuuluvaa funktiota. Libnetiä käyttäessä kirjoitettavaa koodia on vähemmän.

24. Yhteenveto Raw –socketeja käytettäessä voidaan lukea ja kirjoittaa IP –datagrammeja joita kernel ei ymmärrä. Datalink –kerroksella toimiessa voidaan lukea ja kirjoittaa minkälaisia kerroksen frameja tahansa – ei siis pelkästään IP datagrammeja. Eri käyttöjärjestelmissä datalink –kerroksen käyttö voi olla hyvinkin erilaista, mutta esim. libpcap –kirjastoa käytettäessä ei erikoista tarvitse välittää.