Home › Forums › Discussions › Support › Redirect after filter on packets
- This topic has 9 replies, 2 voices, and was last updated 19 years, 3 months ago by
Vadim Smirnov.
-
AuthorPosts
-
November 7, 2005 at 9:13 am #4954
Hello,
I’m new to network programming and I need some pointers on how to solve my problem.
I’m using BCB6 to develop a simple firewall to filter packets on IP adresses on port 80. This works great but there is still one little problem to solve.
After filtering a packet, I want to redirect the user to another IP adress (website). This website contains a html file with a warning.I’ve walked through this forum but found no topics with some simple redirect examples. I’ve tried the code to change the ip of the packet and than recalc the checksums but the application just resents the same packet (with the old IP address). After a while the connection is timed out. I found a topic on this forum which eplains why this happens.
Should I change the packet or just create a new one for the new IP address and drop the old one ?
Problem is that this should work on any type of internet connection .. not just mine. 😉
Please help ….
many thanks
November 7, 2005 at 11:15 am #5834Lets assume that you want to redirect user from IP1 to IP2. In order to do so you must do the following:
1) For the outgoing packet change destination IP from IP1 to IP2 and recalcuilate IP checksum. Save the connection state (IP’s, TCP ports).
2) For the incoming packet check if it is from IP2 and if yes also check port information (to be sure that this packet is associated with redirected connection). After this substitute source IP from IP2 to IP1 and recalculate IP checksum.
3) And so on… For the outgoing packets use 1) and use 2) for incoming.
November 14, 2005 at 3:14 pm #5835Sorry for my late response …
thanx for this because it works like a charm 😀
But … what happens if the client uses a proxy … can I use the same method ?
November 14, 2005 at 5:08 pm #5836In case of proxy packet directed to IPproxy (where IPproxy is the proxy IP address). You still can redirect packets from IPproxy to your IP (I assume you fully control this system) and process it by your own proxy.
Another possible approach is parsing/modification of HTTP(DNS) packets payload but it’s a bit more complicated.
December 1, 2005 at 4:32 pm #5837After some struggling with the redirect of the packets (and it works) I am certain now I need to parse the DNS and modify the record to redirect the user. This because filtering (and redirecting) on IP adres is not failsafe. A domainname can have more ip-addresses …..
I’ve succeeded in getting to the DNS request structure from the send packet.
I’m not so lucky in altering the packet; this is logical because the redirect packet is greater in size than the original. This is where i get stuck.
I think I need to create a totally new packet with the correct DNS data. When I filter a packet which has to be redirected I copy the packet (except for the DNS), modify the etherheader size, ip-size and recalc the IP-,TCP- and UDP checksums …
Is that the correct way ? and … if you could please assist me do you have some example code to create a new packet ?
Many thanks
December 1, 2005 at 8:02 pm #5838In case of DNS you can form a new packet and replace the original one with it. It’s pretty easy to do because DNS works over UDP. However, the same trick with TCP packet is much more complex. Packets in TCP stream has sequence and aknowledgement numbers which are incremented to the amount of data payload in the packet. So if you change data length you must also track changes in SEQ and ACK fileds.
December 2, 2005 at 7:11 am #5839Thank you serpentfly for your great support.
But … I’m just a little bit stuck on the altering of packets. As I stated earlier I now do have access to the udp/dns packet.
When I ‘overwrite’ the dns packet, can I do this within the already allocated buffer (by winpkfilter) OR do I need to create a totally new buffer. If so I do not have a clue how …. do you have an example ?
After altering the udp/dns packet I have to change the length of the UDP, TCP/IP packet too … is this correct ?
I could also wait on the response dns and change the IP address of the dns-answer packet. Is this easier to do ?
Thanks
December 2, 2005 at 4:05 pm #5840When I ‘overwrite’ the dns packet, can I do this within the already allocated buffer (by winpkfilter) OR do I need to create a totally new buffer. If so I do not have a clue how …. do you have an example ?
You can do this in the already allocated buffer. Actually, packet buffer is allocated by you, passed to WinpkFilter, which copies packet data into it and returns buffer to you. You can do anything with the packet but don’t forget to adjust packet length and recalculate requred checksums (UDP and IP in case of DNS).
As for the sample, Internet Gateway makes DNS redirect, it may help a bit. However, it does not modify DNS data, only packet header.
In case of DNS hijacking the easiest way is changing IP in the DSN response packet. You are right here.
December 7, 2005 at 9:28 pm #5841Well, I’ve ‘crafted’ a correct dns request packet but the following problem occurs.
Modifying the dns request is done by altering the domainname together with altering the length of the udp and ip packets (including calculation of the checksums). This should be ok otherwise redirected packets which are smaller would not work either.
Logging the packets with ethereal shows that :
1) if the new packet is smaller than the original (shorter domainname) the request is ‘valid’
2) if the new packet is larger than the original I get ‘mailformed packet’What am I doing wrong here ? Ethereal shows that the length of the frame is not altered xxbytes on wire, xx bytes captured); should I modify this too ? And if so … how can I do that ?
December 8, 2005 at 9:01 am #5842Do you also properly adjust DNS records length? (See dnsr_rdlength in the dns_record structure on the following link http://www.chiark.greenend.org.uk/ucgi/~richardk/cvsweb/dns/dns.h?rev=1.8&content-type=text/x-cvsweb-markup)
-
AuthorPosts
- You must be logged in to reply to this topic.