Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have been getting these UDP floods with random IPs and ports.

randomip:randomport -> myip:randomport

0 byte payload

For some reason it is using a lot of CPU. Here is the results of perf top -e cycles:k.

Is there any way to optimize the kernel?

10.42%  [kernel]        [k] inet_getpeer
 7.59%  [kernel]        [k] inet_getpeer.part.4
 6.15%  [kernel]        [k] peer_avl_rebalance.isra.2
 3.38%  [kernel]        [k] fib_table_lookup
 2.77%  [ip_tables]     [k] ipt_do_table
 1.98%  [e1000e]        [k] e1000_clean_rx_irq
 1.82%  [kernel]        [k] md5_transform
 1.69%  [kernel]        [k] __ip_route_output_key
 1.36%  [kernel]        [k] check_leaf.isra.7
 1.34%  [kernel]        [k] __udp4_lib_lookup
 1.31%  [kernel]        [k] kmem_cache_free
 1.09%  [kernel]        [k] __netif_receive_skb_core
 1.01%  [kernel]        [k] __slab_free
 1.00%  [kernel]        [k] __ip_append_data.isra.38
 0.99%  [kernel]        [k] memcpy
 0.98%  [kernel]        [k] kmem_cache_alloc
 0.91%  [kernel]        [k] icmp_send
 0.89%  [xt_multiport]  [k] multiport_mt
 0.83%  [kernel]        [k] update_blocked_averages
 0.79%  [kernel]        [k] kfree
 0.79%  [kernel]        [k] __switch_to
 0.78%  [kernel]        [k] skb_release_data
 0.72%  [kernel]        [k] csum_partial_copy_generic
 0.71%  [kernel]        [k] _raw_spin_lock_irqsave
 0.67%  [kernel]        [k] ip_route_input_noref
 0.63%  [kernel]        [k] __udp4_lib_rcv
 0.61%  [kernel]        [k] dev_gro_receive
 0.59%  [kernel]        [k] __schedule
 0.59%  [kernel]        [k] __ip_make_skb
 0.57%  [kernel]        [k] __copy_skb_header
 0.56%  [kernel]        [k] sock_alloc_send_pskb
 0.55%  [kernel]        [k] nf_iterate
share|improve this question
    
Please update your question with iptables rules, kernel version, distro version, lsmod, and /etc/sysconfig/iptables-config (if exists) –  GioMac Sep 11 '13 at 9:18
    
I am using Ubuntu 12.04 with Linux 3.10.9. I don't think the rules are to blame as you can see from perf top, it is only using 2.77% cpu.-A INPUT -p udp -m udp -d 127.0.0.1 --sport 53 -j ACCEPT -A INPUT -p udp -m udp --match multiport --sports 53,161,19 -j DROP -A INPUT -p tcp -m tcp --tcp-flags SYN,RST,ACK SYN -j SYN –  bob Sep 12 '13 at 21:32

3 Answers 3

Judging by your perf output raising net.ipv4.inet_peer_threshold and lowering both net.ipv4.inet_peer_minttl and net.ipv4.inet_peer_maxttl may slightly help. I assumed you are using somewhat recent kernel e.g. 3.2. You can see inet_getpeer's source code here: http://lxr.linux.no/#linux+v3.2.51/net/ipv4/inetpeer.c#L395

  • If DDoS is CPU bound then you should probably just ban zero-sized UDP packets via netfilter e.g:

    $ iptables -I INPUT -p udp -m length --length NN -j DROP
    

    by replacing NN with actual L3 payload, in your case probably 8 (size of UDP header).

  • If DDoS is interrupt bound you can tune your e1000e, see:

    $ modinfo e1000e | grep ^parm: 
    

    also check Intel's doc for parameter description: http://downloadmirror.intel.com/9180/eng/README.txt

  • If DDoS is network bound then you should ask your ISP (datacenter ops) for assistance.

share|improve this answer
1  
lenght is misspelled in the first iptables command. –  hexafraction Sep 11 '13 at 23:20
    
Oops - thanks for noticing it! –  SaveTheRbtz Sep 12 '13 at 10:17
    
You could probably drop all inbound UDP except for locally initiated connections (probably only DNS lookups) and anything you serve on a UDP port. –  mtm Sep 12 '13 at 10:40
    
The DDoS is CPU bound as you can tell from perf top. I don't want to just drop 0 sized packets because the attacker could just increase the payload by 1 byte. But I am already dropping them. And the length is 28 (tcp header is included in the size). –  bob Sep 12 '13 at 21:26

What do you think you can optimize? You are experiencing an DDoS attack, which attempts to overload the server. This takes usually success if there is no network component in front of the server, which does zero-routing to the server.

You can not prevent a DDoS on the server directly, only trough a good network infrastructure with preventing systems.

share|improve this answer
    
Setting a default policy of ignoring UDP traffic except for any services you are providing seem to me to be a good way to mitigate a DDOS. –  symcbean Sep 11 '13 at 21:04

You can use ipset in conjunction with iptables as it is ultra efficient at processing lots of parameters such as IP addresses or ports.

Here is an example of use of ipset where P2P offenders are put into a set and allocated a time out P2P timeout soltuion

or creating a live blacklist Use ipset for live blacklist

Ipset is ultra efficient for lots of IP addresses and ports because it stores the values in RAM.

Good luck.

share|improve this answer
    
Using ipset in blacklist mode won't help against UDP flood with random source IPs. –  SaveTheRbtz Sep 11 '13 at 20:57
    
True - if they are totally random & never repeat. However if there is some repetition ipset would simply be another tool that could assist. However your suggestion using netfilter length option sounds like an excellent quick assist. –  Eureka Ikara Sep 13 '13 at 0:57

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.