spamd flooded, problem solved [was: Re: : : : Zombie Network Spam Attack]
Top posting, for the archives...
Problem probably solved. There has been a new spam backscatter
flood, and this time it had no impact on my server's network
connectivity. Spamd did just fine. It now runs with the
flags -B 300 -c 400 -S 30 -s 3 (among others) and they
brought down the network load to a totally acceptable level.
Thank you all that contributed to the solution!
PS: It appears the spammers have got new software for
generating names. My mailserver logs show lots of
fake names I have not seen before in a new style a'la:
Abdul.Hutchison
AbdulballastBender
AbdulballastJoyner
AbdulboxwoodRowland
AbdulboxwoodStein
AbdulcivilianGalloway
AbdulconvairBenjamin
AbdulcoordinateGalloway
AbdulcoordinateHester
AbdulcummingsMercer
AbduldebtorStein
AbduldrownMelendez
AbduleggshellRowland
AbdulforcefulSykes
AbdulgastronomeSykes
AbdulgenreMercer
AbdulharvestMelendez
AbduljudiciaryDillon
AbduljudiciaryMelendez
AbduljugoslaviaHester
AbdulmattockHester
AbdulphilosophySykes
AbdulpulsarOsborn
AbdulrepertoireStout
AbdulshoreMercer
AbdulshorePotts
AbdulsophomoricStein
AbdultraffickingFranco
AbdulutrechtSykes
AbdulvacationlandHester
AbdulvaliantAguirre
On Wed, Feb 13, 2008 at 11:32:28AM +0100, Raimo Niskanen wrote:
On Mon, Feb 11, 2008 at 11:33:47AM -0500, Calomel wrote:
On Mon, Feb 11, 2008 at 11:17:35AM +0100, Raimo Niskanen wrote:
On Fri, Feb 08, 2008 at 11:20:31AM -0500, Calomel wrote:
Raimo,
Can you use the spamd.alloweddomains to whitelist email addresses and
domains you accept mail for? Any email sent to your mail server that is
not
on the list will only goto spamd and never get the chance to be
greylisted/whitelisted. Then you could write a simple script to look
through the spamd logs of BLACK entries.
Well, that was already done. All incoming backscatter was to a valid
domain.
If you can compile a list of valid email address this might help. Instead
of @example.com you could list [EMAIL PROTECTED], [EMAIL PROTECTED] Any
server
sending to an invalid address would be blacklisted and a script could add
those ips to a pf block table.
I have now improved the greyscanner script to look up hosts that
send a DSN (sender is empty) and check that they resolves through
DNS both back and forth again to the right IP address.
It is just at little improvement, but catches a few more hosts.
cat /var/log/daemon | grep spamd | grep BLACK | awk '{print $7}' | sort
| uniq
The problem seemed to be that spamd overloaded the network connection.
If spamd is sending to many packets back try increasing the stutter time
-S90 and the stutter speed -s5. At 600 connections total and 600
packets per 5 seconds the network would need to handle 120 packets per
second each direction; around 180 kilobytes in each direction. This might
still need be too much bandwidth, but you could increase the values as
needed or decrease the amount of connections spamd will accept with -c.
maxcon may not exceed kern.maxfiles - 200, and defaults to 800.
I will certainly try this. I guess -S90 will not do much since most of
the conversion tail (after stutter) will go in one packet anyway, but
-s2 should halve the packet load, and -s5 fiftve(? i.e 1/5). -c 400
should also decrease the load, but I have a firewall rule for that
now that should do the same but more lightweight since the
TCP stack is not involved.
...and add the offending ips to a block table with a cron job running a
few
times a day. This page might give you some more ideas:
Spamd tarpit/greylisting anti-spam how to (spamdb)
http://calomel.org/spamd_config.html
I will have a look at it. Thank you for the ideas.
--
Calomel @ http://calomel.org
Open Source Research and Reference
On Fri, Feb 08, 2008 at 11:07:15AM +0100, Raimo Niskanen wrote:
Apparently we (our mail server) got targeted by a zombie network
since suddenly there were some 3 hosts on spamd's whitelist,
continously some 600 connections to spamd, and only mails to
unknown users coming in. The network connection was flooded,
the web server sluggish, downloads creeped, basically
nothing worked.
Can spamd do anything about zombie hosts? They behave like
normal MTAs so they will pass spamd's behavioural tests, right?
Now I analyze the greylist, do some heuristics on the
sender address (among other things) and trap the bad hosts.
The trapped hosts are then copied to a pf table to be blocked
in the firewall. Tarpitting them through spamd is simply
too much work for the mail server, but blocking works fine.
Here come the questions:
* Does anyone know of a good strategy against zombie network
spam attacks?
* To make the greylist heuristics validate recepients and
blacklist hosts that send to invalid recepients would
blacklist valid MTAs that send bounces of mails with
fake
Re: : Zombie Network Spam Attack
On Mon, Feb 11, 2008 at 11:17:35AM +0100, Raimo Niskanen wrote:
On Fri, Feb 08, 2008 at 11:20:31AM -0500, Calomel wrote:
Raimo,
Can you use the spamd.alloweddomains to whitelist email addresses and
domains you accept mail for? Any email sent to your mail server that is not
on the list will only goto spamd and never get the chance to be
greylisted/whitelisted. Then you could write a simple script to look
through the spamd logs of BLACK entries.
Well, that was already done. All incoming backscatter was to a valid
domain.
If you can compile a list of valid email address this might help. Instead
of @example.com you could list [EMAIL PROTECTED], [EMAIL PROTECTED] Any server
sending to an invalid address would be blacklisted and a script could add
those ips to a pf block table.
cat /var/log/daemon | grep spamd | grep BLACK | awk '{print $7}' | sort |
uniq
The problem seemed to be that spamd overloaded the network connection.
If spamd is sending to many packets back try increasing the stutter time
-S90 and the stutter speed -s5. At 600 connections total and 600
packets per 5 seconds the network would need to handle 120 packets per
second each direction; around 180 kilobytes in each direction. This might
still need be too much bandwidth, but you could increase the values as
needed or decrease the amount of connections spamd will accept with -c.
maxcon may not exceed kern.maxfiles - 200, and defaults to 800.
...and add the offending ips to a block table with a cron job running a few
times a day. This page might give you some more ideas:
Spamd tarpit/greylisting anti-spam how to (spamdb)
http://calomel.org/spamd_config.html
I will have a look at it. Thank you for the ideas.
--
Calomel @ http://calomel.org
Open Source Research and Reference
On Fri, Feb 08, 2008 at 11:07:15AM +0100, Raimo Niskanen wrote:
Apparently we (our mail server) got targeted by a zombie network
since suddenly there were some 3 hosts on spamd's whitelist,
continously some 600 connections to spamd, and only mails to
unknown users coming in. The network connection was flooded,
the web server sluggish, downloads creeped, basically
nothing worked.
Can spamd do anything about zombie hosts? They behave like
normal MTAs so they will pass spamd's behavioural tests, right?
Now I analyze the greylist, do some heuristics on the
sender address (among other things) and trap the bad hosts.
The trapped hosts are then copied to a pf table to be blocked
in the firewall. Tarpitting them through spamd is simply
too much work for the mail server, but blocking works fine.
Here come the questions:
* Does anyone know of a good strategy against zombie network
spam attacks?
* To make the greylist heuristics validate recepients and
blacklist hosts that send to invalid recepients would
blacklist valid MTAs that send bounces of mails with
fake sender addresses to me, right? And that would be
too cruel, or? Because it would certainly decrease
the spam amount.
* To make the greylist herustics validate the hosts
by reverse DNS PTR lookup and then forward A lookup
is apparetly a debatable issue according to the
current thread running mail server at home.
But if it is (fairly) common practice it would
be a simple thing to do, and certainly decrease
spam volume. But would it be to narrow?
--
/ Raimo Niskanen, Erlang/OTP, Ericsson AB
--
/ Raimo Niskanen, Erlang/OTP, Ericsson AB
Re: : : Zombie Network Spam Attack
On Monday 11 February 2008, Raimo Niskanen wrote: 'Mail From: ' One of several that will put you on the http://rfc-ignorant.org/ blacklist. -- Chris
Re: : Zombie Network Spam Attack
On Fri, Feb 08, 2008 at 11:20:31AM -0500, Calomel wrote:
Raimo,
Can you use the spamd.alloweddomains to whitelist email addresses and
domains you accept mail for? Any email sent to your mail server that is not
on the list will only goto spamd and never get the chance to be
greylisted/whitelisted. Then you could write a simple script to look
through the spamd logs of BLACK entries.
Well, that was already done. All incoming backscatter was to a valid
domain.
cat /var/log/daemon | grep spamd | grep BLACK | awk '{print $7}' | sort | uniq
The problem seemed to be that spamd overloaded the network connection.
...and add the offending ips to a block table with a cron job running a few
times a day. This page might give you some more ideas:
Spamd tarpit/greylisting anti-spam how to (spamdb)
http://calomel.org/spamd_config.html
I will have a look at it. Thank you for the ideas.
--
Calomel @ http://calomel.org
Open Source Research and Reference
On Fri, Feb 08, 2008 at 11:07:15AM +0100, Raimo Niskanen wrote:
Apparently we (our mail server) got targeted by a zombie network
since suddenly there were some 3 hosts on spamd's whitelist,
continously some 600 connections to spamd, and only mails to
unknown users coming in. The network connection was flooded,
the web server sluggish, downloads creeped, basically
nothing worked.
Can spamd do anything about zombie hosts? They behave like
normal MTAs so they will pass spamd's behavioural tests, right?
Now I analyze the greylist, do some heuristics on the
sender address (among other things) and trap the bad hosts.
The trapped hosts are then copied to a pf table to be blocked
in the firewall. Tarpitting them through spamd is simply
too much work for the mail server, but blocking works fine.
Here come the questions:
* Does anyone know of a good strategy against zombie network
spam attacks?
* To make the greylist heuristics validate recepients and
blacklist hosts that send to invalid recepients would
blacklist valid MTAs that send bounces of mails with
fake sender addresses to me, right? And that would be
too cruel, or? Because it would certainly decrease
the spam amount.
* To make the greylist herustics validate the hosts
by reverse DNS PTR lookup and then forward A lookup
is apparetly a debatable issue according to the
current thread running mail server at home.
But if it is (fairly) common practice it would
be a simple thing to do, and certainly decrease
spam volume. But would it be to narrow?
--
/ Raimo Niskanen, Erlang/OTP, Ericsson AB
--
/ Raimo Niskanen, Erlang/OTP, Ericsson AB
Re: : : Zombie Network Spam Attack
On Fri, Feb 08, 2008 at 11:19:06AM -0500, Dave Anderson wrote: On Fri, 8 Feb 2008, Raimo Niskanen wrote: Now I am trying to improve the Greyscanner. I noticed it did not trap hosts using an empty envelope sender, unless there were more than one entry from that host. I regarded it as a bug and fixed it. I hope an empty envelope sender really is suspicious or disallowed. Read the RFCs rather than guessing. 'Mail From: ' is not merely allowed but is _required_ when a delivery-failure message is sent. You're throwing away most legitimate notifications of errors delivering messages which originated on your server. Slap! Thank you sir for setting me straight! I will aquire that habit (RFC read) and of course change my current scripts! The problem is usually to find the right RFCs (they usually build on each other and there is very often a later one I should have read too, and some that in practice is not used, ...) Dave -- Dave Anderson [EMAIL PROTECTED] -- / Raimo Niskanen, Erlang/OTP, Ericsson AB
Re: : Zombie Network Spam Attack
Raimo Niskanen [EMAIL PROTECTED] writes: What does lsof -ni:spamd | wc -l say during the peaks? On my machine spamd ran out of sockets (about 670). Depending on the exact properties of the traffic you may get some mileage out of using state tracking options to limit the number of simultaneous connections from a single host, rate of new connections etc and creative use of overload tables. Much like the mainly ssh focused example at [1], only the technique is a general one and could just as easily be applied to SMTP connections. [1] http://home.nuug.no/~peter/pf/en/bruteforce.html -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: Zombie Network Spam Attack
On 08/02/2008, Raimo Niskanen [EMAIL PROTECTED] wrote: Can spamd do anything about zombie hosts? They behave like normal MTAs so they will pass spamd's behavioural tests, right? I don't think most zombies behave like ordinary hosts. Well, it depends on what you mean by zombie. If someone runs an MTA and an attacker roots that MTA box and uses the existing SMTPD to, among other things, also deliver some spam, then yeah, that zombie is going to pretty much behave like an ordinary MTA. However, most people, inluding myself, understand zombie to mean Joe Random User's Windows PC that got (automatically) infected via a virus or trojan or worm and that now is part of a botnet that sometimes sends spam. In this latter case, the payload probably contains an MTA, and these MTAs probably are *not* full sendmail/postfix/qmail/exim/whatever installations. And a lot of them still take a fire and forget approach, which is why greylisting still works. Maybe the virus coders feel that the virus code has to hide and thus can't afford to run for a long time and to eat up a lot of resources. Or maybe they just don't know any better, or don't care because, heck, with most naive MTAs out there it still works. That said, I haven't got a lot of hands-on experience with spam fighting, so I could be wrong. regards, --ropers PS: Essential listening: http://www.the-fifth-hope.org/mp3/draper-spam.mp3 PPS: I have a transcript of this somewhere. Email me if you want it.
Re: Zombie Network Spam Attack
On Fri, 8 Feb 2008 11:07:15 +0100, Raimo Niskanen wrote: Apparently we (our mail server) got targeted by a zombie network since suddenly there were some 3 hosts on spamd's whitelist, continously some 600 connections to spamd, and only mails to unknown users coming in. The network connection was flooded, the web server sluggish, downloads creeped, basically nothing worked. Can spamd do anything about zombie hosts? They behave like normal MTAs so they will pass spamd's behavioural tests, right? Now I analyze the greylist, do some heuristics on the sender address (among other things) and trap the bad hosts. The trapped hosts are then copied to a pf table to be blocked in the firewall. Tarpitting them through spamd is simply too much work for the mail server, but blocking works fine. Here come the questions: * Does anyone know of a good strategy against zombie network spam attacks? * To make the greylist heuristics validate recepients and blacklist hosts that send to invalid recepients would blacklist valid MTAs that send bounces of mails with fake sender addresses to me, right? And that would be too cruel, or? Because it would certainly decrease the spam amount. * To make the greylist herustics validate the hosts by reverse DNS PTR lookup and then forward A lookup is apparetly a debatable issue according to the current thread running mail server at home. But if it is (fairly) common practice it would be a simple thing to do, and certainly decrease spam volume. But would it be to narrow? Every so often we see a flood of connections trying to deliver bounce messages to nonexisting mailboxes here where there are two domains sharing a postfix/OpenBSD box running spamd in greylisting/trapping mode. Mostly: The sender domains are real and the mail is from valid MTAs for those domains. The admins of those senders are incompetent wankers who run MTAs that accept mail for any address and later bounce it to the purported sender. but not 100%. My solution was to run a script from cron every four minutes that looks like: = #!/bin/sh spamdb|grep GREY|cut -d | -f2|tr -d |tr -d |tr | /var/db/slice s while read villain; do /usr/local/sbin/postmap -q $targ /etc/postfix/vmailbox /dev/null if [ $? -ne 0 ] ; then spamdb -ta $villain fi done /var/db/slices rm /var/db/slices == Caveat: This script will tarpit otherwise innocent senders who have clients who use a mailbox name with a tyop in it because it traps ALL messages addressed to invalid mailboxes. Using another grep to select on a match of will eliminate all but bounces to invalid addresses from the null sender. They would not have reached a mailbox anyway. I figure that maybe, just maybe, some admins will see the log message repeating during all the trapitting and get a clue. It is easier than sending an email complaining about their cluelessness. As to load: The box is a Celeron 1.3GHz with 256 MB RAM. It handles lots of mail with reasonably large PDF and graphics attached and runs a POP3 daemon as well that is polled regularly by about 70 always on accounts. I cannot see any degradation of performance when these storms are peaking. spamd rocks! Rod/ (CC not needed, thanx.) Rod/ From the land down under: Australia. Do we look umop apisdn from up over?
Zombie Network Spam Attack
Apparently we (our mail server) got targeted by a zombie network since suddenly there were some 3 hosts on spamd's whitelist, continously some 600 connections to spamd, and only mails to unknown users coming in. The network connection was flooded, the web server sluggish, downloads creeped, basically nothing worked. Can spamd do anything about zombie hosts? They behave like normal MTAs so they will pass spamd's behavioural tests, right? Now I analyze the greylist, do some heuristics on the sender address (among other things) and trap the bad hosts. The trapped hosts are then copied to a pf table to be blocked in the firewall. Tarpitting them through spamd is simply too much work for the mail server, but blocking works fine. Here come the questions: * Does anyone know of a good strategy against zombie network spam attacks? * To make the greylist heuristics validate recepients and blacklist hosts that send to invalid recepients would blacklist valid MTAs that send bounces of mails with fake sender addresses to me, right? And that would be too cruel, or? Because it would certainly decrease the spam amount. * To make the greylist herustics validate the hosts by reverse DNS PTR lookup and then forward A lookup is apparetly a debatable issue according to the current thread running mail server at home. But if it is (fairly) common practice it would be a simple thing to do, and certainly decrease spam volume. But would it be to narrow? -- / Raimo Niskanen, Erlang/OTP, Ericsson AB
Re: : Zombie Network Spam Attack
On Fri, Feb 08, 2008 at 10:08:19PM +1100, Rod Whitworth wrote: On Fri, 8 Feb 2008 11:07:15 +0100, Raimo Niskanen wrote: : : * To make the greylist herustics validate the hosts by reverse DNS PTR lookup and then forward A lookup is apparetly a debatable issue according to the current thread running mail server at home. But if it is (fairly) common practice it would be a simple thing to do, and certainly decrease spam volume. But would it be to narrow? Every so often we see a flood of connections trying to deliver bounce messages to nonexisting mailboxes here where there are two domains sharing a postfix/OpenBSD box running spamd in greylisting/trapping mode. Mostly: The sender domains are real and the mail is from valid MTAs for those domains. The admins of those senders are incompetent wankers who run MTAs that accept mail for any address and later bounce it to the purported sender. but not 100%. My solution was to run a script from cron every four minutes that looks like: = #!/bin/sh spamdb|grep GREY|cut -d | -f2|tr -d |tr -d |tr | /var/db/slice s while read villain; do /usr/local/sbin/postmap -q $targ /etc/postfix/vmailbox Where did the $targ variable come from? I do not run postfix. What do you search for in what database? /dev/null if [ $? -ne 0 ] ; then spamdb -ta $villain fi done /var/db/slices rm /var/db/slices == Caveat: This script will tarpit otherwise innocent senders who have clients who use a mailbox name with a tyop in it because it traps ALL messages addressed to invalid mailboxes. Using another grep to select on a match of will eliminate all but bounces to invalid addresses Does a sender (spamdb field 5 (starting at 1)) == indicate a bounce. And you say it is OK to tarpit hosts that bounce to invalid addresses? from the null sender. They would not have reached a mailbox anyway. I figure that maybe, just maybe, some admins will see the log message repeating during all the trapitting and get a clue. It is easier than sending an email complaining about their cluelessness. As to load: The box is a Celeron 1.3GHz with 256 MB RAM. It handles lots of mail with reasonably large PDF and graphics attached and runs a POP3 daemon as well that is polled regularly by about 70 always on accounts. I cannot see any degradation of performance when these storms are peaking. spamd rocks! What does lsof -ni:spamd | wc -l say during the peaks? On my machine spamd ran out of sockets (about 670). Rod/ (CC not needed, thanx.) Rod/ From the land down under: Australia. Do we look umop apisdn from up over? -- / Raimo Niskanen, Erlang/OTP, Ericsson AB
Re: : Zombie Network Spam Attack
On Fri, Feb 08, 2008 at 12:33:47PM +0100, Peter N. M. Hansteen wrote: Raimo Niskanen [EMAIL PROTECTED] writes: Apparently we (our mail server) got targeted by a zombie network since suddenly there were some 3 hosts on spamd's whitelist, continously some 600 connections to spamd, and only mails to unknown users coming in. The network connection was flooded, the web server sluggish, downloads creeped, basically nothing worked. To me this sounds very much like when we got hit by serious amounts of backscatter. That is, the messages we kept seeing was bounces for spam messages intended for non-existent users elsewhere, so the server at the other end was likely a real one, only with deficient spam countermeasures. I think anyway you want to do some greytrapping, either the empirical approach[1] or Bob Beck's Greyscanner script[2], depending on how much you crave 'getting a feel for the data'. They keep trying, but they really don't bother us much anymore, and the addresses I've collected at [3] keep turning up in my spamd logs. I am doing greytrapping through spamd, and using Bob Beck's Greyscanner script, but it was not enough. I have not, however, activated the feature in the Greyscanner script to trap all hosts that send to unknown RCPT addresses, since I thought it was a too hard measure. Now I am trying to improve the Greyscanner. I noticed it did not trap hosts using an empty envelope sender, unless there were more than one entry from that host. I regarded it as a bug and fixed it. I hope an empty envelope sender really is suspicious or disallowed. Anyway, this is not in any way cruel. This is not cute little furry animals we're talking about, but humans, grownups who should know better. The fact that they're bouncing spam back means that they were probably about to deliver spam to their existing users too, and that is for the most part avoidable. If a backscatter gets through to sendmail, and it is to an invalid user, what is the proper thing for sendmail to do? My sendmail most probably does the default, which I guess is to bounce the mail. [1] see my ramblings about the fun to be had with greytrapping starting at http://bsdly.blogspot.com/2007/07/hey-spammer-heres-list-for-you.html - also the subject of an upcoming BSD Magazine article [2] http://www.ualberta.ca/~beck/nycbug06/scripts/greyscanner.41 [3] http://www.bsdly.net/~peter/traplist.shtml -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds. -- / Raimo Niskanen, Erlang/OTP, Ericsson AB
Re: : Zombie Network Spam Attack
On Fri, 8 Feb 2008, Raimo Niskanen wrote: Now I am trying to improve the Greyscanner. I noticed it did not trap hosts using an empty envelope sender, unless there were more than one entry from that host. I regarded it as a bug and fixed it. I hope an empty envelope sender really is suspicious or disallowed. Read the RFCs rather than guessing. 'Mail From: ' is not merely allowed but is _required_ when a delivery-failure message is sent. You're throwing away most legitimate notifications of errors delivering messages which originated on your server. Dave -- Dave Anderson [EMAIL PROTECTED]
Re: Zombie Network Spam Attack
Raimo,
Can you use the spamd.alloweddomains to whitelist email addresses and
domains you accept mail for? Any email sent to your mail server that is not
on the list will only goto spamd and never get the chance to be
greylisted/whitelisted. Then you could write a simple script to look
through the spamd logs of BLACK entries.
cat /var/log/daemon | grep spamd | grep BLACK | awk '{print $7}' | sort | uniq
...and add the offending ips to a block table with a cron job running a few
times a day. This page might give you some more ideas:
Spamd tarpit/greylisting anti-spam how to (spamdb)
http://calomel.org/spamd_config.html
--
Calomel @ http://calomel.org
Open Source Research and Reference
On Fri, Feb 08, 2008 at 11:07:15AM +0100, Raimo Niskanen wrote:
Apparently we (our mail server) got targeted by a zombie network
since suddenly there were some 3 hosts on spamd's whitelist,
continously some 600 connections to spamd, and only mails to
unknown users coming in. The network connection was flooded,
the web server sluggish, downloads creeped, basically
nothing worked.
Can spamd do anything about zombie hosts? They behave like
normal MTAs so they will pass spamd's behavioural tests, right?
Now I analyze the greylist, do some heuristics on the
sender address (among other things) and trap the bad hosts.
The trapped hosts are then copied to a pf table to be blocked
in the firewall. Tarpitting them through spamd is simply
too much work for the mail server, but blocking works fine.
Here come the questions:
* Does anyone know of a good strategy against zombie network
spam attacks?
* To make the greylist heuristics validate recepients and
blacklist hosts that send to invalid recepients would
blacklist valid MTAs that send bounces of mails with
fake sender addresses to me, right? And that would be
too cruel, or? Because it would certainly decrease
the spam amount.
* To make the greylist herustics validate the hosts
by reverse DNS PTR lookup and then forward A lookup
is apparetly a debatable issue according to the
current thread running mail server at home.
But if it is (fairly) common practice it would
be a simple thing to do, and certainly decrease
spam volume. But would it be to narrow?
--
/ Raimo Niskanen, Erlang/OTP, Ericsson AB
Re: : Zombie Network Spam Attack
On Fri, 8 Feb 2008, Peter N. M. Hansteen wrote: Raimo Niskanen [EMAIL PROTECTED] writes: If a backscatter gets through to sendmail, and it is to an invalid user, what is the proper thing for sendmail to do? My sendmail most probably does the default, which I guess is to bounce the mail. yes, if you receive a message intended for a non-existing user, you most likely bounce with 'unknown user' or the equivalent. it's the other end, where spam apparently gets delivered, that's making more noise than necessary by bouncing messages that should have simply been forwarded to /dev/null instead. While I agree with most of what you're saying, quietly dropping messages identified as spam is _not_ the best way of handling them -- since it's rarely possible to be 100% certain that a message really is spam, and it's harmful to not notify the sender that a legitimate message has not been delivered. We'd all be a lot better off if everyone running a mail server went to the extra effort of configuring their server to reject as many problem messages as possible during the SMTP session rather than accepting them and then having to either drop them without notice or send a failure message to the 'from' header address. That way the sender of legitimate messages gets notified of any problems, but the server doesn't contribute to the 'distributed mail-bombing' caused by forged 'from' header addresses in spam. While it's not possible to do this in _all_ cases, bad addresses can be handled at the SMTP 'rcpt to' command with (usually) very little effort and greylisting (and associated tools) can reject a large fraction of spam messages at this stage. Dave -- Dave Anderson [EMAIL PROTECTED]
Re: : Zombie Network Spam Attack
Raimo Niskanen [EMAIL PROTECTED] writes: If a backscatter gets through to sendmail, and it is to an invalid user, what is the proper thing for sendmail to do? My sendmail most probably does the default, which I guess is to bounce the mail. yes, if you receive a message intended for a non-existing user, you most likely bounce with 'unknown user' or the equivalent. it's the other end, where spam apparently gets delivered, that's making more noise than necessary by bouncing messages that should have simply been forwarded to /dev/null instead. - P -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: Zombie Network Spam Attack
Raimo Niskanen [EMAIL PROTECTED] writes: Apparently we (our mail server) got targeted by a zombie network since suddenly there were some 3 hosts on spamd's whitelist, continously some 600 connections to spamd, and only mails to unknown users coming in. The network connection was flooded, the web server sluggish, downloads creeped, basically nothing worked. To me this sounds very much like when we got hit by serious amounts of backscatter. That is, the messages we kept seeing was bounces for spam messages intended for non-existent users elsewhere, so the server at the other end was likely a real one, only with deficient spam countermeasures. I think anyway you want to do some greytrapping, either the empirical approach[1] or Bob Beck's Greyscanner script[2], depending on how much you crave 'getting a feel for the data'. They keep trying, but they really don't bother us much anymore, and the addresses I've collected at [3] keep turning up in my spamd logs. Anyway, this is not in any way cruel. This is not cute little furry animals we're talking about, but humans, grownups who should know better. The fact that they're bouncing spam back means that they were probably about to deliver spam to their existing users too, and that is for the most part avoidable. [1] see my ramblings about the fun to be had with greytrapping starting at http://bsdly.blogspot.com/2007/07/hey-spammer-heres-list-for-you.html - also the subject of an upcoming BSD Magazine article [2] http://www.ualberta.ca/~beck/nycbug06/scripts/greyscanner.41 [3] http://www.bsdly.net/~peter/traplist.shtml -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: : Zombie Network Spam Attack
On Fri, 8 Feb 2008, Stuart Henderson wrote: On 2008/02/08 11:35, Dave Anderson wrote: On Fri, 8 Feb 2008, Peter N. M. Hansteen wrote: Raimo Niskanen [EMAIL PROTECTED] writes: If a backscatter gets through to sendmail, and it is to an invalid user, what is the proper thing for sendmail to do? My sendmail most probably does the default, which I guess is to bounce the mail. yes, if you receive a message intended for a non-existing user, you most likely bounce with 'unknown user' or the equivalent. it's the other end, where spam apparently gets delivered, that's making more noise than necessary by bouncing messages that should have simply been forwarded to /dev/null instead. While I agree with most of what you're saying, quietly dropping messages identified as spam is _not_ the best way of handling them -- since it's rarely possible to be 100% certain that a message really is spam, and it's harmful to not notify the sender that a legitimate message has not been delivered. If you do this, and people forward mail to your machine, or you list a backup MX which accepts some spam that your machine doesn't, your policy results in backscatter to the envelope sender address. As I stated in the part of my message that you didn't quote, it's not a 100% solution -- but it would drastically reduce the amount of backscatter if everyone did it. And, IMO, some backscatter is a much less serious problem than _any_ legitimate message disappearing without a trace. There's no right answer... There's no _perfect_ answer (short of a complete redesign of SMTP), but there are certainly ones which improve on the current state of affairs. Dave -- Dave Anderson [EMAIL PROTECTED]
Re: : Zombie Network Spam Attack
On 2008/02/08 11:35, Dave Anderson wrote: On Fri, 8 Feb 2008, Peter N. M. Hansteen wrote: Raimo Niskanen [EMAIL PROTECTED] writes: If a backscatter gets through to sendmail, and it is to an invalid user, what is the proper thing for sendmail to do? My sendmail most probably does the default, which I guess is to bounce the mail. yes, if you receive a message intended for a non-existing user, you most likely bounce with 'unknown user' or the equivalent. it's the other end, where spam apparently gets delivered, that's making more noise than necessary by bouncing messages that should have simply been forwarded to /dev/null instead. While I agree with most of what you're saying, quietly dropping messages identified as spam is _not_ the best way of handling them -- since it's rarely possible to be 100% certain that a message really is spam, and it's harmful to not notify the sender that a legitimate message has not been delivered. If you do this, and people forward mail to your machine, or you list a backup MX which accepts some spam that your machine doesn't, your policy results in backscatter to the envelope sender address. There's no right answer...
Re: : Zombie Network Spam Attack
On Fri, 8 Feb 2008 15:36:01 +0100, Raimo Niskanen wrote: On Fri, Feb 08, 2008 at 10:08:19PM +1100, Rod Whitworth wrote: On Fri, 8 Feb 2008 11:07:15 +0100, Raimo Niskanen wrote: : : * To make the greylist herustics validate the hosts by reverse DNS PTR lookup and then forward A lookup is apparetly a debatable issue according to the current thread running mail server at home. But if it is (fairly) common practice it would be a simple thing to do, and certainly decrease spam volume. But would it be to narrow? Every so often we see a flood of connections trying to deliver bounce messages to nonexisting mailboxes here where there are two domains sharing a postfix/OpenBSD box running spamd in greylisting/trapping mode. Mostly: The sender domains are real and the mail is from valid MTAs for those domains. The admins of those senders are incompetent wankers who run MTAs that accept mail for any address and later bounce it to the purported sender. but not 100%. My solution was to run a script from cron every four minutes that looks like: = #!/bin/sh spamdb|grep GREY|cut -d | -f2|tr -d |tr -d |tr | /var/db/slice s while read villain; do /usr/local/sbin/postmap -q $targ /etc/postfix/vmailbox Where did the $targ variable come from? Aaargh! After a 0430 start yesterday I try to send helpful info at 2208. It might have been more helpful if I slept first. Sorry. I was doing the script from memory so now here is the correct one cut and pasted. === #!/bin/sh spamdb|grep GREY|cut -d | -f2,5|tr -d |tr -d |tr | /var/db/slices while read villain targ; do /usr/local/sbin/postmap -q $targ /etc/postfix/vmailbox /dev/null if [ $? -ne 0 ] ; then spamdb -ta $villain fi done /var/db/slices rm /var/db/slices === I do not run postfix. What do you search for in what database? The postconf line queries the valid recipients database. /dev/null if [ $? -ne 0 ] ; then spamdb -ta $villain fi done /var/db/slices rm /var/db/slices == Caveat: This script will tarpit otherwise innocent senders who have clients who use a mailbox name with a tyop in it because it traps ALL messages addressed to invalid mailboxes. Using another grep to select on a match of will eliminate all but bounces to invalid addresses Does a sender (spamdb field 5 (starting at 1)) == indicate a bounce. No. The sender field is 4 and 5 is the recipient (or target in my terms for spammers, hence $targ in the script.) And you say it is OK to tarpit hosts that bounce to invalid addresses? Well I did put a caveat in my message BUT the following considerations apply: We are not supposed to reject messages from the null sender because they are supposed to be genuine bounce messages. So I don't reject based on the null sender alone. However nobody could be legitimally bouncing a message from a non-existant sender. In the nasty spammy email world we live in accept and bounce should only apply to mail from authenticated MUAs talking to their own outbound MTA. Otherwise spammers do what we are discussing and hope their payload ends up being read by someone. from the null sender. They would not have reached a mailbox anyway. I figure that maybe, just maybe, some admins will see the log message repeating during all the trapitting and get a clue. It is easier than sending an email complaining about their cluelessness. As to load: The box is a Celeron 1.3GHz with 256 MB RAM. It handles lots of mail with reasonably large PDF and graphics attached and runs a POP3 daemon as well that is polled regularly by about 70 always on accounts. I cannot see any degradation of performance when these storms are peaking. spamd rocks! What does lsof -ni:spamd | wc -l say during the peaks? On my machine spamd ran out of sockets (about 670). I don't have a storm at the moment. Last one was about a month ago. I have only seen an increased load prior to trapping these backscatter senders. Running the script cut the load to normal performance. Not that I measured it but it was just no longer noticeably slow. Oh, and I haven't used lsof since I retired from teaching Linux stuff for IBM a few years ago. It isn't part of OpenBSD tools. Best regards, Rod/ /earth: write failed, file system is full cp: /earth/creatures: No space left on device
