some updates to snapshot site?
All, I just wanted to point someone to a recent snapshot of 2.2 branch, but found that there is none; we only have 2.0 branch and HEAD ... I think it would make sense to add 2.2 branch snapshots. Also when on that topic: we have apr/apr-util snapshots of 0.9 and 1.0 branch, but none of 1.2 / 1.3 / 1.4; wouldnt it make sense to at least drop 1.0, and replace with 1.3 now? Same for apr-iconv where we have 0.9 and 1.0, but no 1.2 branch ... Günter.
Re: svn commit: r790205 - /httpd/httpd/trunk/modules/experimental/mod_noloris.c
Joe Orton wrote: > On Thu, Jul 02, 2009 at 01:37:22PM +0100, Nick Kew wrote: >> Joe Orton wrote: >> >>> 1) A *linear-time* search on a shm segment, using strstr. >>> 2) ... for each new connection. >> With the expectation that the shm segment normally has strlen >> of zero, and even under attack is just a few bytes. > > As far as I can tell, the worst case is when the size of the string in > the shm segment approaches the maximum in a distributed DoS. The > maximum will need to be: > > (MaxClients / MaxClientConnections) * 47 + 1 > > (46 is the max length of an IPv6 address, not 18, IIRC, and you need > +1's for both the space and the NUL terminator which strcpy will append) > > That could easily be tens or hundreds of kilobytes, depending on > configuration. Presuming that strstr() on that could be non-trivial, > the CPU cost of handling a DDoS attack becomes O(N^2) in an effort to > mitigate a single-client-DoS. That sounds like very poor trade-off. A fixed memcmp of the fixed strlen(match)+1 is sufficient, as you are observing the trailing NULL, which should correspond to the individual client IP strings' trailing NULLs. strstr is certainly suboptimal.
Re: svn commit: r790205 - /httpd/httpd/trunk/modules/experimental/mod_noloris.c
On Thu, Jul 02, 2009 at 01:37:22PM +0100, Nick Kew wrote: > Joe Orton wrote: > >> 1) A *linear-time* search on a shm segment, using strstr. > > 2) ... for each new connection. > > With the expectation that the shm segment normally has strlen > of zero, and even under attack is just a few bytes. As far as I can tell, the worst case is when the size of the string in the shm segment approaches the maximum in a distributed DoS. The maximum will need to be: (MaxClients / MaxClientConnections) * 47 + 1 (46 is the max length of an IPv6 address, not 18, IIRC, and you need +1's for both the space and the NUL terminator which strcpy will append) That could easily be tens or hundreds of kilobytes, depending on configuration. Presuming that strstr() on that could be non-trivial, the CPU cost of handling a DDoS attack becomes O(N^2) in an effort to mitigate a single-client-DoS. That sounds like very poor trade-off. Regards, Joe
Re: svn commit: r790205 - /httpd/httpd/trunk/modules/experimental/mod_noloris.c
On 7/2/09 8:37 AM, "Nick Kew" wrote: > Not everyone who's concerned right now about slowloris has > iptables at their disposal. Also, not everyone has access to the "real" IP very early in the connection phase. Some load balancers add the IP as a header. Generally speaking, most load balancers can handle many times more connections than the actual webservers (even when there are many webservers). Some load balancers per IP blocking schemes are either nonexistent or just don't work. Perhaps this is beyond the scope of this discussion, but it is an unfortunate reality for some folks. -- Brian Akins
Re: svn commit: r790205 - /httpd/httpd/trunk/modules/experimental/mod_noloris.c
Joe Orton wrote: 1) A *linear-time* search on a shm segment, using strstr. > 2) ... for each new connection. With the expectation that the shm segment normally has strlen of zero, and even under attack is just a few bytes. 3) On a shm segment which will get modified in-place by another process 4) ... without locking with a comment about the race condition. When the worst outcome is that a connection is accepted from a should-be-banned client ... p.s. iptables -A INPUT -p tcp --syn --dport 80 \ -m connlimit --connlimit-above 50 -j REJECT Not everyone who's concerned right now about slowloris has iptables at their disposal. -- Nick Kew
Re: mod_ssl / ssl_engine_ocsp.c customizations
On Fri, Jun 26, 2009 at 03:55:27PM +0200, Natanael Mignon - michael-wessel.de wrote: > I am currently working on - dirty, please have mercy - customizations > of mod_ssl and especially OCSP-handling for a specific project (on > basis of Apache 2.3 code). As I am neither a seasoned C-coder nor > familiar with OpenSSL libraries, I am having problems extracting the > issuer name from an X.509 cert into a usable string format. > > What I need to do: > > > · Write my own "static const char *extract_responder_uri()" > > · Don't read responder uri from certificate, but from a file This could be done by making mod_ssl run an optional external hook to retrieve a responder URI given a certificate. I will try to find time to add such a hook, or patches are welcome ;) > how to get a char* or some string from an X509_NAME? This kind of question is better off asked in openssl-us...@openssl.org - you can see lots of examples of how to do it in mod_ssl's ssl_engine_vars.c however. Regards, Joe
Re: svn commit: r790205 - /httpd/httpd/trunk/modules/experimental/mod_noloris.c
On Jul 2, 2009, at 5:58 AM, Joe Orton wrote: On Wed, Jul 01, 2009 at 03:01:55PM -, n...@apache.org wrote: Author: niq Date: Wed Jul 1 15:01:55 2009 New Revision: 790205 URL: http://svn.apache.org/viewvc?rev=790205&view=rev Log: mod_noloris just moved from discussion to attracting its first patch on d...@. That means it wants to be in svn. Adding to modules/ experimental pending anything more definite. 1) A *linear-time* search on a shm segment, using strstr. 2) ... for each new connection. 3) On a shm segment which will get modified in-place by another process 4) ... without locking Awesome! What could possibly go wrong? Ship it! lol Regards, Joe p.s. iptables -A INPUT -p tcp --syn --dport 80 \ -m connlimit --connlimit-above 50 -j REJECT
Re: svn commit: r790205 - /httpd/httpd/trunk/modules/experimental/mod_noloris.c
On Wed, Jul 01, 2009 at 03:01:55PM -, n...@apache.org wrote: > Author: niq > Date: Wed Jul 1 15:01:55 2009 > New Revision: 790205 > > URL: http://svn.apache.org/viewvc?rev=790205&view=rev > Log: > mod_noloris just moved from discussion to attracting its first patch > on d...@. That means it wants to be in svn. Adding to modules/experimental > pending anything more definite. 1) A *linear-time* search on a shm segment, using strstr. 2) ... for each new connection. 3) On a shm segment which will get modified in-place by another process 4) ... without locking Awesome! What could possibly go wrong? Ship it! Regards, Joe p.s. iptables -A INPUT -p tcp --syn --dport 80 \ -m connlimit --connlimit-above 50 -j REJECT
