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 <[EMAIL PROTECTED]> (part time cyborg) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
