How to write a rule to drop malicious packets?

[haohaolee]

Background:
My ISP is doing evil, it will randomly insert malicious packets to my HTTP connections to hijack my browser and push their advertisements.

The process is: When you send out a Get request, ISP will immediately return a packet which contains a iframe pointing to my target before the real packet attends, so the result is I can browse the website I want but with annoying advertisements.

Currently I'm trying to complain this but at the same time, I want to know if there is a way to identify such kind of packet and then drop it with PF.

http://pastebin.com/QRtvCApq here is my tcpdump capture of the whole hijack process, in which there is a packet with TTL 49 I think is fake packet.

 

[ecazamir]

AdBlock Plus can't help ?

 

[gkontos]

Background:
My ISP is doing evil, it will randomly insert malicious packets to my HTTP connections to hijack my browser and push their advertisements.

The process is: When you send out a Get request, ISP will immediately return a packet which contains a iframe pointing to my target before the real packet attends, so the result is I can browse the website I want but with annoying advertisements.

Currently I'm trying to complain this but at the same time, I want to know if there is a way to identify such kind of packet and then drop it with PF.

http://pastebin.com/QRtvCApq here is my tcpdump capture of the whole hijack process, in which there is a packet with TTL 49 I think is fake packet.

The only way for your ISP to do this is to use a transparent proxy. I don't think that a network firewall would help here because it all happens in the application layer.
You can either tunnel your traffic or change ISP.

 

[haohaolee]

AdBlock Plus can't help ?

1. It depends on browser.
2. what's more, the iframe still exists even if advertisements do not show up, this sometimes influences the browsing experience and web dev much.

 

[haohaolee]

The only way for your ISP to do this is to use a transparent proxy. I don't think that a network firewall would help here because it all happens in the application layer.
You can either tunnel your traffic or change ISP.

Not all in application I think, I found some characteristics of such kind of packets:

1. in IP header, the fake packet has its TOS(type of service) set to 0x10, meaning minimize delay and has different TTL.
2. in TCP header, the fake packet has its flags set to FIN PSH ACK.


All I want to know is "Is this enough to distinguish normal ones from fake ones?"

 

[kpa]

Not really, it's not an easy task to inject fake TCP packets into an established connection like you're implying. I have a hard time believing that your ISP would have the competence to do so, besides it's much easier to achieve what they are doing with just a forced proxy that adds the extra content.

 

[haohaolee]

Not really, it's not an easy task to inject fake TCP packets into an established connection like you're implying. I have a hard time believing that your ISP would have the competence to do so, besides it's much easier to achieve what they are doing with just a forced proxy that adds the extra content.

I'm sure they do tricks in IP layer and TCP layer. If you know I'm from the country which built the largest censoring network in the world, you may believe they have the techs and motivations to do so. sigh...

 

[ecazamir]

If you try to identify and drop some packets from a TCP session, most likely those packets will be resent later and dropped again, leading to timeouts and/or dropped connections, I assume this is not what you want.
Your ISP is modifying the contents of the entire TCP transmission, at the application level. This IS usually done with a transparent proxy server.

 

[haohaolee]

If you try to identify and drop some packets from a TCP session, most likely those packets will be resent later and dropped again, leading to timeouts and/or dropped connections, I assume this is not what you want.
Your ISP is modifying the contents of the entire TCP transmission, at the application level. This IS usually done with a transparent proxy server.

Thanks for your concern.

I don't know what technology they use, but I can confirm that if I drop the fake packet the real response would attend because the key of this tech is the fake packet attends *FIRST*, so the browser drops the latter one.

I'm so sure because my friend uses a Linux box with IPTABLES to drop fake packets successfully, but I want the same effects on my FreeBSD box.

 

[Crivens]

If everything fails, try to use https. But after thinking a bit about your answer w.r.t. where you are from: Is such knowledge, such information about how to manipulate web traffic without Joe Sixpack even suspecting, not something that sounds terribly "usefull for terrists"? *hint hint*

 

[drhowarddrfine]

There are a number of unscrupulous ISPs that do such things. Usually they are scum operators and the best thing to do is find another. Most don't do such underhanded things.

 

[wblock@]

Thanks for your concern.

I don't know what technology they use, but I can confirm that if I drop the fake packet the real response would attend because the key of this tech is the fake packet attends *FIRST*, so the browser drops the latter one.

I'm so sure because my friend uses a Linux box with IPTABLES to drop fake packets successfully, but I want the same effects on my FreeBSD box.

Get a copy of the rules from him and surely there are people who can translate it to PF.

 

[haohaolee]

If everything fails, try to use https. But after thinking a bit about your answer w.r.t. where you are from: Is such knowledge, such information about how to manipulate web traffic without Joe Sixpack even suspecting, not something that sounds terribly "usefull for terrists"? *hint hint*

Honestly speaking, I'm from China and the ISP is ChinaTelecom. Actually many people have encountered this, a Joe Sixpack may just bear it because he does not know what's going on under the hood, on the other side many IT guys do know and have called them for complaint. The problem is: Sometimes somewhere they apologized and set you free (however they always come back if you don't keep complaining), but many of us couldn't get meaningful response from them, and it will take much time and money to play with them. What's worse? We don't have many choices, The ISP I use is still the best choice for the better bandwidth and speed. I don't want to go deeper for why all the things here work like this because it's a huge topic.

 

[haohaolee]

Get a copy of the rules from him and surely there are people who can translate it to PF.

After checking that rule I found one thing: the rule involves a string match which I think is a Layer7 functionality.

Now I realize PF cannot provide this kind of checking.

Thanks all the same.

 

[gkontos]

After checking that rule I found one thing: the rule involves a string match which I think is a Layer7 functionality.

Now I realize PF cannot provide this kind of checking.

Thanks all the same.

Now I am getting even more curious to see that layer 7 IPTABLES rule.

 

[haohaolee]

Now I am getting even more curious to see that layer 7 IPTABLES rule.

Okay here it is:

iptables -I FORWARD -p tcp --sport 80 --tcp-flags FIN,PSH,ACK FIN,PSH,ACK -m tos --tos 0x10/0x3f -m string --algo bm --string "hijack keyword" -j DROP

The keyword is something in the HTTP section of the packet

 

[Crivens]

Honestly speaking, I'm from China and the ISP is ChinaTelecom.

Ok, that changes a lot. I thought you were from GB where they try to make George Orwell into a nursery story. There, the possesion of information which may be useful for terrorists can land you before the judges.

I don't want to go deeper for why all the things here work like this because it's a huge topic.

I know, I have friends from there.

 

[ecazamir]

Thanks for your concern.

I don't know what technology they use, but I can confirm that if I drop the fake packet the real response would attend because the key of this tech is the fake packet attends *FIRST*, so the browser drops the latter one.

I'm so sure because my friend uses a Linux box with IPTABLES to drop fake packets successfully, but I want the same effects on my FreeBSD box.

I looked again to your traffic dump at the link you provided. I've seen no evidence of any 'double packet' in response to the legitimate TCP connection. Instead, i've seen some iframe+javascript page, which instructs your browser to load some supplemental javascript content (if certain conditions are met) from a server (http://61.183.0.83:9999). Rejecting connections to this server will block the extra javascript, but won't get rid of the first iframe set.

Considering this, you can simply block the "javascript content" server with your preferred firewall.

 

[haohaolee]

I looked again to your traffic dump at the link you provided. I've seen no evidence of any 'double packet' in response to the legitimate TCP connection. Instead, i've seen some iframe+javascript page, which instructs your browser to load some supplemental javascript content (if certain conditions are met) from a server (http://61.183.0.83:9999). Rejecting connections to this server will block the extra javascript, but won't get rid of the first iframe set.

Considering this, you can simply block the "javascript content" server with your preferred firewall.

Sorry maybe I have misguided you guys. If you take a look at the dump again, you can find a packet with flag RESET at about line 161. If I analyzed it correctly, the whole process should be: When the fake packet attend before the real one, the browser would give a response, but this would confuse the web server because of inconsistent seq number or something else, so the web server send a RESET packet to the browser. But if dropping the fake one, the connection won't be reset. I am not sure why the real packet didn't appear, maybe it just haven't been sent out.

If I am wrong please correct me. Thanks.

 

[haohaolee]

Ok, that changes a lot. I thought you were from GB where they try to make George Orwell into a nursery story. There, the possesion of information which may be useful for terrorists can land you before the judges.


I know, I have friends from there.

This issue might not be considered as a sort of censorship because of the apparent commercial behaviors, but it does show how the individual's rights aren't protected. Off topic.

 

[ecazamir]

Sorry maybe I have misguided you guys. If you take a look at the dump again, you can find a packet with flag RESET at about line 161. If I analyzed it correctly, the whole process should be: When the fake packet attend before the real one, the browser would give a response, but this would confuse the web server because of inconsistent seq number or something else, so the web server send a RESET packet to the browser. But if dropping the fake one, the connection won't be reset. I am not sure why the real packet didn't appear, maybe it just haven't been sent out.

If I am wrong please correct me. Thanks.

What would you expect to arrive AFTER some HTTP content ending with this:

var.s=document.createElement("script");
s.src="http://61.183.0.83:9999/file/2011/08/201108101656564e4247d811df8.js?"+"rnd="+Math.random();
document.body.appendChild(s);
</script>
</body>
</html>

Is the reset packet unexpected ?

 

[haohaolee]

What would you expect to arrive AFTER some HTTP content ending with this:

var.s=document.createElement("script");
s.src="http://61.183.0.83:9999/file/2011/08/201108101656564e4247d811df8.js?"+"rnd="+Math.random();
document.body.appendChild(s);
</script>
</body>
</html>

Sorry, I didn't get what you meant. I mean, when the browser gets the fake html content you mentioned above, it should send a ACK packet back to the server, but it's a ACK to the fake packet, so the web server then sends a RST packet.

Is the reset packet unexpected ?

Yes, it's unexpected.

 

[ecazamir]

If you want to block the packets containing the Reset flag, the pf rule might be:

table <me> { self }
block in on fxp0 proto tcp from any port 80 to <me> flags R/R

More info on that can be found here.

 

[gkontos]

Okay here it is:

iptables -I FORWARD -p tcp --sport 80 --tcp-flags FIN,PSH,ACK FIN,PSH,ACK -m tos --tos 0x10/0x3f -m string --algo bm --string "hijack keyword" -j DROP

The keyword is something in the HTTP section of the packet

I see what you mean. No, there is nothing similar in PF.
However, I wonder if something like this can really work.

If you can't find a reliable ISP then, depending on your budget, you can set up an openvpn server at a different country and route all of your Internet connection there.
Sorry, this is the only thing that comes to my mind!

 

[haohaolee]

What would you expect to arrive AFTER some HTTP content ending with this:

var.s=document.createElement("script");
s.src="http://61.183.0.83:9999/file/2011/08/201108101656564e4247d811df8.js?"+"rnd="+Math.random();
document.body.appendChild(s);
</script>
</body>
</html>

Is the reset packet unexpected ?

If you want to block the packets containing the Reset flag, the pf rule might be:

table <me> { self }
block in on fxp0 proto tcp from any port 80 to <me> flags R/R

More info on that can be found here.

I said it's unexpected because it wouldn't appear in a normal connection, but dropping the reset packet does not solve this issue. All I want is a rule like the iptables rule I gave to identify the packet containing the above html content and drop it.

Now I know it cannot be that easy by using PF, never mind. Thanks you all the same.