HTTP-Packets monitoren en aanpassen

[Verwijderd]

Hey tweakers,

Ik heb een zeer ambitieus idee voor een programma dat ik wil programmeren in C, maar het lijkt me heel leuk en uitdagend(dat zeker) om te doen. Ik wil een applicatie maken die HTTP-Packets die de browser verstuurt ontvangt en aanpast. Nu heb ik een beetje gegoogled en er zijn al libraries die packets kunnen monitoren. Om daadwerkelijk packets aan te passen werd zo ongeveer 20 jaar programmeer ervaring aangereden(Dat is meer dan mijn leeftijd =P).

Daarom kwam ik op het volgende idee uit: als ik dus niet de bestaande packets aan kan passen dan moet het maar anders. Ik kan namelijk wel met de LIBPCAP library packets bekijken. Ik kan dan het packet gewoon bekijken>nieuw packet maken die er heel veel op lijkt maar dit keer met de aangepaste data. Enigste probleem is alleen dat het oude packet dat dan eerst verstuurd was ook nog steeds verzonden wordt. Dat het packet verzonden wordt maakt in principe niet uit. Maar ik wil graag het antwoord van het packet dat ik aangepast heb.

Ik denk dat ik om dat te bereiken firefox configureer welk packet hij ontvangt maar dat is zorg voor later. Wat meer mijn vraag was: Kan dit uberhaupt in C? Een packet bekijken en daarna zelf een packet maken dat er heel veel op lijkt en deze versturen?

Ik hoop dat ik mijn vraag een beetje duidelijk heb geformuleerd

[u_nix_we_all]

Ja hoor, dat kan in C.
En hoewel je met libpcap prima pakketjes kunt capturen, en bekijken, lijkt me dat toch niet de slimste weg. Het lijkt mij veel meer voor de hand liggen om dit op ethernet-frame niveau te doen, en dus in de device-driver. Een alternatieve ethernet driver met een mogelijkheid pakketjes aan te passen volgens een bepaald patroon ofzo.

[joppybt]

Even voor de duidelijkheid: je wilt echt op packet-niveau gaan werken en een proxy is niet afdoende? Dat laatst is namelijk veel eenvoudiger (gebruik bijvoorbeeld Fiddler) maar vergt wel dat de gebruiker van FireFox 'meewerkt'.

[Verwijderd]

u_nix_we_all schreef op vrijdag 25 februari 2011 @ 17:07:
Ja hoor, dat kan in C.
En hoewel je met libpcap prima pakketjes kunt capturen, en bekijken, lijkt me dat toch niet de slimste weg. Het lijkt mij veel meer voor de hand liggen om dit op ethernet-frame niveau te doen, en dus in de device-driver. Een alternatieve ethernet driver met een mogelijkheid pakketjes aan te passen volgens een bepaald patroon ofzo.

Ik denk niet dat klaar ben om echt te gaan programmeren op het niveau van de driver. Ik ben veel te bang dat ik daar iets kapotmaak

En omdat te doen moet je toch ook in assembly programmeren?

joppybt schreef op vrijdag 25 februari 2011 @ 17:13:
Even voor de duidelijkheid: je wilt echt op packet-niveau gaan werken en een proxy is niet afdoende? Dat laatst is namelijk veel eenvoudiger (gebruik bijvoorbeeld Fiddler) maar vergt wel dat de gebruiker van FireFox 'meewerkt'.

Het is juist dat een proxy bepaalde HTTP-Packets eruit filtert. Door de packets te pakken>ze encrypten>het destination IP veranderen naar een server bij mij thuis
Kan de proxy niet zien dat het een packet was dat hij eruit moest filteren.

[DiedX]

Maar, call me stupid, waarom zou een proxy dat niet kunnen zien?

[Verwijderd]

DiedX schreef op vrijdag 25 februari 2011 @ 17:42:
Maar, call me stupid, waarom zou een proxy dat niet kunnen zien?

Neenee je bent echt niet stupid Waarschijnlijk slimmer als mij en het kan goed zijn dat ik nu heel fout zit te redeneren.
De software waarmee die proxy draait die blockt http_requests voor verschillende sites. Als ik mijn packets encrypt zodat data als het adres van de site waar je heen wil nu geëncrypt zijn. Dan kan hij er toch niks meer mee? Stel je voor dat www.google.nl geblokeerd is. Als ik dat pakket dan encrypt zodat het IP van google niet 12.13.15.16 of iets dergelijks maar 21312321.21232141.212121321.1242142141 is. Dan denkt die proxy: "Ehh wat een vaag IP maar in iedergeval staat hij niet in mijn lijstje van verboden sites dus lekker laten gaan."

Met de software die ik dan maak voor op de server thuis decrypt ik het IP weer. Zodat de software bij mij thuis weer weet van: "Ohh dus je wou naar 12.13.15.16" en dan stuurt hij mij die terug.

----------------------------------------------------------------------------------------------------------------------------------------------
Enigste probleem waar ik nu mee zit maar wat ik nog wel ga verhelpen is dat als ik het 'destination IP' verander naar mijn server thuis, dat de software thuis dan ook niet meer weet waar ik nou oorspronkelijk heen wou. Wat ik hiervoor in gedachten had was het volgende: Ik wissel gewoon het 'source ip' en 'destination IP' om. Dan hoef ik het ook niet meer te encrypten. Het enigste wat ik dan op mijn server thuis hoef te doen is kijken wat het 'source IP' was en daar een nieuwe HTTP-GET request heendoen.

Maar wat ik me dus wel echt afvraag is kan ik zegmaar zo zeggen in een packet: ja het source-ip was 87.87.83.43? Of zegt er ergens dan iemand: "Ja maar dat is helemaal niet zo want dat is niet jouw IP!"?

[ Voor 38% gewijzigd door Verwijderd op 25-02-2011 17:54 ]

[DiedX]

maar eigenlijk wil je dus naar je eigen IP een vage header sturen? En thuis die header laten proxyen?

Dat klinkt ingewikkeld. Volgens mij kan je beter OpenVPN thuis op 443 draaien, en een client installeren. Dan passeer je de proxy (want gecrypt) totdat de systeembeheerder man-in-the-middle HTTPS af gaat dwingen, of gewoon heel HTTP/HTTPS naar onbekende adressen in /dev/null gooit...

[Verwijderd]

DiedX schreef op vrijdag 25 februari 2011 @ 17:54:
maar eigenlijk wil je dus naar je eigen IP een vage header sturen? En thuis die header laten proxyen?

Dat klinkt ingewikkeld. Volgens mij kan je beter OpenVPN thuis op 443 draaien, en een client installeren. Dan passeer je de proxy (want gecrypt) totdat de systeembeheerder man-in-the-middle HTTPS af gaat dwingen, of gewoon heel HTTP/HTTPS naar onbekende adressen in /dev/null gooit...

Tsja hey, als hij dat gaat doen dan ben ik screwed. Maar zover is het nog niet, en dan verzin ik weer wat nieuws =P

Over dat OpenVPN ga ik nog even nadenken, want ik moet toegeven dat ik nog geen idee heb wat het is en wat het doet

[ACM]

Er bestaan allerlei HTTP-tunneling oplossingen. Ik zou daar eerst eens naar kijken voor je moeilijk gaat doen met zelf dingen schrijven.

Het is natuurlijk wel een interessante uitdaging om het zelf te doen. Maar dan zal je wel een wat beter begrip van onder andere het HTTP-protocol moeten hebben, gok ik zo

[Verwijderd]

Lijkt me wel echt leuk om te doen, ik ben nu ook al een beetje begonnen. Maar de man page van pcap is niet zo daverend. Dus gaat wel wat tijd in zitten

[leuk_he]

Ik heb er ook wel eens naar gezocht, maar zo snel geen kant en klare oplossing voor gevonden.

In de eerste plaats zul je een netwerk node moeten hebben die de mogelijkheid heeft verkeer te onderscheppen en weer door te zenden. Die stap is niet zo heel moeilijk.

In plaats van verkeer low-level aan te passen is het wellicht veel simpeler een tranparante proxy in te richten en in de proxy het verkeer aan te passen. Dat kan met kant en klare open source software (linux+ linux firewall + squid proxy): zoiets

http://www.cyberciti.biz/...nt-proxy-squid-howto.html

Vervolgens zul je in de proxy een module moeten laden die niet alleen logt, maar ook aanpassingen doet in de content.

alt tekst verwijst naar:


http://www.ex-parrot.com/pete/upside-down-ternet.html

waar alle plaatjes op de kop worden gezet.. have fun.

Wel een beetje off topic geworden wat betreft programmeren, maar wellicht heb je wat meer aan de goede stapjes in dezefde richting ipv proberen low-leve in te grijpen op osi nivo 2/3

[Verwijderd]

OSI Niveau 2 is inderdaad wel vrij laag . Dat is echt zeker een goeie deze ga ik eens goed overwegen. Ik heb Squid al gedownload, het grappige is dat de proxy die de content er nu uit filtert ook squid is

[Soultaker]

Zolang je dit soort dingen bedenkt:

Verwijderd schreef op vrijdag 25 februari 2011 @ 17:49:
Ik wissel gewoon het 'source ip' en 'destination IP' om.

Zou ik me nog maar niet op een al te low level oplossing storten.

Afhankelijk van wat voor internettoegang je nu precies hebt en wat je precies wil bereiken, zou ik toch overwegen een HTTP proxy op een vage poort, of een VPN, of een ssh-tunnel of iets dergelijks te gebruiken, in plaats van je eigen netwerkprotocol te gaan ontwikkelen.

[Verwijderd]

Soultaker schreef op zaterdag 26 februari 2011 @ 16:07:
Zolang je dit soort dingen bedenkt:

[...]

Zou ik me nog maar niet op een al te low level oplossing storten.

Afhankelijk van wat voor internettoegang je nu precies hebt en wat je precies wil bereiken, zou ik toch overwegen een HTTP proxy op een vage poort, of een VPN, of een ssh-tunnel of iets dergelijks te gebruiken, in plaats van je eigen netwerkprotocol te gaan ontwikkelen.

Vandaar deze regel:

Maar wat ik me dus wel echt afvraag is kan ik zegmaar zo zeggen in een packet: ja het source-ip was 87.87.83.43? Of zegt er ergens dan iemand: "Ja maar dat is helemaal niet zo want dat is niet jouw IP!"?

Maar zoals gewoonlijk mag duidelijk zijn dat ik weer eens iets te ambiteus was

[leuk_he]

Verwijderd schreef op vrijdag 25 februari 2011 @ 17:49:
[...]

De software waarmee die proxy draait die blockt http_requests voor verschillende sites. A

oh deze effe over het hoofd gelezen..

https://calomel.org/firefox_ssh_proxy.html

heb je dus een sshd nodig buiten de firewall, welke je gratis voor alle OSén kunt krijgen.