Re: blacklists
On Fri, Dec 10, 2004 at 11:20:28AM -0700, Michael Loftis wrote:
> >i certainly wouldn't recommend running it on a large installation.
> >i'm surprised you even tried.
>
> Well, we're very anti-spam, and willing ot try anything to help...I
> had to disable it after we got around ~8K rules in the tables on that
> box, that ended up causing the system CPU time to go through the roof.
> Though it was very effective. :)
i guess what it needs is something that can merge addresses into a CIDR range.
e.g. if it sees x.y.z.1 through to .8, it should merge them all into a /29.
delete the individual /32 rules and replace them with the /29.
managing that would get fairly complicated, especially when it has to later
merge a few /29s and /32s into larger blocks. but it should be doable. if i
get time, i'll think about how that might be implemented.
the simpler thing is to just uncomment the /24 stuff that's already in there,
and block the entire /24 rather than just the offending host. heavy-handed
but it should reduce the number of entries in iptables.
hmmm. one useful optimisation here would be to use Net::DNS to find out whether
the IP is in a DUL - and if it is, then block the entire /24. i reject all mail
direct from dynamic/dialups anyway so it wouldn't hurt anything. (and remember
to add your own dialup pools to @whitelist :)
another thing it should do is add the rules to a SPAMMERS table, rather than to
the main INPUT table. that would be a trivial change, only a few minutes work.
...done.
new version now published:
# v1.8 - changed to use SPAMMERS table rather than INPUT.
# use --syn when adding iptables rules, to avoid hanging smtpd processes
#
# the SPAMMERS table should be set up like this (BEFORE this script is run):
#
# # create SPAMMERS table
# iptables -F SPAMMERS
# iptables -X SPAMMERS
# iptables -N SPAMMERS
#
# # send all INPUT & FORWARD packets to the SPAMMERS table
# iptables -I INPUT -j SPAMMERS
# iptables -I FORWARD -j SPAMMERS
#
# FORWARD rule needed only on gateway/router boxes, not normal hosts.
#
# you could optionally create a SPAMDROP table too, which logged the packet
# with a "SPAMMERS" prefix before dropping it....but that kind of defeats the
# purpose of this script which is to remove spammer noise from the logs.
> I've made a few modifications already, including making everything
> persistent and making it purge SEEN entries after not seeing a host
> for 24hrs (this also effectively caps any block time to being 24hrs).
> I might just set it so that it only watches our MailScanner and blocks
> the IPs it reports as sending virii. That would probably help to
> shrink the number of reports a lot, and help with my virus load.
> That'd be a good site-wide table to share (we use central mysql maps a
> lot).
diff -u ???
> >one of the things i wrote was a script which i could bounce spam to.
> >it would then parse the sender addresses and add it to a database of
> >spammers....and sent copies of each spam to a random subset of the
> >database. that infuriated them and amused me no end. my intention
>
> Now that's a heck of a tactic LOL :)
oh yes, i forgot the most amusing thing about it. it not only sent it to a
subset of the spammer database, it also used random addresses out of that db as
the envelope and header sender addresses, so that they'd complain at each
other.
craig
--
craig sanders <cas@taz.net.au> (part time cyborg)
Reply to: