Re: DDoS attack causing bad effect on conntrack searches

[Eric Dumazet <eric.dumazet@gmail.com>]

Le jeudi 22 avril 2010 à 22:38 +0200, Jesper Dangaard Brouer a écrit :
> 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.
> 

OK but a lookup last a fraction of a micro second, unless interrupted by
hard irq.

Probability of a change during a lookup should be very very small.

Note that the scenario for a restart is :

The lookup go through the chain.
While it is examining one object, this object is deleted.
The object is re-allocated by another cpu and inserted to a new chain.


What exact version of kernel are you running ?

> 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
> -------------------------------------------------------------------


--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html