lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <Pine.LNX.4.64.1004222213290.10919@ask.diku.dk> Date: Thu, 22 Apr 2010 22:38:02 +0200 (CEST) From: Jesper Dangaard Brouer <hawk@...u.dk> To: Eric Dumazet <eric.dumazet@...il.com> Cc: paulmck@...ux.vnet.ibm.com, Patrick McHardy <kaber@...sh.net>, Changli Gao <xiaosuo@...il.com>, hawk@...x.dk, Linux Kernel Network Hackers <netdev@...r.kernel.org>, Netfilter Developers <netfilter-devel@...r.kernel.org> Subject: Re: DDoS attack causing bad effect on conntrack searches On Thu, 22 Apr 2010, Eric Dumazet wrote: > Le jeudi 22 avril 2010 à 08:51 -0700, Paul E. McKenney a écrit : >> On Thu, Apr 22, 2010 at 04:53:49PM +0200, Eric Dumazet wrote: >>> Le jeudi 22 avril 2010 à 16:36 +0200, Eric Dumazet a écrit : >>> >>> If we can do the 'retry' a 10 times, it means the attacker was really >>> clever enough to inject new packets (new conntracks) at the right >>> moment, in the right hash chain, and this sounds so higly incredible >>> that I cannot believe it at all :) >> >> Or maybe the DoS attack is injecting so many new conntracks that a large >> fraction of the hash chains are being modified at any given time? >> I think its plausable, there is a lot of modification going on. Approx 40.000 deletes/sec and 40.000 inserts/sec. The hash bucket size is 300032, and with 80000 modifications/sec, we are (potentially) changing 26.6% of the hash chains each second. As can be seen from the graphs: http://people.netfilter.org/hawk/DDoS/2010-04-12__001/list.html Notice that primarily CPU2 is doing the 40k deletes/sec, while CPU1 is caught searching... > maybe hash table has one slot :) Guess I have to reproduce the DoS attack in a testlab (I will first have time Tuesday). So we can determine if its bad hashing or restart of the search loop. The traffic pattern was fairly simple: 200 bytes UDP packets, comming from approx 60 source IPs, going to one destination IP. The UDP destination port number was varied in the range of 1 to 6000. The source UDP port was varied a bit more, some ranging from 32768 to 61000, and some from 1028 to 5000. Cheers, Jesper Brouer -- ------------------------------------------------------------------- MSc. Master of Computer Science Dept. of Computer Science, University of Copenhagen Author of http://www.adsl-optimizer.dk -------------------------------------------------------------------
Powered by blists - more mailing lists