2

So, it appears about 2 IP addresses are overloading my HTTP server (apache) over UDP and I am unable to stop this using IP Tables. I am using CentOS 5. I managed to block some other IP addresses that were overloading TCP, but can't seem to stop the UDP.

I've narrowed down the offenders to connecting to random ports using UDP connections, but the following entry in iptables isn't working:

-A INPUT -s <offending IP> -p udp -j DROP

Can anyone offer some advice as to what I'm doing wrong?

UPDATE: I noticed that all offending incoming connections were from port 53, so did the following and it seemed to work:

-A INPUT -s <offending IP> -p udp --dport 53 -j REJECT
Tristen
  • 23
  • 1
  • 3
  • Even if your iptables rule does work, keep in mind that it won't slow down the attackers' UDP rates, since, unlike TCP, the protocol does not react to datagram drops. –  May 16 '11 at 18:23
  • What are my options to block UDP? There are only 2 IP addresses and I've tried to block them on specific ports as well. Basically netstat tells me they are connecting with port 53 using UDP and my apache server is responding to it (spawns new httpd processes). –  May 16 '11 at 18:42
  • 1
    It seems your problem is solved. Good! Anyway, there's not much you can do to _effectively_ block UDP. Sure, you can always discard the datagrams with iptables or at a router, but it won't slow down the attacker's stream, which means that your inbound link still would be taxed (also, the server still has to received the datagram before deciding to discard it :). On this case, your best bet would be contacting your ISP/Datacenter provider/etc and see if they can block the attacker's traffic before it arrives at your server. –  May 17 '11 at 10:51

1 Answers1

2

With any kind of DoS or DDoS attack, the only real thing you can do is talk to your upstream provider, and have them block the traffic as it hits their network, otherwise it'll still saturate your connections to the internet, and although you're dropping the traffic, you'll likely still have connectivity problems.

Tom O'Connor
  • 27,440
  • 10
  • 72
  • 148