Zardoz

Two of my Media Temple (dv) servers were getting hit by a botnet-like spam attack this morning, causing a significant number of concurrent SMTP connections. There was a rapid succession of /var/qmail/bin/relaylock entries in the maillog (checking that with tail -f /usr/local/psa/var/log/maillog), but the real problem was the number of qmail-smtpd instances running (found through either top or ps aufx), each of which was eating into the available kmemsize.

I think I’ve managed I thought I managed to limit the number of simultaneous qmail-smtpd instances by changing the number of instances from 60 to 10 in /etc/xinetd.conf and restarting xinetd & qmail. I tried changing the instances of both /etc/xinetd.d/smtp_psa and /etc/xinetd.d/smtps_psa to 10 (from the default UNLIMITED) as well, but that didn’t seem to have any effect. After both changes I restarted xinetd and then qmail like so:

/etc/init.d/xinetd restart
/etc/init.d/qmail restart

Update:

On further investigation, this measure didn’t work out, qmail-smtpd instances were still going overboard and causing kmemsize problems. However I did find another option which seems to be having a slight effect: adding a “per source” to smtp_psa and smtps_psa, which means each IP can only have one connection at a time (doesn’t do much for spam flooding in from hundreds of different IPs, but still):

service smtp
{
socket_type = stream
protocol = tcp
wait = no
disable = no
user = root
instances = 10
per_source = 1
server = /var/qmail/bin/tcp-env
server_args = -Rt0 /var/qmail/bin/relaylock /var/qmail/bin/qmail-smtpd /var/qmail/bin/smtp_auth /var/qmail/bin/true /var/qmail/bin /cmd5checkpw /var/qmail/bin/true
}