I have a few web sites that have certain forum software loaded. What I’m seeing in the logs is post attempts from many IP’s containing certain SID’s. A typical Apache log shows this string (part of it shown):
Where Virus chain is entered by a jump from the forward chain. Yet it does not seem to work, as I’ve seen that SID come through again in the logs. Other filter rules in this chain that do similar things are all working fine (but none have a “content=” rule)
So, am I dreaming this will work, or am I missing something. Could it be that the sid is generated by the PHP and not in the packet? I had tried adding the connection http originally, but now I’m trying without it. I don’t have a lot of these, a few rules will block many false post attempts (74 different IPs have tried this ID for far this month). However, I have to sit and wait for the next hacker to try and post to the forums (forum is not open to public)
The other option is to block by length, almost all these login attempts are 7459 bytes long, whereas legitimate users have slightly different lengths…
What you are trying should possibly work. You should also put dst-port=80 and well as the tcp flags PSH.
Run packet sniffer and see if you can actually see that text within a single packet and not broken up in two pieces, or spread across two packets. If it’s a fragmented packet the content filter will not find it. If its SSL it will not find it.
PS, I think it is better to use mangle and not firewall chain for these types of things. I am not sure what the preference of most others is. Make sure this rule is high enough it’s being hit and not accepted before it hits.
I copied the rule into the Forward chain, and changed it to only log, and it works there, I got one entry already. So, it is in the packet somewhere…
Now to figure out why the same rule in the next chain (Jump to virus) doesn’t pick it up. Could it be some packets are fragmented?
The packet that triggered the log message in the Forward chain was: (my WAN IPs are NAT’d)
13:05:21 firewall,info TEST LOG forward: in:WAN out:LAN1, src-mac
00:e0:14:01:a0:00, proto TCP (ACK,PSH), 76.16.255.133:2203-
>192.168.50.18:80, len 385
Anyway, I’ll experiment a bit more… Any other ideas why it might not work in the next chain, let me know… These login attempts are all the same, so if packets are fragmented, that could be a reason some get missed…
the packet isnt getting that far in the chain probably. Make sure its in the mangle chain and not the firewall filter chains. if you are using a virus chain make sure you are jumping to that chain from the forward chain.
I tried some tests (logging message) in Mangle, and never saw a trigger with various text (content)
My forward chain is short, as per examples, and jumps to virus chain right away. Here is the initial script (first few lines) for my firewall:
/ ip firewall filter
add chain=forward in-interface=LAN1 out-interface=LAN1 action=accept \
comment="Allow traffic between wired and wireless networks" disabled=no
add chain=forward in-interface=LAN2 out-interface=LAN2 action=accept \
comment="Allow traffic between wired and wireless networks" disabled=no
add chain=forward in-interface=WAN content=8b89549151 action=log \
log-prefix="TEST LOG" comment="Test" disabled=no
add chain=forward connection-state=established action=accept comment="allow \
established connections" disabled=no
add chain=forward connection-state=related action=accept comment="allow \
related connections" disabled=no
add chain=forward connection-state=invalid action=drop comment="drop invalid \
connections" disabled=no
add chain=forward action=jump jump-target=virus comment="jump to the virus \
chain" disabled=no
I’ll try Mangle again anyway…
Thanks for the advise.
Well, I tried Mangle, and had to put the content marks in the pre-route tables. I also went to mark-packet instead of mark-connection. Seems data in a HTTP connection is deemed “established” once a connection is made, that is, it is not considered a “new” connection because the original http request is completed, and after that it’s considered established (or related?) Thus, the next packets with the log-on attempts are after “new”.
Any, by marking the packets in Mangle (pre-routing), then doing a test in the forward chain before “established”, I can make the packets jump to a drop chain. In the drop chain, I can check for the marked packets and destination port=80 (or 25 for spam mail content), adding to a block list at that point.
I can now add more Mangle rules up front for more text (content=) and if any unwanted text is triggered, I drop it from any destination that is port 80 or 25.
In summary, my steps are:
Mark packets from WAN with bad content (ie “content=w00tw00t”) in pre-routing in Mangle (before any connection marks, etc…)
In filter rules, test packet marks in Forward chain, before any “established” or “related” rules.
marked packets that match, jump to Drop chain (or drop right now?)
Drop chain again checks marked packet and destination ports, and adds source to blocked-list
This seems to be ok for outgoing packets, like searching google for “w00tw00t” or something similar because destination ports seem to be different (my outgoing ports)