# How to write a rule to drop malicious packets?



## haohaolee (Nov 16, 2011)

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 (Nov 16, 2011)

AdBlock Plus can't help ?


----------



## gkontos (Nov 16, 2011)

haohaolee said:
			
		

> 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.
> ...



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 (Nov 17, 2011)

ecazamir said:
			
		

> 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 (Nov 17, 2011)

gkontos said:
			
		

> 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 (Nov 17, 2011)

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 (Nov 17, 2011)

kpa said:
			
		

> 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 (Nov 17, 2011)

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 (Nov 17, 2011)

ecazamir said:
			
		

> 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 (Nov 17, 2011)

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 (Nov 17, 2011)

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@ (Nov 17, 2011)

haohaolee said:
			
		

> 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 (Nov 18, 2011)

Crivens said:
			
		

> 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 (Nov 18, 2011)

wblock@ said:
			
		

> 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 (Nov 18, 2011)

haohaolee said:
			
		

> 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 (Nov 18, 2011)

gkontos said:
			
		

> 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 (Nov 18, 2011)

haohaolee said:
			
		

> 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. 



			
				haohaolee said:
			
		

> 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 (Nov 18, 2011)

haohaolee said:
			
		

> 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 (Nov 18, 2011)

ecazamir said:
			
		

> 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 (Nov 18, 2011)

Crivens said:
			
		

> 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 (Nov 18, 2011)

haohaolee said:
			
		

> 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 (Nov 18, 2011)

ecazamir said:
			
		

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



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 (Nov 18, 2011)

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 (Nov 18, 2011)

haohaolee said:
			
		

> 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
> ...



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 (Nov 18, 2011)

ecazamir said:
			
		

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





			
				ecazamir said:
			
		

> If you want to block the packets containing the Reset flag, the pf rule might be:
> 
> ```
> table <me> { self }
> ...



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.


----------



## wblock@ (Nov 18, 2011)

Seems like AdblockPlus still might be able to deal with the HTML with a sufficient regex.  Or maybe run a local proxy just to do that.

It would be worth asking on the pf mailing list.  If the latest version of pf can't do it, they might consider adding it, or suggest a different way to accomplish the same thing.  Note that FreeBSD's version of pf usually lags behind the newest version.


----------

