2

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
2
  • Please update your question with iptables rules, kernel version, distro version, lsmod, and /etc/sysconfig/iptables-config (if exists)
    – GioMac
    Sep 11, 2013 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, 2013 at 21:32

3 Answers 3

2

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.

3
  • 1
    lenght is misspelled in the first iptables command.
    – nanofarad
    Sep 11, 2013 at 23:20
  • You could probably drop all inbound UDP except for locally initiated connections (probably only DNS lookups) and anything you serve on a UDP port.
    – Matt
    Sep 12, 2013 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, 2013 at 21:26
1

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.

2
  • Using ipset in blacklist mode won't help against UDP flood with random source IPs. Sep 11, 2013 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. Sep 13, 2013 at 0:57
-1

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.

1
  • 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, 2013 at 21:04

You must log in to answer this question.

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