Stopping ISP customers from sending spam
This article is for ISP email administrators who have a problem with spam originating from their customers.
This article discusses using the tcpblocker program. Administrators looking for solutions should also look at the spam throttle patch for qmail.
The tcpblocker program uses a simple technique of blocking an IP for a duration of time if they make too many smtp connections. This simple trick works surprisingly well against customer machines that are infected with spam zombie programs.
I first ran into this problem when the ISP I was helping administer got listed on spam block lists like spam cop or spam haus. This was acommpanied by users complaining of email not getting delivered.
We installed tcpblocked on the qmail smtp service. It runs every 5 minutes and counts all the connections for the last 30 minutes. If an IP or optionally a C class has too many connections then we put a temporary block on the IP.
To make life simple there are some plain text configuration files exclude list - list of IPs to never block permenent list - standard tcpserver tcp.smtp file with list of all customer IPs with relay client enabled and remote black hole lookup disabled
output block list - generated list of IP blocks. This can be handy when checking what IP blocks are currently in place.
tcpblocker uses Dan Bernstein's standard TAI64 (64 bit time stamp) format that multilog likes to log with. The file parsing code was borrowed from qmailmrtg which optimized which files to parse based on the time period of interest.
Question: Is a service restart required? Answer: No. tcpserver reads the tcp.smtp.cdb file, which is a constant database file format devised by Dan Bernstien to optimize disk reads to a maximum of 2 for looking up any information even in large files. Each connection to the tcpserver hosted smtp services causes tcpserver to open the tcp.smtp.cdb file. Tcpblocker uses the standard tcprules program which utilizes the atomic file rename operation. Long answer short, the changes get applied immediately.
On the machine we were working on the results were successful enough to stop enough customer spam mail to get us cleared from the black hole lists. I was actually suprised by the results. We did some guessing and tweaking of the parameters but over all it works well enough. I do see some spikes where someone starts a blast and it runs for 10 minutes or so before getting shut down.
One other odd result was that did not see senders re-attempting a blast after the time period was over. We saw that behavior on a different machine. This time we used sample period of 30 minutes with a 30 minute shutdown.
We use qmailmrtg to graph all the qmail statistics. The historical graphs allowed us to see when the problem started and it's effects on the system. And we could see when tcpblocker closed down the offenders.
One thing we notices was the qmail queue size would balloon when an offender was in the process of sending. As they stopped the queue size would slowly drop.
Question: How can I easily see if we have a problem Answer: Either your queue will drastically jump in size from, say a few hundred into the thousands or higher. Or you see spam block URL status message returns from the remote servers in the qmail-send log files.
Be sure to ask to be removed from any block you are on. Read over your qmail-send logs. Blockers usually report a URL you can follow to find who blocked you and request removal.
Make sure what ever solution you put in place actually solves the problem before requesting removal. Otherwise you will have to go through the same process again. And some of those sites will only remove you a few times before giving up on you.
This also helped stop external servers from sending email blasts to customer accounts. All of the email we caught that was being blocked was spam. So we liked this side effect.
All the code is written in C and shares code from the qmailmrtg project and Dan Bernstiens cdb and tai64 code examples.