From: Ruediger Pluem <rpluem@apache.org>
Date: Tue, 17 Jan 2006 16:14:49 +0000 (+0000)
Subject: * Removed patch again as it clashed with Joshua's on the same topic
X-Git-Tag: 2.3.0~2599
X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=eb1c9b24f7bfceb95173086562f66367a8f3a2a5;p=apache

* Removed patch again as it clashed with Joshua's on the same topic


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@369829 13f79535-47bb-0310-9956-ffa450edef68
---

diff --git a/docs/manual/misc/security_tips.xml b/docs/manual/misc/security_tips.xml
index 70ca087a8a..5a77711872 100644
--- a/docs/manual/misc/security_tips.xml
+++ b/docs/manual/misc/security_tips.xml
@@ -398,58 +398,5 @@
     </example>
     
   </section>
-
-  <section id="timeoutsettings">
-
-    <title>Mitigate the risk of DoS attacks</title>
-
-    <p>DoS attacks on systems that assign one thread / process to a client
-    connection for the duration of the connection are a general problem and well
-    known for a long time. Not only httpd is affected by this problem, but also
-    several other servers of different vendors, e.g. smtp servers, pop3 servers,
-    application servers.</p>
-
-    <p>Usual approaches to mitigate this risk are</p>
-
-    <ol>
-        <li>Set a timeout value for the network operations, such that the
-        connection gets canceled if no data is transmitted on this connection
-        within the timeout period.</li>
-
-        <li>Limit the number of simultaneous connections that can be made from
-        one IP. Of course this is no help against DDoS.</li>
-    </ol>
-
-    <p>Mapping this back to the Apache httpd server 1. can be reached by
-    lowering the value of the parameters
-    <directive module="core">Timeout</directive> and
-    <directive module="core">KeepAliveTimeout</directive>. A value that should
-    work for most sites not using long running CGI scripts is between 5 and 10.
-    Some sites even turn off the keepalives completely, which has of course other
-    drawbacks on performance.</p>
-
-    <p>2. can be reached by either limiting this on firewall / OS level or by
-    using 3rd party httpd modules that limit the number of simultaneous
-    connections from one IP.</p>
-
-    <p>Since httpd 2.2.0 the risk of tying httpd processes / threads in request
-    reads can be further limited by the use of accept filters via the directive 
-    <directive module="core">AcceptFilter</directive>. These are currently only
-    available on Linux and FreeBSD systems. The protection by the FreeBSD accept
-    filters is better than by Linux's more primitive TCP_DEFER_ACCEPT. For more
-    details see the link above.</p>
-
-    <p>Another approach to mitigate this risk is to decouple the fixed one
-    thread / process to one client connection assignment and change it to an
-    event driven modell, that assigns threads / processes to the connection
-    only when there is data available to process. During the time where there
-    is no data available the client connections do not block a thread / process
-    but are only watched by one common event thread for new data to arrive via
-    system calls like poll. This is currently work in progress on the trunk
-    (development branch of httpd). It might be part of the next stable major
-    release (2.4 or 3.0). Parts of this are already available as the
-    experimental event MPM in httpd 2.2.x (see <module>event</module>).</p>
-
-  </section>
   
 </manualpage>