Hide Forgot
Last week a tool, Slowloris, was released designed to perform a denial of service attack against various TCP servers; including Apache, Squid, and others. The Apache Software Foundation treated this as a known issue as: http://httpd.apache.org/docs/trunk/misc/security_tips.html#dos See also http://marc.info/?l=apache-httpd-dev&m=124583517602035 We will continue to monitor this issue and should the Apache team decide there are changes that can help mitigate this issue within Apache itself we will evaluate those and if we can provide them as updates.
Here is an example of an iptables command which can be used to limit the number of concurrent connections that can be established to port 80 from a single client host: # iptables -A INPUT -p tcp --syn --dport 80 \ -m connlimit --connlimit-above 50 -j REJECT
Are you sure this iptables rule works on RHEL? Here's what I get on RHEL5, kernel 2.6.18-128.7.1.el5: [root@ ~]# iptables -A INPUT -p tcp --syn --dport 80 -m connlimit --connlimit-above 50 -j REJECT iptables: Unknown error 4294967295 [root@ ~]#
If even this rule worked, it wouldn't solve the problem as multiple IPs are being used by botnets. One thing that could be tried would killing "dead" port 80 connections as in: iptables -A INPUT -p TCP --dport 80 -m state --state ESTABLISHED -j LIMIT_RATE iptables -A LIMIT_RATE -p tcp --dport 80 -m connrate --connrate 0:$LOWRATELIM -j REJECT But connrate also doesn't work on RHEL5.
(In reply to comment #3) > Are you sure this iptables rule works on RHEL? Here's what I get on RHEL5, > kernel 2.6.18-128.7.1.el5: > > [root@ ~]# iptables -A INPUT -p tcp --syn --dport 80 -m connlimit > --connlimit-above 50 -j REJECT > iptables: Unknown error 4294967295 > [root@ ~]# Support for connlimit in the kernel was added in Red Hat Enterprise Linux 5 via the advisory RHSA-2009:1243, but a bug is preventing it from working correctly. This bug will be addressed soon. See bug 520797.
(In reply to comment #4) > If even this rule worked, it wouldn't solve the problem as multiple IPs are > being used by botnets. > > One thing that could be tried would killing "dead" port 80 connections as in: > > iptables -A INPUT -p TCP --dport 80 -m state --state ESTABLISHED -j LIMIT_RATE > iptables -A LIMIT_RATE -p tcp --dport 80 -m connrate --connrate 0:$LOWRATELIM > -j REJECT > > But connrate also doesn't work on RHEL5. Please file a RFE bug for connrate.
Hi Eugene, There's already a bug for connrate: https://bugzilla.redhat.com/show_bug.cgi?id=185294 It can probably be reopened to avoid duplication.
Links for mod_antiloris, which seems to work for countering slowloris: http://lists.centos.org/pipermail/centos/2009-July/078644.html I'm posting some generic iptables which do 3 things: - blacklist - prevent new connection floods (per IP and overall) - prevent over usage (same IP or set of IPs slowly opening new connections and keeping them open) There rules can't look at the connection rates as connrate is not working. The parameters have to be studied and tuned depending on the situation. Comments are welcome. ###################################### # Special rules for port 80 - help preventing abuses from botnets # bad http hosts present on this file will be dropped BLACKLIST=`cat /usr/local/AS/etc/blacklist.txt` for i in $BLACKLIST; do iptables -A INPUT -p tcp -m tcp --dport http -s $i -j DROP done # IPs which will never be refused - partner hosts WHITELIST=***********INSERT YOUR PERMANENT WHITELIST IPS HERE ************* for i in $WHITELIST; do iptables -A INPUT -p tcp -m tcp --dport http -s $i -j ACCEPT done # don't lower too much - browsers open multiple connections OVERLIM_NEW=500 # overall limit for new connections per second INDILIM_NEW=30 # limit for individual IP, new connections per second - prevents floods INDILIM_CURRENT=200 # limit for individual IP, total connections - prevents overusage CURRENT_EVAL_INTERVAL=300 # interval length for IP usage evaluation iptables -N LIMIT_INDIVIDUAL_NEW iptables -N LIMIT_INDIVIDUAL_CURRENT iptables -N LIMIT_OVERALL_NEW iptables -A INPUT -p tcp --dport 80 -m state --state ESTABLISHED -j LIMIT_INDIVIDUAL_CURRENT iptables -A INPUT -p tcp --dport 80 --syn -m state --state NEW -j LIMIT_INDIVIDUAL_NEW iptables -A LIMIT_INDIVIDUAL_CURRENT -m recent --set iptables -A LIMIT_INDIVIDUAL_CURRENT -p tcp --tcp-flags FIN FIN -m recent --remove iptables -A LIMIT_INDIVIDUAL_CURRENT -m recent --update --seconds $CURRENT_EVAL_INTERVAL --hitcount $INDILIM_CURRENT -j DROP iptables -A LIMIT_INDIVIDUAL_CURRENT -j ACCEPT iptables -A LIMIT_INDIVIDUAL_NEW -m recent --set iptables -A LIMIT_INDIVIDUAL_NEW -m recent --update --seconds 1 --hitcount $INDILIM_NEW -j DROP iptables -A LIMIT_INDIVIDUAL_NEW -j LIMIT_OVERALL_NEW iptables -A LIMIT_OVERALL_NEW -m limit --limit $OVERLIM_NEW/second -j ACCEPT iptables -A LIMIT_OVERALL_NEW -j DROP ######################################
> > I'm posting some generic iptables which do 3 things: > > - blacklist > - prevent new connection floods (per IP and overall) > - prevent over usage (same IP or set of IPs slowly opening new connections and > keeping them open) This should read: slowly opening, using and closing connections so that it doesn't look like a flood but the number of used connections per IP remains higher than desired (ie, abusive).
(In reply to comment #9) > INDILIM_CURRENT=200 ... > iptables -A LIMIT_INDIVIDUAL_CURRENT -m recent --update --seconds > $CURRENT_EVAL_INTERVAL --hitcount $INDILIM_CURRENT -j DROP If you've tweaked ipt_recent parameters already, you may probably want to have a closer look at them and at bug #523977.
(In reply to comment #11) > (In reply to comment #9) > > INDILIM_CURRENT=200 > > ... > > > iptables -A LIMIT_INDIVIDUAL_CURRENT -m recent --update --seconds > > $CURRENT_EVAL_INTERVAL --hitcount $INDILIM_CURRENT -j DROP > > If you've tweaked ipt_recent parameters already, you may probably want to have > a closer look at them and at bug #523977. Thanks for pointing this out. I really hope bugs #520797 and #523977 get solved soon.
This issue has been assigned CVE-2007-6750
mod_reqtimeout can be used to mitigate against the slowloris attack, more details about this module is available at: http://httpd.apache.org/docs/2.2/mod/mod_reqtimeout.html It is available in Apache HTTPD 2.2.15 and later. mod_reqtimeout in now alse available in the version of httpd shipped with Red Hat Enterprise Linux 5: http://rhn.redhat.com/errata/RHBA-2011-1067.html
This issue is mitigated by the use of mod_reqtimeout, which is available by default in httpd >= 2.2.15 (which is included in Red Hat Enterprise Linux 6 and later, and JBoss Enterprise Web Server 1 and later). mod_reqtimeout was introduced to httpd packages in Red Hat Enterprise Linux 5 via RHBA-2011:1067. Statement: This issue affects the version of httpd package as shipped with Red Hat Enterprise Linux 4. This issue is mitigated by the use of mod_reqtimeout module shipped with the httpd package in Red Hat Enterprise Linux 5 and 6.
mod_reqtimeout module is now available in Red Hat Enterprise Linux 5 and later, and JBoss Enterprise Web Server 1 and later. This can be used to configure mitigation against Slowloris attack.
Do not use iptables rules from comment #9 without carefully reviewing them. Restrictions defined by them can be rather easily bypassed, and they may negatively impact non-malicious connections.