All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick McHardy <kaber@trash.net>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Jesper Dangaard Brouer <hawk@diku.dk>,
	paulmck@linux.vnet.ibm.com, Changli Gao <xiaosuo@gmail.com>,
	hawk@comx.dk,
	Linux Kernel Network Hackers <netdev@vger.kernel.org>,
	Netfilter Developers <netfilter-devel@vger.kernel.org>
Subject: Re: DDoS attack causing bad effect on conntrack searches
Date: Fri, 23 Apr 2010 12:55:38 +0200	[thread overview]
Message-ID: <4BD17CAA.4090708@trash.net> (raw)
In-Reply-To: <1271970199.7895.6482.camel@edumazet-laptop>

Eric Dumazet wrote:
> 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.

I think another scenario that seems a bit more likely would be
that a new entry is added to the chain after it was fully searched.
Perhaps we could continue searching at the last position if the
last entry is not a nulls entry to improve this.
--
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

  parent reply	other threads:[~2010-04-23 10:55 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-22 12:58 DDoS attack causing bad effect on conntrack searches Jesper Dangaard Brouer
2010-04-22 13:13 ` Changli Gao
2010-04-22 13:17   ` Patrick McHardy
2010-04-22 14:36     ` Eric Dumazet
2010-04-22 14:53       ` Eric Dumazet
2010-04-22 15:51         ` Paul E. McKenney
2010-04-22 16:02           ` Eric Dumazet
2010-04-22 16:34             ` Paul E. McKenney
2010-04-22 20:38             ` Jesper Dangaard Brouer
2010-04-22 21:03               ` Eric Dumazet
2010-04-22 21:14                 ` Eric Dumazet
2010-04-22 23:44                   ` David Miller
2010-04-23  5:44                     ` Eric Dumazet
2010-04-23  8:13                       ` David Miller
2010-04-23  8:18                         ` David Miller
2010-04-23  8:40                           ` Jesper Dangaard Brouer
2010-04-23 10:36                   ` Patrick McHardy
2010-04-23 11:06                     ` Eric Dumazet
2010-04-22 21:28                 ` Jesper Dangaard Brouer
2010-04-23  7:23                   ` Jan Engelhardt
2010-04-23  7:46                     ` Eric Dumazet
2010-04-23  7:55                       ` Jan Engelhardt
2010-04-23  9:23                         ` Eric Dumazet
2010-04-23 10:55                 ` Patrick McHardy [this message]
2010-04-23 11:05                   ` Eric Dumazet
2010-04-23 11:06                     ` Patrick McHardy
2010-04-23 20:57               ` Eric Dumazet
2010-04-24 11:11                 ` Jesper Dangaard Brouer
2010-04-24 20:11                   ` Eric Dumazet
2010-04-26 14:36                     ` Jesper Dangaard Brouer
2010-05-31 21:21                       ` Eric Dumazet
2010-06-01  0:28                         ` Changli Gao
2010-06-01  5:05                           ` Eric Dumazet
2010-06-01  5:48                             ` Changli Gao
2010-06-01 10:18                             ` Patrick McHardy
2010-06-01 10:31                               ` Eric Dumazet
2010-06-01 10:41                                 ` Patrick McHardy
2010-06-01 16:20                                   ` [RFC nf-next-2.6] conntrack: per cpu nf_conntrack_untracked Eric Dumazet
2010-06-04 11:40                                     ` Patrick McHardy
2010-06-04 12:10                                       ` Changli Gao
2010-06-04 12:29                                         ` Patrick McHardy
2010-06-04 12:36                                           ` Eric Dumazet
2010-06-04 16:25                                             ` [PATCH nf-next-2.6] conntrack: IPS_UNTRACKED bit Eric Dumazet
2010-06-04 20:15                                               ` [PATCH nf-next-2.6 2/2] conntrack: per_cpu untracking Eric Dumazet
2010-06-08 14:29                                                 ` Patrick McHardy
2010-06-08 14:52                                                   ` Eric Dumazet
2010-06-08 15:12                                                     ` Eric Dumazet
2010-06-09 12:45                                                       ` Patrick McHardy
2010-06-08 14:12                                               ` [PATCH nf-next-2.6] conntrack: IPS_UNTRACKED bit Patrick McHardy
2010-04-23 10:56       ` DDoS attack causing bad effect on conntrack searches Patrick McHardy
2010-04-23 12:45         ` Jesper Dangaard Brouer
2010-04-23 13:57           ` Patrick McHardy
2010-04-22 13:31   ` Jesper Dangaard Brouer
2010-04-23 10:35     ` Patrick McHardy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4BD17CAA.4090708@trash.net \
    --to=kaber@trash.net \
    --cc=eric.dumazet@gmail.com \
    --cc=hawk@comx.dk \
    --cc=hawk@diku.dk \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=xiaosuo@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.