[Mimedefang] Blocking spam senders using IPTables?
pmurphy at ionixpharma.com
Wed Nov 3 12:01:38 EST 2004
> Probably not a good idea, since you don't know how big is remote network
> block. It might be something like /24, but it also might be something
> like /29. If you blindly assume it is /24, you'll get the spammer
> blocked (maybe, it just might be that one of your users had .forward
> file at remote site, and you can't know that either), but you will also
> penalize everybody else.
My approach is to arbitrarily look across the last octet, work out the
distribution of the addresses which are sending spam, and then take action to
block any address within one standard deviation of the average octet value.
Whether the network is /24 or /29 doesn't matter, until two /29 blocks which are
in the same /24 both start sending me spam which triggers this check, in which
case, yes it is possible that someone in the middle gets burned.
As examples, here is one block which has been sending me spam:
All I can assume is that since all of these addresses are sending me the same
type of spam (recipient address in the subject, mainly consumer electronics or
casino related), they must be owned by the same people. A check with WHOIS says
the whole range is owned by Vendare (VENDARE-EMAIL), but I can't assume they
haven't subnetted and sold on addresses in blocks. However, I do know the
extent (16 - 63), and I can assume that they own all of the addresses in that
range. However, if they owned 1-64, and someone else has 65-128, and I got a
spam from 66, I might assume that their range was 1-66, and accidentally block
To counter this, I use the average +/- one SD, which in this particular case
gives a range from 27 to 56, so I block all known spammer addresses, and also
every address between 27 and 56. If I add an entry for 66, the average changes
from 41.25 to 42.03, the SD from 14.18 to 14.60, and the range changes to be 27
If I add a single spammer at 126.96.36.199, the results are dramatically
different - the range becomes 8 to 88, which is not good. The reason is because
the average is based on an assumption that we have only one entry per IP
address, but of course it will be weighted based on the number received from
each address, so if the spammer range is showing up to 10 spam messages per
address, and the outlier is showing 1, this sort of skewing should not happen.
Also, by keeping a spam/ham count for every IP address we see, it would be
possible to also check whether any predicted spammer addresses were in fact
known to us for sending legitimate mail. This also allows for .forward files
from MSN, Yahoo, etc plus mailing lists which occasionally carry Spam - if we
receive 1000 legitimate e-mails and 5 spams, the total for this domain is -995
which would not trigger the IpTables block at +10.
Storing this data in a database table with spam and ham counts per IP address
per day/week and then summing over the last week/month to get a current ham/spam
ratio per IP would be relatively simple. Expiring old totals would be
necessary, but also simple. Perhaps once per hour, the ratio would be
calculated for each IP, the IPTables list updated to reflect any changes, and a
notification sent to the administrator with a list of the changes made, and the
domain names of any systems now blocked.
Head of Informatics
Ionix Pharmaceuticals Ltd
418 Science Park, Cambridge, CB4 0PA
Tel. 01223 433741
Fax. 01223 433788
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to which they
are addressed. If you have received this email in error please contact
the sender or the Ionix IT Helpdesk on +44 (0) 1223 433741
More information about the MIMEDefang