up vote 0 down vote favorite
2

Possible Duplicate:
UDP Flood Attack (linux server)

How can i detect a UPD flood on a linux server or check if i had a udp flood attack?

I want to detect whats happening and when.

share|improve this question

migrated from stackoverflow.com May 13 '11 at 20:05

This question came from our site for professional and enthusiast programmers.
    
i'm sure iptables can do this – Gunslinger_ May 13 '11 at 18:45
    
Do you have any daemons which use UDP ? – Sameer May 13 '11 at 18:46
    
But how to detect that I am under attack of a UDP Flood? (except for the fact that the website is offline) and what log file to check? – Milner May 13 '11 at 18:49
    
I run a webserver. But how to detect that I am under attack of a UDP Flood? (except for the fact that the website is offline) and what log file to check? – Marc May 13 '11 at 18:49
    
Are you sure that the UDP connection is flooding your socket buffers? I ask this so that I can know how you are determining that the machine is being flooded with UDP packets. – Gangadhar May 13 '11 at 19:00
up vote 1 down vote

Open up a traffic sniffer like tcpdump or wireshark as follows:

tshark -i any port 53

I would also double check as Sameer said above to see if you are running any services that listen for UDP by running:

netstat -nulp
share|improve this answer
    
Yes, when i run netstat -nulp 6 times udp, and 3x udp6, not good? 0.... 192.168... - server ip range - server ip range - 127.0 - 0.0 – Marc May 13 '11 at 19:06
    
It's okay. It just means you have some daemons running that rely on UDP. Probably a DNS server, NTP, and something else. The reason we asked was to see whether you could safely drop all UDP which you cannot. – dmourati May 13 '11 at 20:13
    
It is probably not the best idea to fire up a resource-intensive and exploit-prone sniffer like Wireshark to check out if there is a denial-of-service attack underway - most likely this will make things much worse if it is. UDP-based DDoS attacks are mostly dangerous due to the fact that they produce a lot of traffic and fill up your upstream - nothing will help you there but asking your upstream provider to filter the traffic. Detection can be done through observation of the counters and health states. Iptrafs interface statistics should be able to give a quick overview. – the-wabbit May 13 '11 at 22:28
up vote 0 down vote

Here's how you match whenever you're being hit with 5 packets per second

[UNTESTED]
iptables -A INPUT -p udp -m limit --limit 5/s -j LOG
share|improve this answer
    
I'd say it does quite the reverse - it logs every packet unless the rate hits 5 packets / s, in which case logging is suspended for everything above. Inverting the statement to ! --limit 5/s is unfortunately not supported, but using a combination of --limit 5/s -j RETURN and an unconditional -j LOG as the next rule would do the trick. – the-wabbit May 14 '11 at 13:05
up vote 0 down vote

If you're not expecting udp traffic at all I might recommend just dropping it (except for your DNS servers, of course!):

iptables -A INPUT -p udp --sport 53 -s my.dns.server1 -j ACCEPT
iptables -A INPUT -p udp --sport 53 -s my.dns.server2 -j ACCEPT
iptables -A INPUT -p udp -j DROP
share|improve this answer
up vote 0 down vote

Use a "machine in the middle" with a packet analyzer like Wireshark. http://wiki.wireshark.org/CaptureSetup/Ethernet#Capture_using_a_machine-in-the-middle

Or do it with a transparent bridge using OpenBSD, netBSD or FreeBSD and port mirroring, a standard setup for packet analyzing. Three NICs, one connected to Internet, one connected to internal network, the third mirrored and connected to a packet analyzer and/or intrusion detection system.(BSD has been doing transparent bridging longer than Linux, Linux may have caught up by now and work sufficiently. High load throughput, either packets per second or bytes per second, is usually where you'll see differences.)

In high traffic the MITM can lose packets or possibly change the data stream because of the overhead of decoding. You could also try a monitor port on a managed switch but again you will lose packets. Either simple method, MITM or managed switch monitor port may be enough to determine the problem even without an exact packet capture.

If your server is not under high load, consider an IDS like Snort or Prelude. If this is a production server use port mirroring and send packets to a dedicated IDS/packet analyzer machine rather than installing the IDS on the server itself.

share|improve this answer
up vote -1 down vote

blocking UDP flood attack could be solved with iptables. and you can drop packet with it. seems this is good reference for you : http://bradmontgomery.net/blog/blocking-outgoing-udp-traffic-using-iptables/

share|improve this answer
    
Please don't post link-only answers. – ceejayoz Apr 15 '14 at 14:35
    
@ceejayoz I've edited my answer. – Yuda Prawira Apr 15 '14 at 14:42