On Wed, Nov 29, 2006 at 06:49:34AM -0700, Matt wrote:
> So I've searched around but haven't found any real solutions (in fact,
> there may not be any solutions). For the past week one of my virtual
> domains has been slammed by what appears to be a distributed spam
> attack.
Could you describe the attack a bit more detailed?
What I did but what doesn't work "immediately and right now" is:
1) Analyze logfiles of a few weeks (did this also for an evaluation of
greylisting). Used the info of "good mailservers" to feed them in
two DNS whitelists.
o an IP address based whitelist
o a domain name based whitelist
o used wildcard for both like *.outgoing.example.com. or *.0.0.10
this is very useful in conjunction with greylisting to not block
"well known" mailservers or "delivery farms".
Keep maintining that whitelist (the greylisting database is good for
data mining for that purpose)
2) Use a modified "rblsmtpd" that works with that whitelists and sets a few
additional environment variables for later use (e.g. disable greylisting)
With this informaton you can setup a lot of semi-automatic blacklists
without having to fear to block "well known or important (for you and
your customers) mailservers".
I do this with a heavily modified qmail-smtpd that has a simple UDP
sending interface that sends packets with the contents of "sending-ip reason"
to a central server (did this for a lot of mail servers ansd mail
clussters). The central servers receives the UDP messages and puts them
in a MySQL database which in turn feeds a powerdns server that acts as
a blacklist (during attacks or virus outbreaks the "incoming" rate was
so high that using e.g. rbldns from the djbdns package was inconvenient
because it needed locking and regular rebuilding of the CDB file. Using
powerdns and it's MySQL backend was easier for me to accomplish).
I used UDP because it does cost less than TCP, is faster and I have no
problem losing a notification (whihc rarely happens on the LAN anyway).
3) I use temporary blacklists. Entries in the blacklists are cleaned out on
a timely basis depending on the "reason".
qmail-smtpd sends the UDP notifies for e.g.
o sending hosts send own IP address or own hostname in HELO
o sending hosts send my own domain as the sender address domain
(careful with that!!)
o some other checks which lead to a strong assumption the sending
host is spamming
I also have a small program that is called from the qmail-queue
replacement that calls clamav and that sends UDP messages to the
central server in case of deteced viruses
Hosts that violate the above policies are added to the blacklist.
rblsmtpd takes care of future connections (unless the IP/hostname is
in the whilelist). Depending on the reason I feed different
blocklists so the rblsmtpd can issue temporary errors (virus senders)
or permanent errors (my hostname/ip in HELO/EHLO command).
A SQL script on the central server deletes blocked hosts after some
period of time (e.g. virus blocks after 24 hours, my hostname/ip in
HELO/EHLO after 72 hours, ...). It is run in a "daemontools" loop
every hour.
Once you have the "udpsend" program and function (for e.g. qmail-smtpd)
and the central server framework running and a well maintained whitelist
this leads to a large set of possibilities to block/tag spam(ming hosts).
>From my experience this also works a lot better than a huge list of
firewall rules, especially for the setup I worked in whith some 100
mailservers.
If I'll find some time I'll cleanup the code and make the stuff a bit
more structured and will make it publicly available.
Some things learned:
- whitelists are essential
there are a lot of ISPs with larger installations that do no virus
checking. Customers often have forwards with other ISPs so viruses are
coming from them even if they are not the source of the virus. You
definitely don't want to block those kind of mailservers.
- whitelists need maintenance
o while a whitelist may work perfectly for 100 customers adding one more
customer that has a different business than all the other may need
massive work on the whitelist to fit also the additional customer.
o Mailservers change
monitor your logfiles also for changes
o "big company" does not mean "have a clue"
Companies could make everything a lot more easier if they would use
"speaking names" for their mailservers.
DNS whitelists can *very* easily handle names of the form
*.mailout.example.com
which perfectly fits in the hierarchy model of DNS. However DNS
whitelists are a pain in the ass to manage for hosts named
mailout-001.example.com
mailout-002.example.com
...
mailout-nnn.example.com
Even large companies like google, amazon, ebay, yahoo, ... don't
get that right. This is rather depressing if one takes into account
the problems they must have with the amount of message they are
receiving and the problems even they must experience with setups
like that.
- if you install a new blocking method do yourself a favour and think
about it, then think again and think once more. After establishing the
blocks monitor your logfiles closely and be prepared to remove it.
This is a lesson I have learned from the "got virus from you" block.
It also helps to only temp reject in the beginning to more easily recover
from errors :)
- even temp rejects can be bad.
if you temp reject a legit server which has a queue lifetime of 14
days (or even 7 days) the sender will notice only after that time
and that can result in an angry sender and an angry customer :/
\Maex
|