Connection Limiting, etc...

I use MT2.8.21 as Gateway/Cacheing DNS/Proxy Server for an Internet Cafe. Some malicious users often use software to mine/extract email addresses, and then broadcast spam to these email addresses using some other software. Some of the software use non-standard ports with I successfully blocked with a forward rule in the firewall. The problem I now have is with software that use standard ports (80, 25) to extract email addresses and broadcast spam. I notice in the firewall connections that these software make several connections and thereby choke up our Internet access. Is there a way to limit the number of connections each host/workstation can make on MT? Are they steps/configurations I can undertake to prevent the email mining and spam launching? Any/all suggestions will be gladly welcome…

Thanks

Tonnie

At least for port 25 outbound you could probably rate limit them to some small number of syn packets per minute, which wouldn’t effect normal users but would put a limit on a spammer. If they are exploiting external webservers to relay spam through them using the CONNECT command, you could probably flat out block that with a firewall rule or two by watching for that data pattern during an outbound request sequence.

Could you please attach sample instructions/commands to achieve these? Thanks in anticipation of your cherished assistance…

Tonnie

I can’t provide examples, but I can give you a general idea of how I’d try to implement it and you can experiment.

To rate limit outbound SMTP connections on port 25, create a mangle rule that watches for SYN packets outbound to port 25. Then create a queue that limits how many of those can occur in the time period you decide on. You’ll probably want that queue to be based on the source IP also so that the limitation is per customer, not for your entire network.

Blocking attempts to exploit external web servers using the CONNECT command is a similar thing. Create a set of mangle rules that tests outbound traffic to port 80 for the character sequence CONNECT, HTTP/1. and possible other parts of the packet. Link these together so that later rules only match if the earlier rules marked the packet flow in a special manner, that way you can be reasonably sure that you’re actually looking at a http command header that is a CONNECT command. Then simply add a firewall rule that drops any packet that matches the flow specified by the final mangle rule in the sequence.

This same idea can be used to block other kinds of traffic, you could probably look for the HELO, RCPT TO:, sequenced for SMTP commands and block using those also.

There are some problems with this method though, the mangle rules don’t allow data patterns that are regex expressions as best I can tell so you might block CONNECT and a smarter spammer would still abuse you because he used software that sent CoNnEcT. Doing data tests against every packet leaving your router is also going to take extra CPU time, so try to arrange mangle rules so that the least likely pattern of the sequence is what you test for first. Lots of packets will have HTTP/1. in them, but few will have CONNECT in them, so test for CONNECT first and the other rules will be skipped because the flow isn’t marked correctly when their turn to test the packet comes around.

Yeah, there are probably better ways to do this, but I threw this together one day on short notice and it seemed to work.