High # of emails from -remote-, plus named attack

[GoWilkes]

Starting around 1/25/13 or 1/26/13, I've seen a major increase in server load. Specifically, under "View Relayers", I'm seeing a ton of emails being sent by "-remote-", and when I created a log file for "named", I'm seeing a HUGE number of DDoS attacks (I'm guessing). I'm making an educated guess that these two are symptoms of the same problem.

When I say a "ton of emails being sent by '-remote-'", I mean that in the last 12 hours "-remote-" has sent close to 4,000 emails. The default for all of my email accounts on this server is "blackhole", so there shouldn't be very many bounced emails sent; certainly not 4,000!

And when I say a "HUGE number of DDoS attacks", I mean that I updated named.conf to log IPs, using:

logging {
    channel debug {
      file "/var/named/data/debug.log" versions 3 size 5m;
      severity debug 2;
      print-category yes;
      print-severity yes;
      print-time yes;
    };
    category queries {
      debug;
    };
};

The file reaches 5MB in about 30 seconds, which is roughly 64,000 accesses in 30 seconds. This is on a very low traffic server, though, so I shouldn't be seeing more than 10 or 20 legitimate accesses in that time.

Worse, as soon as I block an IP (or IP range) in the firewall, a new IP immediately starts accessing. I've blocked 70 IPs in the last hour, but it's had no real impact on the "named" load.

A scan with rkhunter returns no problems, and I can't find where any account on the server is sending unexpected emails (other than "-remote-"). Further, there haven't been any root logins other than from me, so I don't think that the server is actually compromised; the issue must be coming from an outside source.

I've also turned on the SMTP Tweak in WHM, and set "recursion: no" in named.conf. Neither of these had a noticeable impact.

Any suggestions for either symptom?

 

[GoWilkes]

As an update, I modified /etc/named.conf like so, but it had no noticeable impact:

// where 1.2.3.4 and 1.2.3.5 represent my server's IP addresses
acl "trusted" {
    1.2.3.4;
    1.2.3.5;
    127.0.0.1;
};

options {
     directory "/var/named";
     version "not currently available";
     allow-recursion { trusted; };
     allow-notify { trusted; };
     allow-transfer { trusted; };
};

I also turned on SYNFLOOD in CSF, and changed PORTFLOOD to:

80;tcp;20;1

(it was empty). But neither have had a noticeable impact.

I have Munin installed, and it shows a major increase in "firewall throughput" since 1/26/13. Before, the average was around 0.2k packets/second, but now it hovers around 1.4k.

And, named used to use about 2.5% of the CPU. Now, it's closer to 70%.

 

[Infopro]

The default for all of my email accounts on this server is "blackhole", so there shouldn't be very many bounced emails sent

You might find this useful:
Why you should use :fail: - ConfigServer Blog

 

[GoWilkes]

Just to update any future reader, I finally found a resolution. I'm not sure if this fixed the problem or just a symptom, but either way the server load is back to normal.

I mentioned before that I use CSF for the firewall, and I had changed PORTFLOOD to:

80;tcp;20;1

I discovered from my server provider that the DNS port was actually 53 (not 80), and the protocol for that is UDP (not TCP). This means that I was protecting the wrong port! So, I changed it to:

80;tcp;20;3,53;udp;20;3

This prevents the same IP from accessing port 80 (TCP) more than 20 times in 3 seconds, AND prevents the same IP from accessing port 53 (UDP) more than 20 times in 3 seconds. So, where the debug.log file was reaching 5MB in about 30 seconds, today it only reached 3MB in 24 hours! I consider that a major success.

You can find a little more information on this here, but to be honest, as a newbie I found it to be more confusing than helpful:

http://configserver.com/free/csf/readme.txt

Regardless, this change has all but stopped the DNS attack. I've read that it does make the DNS server respond marginally slower, though, so I hope that the attack will eventually stop and that I will be able to remove the setting.