On Nov 29, 2006, at 8:43 PM, Richard Feldmann wrote:
Are you using any antispam techniques? RBLs, greylisting, etc?
i should have been more specific, my bad. in this case i'm using a
lwq setup with a few additions like tls, smtp-auth, tarpitting
(tarpitcount=2, tarpitdelay=5). i'm also using russel nelson's qmail-
smtpd-viruscan-1.3.patch (to which i have added 2 or 3 signatures),
which i find extremely efficient. i also use rblsmtpd with
sbl.spamhaus.org (tried sbl-xbl, but that was a bit too aggressive
for my taste, and bounced too many innocent mails).
i use qscanq with clamav. it rejects quite a few phishing mails, but
hardly any virus-infected mails (simply because most of them don't
even get that far - even though this is still during the smtp
session). last week for the first time in about 3 years a virus
actually made it through all the way into a mailbox (ok, at least it
was the only one i know of). half an hour later the clamav virus
definitions were updated. but by that time i had already added the
signature to /var/qmail/control/signatures.
i used to use qmaildcc (for greylisting) and spamassassin with qmail-
qfilter (also during the smtp session). yes, greylisting works really
well. or not... sure - hardly any virus or spam even made it to
clamav or spamassassin. but still there are some applications that
only try to deliver once (like billing systems sending out bills as
pdf via email, trouble ticketing systems, etc). these mails get lost.
also a lot of customers get the feeling that the email service is
unstable - they don't understand that some mails arrive within
seconds and others within hours. the more users you have, the harder
it is to keep your whitelists up to date. besides all that, i don't
really like to exploit a standard this way. if there's an rfc that
says the sending mailserver should retry if it receives a temporary
error, then to me that's an instruction or suggestion about how i
should deal with a temporary error. i don't want all mail to be
delivered like this just to distinguish it from spam.
so i got rid of dcc and also spamassassin. instead i'm using dspam
with maildrop now. my users are getting more spam than before, but it
gets moved to their spam folders automatically, so they don't care.
cpu load actually dropped a bit even though more messages are getting
delivered now.
the spam "attack" i experienced was like so:
tens of thousands of mailservers from all over the world in all kinds
of ip ranges were bouncing spam mails to my server. most of the
bounces i looked at were "no such user", "we don't accept spam", etc.
of course the from: addresses were all forged and bounced to me.
first i thought it was a dictionary attack, but it was really bounces
to random non-existing accounts at a domain i'm hosting on this
server (along with a bunch of other domains).
now, even the validrcptto patch didn't help! so even though all these
spam-bounces were rejected immediately, all my concurrencyincoming
session were used up, and no email could be delivered to the other
domains on this server. i played around with concurrencyincoming
until the server started to run out of resources. since all of these
messages got rejected during the smtp session anyway, i don't think
greylisting would have helped, either. it probably would have made it
worse, because it would have recorded every single connection attempt
to a database.
then i decided to change the mx record and point it to a new server
so i can deal with the problem there, without affecting any other
domains. already a few seconds later the attack moved to the new
server, i was surprised it didn't take any longer.
from then on i had more time to investigate the whole thing. i am
shocked about how many mailservers retry to send bounces even when
you respond with a permanent error! so i changed the setup again.
plain lwq + djbdns, doublebounces and mails to unknown users go to /
dev/null. within 2 days the attack had died down to a level so i
could move everything back to the original server.
I decided to implement the firewall changes listed at http://
okean.com in order to block spam coming from Korea and China. I
did see a reduction, but not a ton since I don't really get
hammered anyway. For you it could be more significant if the bulk
of spam hitting your system(s) are from these regions.
it came from all over the world, and i wouldn't really like to block
entire countries either...
You might want to look at tcpblocker (http://inter7.com/?
page=tcpblocker) from inter7. I don't use it personally, but it
seems useful. There are other solutions that were suggested within
the past several weeks or so, and I think there was a script that
someone posted that would dynamically apply rules to iptables.
tcpblocker looks interesting, i will look into that, thanks! i don't
want to change firewall rules dynamically, but i will definately
check out tcpblocker.
sorry for the long post, and thanks for all the interesting comments!
so long,
randy
|