Return-Path: Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: (qmail 97887 invoked from network); 25 Jun 2009 16:54:28 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 25 Jun 2009 16:54:28 -0000 Received: (qmail 64491 invoked by uid 500); 25 Jun 2009 16:54:38 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 64414 invoked by uid 500); 25 Jun 2009 16:54:38 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 64405 invoked by uid 99); 25 Jun 2009 16:54:38 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 25 Jun 2009 16:54:38 +0000 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [64.202.165.30] (HELO smtpauth19.prod.mesa1.secureserver.net) (64.202.165.30) by apache.org (qpsmtpd/0.29) with SMTP; Thu, 25 Jun 2009 16:54:28 +0000 Received: (qmail 20832 invoked from network); 25 Jun 2009 16:53:59 -0000 Received: from unknown (76.252.112.72) by smtpauth19.prod.mesa1.secureserver.net (64.202.165.30) with ESMTP; 25 Jun 2009 16:53:58 -0000 Message-ID: <4A43AB9A.5070503@rowe-clan.net> Date: Thu, 25 Jun 2009 11:53:46 -0500 From: "William A. Rowe, Jr." User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: dev@httpd.apache.org Subject: Re: mod_noloris: mitigating against slowloris-style attack References: <4A437E26.2050103@webthing.com> <4A4393D9.2000808@rowe-clan.net> <35D1BBF2-3ED4-49D4-9F65-257E0BD80766@webthing.com> In-Reply-To: <35D1BBF2-3ED4-49D4-9F65-257E0BD80766@webthing.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Nick Kew wrote: > > How would you keep an index keyed on client-IP using scoreboard? > Or did you have something else in mind? Exactly; this could not be keyed. Not without additional data and additional cross-thread+cross-proc locking semantics. If we can tolerate a 'soft limit' then simply memcmp'ing the client of scoreboard slot might be more efficient than the whole locking and db access overhead, at least for cases of ~500 clients or less. To get a hard and fast limit, locking is required.