[C/Linux]Na UDP packet lezen ruw IP packet ophalen

[StM]

Ik ben met een soort filter applicatie bezig. Dit filter komt voor een andere applicatie te staan. Het is de bedoeling om al het verkeer door die applicatie door het filter te gooien. Voor de client of de applicatie mag het echter niet merkbaar zijn dat er een filter tussen zit.

Een schematische weergave:

client connect naar poort x -> server herschrijft het request naar poort x +1 via iptables, hierop draait het filter -> het filter doet zn werkt en als het packetje door mag faked hij een IP packet alsof het van de client komt en stuurt het naar poort x -> de normale applicatie op poort x antwoord terug naar de client.

Dit werkt goed en heb ik gecontroleerd met packet sniffers etc. Het antwoord komt netjes terug bij de client, echter de NAT voor de client snapt het niet want het id seq nr is veranderd. Het orginele seq nr kan ik niet zo achterhalen in het filter. Ik gebruik gewoon 0 in het gespoofde packet. Om de NAT echter te laten werken MOET ik dat seq nr achterhalen.

1 van de oplossingen is een packet sniffer in het filter implementeren..... Ik hoop echter dat dat niet hoeft en dat er een mogelijkheid is om het orginele IP packet terug te halen....

C:

int recievePacket(struct sockaddr_in * cliaddr, char * msg) {
    int n;
    socklen_t len;
    
    len = sizeof(*cliaddr);
    n = recvfrom(sockfd,msg,1024,0,(struct sockaddr *)&(*cliaddr),&len);
    
    msg[n] = 0;
     
    return n;
}

Helaas kan ik hier niks over vinden in de man pagina's etc...

[farlane]

Lijkt me dat je dan een raw socket moet openen.

[StM]

Met een raw socket trek je al het verkeer naar je toe. Op zich kan dat wel maar het zou idealer zijn als ik het van een invidueel packet op kan halen. (+ krijgen andere applicatie's de packetjes wel gewoon?..)

[farlane]

Site.to.Make schreef op zaterdag 30 mei 2009 @ 23:44:
Met een raw socket trek je al het verkeer naar je toe.

Hoe kom je daar bij?

[StM]

Mja zeg ik een beetje verkeerd. Je gaat al het udp verkeer lezen van die machine, maar ik denk dat je gelijk hebt dat dit de oplossing is. Ben iets in elkaar aan het knutselen

[Exirion]

Hou er wel rekening dat het gedrag van raw sockets per platform nogal kan verschillen. Als het alleen op Linux moet draaien hoef je je daar niet echt druk over te maken.

[ Voor 3% gewijzigd door Exirion op 31-05-2009 00:32 ]

[StM]

Het is linux only dus dat is simpel. Ik ben nu ook zover dat ik hem goed uitlees en zover ik kan zien ook goed wegschrijf maar het blijft niet werken *sniffed verder*...

[Exirion]

Site.to.Make schreef op zondag 31 mei 2009 @ 00:54:
maar het blijft niet werken *sniffed verder*...

Wat werkt er dan precies niet. Als je een echte raw socket aanmaakt krijg je al het verkeer voor je kiezen en kun je aan de hand van de headers van de verschillende protocollen bepalen wat voor jou relevant is.

[StM]

Het lijkt erop dat door het herschrijven met iptables hij de source poort in het ip packet veranderd. De source poort gebruik ik om terug te antwoorden. Omdat dat opeens een andere poort geworden is (de x+1) snapt hij het niet als ik wat terug stuur.

Ik begin geloof ik aardig moe te worden dat ik het al die tijd over het hoofd zie....

edit: ook dat is het niet, hoewel ik wel een d en s omgedraait had.... Het is geloof ik tijd om te stoppen en morgen verder te gaan.

[ Voor 16% gewijzigd door StM op 31-05-2009 01:17 ]

[StM]

Goed nieuwe dag verse blik

Dit is een normaal request:

13:17:45.807755 IP (tos 0x0, ttl 58, id 35672, offset 0, flags [DF], proto: UDP (17), length: 42) thuis.adsl.nl.19560 > server.dc.nl.27960: UDP, length 14
13:17:45.807912 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 1181) server.dc.nl.27960 > thuis.adsl.nl.19560: UDP, length 1153

Dit is een gemodificeerd request:

13:18:58.801884 IP (tos 0x0, ttl 58, id 53549, offset 0, flags [DF], proto: UDP (17), length: 40) thuis.adsl.nl.19564 > server.dc.nl.27960: UDP, length 12
13:18:58.802034 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 339) server.dc.nl.27960 > thuis.adsl.nl.1090: UDP, length 311

Het is duidelijk dat het antwoord naar de verkeerde poort gaat. Dit komt ook overeen wat ik in de applicatie zie waarhet request vandaan komt:

R: xx.xx.xx.xx:1090 id: 53547 (12) <data>

Wss komt dit door mn rewrite rule die ik in iptables gebruik:

iptables -t nat -A PREROUTING -p udp -s xx.xx.xx.xx --dport 27960 -j DNAT --to server.ip:27961

Deze NAT hem door. Omdat ik het request via een fake IP packet naar de normale app doorstuur rewrite hij het source adres niet terug. De bedoeling is echter dat de destionation poort veranderd wordt. niks meer niks minder.

Een andere rule die ik geprobeerd heb:

iptables -t nat -A PREROUTING -p udp -s xx.xx.xx.xx --dport 27960 -j REDIRECT --to-ports 27961

Nu verdwijnen de packetjesin het niks. Ze zijn te zien met tcpdump maar komen niet bij de applicatie noch bij het filter.

Ik hoop dat er een methode is om dit te doen, anders ben ik heeeeel bang dat ik een eigen kernel module moet gaan bouwen hiervoor. Ik hoop dat jullie me uit de brand kunnen helpen.

offtopic:
Misschien is een kickje naar NOS nodig? Hoewel als het een kernel module wordt blijft het PRG...

[blaataaps]

Kun je niet met libpcap de pakketjes onderscheppen, en met libnet de herschreven pakketjes weer de wereld insturen? Met libpcap heb je volgens mij alle informatie tot je beschikking, en met libnet kun je ze precies zo schrijven als je maar wil dacht ik.

[blaataaps]

En anders kun je ook nog naar een oplossing als blaataaps in "hoe programma binden op ip" kijken

[Soultaker]

Het probleem met packet capturing (en ook readen van raw sockets) is dat je pakketjes wel kunt uitlezen, maar niet echt kunt onderscheppen. Het lijkt erop dat de TS juist eerst het pakketje wil bekijken, en dan beslissen of 'ie door gestuurd kan worden.

Onder de BSDs (en OS X) zijn divert sockets (zie ipfw en divert) daar ideaal voor. Zo'n soort mechanisme zou je ook moeten zoeken voor Linux. Het enige wat ik zo snel bij elkaar kon Googlen was een kernel patch die support daarvoor toevoegt (en ook een patch voor iptables) maar dan zit je met een custom kernel opgescheept.

blaataaps schreef op zondag 31 mei 2009 @ 14:28:
Kun je niet met libpcap de pakketjes onderscheppen, en met libnet de herschreven pakketjes weer de wereld insturen? Met libpcap heb je volgens mij alle informatie tot je beschikking, en met libnet kun je ze precies zo schrijven als je maar wil dacht ik.

Dan zou je de uitgaande pakketjes in eerste instantie moeten droppen met iptables, anders valt er weinig te filteren, maar dan is de vraag hoe je voorkomt dat pakketjes die je wél door wil laten ook weggefilterd worden?

Wellicht een andere suggestie: kun je de filterapplicatie niet als tunneling applicatie implementeren (met de TUN driver)? Dan hoef je met iptables de interessante pakketjes de tunnel insturen, en in je applicatie stuur je de gewenste pakketjes dan door (uitvoer van de tunnel is dan niet gefilterd).

[farlane]

Soultaker schreef op zondag 31 mei 2009 @ 16:37:
Het lijkt erop dat de TS juist eerst het pakketje wil bekijken, en dan beslissen of 'ie door gestuurd kan worden.

Dat was volgens mij een gevolg van het gebruik van de raw socket, je kunt enkel op protocol niveau aangeven welke packets op je socket binnenkomen.

[StM]

Het is me gelukt op blaadaaps manier door sendto en recfrom te overriden. Bedankt voor de hulp!