0
votes

I have been receiving countless ddos attacks the last couple of weeks. Just now I caught one while I was running iptraf. Normally 99.9% of the packets used on my server are TCP packages, and not UDP. A few are used I see, but normally hardly any.

Now while the attack happened I noticed thousands of incoming UDP packets per second. Also tcpdump was showing this: http://pastebin.com/raw.php?i=QaybC8C1.

I run CENTOS 5.6, and I only use it for nginx (80,443), ssh (22), ftp (21). I dont run nameservers, email or anything like that.

My question is. Can I block all incoming UDP traffic via iptables? Would this be effective against UDP ddos attacks? And if I can block all UDP traffic, would this cause any problems in linux?

4
  • 4
    DNS resolution would fail if you blocked all UDP traffic
    – EEAA
    Aug 8, 2011 at 19:43
  • 1
    Are these "DDoS attacks" causing any performance issues? If not, I'd be inclined to not worry about it.
    – EEAA
    Aug 8, 2011 at 19:46
  • 4
    Reading back at your previous questions on the subject, it sounds as if it's "flooding your network". If that is indeed true and your circuit is being pegged, there's absolutely nothing you can do on your server itself (short of changing its IP) that will help. You'll need to work the issue upstream.
    – EEAA
    Aug 8, 2011 at 19:53
  • Just un plug the network card :)
    – Alan
    Aug 8, 2011 at 21:00

3 Answers 3

1
vote
  • Yes you can block UDP packets
  • It won't cause problems unless you allow incoming DNS packets for your DNS queries. (related packets)
4
  • 1
    And when the server tried to do it's own DNS query? Say when you're trying to ssh into the server and it does forward and reverse lookups on your IP?
    – Chris S
    Aug 8, 2011 at 20:45
  • Then he hopefully will only block incoming UDP as it is only an incoming attack.
    – mailq
    Aug 9, 2011 at 15:11
  • I suppose you think the DNS response would come in on some protocol other than UDP?
    – Chris S
    Aug 9, 2011 at 16:57
  • Yes sorry. You are right. DNS UDP answers always come back on 53. (But port numbers aren't telling something about the used protocol.) But if you have a DNS forwarder that forces to use DNS over TCP then they could come back on another port.
    – mailq
    Aug 9, 2011 at 17:40
7
votes

Based on the image of your capture, it looks like a DOS and not a DDOS since the originating ip address is the same. It looks like they're trying to connect to UDP port 17 (QOTD - http://en.wikipedia.org/wiki/QOTD), if I'm reading the capture correctly, which I might not be since I've never used tcpdump. How about starting out by blocking just that ip address or just that port?

10
  • 3
    +1 - Blocking ALL UDP traffic to prevent a (D)DoS attack is the equivalent of encasing your daughter in lucite to keep the boys away from her. Sure it works, but there are unpleasant side effects.
    – voretaq7
    Aug 8, 2011 at 19:59
  • @joeqwerty Agreed and +1 - minor correction; UDP is IP protocol 17, the capture text doesn't include the port that's being hit. Aug 8, 2011 at 20:17
  • 1
    I agree with @joeqwerty, but I'll also add that if you feel you can resolve this by blocking udp, as long as your firewall/packet filter will allow UDP in for open states where the connection was initiated from within your network (and the authoritative DNS for your domain is off-network). What I mean is that all UDP that is initiated from external is dropped, but if you initiate a port 53 UDP connection from internal, to get DNS resolution, you allow that through. I still wouldn't do it though.
    – sandroid
    Aug 8, 2011 at 20:17
  • 1
    @Shane - actually port is there: 14:11:28.698157 IP (tos 0x0, ttl 120, id 4014, offset 0, flags [+], proto: UDP (17), length: 1500) 64-37-60-212.static.dimenoc.com.58703 > s1.jeroenvader.com.24012: It's from port 58703 to port 24012. Regardless, it's not port 17, and it's not relevant either. If UDP is not desired traffic and/or expected behavior from real users, best he can do is block it. Doesn't change the fact it fills his incoming pipe though.
    – sandroid
    Aug 8, 2011 at 20:21
  • 1
    @Shane & sandroid: Gotcha, thanks. I was reading the capture incorrectly. In any event, I would start by blocking inbound traffic to that particular TCP or UDP port or block inbound traffic from that particular originating ip address since in this case it looks like it's all coming from the same source. blocking all UDP traffic seems somewhat like using a sledgehammer to kill a fly.
    – joeqwerty
    Aug 8, 2011 at 20:29
6
votes

Can I block all incoming UDP traffic via iptables?

Sure - but it will likely not do you any good.

Would this be effective against UDP ddos attacks?

Depends what the DDoS is hitting. From your other questions, it's clear that bandwidth is your concern; so, discarding the request once it's already hit your server will do you no good; especially since your current configuration is likely already discarding the packets immediately.

And if I can block all UDP traffic, would this cause any problems in linux?

Yes. UDP is a stateless protocol; blocking all traffic would block, for instance, inbound replies to DNS requests made by your server.


I continue to be unconvinced that this is a DoS at all (and it's clearly not a DDoS, as @joeqwerty pointed out); they're certainly exhausting your inbound bandwidth, but it may not be intentional or malicious.

The source of the traffic seems to be a legitimate data center; 64.37.60.212 is these guys (I'm assuming that those PTR records are legit, here - confirm that the source IP matches the PTR records), and they have a very clear policy about abusive traffic posted; if nothing else, you can contact their abuse address.

More to the point, the "attack" traffic looks to be fragmented UDP packets of exactly 8192 bytes - that strikes me as some kind of file transfer. Since you're running a web server, a far more effective (and far more common) DDoS strategy would be to use TCP connections on open ports, exhausting system resources without having to locally used as much upstream bandwidth as they're consuming of your downstream.

Can you look into what port they're sending data to? That may really shed some light on this issue.

Edit: I'm gonna guess NFS - port 2049.

1
  • 1
    +1 for a well thought out and comprehensive answer.
    – joeqwerty
    Aug 8, 2011 at 20:31

Not the answer you're looking for? Browse other questions tagged .