Nicola Bianchi | 23 Jun 15:49

Apache hang on https protocol violation

Hi people,
I'm a new modsecurity user and I've a problem which maybe some of you can resolve ;).

My configuration is: reverse proxy (http/https) with apache 2.2.9 and modsecurity 2.5.5 (core rules 2.5-1.6.1) on Linux SUSE SLES10.
Hardware: 2CPU dual core Intel(R) Xeon(R) <at> 2.33GHz, 4GB of RAM

If I try this benchmark all work fine, without problem:
 ab -k -c 200 -n 8000 http://www.mysite.com/
 ab -k -c 200 -n 8000 https://www.mysite.com/

... no lost requests, no particular delay.

The problem come out if I try to do a "DOS attack" pointing directly to the ip address of mysite in https
After few request (~200) apache hang and stop responding ...

 ab -k -c 200 -n 8000 https://192.168.168.100/).
#############################################################################
# This is ApacheBench, Version 2.3 <$Revision: 655654 $>
# Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
# Licensed to The Apache Software Foundation, http://www.apache.org/
#
# Benchmarking 192.168.168.100 (be patient)
# Completed 200 requests
# apr_poll: The timeout specified has expired (70007)
# Total of 272 requests completed
#############################################################################

Here an extract from the logs:
#############################################################################
Jun 23 14:31:47 ulxbwaf httpd[8103]: [error] [client 192.168.168.168] ModSecurity: Access denied with code 400 (phase 2). Pattern match "^[\\d\\.]+$" at REQUEST_HEADERS:Host. [file "/opt/jail/opt/waf/mod_security/prod/conf/core_rules/modsecurity_crs_21_protocol_anomalies.conf"] [line "60"] [id "960017"] [msg "Host header is a numeric IP address"] [severity "CRITICAL"] [tag "PROTOCOL_VIOLATION/IP_HOST"] [hostname "192.168.168.100"] [uri "/"] [unique_id "SF <at> XssIL0NIAAB <at> ncMAAAACI"]
#############################################################################

If I turn off modsecurity (SecRuleEngine Off) and I repeat the test I don't have problem!
If I disable the specific rule (SecRuleRemoveById "960017") all work fine!

So, have you some idea about this issue?
How can I prevent this kind of "DOS attack"?

Thanks a lot! Regards
 Nick

PS: sorry for my ridicolous english ;)

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
mod-security-users mailing list
mod-security-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users
Ivan Ristic | 24 Jun 18:14

Re: Apache hang on https protocol violation

Hi Nicola,

We'll have to try to reproduce your problem somehow, as it doesn't
happen in my tests. I've been using ab constantly over the years for
testing, and I don't recall any problems either.

Are you using mlogc or any other mechanism to transmit alerts elsewhere?

On Mon, Jun 23, 2008 at 2:51 PM, Nicola Bianchi
<bianchi.nicola <at> gmail.com> wrote:
> Hi people,
> I'm a new modsecurity user and I've a problem which maybe some of you can
> resolve ;).
>
> My configuration is: reverse proxy (http/https) with apache 2.2.9 and
> modsecurity 2.5.5 (core rules 2.5-1.6.1) on Linux SUSE SLES10.
> Hardware: 2CPU dual core Intel(R) Xeon(R) @ 2.33GHz, 4GB of RAM
>
> If I try this benchmark all work fine, without problem:
>  ab -k -c 200 -n 8000 http://www.mysite.com/
>  ab -k -c 200 -n 8000 https://www.mysite.com/
>
> ... no lost requests, no particular delay.
>
> The problem come out if I try to do a "DOS attack" pointing directly to the
> ip address of mysite in https
> After few request (~200) apache hang and stop responding ...
>
>  ab -k -c 200 -n 8000 https://192.168.168.100/).
> #############################################################################
> # This is ApacheBench, Version 2.3 <$Revision: 655654 $>
> # Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
> # Licensed to The Apache Software Foundation, http://www.apache.org/
> #
> # Benchmarking 192.168.168.100 (be patient)
> # Completed 200 requests
> # apr_poll: The timeout specified has expired (70007)
> # Total of 272 requests completed
> #############################################################################
>
> Here an extract from the logs:
> #############################################################################
> Jun 23 14:31:47 ulxbwaf httpd[8103]: [error] [client 192.168.168.168]
> ModSecurity: Access denied with code 400 (phase 2). Pattern match
> "^[\\d\\.]+$" at REQUEST_HEADERS:Host. [file
> "/opt/jail/opt/waf/mod_security/prod/conf/core_rules/modsecurity_crs_21_protocol_anomalies.conf"]
> [line "60"] [id "960017"] [msg "Host header is a numeric IP address"]
> [severity "CRITICAL"] [tag "PROTOCOL_VIOLATION/IP_HOST"] [hostname
> "192.168.168.100"] [uri "/"] [unique_id "SF <at> XssIL0NIAAB <at> ncMAAAACI"]
> #############################################################################
>
> If I turn off modsecurity (SecRuleEngine Off) and I repeat the test I don't
> have problem!
> If I disable the specific rule (SecRuleRemoveById "960017") all work fine!
>
> So, have you some idea about this issue?
> How can I prevent this kind of "DOS attack"?
>
> Thanks a lot! Regards
>  Nick
>
> PS: sorry for my ridicolous english ;)
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> mod-security-users mailing list
> mod-security-users <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
>
>

--

-- 
Ivan Ristic

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
Brian Rectanus | 24 Jun 19:18

Re: Apache hang on https protocol violation

Nicola,

I need to be able to duplicate this problem.  Would you please send your
settings for Apache and modsecurity?

For ModSecurity, I need your config settings (usually in
modsecurity_crs_10_config.conf) and which other files you are including.

For Apache I at least need these:

1. Output from "httpd -V" and "httpd -l"

2. Values for the following directives:

ServerLimit
StartServers
MaxClients
MinSpareThreads
MaxSpareThreads
ThreadsPerChild
MaxRequestsPerChild
MaxRequestsPerThread
KeepAlive
KeepAliveTimeout

3. As well as your config for proxying (Balancer, ProxyPass, etc)?

4. Additionally, your entire error_log at at least level "info" (cleared
before the test), the server-status output during (or near) the hang and
CPU/Mem usage stats during the test would be nice as well.

thanks,
-B

Ivan Ristic wrote:
> Hi Nicola,
> 
> We'll have to try to reproduce your problem somehow, as it doesn't
> happen in my tests. I've been using ab constantly over the years for
> testing, and I don't recall any problems either.
> 
> Are you using mlogc or any other mechanism to transmit alerts elsewhere?
> 
> 
> On Mon, Jun 23, 2008 at 2:51 PM, Nicola Bianchi
> <bianchi.nicola <at> gmail.com> wrote:
>> Hi people,
>> I'm a new modsecurity user and I've a problem which maybe some of you can
>> resolve ;).
>>
>> My configuration is: reverse proxy (http/https) with apache 2.2.9 and
>> modsecurity 2.5.5 (core rules 2.5-1.6.1) on Linux SUSE SLES10.
>> Hardware: 2CPU dual core Intel(R) Xeon(R) @ 2.33GHz, 4GB of RAM
>>
>> If I try this benchmark all work fine, without problem:
>>  ab -k -c 200 -n 8000 http://www.mysite.com/
>>  ab -k -c 200 -n 8000 https://www.mysite.com/
>>
>> ... no lost requests, no particular delay.
>>
>> The problem come out if I try to do a "DOS attack" pointing directly
> to the
>> ip address of mysite in https
>> After few request (~200) apache hang and stop responding ...
>>
>>  ab -k -c 200 -n 8000 https://192.168.168.100/).
>>
> #############################################################################
>> # This is ApacheBench, Version 2.3 <$Revision: 655654 $>
>> # Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
>> # Licensed to The Apache Software Foundation, http://www.apache.org/
>> #
>> # Benchmarking 192.168.168.100 (be patient)
>> # Completed 200 requests
>> # apr_poll: The timeout specified has expired (70007)
>> # Total of 272 requests completed
>>
> #############################################################################
>>
>> Here an extract from the logs:
>>
> #############################################################################
>> Jun 23 14:31:47 ulxbwaf httpd[8103]: [error] [client 192.168.168.168]
>> ModSecurity: Access denied with code 400 (phase 2). Pattern match
>> "^[\\d\\.]+$" at REQUEST_HEADERS:Host. [file
>>
> "/opt/jail/opt/waf/mod_security/prod/conf/core_rules/modsecurity_crs_21_protocol_anomalies.conf"]
>> [line "60"] [id "960017"] [msg "Host header is a numeric IP address"]
>> [severity "CRITICAL"] [tag "PROTOCOL_VIOLATION/IP_HOST"] [hostname
>> "192.168.168.100"] [uri "/"] [unique_id "SF <at> XssIL0NIAAB <at> ncMAAAACI"]
>>
> #############################################################################
>>
>> If I turn off modsecurity (SecRuleEngine Off) and I repeat the test I
> don't
>> have problem!
>> If I disable the specific rule (SecRuleRemoveById "960017") all work fine!
>>
>> So, have you some idea about this issue?
>> How can I prevent this kind of "DOS attack"?
>>
>> Thanks a lot! Regards
>>  Nick
>>
>> PS: sorry for my ridicolous english ;)
>>
>> -------------------------------------------------------------------------
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services for
>> just about anything Open Source.
>> http://sourceforge.net/services/buy/index.php
>> _______________________________________________
>> mod-security-users mailing list
>> mod-security-users <at> lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mod-security-users
>>
>>
> 
> 
> 
> --
> Ivan Ristic
> 
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> mod-security-users mailing list
> mod-security-users <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> 

--

-- 
Brian Rectanus
Breach Security

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
Nicola Bianchi | 24 Jun 19:34

Re: Apache hang on https protocol violation

Hi Ivan,
yes, I use mlogc to send logs to the console (via http).
Maybe the problem is there ?

Tomorrow I'll try to disable the remote logging ;)

Thaks a lot. Regards.
  Nicola

On Tue, Jun 24, 2008 at 6:14 PM, Ivan Ristic <ivan.ristic <at> gmail.com> wrote:
Hi Nicola,

We'll have to try to reproduce your problem somehow, as it doesn't
happen in my tests. I've been using ab constantly over the years for
testing, and I don't recall any problems either.

Are you using mlogc or any other mechanism to transmit alerts elsewhere?


On Mon, Jun 23, 2008 at 2:51 PM, Nicola Bianchi
<bianchi.nicola <at> gmail.com> wrote:
> Hi people,
> I'm a new modsecurity user and I've a problem which maybe some of you can
> resolve ;).
>
> My configuration is: reverse proxy (http/https) with apache 2.2.9 and
> modsecurity 2.5.5 (core rules 2.5-1.6.1) on Linux SUSE SLES10.
> Hardware: 2CPU dual core Intel(R) Xeon(R) <at> 2.33GHz, 4GB of RAM
>
> If I try this benchmark all work fine, without problem:
>  ab -k -c 200 -n 8000 http://www.mysite.com/
>  ab -k -c 200 -n 8000 https://www.mysite.com/
>
> ... no lost requests, no particular delay.
>
> The problem come out if I try to do a "DOS attack" pointing directly to the
> ip address of mysite in https
> After few request (~200) apache hang and stop responding ...
>
>  ab -k -c 200 -n 8000 https://192.168.168.100/).
> #############################################################################
> # This is ApacheBench, Version 2.3 <$Revision: 655654 $>
> # Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
> # Licensed to The Apache Software Foundation, http://www.apache.org/
> #
> # Benchmarking 192.168.168.100 (be patient)
> # Completed 200 requests
> # apr_poll: The timeout specified has expired (70007)
> # Total of 272 requests completed
> #############################################################################
>
> Here an extract from the logs:
> #############################################################################
> Jun 23 14:31:47 ulxbwaf httpd[8103]: [error] [client 192.168.168.168]
> ModSecurity: Access denied with code 400 (phase 2). Pattern match
> "^[\\d\\.]+$" at REQUEST_HEADERS:Host. [file
> "/opt/jail/opt/waf/mod_security/prod/conf/core_rules/modsecurity_crs_21_protocol_anomalies.conf"]
> [line "60"] [id "960017"] [msg "Host header is a numeric IP address"]
> [severity "CRITICAL"] [tag "PROTOCOL_VIOLATION/IP_HOST"] [hostname
> "192.168.168.100"] [uri "/"] [unique_id "SF <at> XssIL0NIAAB <at> ncMAAAACI"]
> #############################################################################
>
> If I turn off modsecurity (SecRuleEngine Off) and I repeat the test I don't
> have problem!
> If I disable the specific rule (SecRuleRemoveById "960017") all work fine!
>
> So, have you some idea about this issue?
> How can I prevent this kind of "DOS attack"?
>
> Thanks a lot! Regards
>  Nick
>
> PS: sorry for my ridicolous english ;)
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> mod-security-users mailing list
> mod-security-users <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
>
>



--
Ivan Ristic

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
mod-security-users mailing list
mod-security-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users
Ivan Ristic | 24 Jun 19:44

Re: Apache hang on https protocol violation

I think the old Perl script was known to cause problems under load.

Mlogc has been tested under heavy load, so that shouldn't be an issue.
But testing without it will demonstrate that the problem is not in
mlogc.

On Tue, Jun 24, 2008 at 6:34 PM, Nicola Bianchi
<bianchi.nicola <at> gmail.com> wrote:
> Hi Ivan,
> yes, I use mlogc to send logs to the console (via http).
> Maybe the problem is there ?
>
> Tomorrow I'll try to disable the remote logging ;)
>
> Thaks a lot. Regards.
>   Nicola
>
> On Tue, Jun 24, 2008 at 6:14 PM, Ivan Ristic <ivan.ristic <at> gmail.com> wrote:
>>
>> Hi Nicola,
>>
>> We'll have to try to reproduce your problem somehow, as it doesn't
>> happen in my tests. I've been using ab constantly over the years for
>> testing, and I don't recall any problems either.
>>
>> Are you using mlogc or any other mechanism to transmit alerts elsewhere?
>>
>>
>> On Mon, Jun 23, 2008 at 2:51 PM, Nicola Bianchi
>> <bianchi.nicola <at> gmail.com> wrote:
>> > Hi people,
>> > I'm a new modsecurity user and I've a problem which maybe some of you
>> > can
>> > resolve ;).
>> >
>> > My configuration is: reverse proxy (http/https) with apache 2.2.9 and
>> > modsecurity 2.5.5 (core rules 2.5-1.6.1) on Linux SUSE SLES10.
>> > Hardware: 2CPU dual core Intel(R) Xeon(R) @ 2.33GHz, 4GB of RAM
>> >
>> > If I try this benchmark all work fine, without problem:
>> >  ab -k -c 200 -n 8000 http://www.mysite.com/
>> >  ab -k -c 200 -n 8000 https://www.mysite.com/
>> >
>> > ... no lost requests, no particular delay.
>> >
>> > The problem come out if I try to do a "DOS attack" pointing directly to
>> > the
>> > ip address of mysite in https
>> > After few request (~200) apache hang and stop responding ...
>> >
>> >  ab -k -c 200 -n 8000 https://192.168.168.100/).
>> >
>> > #############################################################################
>> > # This is ApacheBench, Version 2.3 <$Revision: 655654 $>
>> > # Copyright 1996 Adam Twiss, Zeus Technology Ltd,
>> > http://www.zeustech.net/
>> > # Licensed to The Apache Software Foundation, http://www.apache.org/
>> > #
>> > # Benchmarking 192.168.168.100 (be patient)
>> > # Completed 200 requests
>> > # apr_poll: The timeout specified has expired (70007)
>> > # Total of 272 requests completed
>> >
>> > #############################################################################
>> >
>> > Here an extract from the logs:
>> >
>> > #############################################################################
>> > Jun 23 14:31:47 ulxbwaf httpd[8103]: [error] [client 192.168.168.168]
>> > ModSecurity: Access denied with code 400 (phase 2). Pattern match
>> > "^[\\d\\.]+$" at REQUEST_HEADERS:Host. [file
>> >
>> > "/opt/jail/opt/waf/mod_security/prod/conf/core_rules/modsecurity_crs_21_protocol_anomalies.conf"]
>> > [line "60"] [id "960017"] [msg "Host header is a numeric IP address"]
>> > [severity "CRITICAL"] [tag "PROTOCOL_VIOLATION/IP_HOST"] [hostname
>> > "192.168.168.100"] [uri "/"] [unique_id "SF <at> XssIL0NIAAB <at> ncMAAAACI"]
>> >
>> > #############################################################################
>> >
>> > If I turn off modsecurity (SecRuleEngine Off) and I repeat the test I
>> > don't
>> > have problem!
>> > If I disable the specific rule (SecRuleRemoveById "960017") all work
>> > fine!
>> >
>> > So, have you some idea about this issue?
>> > How can I prevent this kind of "DOS attack"?
>> >
>> > Thanks a lot! Regards
>> >  Nick
>> >
>> > PS: sorry for my ridicolous english ;)
>> >
>> >
>> > -------------------------------------------------------------------------
>> > Check out the new SourceForge.net Marketplace.
>> > It's the best place to buy or sell services for
>> > just about anything Open Source.
>> > http://sourceforge.net/services/buy/index.php
>> > _______________________________________________
>> > mod-security-users mailing list
>> > mod-security-users <at> lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/mod-security-users
>> >
>> >
>>
>>
>>
>> --
>> Ivan Ristic
>
>

--

-- 
Ivan Ristic

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
Nicola Bianchi | 25 Jun 09:26

Re: Apache hang on https protocol violation

Hi Ivan,
I've tested the environment with this line commented out:
#SecAuditLog "|bin/mlogc /opt/waf/mod_security/prod/bin/mlogc.conf"

And...

./ab -k -c 200 -n 2000 https://192.168.168.100/
##################################################################
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 192.168.168.100 (be patient)
Completed 200 requests
Completed 400 requests
Completed 600 requests
Completed 800 requests
Completed 1000 requests
Completed 1200 requests
Completed 1400 requests
Completed 1600 requests
Completed 1800 requests
Completed 2000 requests
Finished 2000 requests


Server Software:       
Server Hostname:        192.168.168.100
Server Port:            443
SSL/TLS Protocol:       TLSv1/SSLv3,DHE-RSA-AES256-SHA,1024,256

Document Path:          /
Document Length:        226 bytes

Concurrency Level:      200
Time taken for tests:   100.266 seconds
Complete requests:      2000
Failed requests:        0
Write errors:           0
Non-2xx responses:      2000
Keep-Alive requests:    0
Total transferred:      752000 bytes
HTML transferred:       452000 bytes
Requests per second:    19.95 [#/sec] (mean)
Time per request:       10026.647 [ms] (mean)
Time per request:       50.133 [ms] (mean, across all concurrent requests)
Transfer rate:          7.32 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       61 2570 2798.0   1659   15258
Processing:    23 7299 14277.7   2397   62731
Waiting:       23 2586 2898.5   1753   21923
Total:         92 9869 15324.2   5277   67583

Percentage of the requests served within a certain time (ms)
  50%   5277
  66%   9082
  75%  10876
  80%  12432
  90%  24629
  95%  54867
  98%  59465
  99%  61960
 100%  67583 (longest request)
##################################################################

Maybe a problem with mlogc is not to be excluded?

Have a nice day!
  Nick


On Tue, Jun 24, 2008 at 7:44 PM, Ivan Ristic <ivan.ristic <at> gmail.com> wrote:
I think the old Perl script was known to cause problems under load.

Mlogc has been tested under heavy load, so that shouldn't be an issue.
But testing without it will demonstrate that the problem is not in
mlogc.

On Tue, Jun 24, 2008 at 6:34 PM, Nicola Bianchi
<bianchi.nicola <at> gmail.com> wrote:
> Hi Ivan,
> yes, I use mlogc to send logs to the console (via http).
> Maybe the problem is there ?
>
> Tomorrow I'll try to disable the remote logging ;)
>
> Thaks a lot. Regards.
>   Nicola
>
> On Tue, Jun 24, 2008 at 6:14 PM, Ivan Ristic <ivan.ristic <at> gmail.com> wrote:
>>
>> Hi Nicola,
>>
>> We'll have to try to reproduce your problem somehow, as it doesn't
>> happen in my tests. I've been using ab constantly over the years for
>> testing, and I don't recall any problems either.
>>
>> Are you using mlogc or any other mechanism to transmit alerts elsewhere?
>>
>>
>> On Mon, Jun 23, 2008 at 2:51 PM, Nicola Bianchi
>> <bianchi.nicola <at> gmail.com> wrote:
>> > Hi people,
>> > I'm a new modsecurity user and I've a problem which maybe some of you
>> > can
>> > resolve ;).
>> >
>> > My configuration is: reverse proxy (http/https) with apache 2.2.9 and
>> > modsecurity 2.5.5 (core rules 2.5-1.6.1) on Linux SUSE SLES10.
>> > Hardware: 2CPU dual core Intel(R) Xeon(R) <at> 2.33GHz, 4GB of RAM
>> >
>> > If I try this benchmark all work fine, without problem:
>> >  ab -k -c 200 -n 8000 http://www.mysite.com/
>> >  ab -k -c 200 -n 8000 https://www.mysite.com/
>> >
>> > ... no lost requests, no particular delay.
>> >
>> > The problem come out if I try to do a "DOS attack" pointing directly to
>> > the
>> > ip address of mysite in https
>> > After few request (~200) apache hang and stop responding ...
>> >
>> >  ab -k -c 200 -n 8000 https://192.168.168.100/).
>> >
>> > #############################################################################
>> > # This is ApacheBench, Version 2.3 <$Revision: 655654 $>
>> > # Copyright 1996 Adam Twiss, Zeus Technology Ltd,
>> > http://www.zeustech.net/
>> > # Licensed to The Apache Software Foundation, http://www.apache.org/
>> > #
>> > # Benchmarking 192.168.168.100 (be patient)
>> > # Completed 200 requests
>> > # apr_poll: The timeout specified has expired (70007)
>> > # Total of 272 requests completed
>> >
>> > #############################################################################
>> >
>> > Here an extract from the logs:
>> >
>> > #############################################################################
>> > Jun 23 14:31:47 ulxbwaf httpd[8103]: [error] [client 192.168.168.168]
>> > ModSecurity: Access denied with code 400 (phase 2). Pattern match
>> > "^[\\d\\.]+$" at REQUEST_HEADERS:Host. [file
>> >
>> > "/opt/jail/opt/waf/mod_security/prod/conf/core_rules/modsecurity_crs_21_protocol_anomalies.conf"]
>> > [line "60"] [id "960017"] [msg "Host header is a numeric IP address"]
>> > [severity "CRITICAL"] [tag "PROTOCOL_VIOLATION/IP_HOST"] [hostname
>> > "192.168.168.100"] [uri "/"] [unique_id "SF <at> XssIL0NIAAB <at> ncMAAAACI"]
>> >
>> > #############################################################################
>> >
>> > If I turn off modsecurity (SecRuleEngine Off) and I repeat the test I
>> > don't
>> > have problem!
>> > If I disable the specific rule (SecRuleRemoveById "960017") all work
>> > fine!
>> >
>> > So, have you some idea about this issue?
>> > How can I prevent this kind of "DOS attack"?
>> >
>> > Thanks a lot! Regards
>> >  Nick
>> >
>> > PS: sorry for my ridicolous english ;)
>> >
>> >
>> > -------------------------------------------------------------------------
>> > Check out the new SourceForge.net Marketplace.
>> > It's the best place to buy or sell services for
>> > just about anything Open Source.
>> > http://sourceforge.net/services/buy/index.php
>> > _______________________________________________
>> > mod-security-users mailing list
>> > mod-security-users <at> lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/mod-security-users
>> >
>> >
>>
>>
>>
>> --
>> Ivan Ristic
>
>



--
Ivan Ristic

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
mod-security-users mailing list
mod-security-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users
Ivan Ristic | 25 Jun 13:01

Re: Apache hang on https protocol violation

Good, we've narrowed it down quickly.

Are you using the mlogc version that comes with ModSecurity 2.5.5? Is
not working as expected (when not under load)?

On Wed, Jun 25, 2008 at 8:26 AM, Nicola Bianchi
<bianchi.nicola <at> gmail.com> wrote:
> Hi Ivan,
> I've tested the environment with this line commented out:
> #SecAuditLog "|bin/mlogc /opt/waf/mod_security/prod/bin/mlogc.conf"
>
> And...
>
> ./ab -k -c 200 -n 2000 https://192.168.168.100/
> ##################################################################
> This is ApacheBench, Version 2.3 <$Revision: 655654 $>
> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
> Licensed to The Apache Software Foundation, http://www.apache.org/
>
> Benchmarking 192.168.168.100 (be patient)
> Completed 200 requests
> Completed 400 requests
> Completed 600 requests
> Completed 800 requests
> Completed 1000 requests
> Completed 1200 requests
> Completed 1400 requests
> Completed 1600 requests
> Completed 1800 requests
> Completed 2000 requests
> Finished 2000 requests
>
>
> Server Software:
> Server Hostname:        192.168.168.100
> Server Port:            443
> SSL/TLS Protocol:       TLSv1/SSLv3,DHE-RSA-AES256-SHA,1024,256
>
> Document Path:          /
> Document Length:        226 bytes
>
> Concurrency Level:      200
> Time taken for tests:   100.266 seconds
> Complete requests:      2000
> Failed requests:        0
> Write errors:           0
> Non-2xx responses:      2000
> Keep-Alive requests:    0
> Total transferred:      752000 bytes
> HTML transferred:       452000 bytes
> Requests per second:    19.95 [#/sec] (mean)
> Time per request:       10026.647 [ms] (mean)
> Time per request:       50.133 [ms] (mean, across all concurrent requests)
> Transfer rate:          7.32 [Kbytes/sec] received
>
> Connection Times (ms)
>               min  mean[+/-sd] median   max
> Connect:       61 2570 2798.0   1659   15258
> Processing:    23 7299 14277.7   2397   62731
> Waiting:       23 2586 2898.5   1753   21923
> Total:         92 9869 15324.2   5277   67583
>
> Percentage of the requests served within a certain time (ms)
>   50%   5277
>   66%   9082
>   75%  10876
>   80%  12432
>   90%  24629
>   95%  54867
>   98%  59465
>   99%  61960
>  100%  67583 (longest request)
> ##################################################################
>
> Maybe a problem with mlogc is not to be excluded?
>
> Have a nice day!
>   Nick
>
>
> On Tue, Jun 24, 2008 at 7:44 PM, Ivan Ristic <ivan.ristic <at> gmail.com> wrote:
>>
>> I think the old Perl script was known to cause problems under load.
>>
>> Mlogc has been tested under heavy load, so that shouldn't be an issue.
>> But testing without it will demonstrate that the problem is not in
>> mlogc.
>>
>> On Tue, Jun 24, 2008 at 6:34 PM, Nicola Bianchi
>> <bianchi.nicola <at> gmail.com> wrote:
>> > Hi Ivan,
>> > yes, I use mlogc to send logs to the console (via http).
>> > Maybe the problem is there ?
>> >
>> > Tomorrow I'll try to disable the remote logging ;)
>> >
>> > Thaks a lot. Regards.
>> >   Nicola
>> >
>> > On Tue, Jun 24, 2008 at 6:14 PM, Ivan Ristic <ivan.ristic <at> gmail.com>
>> > wrote:
>> >>
>> >> Hi Nicola,
>> >>
>> >> We'll have to try to reproduce your problem somehow, as it doesn't
>> >> happen in my tests. I've been using ab constantly over the years for
>> >> testing, and I don't recall any problems either.
>> >>
>> >> Are you using mlogc or any other mechanism to transmit alerts
>> >> elsewhere?
>> >>
>> >>
>> >> On Mon, Jun 23, 2008 at 2:51 PM, Nicola Bianchi
>> >> <bianchi.nicola <at> gmail.com> wrote:
>> >> > Hi people,
>> >> > I'm a new modsecurity user and I've a problem which maybe some of you
>> >> > can
>> >> > resolve ;).
>> >> >
>> >> > My configuration is: reverse proxy (http/https) with apache 2.2.9 and
>> >> > modsecurity 2.5.5 (core rules 2.5-1.6.1) on Linux SUSE SLES10.
>> >> > Hardware: 2CPU dual core Intel(R) Xeon(R) @ 2.33GHz, 4GB of RAM
>> >> >
>> >> > If I try this benchmark all work fine, without problem:
>> >> >  ab -k -c 200 -n 8000 http://www.mysite.com/
>> >> >  ab -k -c 200 -n 8000 https://www.mysite.com/
>> >> >
>> >> > ... no lost requests, no particular delay.
>> >> >
>> >> > The problem come out if I try to do a "DOS attack" pointing directly
>> >> > to
>> >> > the
>> >> > ip address of mysite in https
>> >> > After few request (~200) apache hang and stop responding ...
>> >> >
>> >> >  ab -k -c 200 -n 8000 https://192.168.168.100/).
>> >> >
>> >> >
>> >> > #############################################################################
>> >> > # This is ApacheBench, Version 2.3 <$Revision: 655654 $>
>> >> > # Copyright 1996 Adam Twiss, Zeus Technology Ltd,
>> >> > http://www.zeustech.net/
>> >> > # Licensed to The Apache Software Foundation, http://www.apache.org/
>> >> > #
>> >> > # Benchmarking 192.168.168.100 (be patient)
>> >> > # Completed 200 requests
>> >> > # apr_poll: The timeout specified has expired (70007)
>> >> > # Total of 272 requests completed
>> >> >
>> >> >
>> >> > #############################################################################
>> >> >
>> >> > Here an extract from the logs:
>> >> >
>> >> >
>> >> > #############################################################################
>> >> > Jun 23 14:31:47 ulxbwaf httpd[8103]: [error] [client 192.168.168.168]
>> >> > ModSecurity: Access denied with code 400 (phase 2). Pattern match
>> >> > "^[\\d\\.]+$" at REQUEST_HEADERS:Host. [file
>> >> >
>> >> >
>> >> > "/opt/jail/opt/waf/mod_security/prod/conf/core_rules/modsecurity_crs_21_protocol_anomalies.conf"]
>> >> > [line "60"] [id "960017"] [msg "Host header is a numeric IP address"]
>> >> > [severity "CRITICAL"] [tag "PROTOCOL_VIOLATION/IP_HOST"] [hostname
>> >> > "192.168.168.100"] [uri "/"] [unique_id "SF <at> XssIL0NIAAB <at> ncMAAAACI"]
>> >> >
>> >> >
>> >> > #############################################################################
>> >> >
>> >> > If I turn off modsecurity (SecRuleEngine Off) and I repeat the test I
>> >> > don't
>> >> > have problem!
>> >> > If I disable the specific rule (SecRuleRemoveById "960017") all work
>> >> > fine!
>> >> >
>> >> > So, have you some idea about this issue?
>> >> > How can I prevent this kind of "DOS attack"?
>> >> >
>> >> > Thanks a lot! Regards
>> >> >  Nick
>> >> >
>> >> > PS: sorry for my ridicolous english ;)
>> >> >
>> >> >
>> >> >
>> >> > -------------------------------------------------------------------------
>> >> > Check out the new SourceForge.net Marketplace.
>> >> > It's the best place to buy or sell services for
>> >> > just about anything Open Source.
>> >> > http://sourceforge.net/services/buy/index.php
>> >> > _______________________________________________
>> >> > mod-security-users mailing list
>> >> > mod-security-users <at> lists.sourceforge.net
>> >> > https://lists.sourceforge.net/lists/listinfo/mod-security-users
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Ivan Ristic
>> >
>> >
>>
>>
>>
>> --
>> Ivan Ristic
>
>

--

-- 
Ivan Ristic

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
Nicola Bianchi | 25 Jun 16:23

Re: Apache hang on https protocol violation

Hi Ivan,
I use the version 2.5.5...
but...
after a check it seems that the mlogc don't work... on the console I don't see anything, no connection initailized by the mlogc.
With the old perl script it work.

Here my configuration, for sure something is wrong :(
##########################
#### grep -v "^#" mlogc.conf | grep ..
CollectorRoot       "/opt/jail/opt/waf/mod_security/prod"
ConsoleURI          "http://192.168.9.120:8886/rpc/auditLogReceiver"
SensorUsername      "ulxbwaf2"
SensorPassword      "xxxxxxx"
LogStorageDir       "logs/modsec_audit"
TransactionLog      "logs/mlogc-transaction.log"
QueuePath           "logs/mlogc-queue.log"
ErrorLog            "logs/mlogc-error.log"
KeepEntries         0
ErrorLogLevel       3
MaxConnections      10
TransactionDelay    50
StartupDelay    1000
CheckpointInterval  15
ServerErrorTimeout  60
###########################

However I think the apache server does not to hang for a problem with the console, right?

Regards.
  nick

On Wed, Jun 25, 2008 at 1:01 PM, Ivan Ristic <ivan.ristic <at> gmail.com> wrote:
Good, we've narrowed it down quickly.

Are you using the mlogc version that comes with ModSecurity 2.5.5? Is
not working as expected (when not under load)?

On Wed, Jun 25, 2008 at 8:26 AM, Nicola Bianchi
<bianchi.nicola <at> gmail.com> wrote:
> Hi Ivan,
> I've tested the environment with this line commented out:
> #SecAuditLog "|bin/mlogc /opt/waf/mod_security/prod/bin/mlogc.conf"
>
> And...
>
> ./ab -k -c 200 -n 2000 https://192.168.168.100/
> ##################################################################
> This is ApacheBench, Version 2.3 <$Revision: 655654 $>
> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
> Licensed to The Apache Software Foundation, http://www.apache.org/
>
> Benchmarking 192.168.168.100 (be patient)
> Completed 200 requests
> Completed 400 requests
> Completed 600 requests
> Completed 800 requests
> Completed 1000 requests
> Completed 1200 requests
> Completed 1400 requests
> Completed 1600 requests
> Completed 1800 requests
> Completed 2000 requests
> Finished 2000 requests
>
>
> Server Software:
> Server Hostname:        192.168.168.100
> Server Port:            443
> SSL/TLS Protocol:       TLSv1/SSLv3,DHE-RSA-AES256-SHA,1024,256
>
> Document Path:          /
> Document Length:        226 bytes
>
> Concurrency Level:      200
> Time taken for tests:   100.266 seconds
> Complete requests:      2000
> Failed requests:        0
> Write errors:           0
> Non-2xx responses:      2000
> Keep-Alive requests:    0
> Total transferred:      752000 bytes
> HTML transferred:       452000 bytes
> Requests per second:    19.95 [#/sec] (mean)
> Time per request:       10026.647 [ms] (mean)
> Time per request:       50.133 [ms] (mean, across all concurrent requests)
> Transfer rate:          7.32 [Kbytes/sec] received
>
> Connection Times (ms)
>               min  mean[+/-sd] median   max
> Connect:       61 2570 2798.0   1659   15258
> Processing:    23 7299 14277.7   2397   62731
> Waiting:       23 2586 2898.5   1753   21923
> Total:         92 9869 15324.2   5277   67583
>
> Percentage of the requests served within a certain time (ms)
>   50%   5277
>   66%   9082
>   75%  10876
>   80%  12432
>   90%  24629
>   95%  54867
>   98%  59465
>   99%  61960
>  100%  67583 (longest request)
> ##################################################################
>
> Maybe a problem with mlogc is not to be excluded?
>
> Have a nice day!
>   Nick
>
>
> On Tue, Jun 24, 2008 at 7:44 PM, Ivan Ristic <ivan.ristic <at> gmail.com> wrote:
>>
>> I think the old Perl script was known to cause problems under load.
>>
>> Mlogc has been tested under heavy load, so that shouldn't be an issue.
>> But testing without it will demonstrate that the problem is not in
>> mlogc.
>>
>> On Tue, Jun 24, 2008 at 6:34 PM, Nicola Bianchi
>> <bianchi.nicola <at> gmail.com> wrote:
>> > Hi Ivan,
>> > yes, I use mlogc to send logs to the console (via http).
>> > Maybe the problem is there ?
>> >
>> > Tomorrow I'll try to disable the remote logging ;)
>> >
>> > Thaks a lot. Regards.
>> >   Nicola
>> >
>> > On Tue, Jun 24, 2008 at 6:14 PM, Ivan Ristic <ivan.ristic <at> gmail.com>
>> > wrote:
>> >>
>> >> Hi Nicola,
>> >>
>> >> We'll have to try to reproduce your problem somehow, as it doesn't
>> >> happen in my tests. I've been using ab constantly over the years for
>> >> testing, and I don't recall any problems either.
>> >>
>> >> Are you using mlogc or any other mechanism to transmit alerts
>> >> elsewhere?
>> >>
>> >>
>> >> On Mon, Jun 23, 2008 at 2:51 PM, Nicola Bianchi
>> >> <bianchi.nicola <at> gmail.com> wrote:
>> >> > Hi people,
>> >> > I'm a new modsecurity user and I've a problem which maybe some of you
>> >> > can
>> >> > resolve ;).
>> >> >
>> >> > My configuration is: reverse proxy (http/https) with apache 2.2.9 and
>> >> > modsecurity 2.5.5 (core rules 2.5-1.6.1) on Linux SUSE SLES10.
>> >> > Hardware: 2CPU dual core Intel(R) Xeon(R) <at> 2.33GHz, 4GB of RAM
>> >> >
>> >> > If I try this benchmark all work fine, without problem:
>> >> >  ab -k -c 200 -n 8000 http://www.mysite.com/
>> >> >  ab -k -c 200 -n 8000 https://www.mysite.com/
>> >> >
>> >> > ... no lost requests, no particular delay.
>> >> >
>> >> > The problem come out if I try to do a "DOS attack" pointing directly
>> >> > to
>> >> > the
>> >> > ip address of mysite in https
>> >> > After few request (~200) apache hang and stop responding ...
>> >> >
>> >> >  ab -k -c 200 -n 8000 https://192.168.168.100/).
>> >> >
>> >> >
>> >> > #############################################################################
>> >> > # This is ApacheBench, Version 2.3 <$Revision: 655654 $>
>> >> > # Copyright 1996 Adam Twiss, Zeus Technology Ltd,
>> >> > http://www.zeustech.net/
>> >> > # Licensed to The Apache Software Foundation, http://www.apache.org/
>> >> > #
>> >> > # Benchmarking 192.168.168.100 (be patient)
>> >> > # Completed 200 requests
>> >> > # apr_poll: The timeout specified has expired (70007)
>> >> > # Total of 272 requests completed
>> >> >
>> >> >
>> >> > #############################################################################
>> >> >
>> >> > Here an extract from the logs:
>> >> >
>> >> >
>> >> > #############################################################################
>> >> > Jun 23 14:31:47 ulxbwaf httpd[8103]: [error] [client 192.168.168.168]
>> >> > ModSecurity: Access denied with code 400 (phase 2). Pattern match
>> >> > "^[\\d\\.]+$" at REQUEST_HEADERS:Host. [file
>> >> >
>> >> >
>> >> > "/opt/jail/opt/waf/mod_security/prod/conf/core_rules/modsecurity_crs_21_protocol_anomalies.conf"]
>> >> > [line "60"] [id "960017"] [msg "Host header is a numeric IP address"]
>> >> > [severity "CRITICAL"] [tag "PROTOCOL_VIOLATION/IP_HOST"] [hostname
>> >> > "192.168.168.100"] [uri "/"] [unique_id "SF <at> XssIL0NIAAB <at> ncMAAAACI"]
>> >> >
>> >> >
>> >> > #############################################################################
>> >> >
>> >> > If I turn off modsecurity (SecRuleEngine Off) and I repeat the test I
>> >> > don't
>> >> > have problem!
>> >> > If I disable the specific rule (SecRuleRemoveById "960017") all work
>> >> > fine!
>> >> >
>> >> > So, have you some idea about this issue?
>> >> > How can I prevent this kind of "DOS attack"?
>> >> >
>> >> > Thanks a lot! Regards
>> >> >  Nick
>> >> >
>> >> > PS: sorry for my ridicolous english ;)
>> >> >
>> >> >
>> >> >
>> >> > -------------------------------------------------------------------------
>> >> > Check out the new SourceForge.net Marketplace.
>> >> > It's the best place to buy or sell services for
>> >> > just about anything Open Source.
>> >> > http://sourceforge.net/services/buy/index.php
>> >> > _______________________________________________
>> >> > mod-security-users mailing list
>> >> > mod-security-users <at> lists.sourceforge.net
>> >> > https://lists.sourceforge.net/lists/listinfo/mod-security-users
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Ivan Ristic
>> >
>> >
>>
>>
>>
>> --
>> Ivan Ristic
>
>



--
Ivan Ristic

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
mod-security-users mailing list
mod-security-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users
Brian Rectanus | 25 Jun 17:57

Re: Apache hang on https protocol violation

Nick,

During your load tests, does the logs/mlogc-queue.log file become large?
 This is the backlog of transactions to send to the console.  It sounds
like maybe you are just generating a huge backlog and not sending
requests.  It may be that Apache is hanging when sending data to mlogc.

One thing I noticed is that you are using non-ssl on port 8886 for the
console.  Is this an older console?  The newer console uses SSL on port
8888.

Make sure mlogc is working properly before load testing.  To do this,
you will want to shut down apache and then remove the
logs/mlogc-queue.log file so it does not process the backlog.  Start off
just sending a single request through, checking the mlogc-error.log to
see if it was sent, or there was an error.  You may want to up the log
level to 4 for more details.  Would you please send the relevent errors
(if any)?

thanks,
-B

Nicola Bianchi wrote:
> Hi Ivan,
> I use the version 2.5.5. <http://2.5.5.>..
> but...
> after a check it seems that the mlogc don't work... on the console I
> don't see anything, no connection initailized by the mlogc.
> With the old perl script it work.
> 
> Here my configuration, for sure something is wrong :(
> ##########################
> #### grep -v "^#" mlogc.conf | grep ..
> CollectorRoot       "/opt/jail/opt/waf/mod_security/prod"
> ConsoleURI          "http://192.168.9.120:8886/rpc/auditLogReceiver"
> SensorUsername      "ulxbwaf2"
> SensorPassword      "xxxxxxx"
> LogStorageDir       "logs/modsec_audit"
> TransactionLog      "logs/mlogc-transaction.log"
> QueuePath           "logs/mlogc-queue.log"
> ErrorLog            "logs/mlogc-error.log"
> KeepEntries         0
> ErrorLogLevel       3
> MaxConnections      10
> TransactionDelay    50
> StartupDelay    1000
> CheckpointInterval  15
> ServerErrorTimeout  60
> ###########################
> 
> However I think the apache server does not to hang for a problem with
> the console, right?
> 
> Regards.
>   nick
> 
> On Wed, Jun 25, 2008 at 1:01 PM, Ivan Ristic <ivan.ristic <at> gmail.com
> <mailto:ivan.ristic <at> gmail.com>> wrote:
> 
>     Good, we've narrowed it down quickly.
> 
>     Are you using the mlogc version that comes with ModSecurity 2.5.5? Is
>     not working as expected (when not under load)?
> 
>     On Wed, Jun 25, 2008 at 8:26 AM, Nicola Bianchi
>     <bianchi.nicola <at> gmail.com <mailto:bianchi.nicola <at> gmail.com>> wrote:
>     > Hi Ivan,
>     > I've tested the environment with this line commented out:
>     > #SecAuditLog "|bin/mlogc /opt/waf/mod_security/prod/bin/mlogc.conf"
>     >
>     > And...
>     >
>     > ./ab -k -c 200 -n 2000 https://192.168.168.100/
>     > ##################################################################
>     > This is ApacheBench, Version 2.3 <$Revision: 655654 $>
>     > Copyright 1996 Adam Twiss, Zeus Technology Ltd,
>     http://www.zeustech.net/
>     > Licensed to The Apache Software Foundation, http://www.apache.org/
>     >
>     > Benchmarking 192.168.168.100 <http://192.168.168.100> (be patient)
>     > Completed 200 requests
>     > Completed 400 requests
>     > Completed 600 requests
>     > Completed 800 requests
>     > Completed 1000 requests
>     > Completed 1200 requests
>     > Completed 1400 requests
>     > Completed 1600 requests
>     > Completed 1800 requests
>     > Completed 2000 requests
>     > Finished 2000 requests
>     >
>     >
>     > Server Software:
>     > Server Hostname:        192.168.168.100 <http://192.168.168.100>
>     > Server Port:            443
>     > SSL/TLS Protocol:       TLSv1/SSLv3,DHE-RSA-AES256-SHA,1024,256
>     >
>     > Document Path:          /
>     > Document Length:        226 bytes
>     >
>     > Concurrency Level:      200
>     > Time taken for tests:   100.266 seconds
>     > Complete requests:      2000
>     > Failed requests:        0
>     > Write errors:           0
>     > Non-2xx responses:      2000
>     > Keep-Alive requests:    0
>     > Total transferred:      752000 bytes
>     > HTML transferred:       452000 bytes
>     > Requests per second:    19.95 [#/sec] (mean)
>     > Time per request:       10026.647 [ms] (mean)
>     > Time per request:       50.133 [ms] (mean, across all concurrent
>     requests)
>     > Transfer rate:          7.32 [Kbytes/sec] received
>     >
>     > Connection Times (ms)
>     >               min  mean[+/-sd] median   max
>     > Connect:       61 2570 2798.0   1659   15258
>     > Processing:    23 7299 14277.7   2397   62731
>     > Waiting:       23 2586 2898.5   1753   21923
>     > Total:         92 9869 15324.2   5277   67583
>     >
>     > Percentage of the requests served within a certain time (ms)
>     >   50%   5277
>     >   66%   9082
>     >   75%  10876
>     >   80%  12432
>     >   90%  24629
>     >   95%  54867
>     >   98%  59465
>     >   99%  61960
>     >  100%  67583 (longest request)
>     > ##################################################################
>     >
>     > Maybe a problem with mlogc is not to be excluded?
>     >
>     > Have a nice day!
>     >   Nick
>     >
>     >
>     > On Tue, Jun 24, 2008 at 7:44 PM, Ivan Ristic
>     <ivan.ristic <at> gmail.com <mailto:ivan.ristic <at> gmail.com>> wrote:
>     >>
>     >> I think the old Perl script was known to cause problems under load.
>     >>
>     >> Mlogc has been tested under heavy load, so that shouldn't be an
>     issue.
>     >> But testing without it will demonstrate that the problem is not in
>     >> mlogc.
>     >>
>     >> On Tue, Jun 24, 2008 at 6:34 PM, Nicola Bianchi
>     >> <bianchi.nicola <at> gmail.com <mailto:bianchi.nicola <at> gmail.com>> wrote:
>     >> > Hi Ivan,
>     >> > yes, I use mlogc to send logs to the console (via http).
>     >> > Maybe the problem is there ?
>     >> >
>     >> > Tomorrow I'll try to disable the remote logging ;)
>     >> >
>     >> > Thaks a lot. Regards.
>     >> >   Nicola
>     >> >
>     >> > On Tue, Jun 24, 2008 at 6:14 PM, Ivan Ristic
>     <ivan.ristic <at> gmail.com <mailto:ivan.ristic <at> gmail.com>>
>     >> > wrote:
>     >> >>
>     >> >> Hi Nicola,
>     >> >>
>     >> >> We'll have to try to reproduce your problem somehow, as it doesn't
>     >> >> happen in my tests. I've been using ab constantly over the
>     years for
>     >> >> testing, and I don't recall any problems either.
>     >> >>
>     >> >> Are you using mlogc or any other mechanism to transmit alerts
>     >> >> elsewhere?
>     >> >>
>     >> >>
>     >> >> On Mon, Jun 23, 2008 at 2:51 PM, Nicola Bianchi
>     >> >> <bianchi.nicola <at> gmail.com <mailto:bianchi.nicola <at> gmail.com>>
>     wrote:
>     >> >> > Hi people,
>     >> >> > I'm a new modsecurity user and I've a problem which maybe
>     some of you
>     >> >> > can
>     >> >> > resolve ;).
>     >> >> >
>     >> >> > My configuration is: reverse proxy (http/https) with apache
>     2.2.9 and
>     >> >> > modsecurity 2.5.5 (core rules 2.5-1.6.1) on Linux SUSE SLES10.
>     >> >> > Hardware: 2CPU dual core Intel(R) Xeon(R) @ 2.33GHz, 4GB of RAM
>     >> >> >
>     >> >> > If I try this benchmark all work fine, without problem:
>     >> >> >  ab -k -c 200 -n 8000 http://www.mysite.com/
>     >> >> >  ab -k -c 200 -n 8000 https://www.mysite.com/
>     >> >> >
>     >> >> > ... no lost requests, no particular delay.
>     >> >> >
>     >> >> > The problem come out if I try to do a "DOS attack" pointing
>     directly
>     >> >> > to
>     >> >> > the
>     >> >> > ip address of mysite in https
>     >> >> > After few request (~200) apache hang and stop responding ...
>     >> >> >
>     >> >> >  ab -k -c 200 -n 8000 https://192.168.168.100/).
>     >> >> >
>     >> >> >
>     >> >> >
>     #############################################################################
>     >> >> > # This is ApacheBench, Version 2.3 <$Revision: 655654 $>
>     >> >> > # Copyright 1996 Adam Twiss, Zeus Technology Ltd,
>     >> >> > http://www.zeustech.net/
>     >> >> > # Licensed to The Apache Software Foundation,
>     http://www.apache.org/
>     >> >> > #
>     >> >> > # Benchmarking 192.168.168.100 <http://192.168.168.100> (be
>     patient)
>     >> >> > # Completed 200 requests
>     >> >> > # apr_poll: The timeout specified has expired (70007)
>     >> >> > # Total of 272 requests completed
>     >> >> >
>     >> >> >
>     >> >> >
>     #############################################################################
>     >> >> >
>     >> >> > Here an extract from the logs:
>     >> >> >
>     >> >> >
>     >> >> >
>     #############################################################################
>     >> >> > Jun 23 14:31:47 ulxbwaf httpd[8103]: [error] [client
>     192.168.168.168 <http://192.168.168.168>]
>     >> >> > ModSecurity: Access denied with code 400 (phase 2). Pattern
>     match
>     >> >> > "^[\\d\\.]+$" at REQUEST_HEADERS:Host. [file
>     >> >> >
>     >> >> >
>     >> >> >
>     "/opt/jail/opt/waf/mod_security/prod/conf/core_rules/modsecurity_crs_21_protocol_anomalies.conf"]
>     >> >> > [line "60"] [id "960017"] [msg "Host header is a numeric IP
>     address"]
>     >> >> > [severity "CRITICAL"] [tag "PROTOCOL_VIOLATION/IP_HOST"]
>     [hostname
>     >> >> > "192.168.168.100 <http://192.168.168.100>"] [uri "/"]
>     [unique_id "SF <at> XssIL0NIAAB <at> ncMAAAACI"]
>     >> >> >
>     >> >> >
>     >> >> >
>     #############################################################################
>     >> >> >
>     >> >> > If I turn off modsecurity (SecRuleEngine Off) and I repeat
>     the test I
>     >> >> > don't
>     >> >> > have problem!
>     >> >> > If I disable the specific rule (SecRuleRemoveById "960017")
>     all work
>     >> >> > fine!
>     >> >> >
>     >> >> > So, have you some idea about this issue?
>     >> >> > How can I prevent this kind of "DOS attack"?
>     >> >> >
>     >> >> > Thanks a lot! Regards
>     >> >> >  Nick
>     >> >> >
>     >> >> > PS: sorry for my ridicolous english ;)
>     >> >> >
>     >> >> >
>     >> >> >
>     >> >> >
>     -------------------------------------------------------------------------
>     >> >> > Check out the new SourceForge.net Marketplace.
>     >> >> > It's the best place to buy or sell services for
>     >> >> > just about anything Open Source.
>     >> >> > http://sourceforge.net/services/buy/index.php
>     >> >> > _______________________________________________
>     >> >> > mod-security-users mailing list
>     >> >> > mod-security-users <at> lists.sourceforge.net
>     <mailto:mod-security-users <at> lists.sourceforge.net>
>     >> >> > https://lists.sourceforge.net/lists/listinfo/mod-security-users
>     >> >> >
>     >> >> >
>     >> >>
>     >> >>
>     >> >>
>     >> >> --
>     >> >> Ivan Ristic
>     >> >
>     >> >
>     >>
>     >>
>     >>
>     >> --
>     >> Ivan Ristic
>     >
>     >
> 
> 
> 
>     --
>     Ivan Ristic
> 
> 

--

-- 
Brian Rectanus
Breach Security

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
Nicola Bianchi | 26 Jun 10:52

Re: Apache hang on https protocol violation

Brian,
I use the console version 1.5.
The logs/mlogc-queue.log file don't grow up.

I still use the 8886 port because I'm lazy ? ... :-D  ..and beacuse I've some instance of modsecurity that use the old perl-logger...

I still have problem working with mlogc... no data are send to the console... no error messages... (but locally the transaction are logged)
##################################################
[Thu Jun 26 08:26:37 2008] [3] [29045/0] ModSecurity Audit Log Collector 1.4.4 delaying startup for 1000ms
[Thu Jun 26 08:26:38 2008] [3] [29045/0] ModSecurity Audit Log Collector 1.4.4 started.
[Thu Jun 26 08:26:38 2008] [3] [29048/0] ModSecurity Audit Log Collector 1.4.4 delaying startup for 1000ms
[Thu Jun 26 08:26:39 2008] [3] [29048/0] ModSecurity Audit Log Collector 1.4.4 started.
##################################################

If I stop apache some process of mlogc still alive? is it correct?

Regards.
  Nick


On Wed, Jun 25, 2008 at 5:57 PM, Brian Rectanus <Brian.Rectanus <at> breach.com> wrote:
Nick,

During your load tests, does the logs/mlogc-queue.log file become large?
 This is the backlog of transactions to send to the console.  It sounds
like maybe you are just generating a huge backlog and not sending
requests.  It may be that Apache is hanging when sending data to mlogc.


One thing I noticed is that you are using non-ssl on port 8886 for the
console.  Is this an older console?  The newer console uses SSL on port
8888.

Make sure mlogc is working properly before load testing.  To do this,
you will want to shut down apache and then remove the
logs/mlogc-queue.log file so it does not process the backlog.  Start off
just sending a single request through, checking the mlogc-error.log to
see if it was sent, or there was an error.  You may want to up the log
level to 4 for more details.  Would you please send the relevent errors
(if any)?

thanks,
-B

Nicola Bianchi wrote:
> Hi Ivan,
> I use the version 2.5.5. <http://2.5.5.>..
> but...
> after a check it seems that the mlogc don't work... on the console I
> don't see anything, no connection initailized by the mlogc.
> With the old perl script it work.
>
> Here my configuration, for sure something is wrong :(
> ##########################
> #### grep -v "^#" mlogc.conf | grep ..
> CollectorRoot       "/opt/jail/opt/waf/mod_security/prod"
> ConsoleURI          "http://192.168.9.120:8886/rpc/auditLogReceiver"
> SensorUsername      "ulxbwaf2"
> SensorPassword      "xxxxxxx"
> LogStorageDir       "logs/modsec_audit"
> TransactionLog      "logs/mlogc-transaction.log"
> QueuePath           "logs/mlogc-queue.log"
> ErrorLog            "logs/mlogc-error.log"
> KeepEntries         0
> ErrorLogLevel       3
> MaxConnections      10
> TransactionDelay    50
> StartupDelay    1000
> CheckpointInterval  15
> ServerErrorTimeout  60
> ###########################
>
> However I think the apache server does not to hang for a problem with
> the console, right?
>
> Regards.
>   nick
>
> On Wed, Jun 25, 2008 at 1:01 PM, Ivan Ristic <ivan.ristic <at> gmail.com
> <mailto:ivan.ristic <at> gmail.com>> wrote:
>
>     Good, we've narrowed it down quickly.
>
>     Are you using the mlogc version that comes with ModSecurity 2.5.5? Is
>     not working as expected (when not under load)?
>
>     On Wed, Jun 25, 2008 at 8:26 AM, Nicola Bianchi
>     <bianchi.nicola <at> gmail.com <mailto:bianchi.nicola <at> gmail.com>> wrote:
>     > Hi Ivan,
>     > I've tested the environment with this line commented out:
>     > #SecAuditLog "|bin/mlogc /opt/waf/mod_security/prod/bin/mlogc.conf"
>     >
>     > And...
>     >
>     > ./ab -k -c 200 -n 2000 https://192.168.168.100/
>     > ##################################################################
>     > This is ApacheBench, Version 2.3 <$Revision: 655654 $>
>     > Copyright 1996 Adam Twiss, Zeus Technology Ltd,
>     http://www.zeustech.net/
>     > Licensed to The Apache Software Foundation, http://www.apache.org/
>     >
>     > Benchmarking 192.168.168.100 <http://192.168.168.100> (be patient)
>     > Completed 200 requests
>     > Completed 400 requests
>     > Completed 600 requests
>     > Completed 800 requests
>     > Completed 1000 requests
>     > Completed 1200 requests
>     > Completed 1400 requests
>     > Completed 1600 requests
>     > Completed 1800 requests
>     > Completed 2000 requests
>     > Finished 2000 requests
>     >
>     >
>     > Server Software:
>     > Server Hostname:        192.168.168.100 <http://192.168.168.100>
>     > Server Port:            443
>     > SSL/TLS Protocol:       TLSv1/SSLv3,DHE-RSA-AES256-SHA,1024,256
>     >
>     > Document Path:          /
>     > Document Length:        226 bytes
>     >
>     > Concurrency Level:      200
>     > Time taken for tests:   100.266 seconds
>     > Complete requests:      2000
>     > Failed requests:        0
>     > Write errors:           0
>     > Non-2xx responses:      2000
>     > Keep-Alive requests:    0
>     > Total transferred:      752000 bytes
>     > HTML transferred:       452000 bytes
>     > Requests per second:    19.95 [#/sec] (mean)
>     > Time per request:       10026.647 [ms] (mean)
>     > Time per request:       50.133 [ms] (mean, across all concurrent
>     requests)
>     > Transfer rate:          7.32 [Kbytes/sec] received
>     >
>     > Connection Times (ms)
>     >               min  mean[+/-sd] median   max
>     > Connect:       61 2570 2798.0   1659   15258
>     > Processing:    23 7299 14277.7   2397   62731
>     > Waiting:       23 2586 2898.5   1753   21923
>     > Total:         92 9869 15324.2   5277   67583
>     >
>     > Percentage of the requests served within a certain time (ms)
>     >   50%   5277
>     >   66%   9082
>     >   75%  10876
>     >   80%  12432
>     >   90%  24629
>     >   95%  54867
>     >   98%  59465
>     >   99%  61960
>     >  100%  67583 (longest request)
>     > ##################################################################
>     >
>     > Maybe a problem with mlogc is not to be excluded?
>     >
>     > Have a nice day!
>     >   Nick
>     >
>     >
>     > On Tue, Jun 24, 2008 at 7:44 PM, Ivan Ristic
>     <ivan.ristic <at> gmail.com <mailto:ivan.ristic <at> gmail.com>> wrote:
>     >>
>     >> I think the old Perl script was known to cause problems under load.
>     >>
>     >> Mlogc has been tested under heavy load, so that shouldn't be an
>     issue.
>     >> But testing without it will demonstrate that the problem is not in
>     >> mlogc.
>     >>
>     >> On Tue, Jun 24, 2008 at 6:34 PM, Nicola Bianchi
>     >> <bianchi.nicola <at> gmail.com <mailto:bianchi.nicola <at> gmail.com>> wrote:
>     >> > Hi Ivan,
>     >> > yes, I use mlogc to send logs to the console (via http).
>     >> > Maybe the problem is there ?
>     >> >
>     >> > Tomorrow I'll try to disable the remote logging ;)
>     >> >
>     >> > Thaks a lot. Regards.
>     >> >   Nicola
>     >> >
>     >> > On Tue, Jun 24, 2008 at 6:14 PM, Ivan Ristic
>     <ivan.ristic <at> gmail.com <mailto:ivan.ristic <at> gmail.com>>
>     >> > wrote:
>     >> >>
>     >> >> Hi Nicola,
>     >> >>
>     >> >> We'll have to try to reproduce your problem somehow, as it doesn't
>     >> >> happen in my tests. I've been using ab constantly over the
>     years for
>     >> >> testing, and I don't recall any problems either.
>     >> >>
>     >> >> Are you using mlogc or any other mechanism to transmit alerts
>     >> >> elsewhere?
>     >> >>
>     >> >>
>     >> >> On Mon, Jun 23, 2008 at 2:51 PM, Nicola Bianchi
>     >> >> <bianchi.nicola <at> gmail.com <mailto:bianchi.nicola <at> gmail.com>>
>     wrote:
>     >> >> > Hi people,
>     >> >> > I'm a new modsecurity user and I've a problem which maybe
>     some of you
>     >> >> > can
>     >> >> > resolve ;).
>     >> >> >
>     >> >> > My configuration is: reverse proxy (http/https) with apache
>     2.2.9 and
>     >> >> > modsecurity 2.5.5 (core rules 2.5-1.6.1) on Linux SUSE SLES10.
>     >> >> > Hardware: 2CPU dual core Intel(R) Xeon(R) <at> 2.33GHz, 4GB of RAM
>     >> >> >
>     >> >> > If I try this benchmark all work fine, without problem:
>     >> >> >  ab -k -c 200 -n 8000 http://www.mysite.com/
>     >> >> >  ab -k -c 200 -n 8000 https://www.mysite.com/
>     >> >> >
>     >> >> > ... no lost requests, no particular delay.
>     >> >> >
>     >> >> > The problem come out if I try to do a "DOS attack" pointing
>     directly
>     >> >> > to
>     >> >> > the
>     >> >> > ip address of mysite in https
>     >> >> > After few request (~200) apache hang and stop responding ...
>     >> >> >
>     >> >> >  ab -k -c 200 -n 8000 https://192.168.168.100/).
>     >> >> >
>     >> >> >
>     >> >> >
>     #############################################################################
>     >> >> > # This is ApacheBench, Version 2.3 <$Revision: 655654 $>
>     >> >> > # Copyright 1996 Adam Twiss, Zeus Technology Ltd,
>     >> >> > http://www.zeustech.net/
>     >> >> > # Licensed to The Apache Software Foundation,
>     http://www.apache.org/
>     >> >> > #
>     >> >> > # Benchmarking 192.168.168.100 <http://192.168.168.100> (be
>     patient)
>     >> >> > # Completed 200 requests
>     >> >> > # apr_poll: The timeout specified has expired (70007)
>     >> >> > # Total of 272 requests completed
>     >> >> >
>     >> >> >
>     >> >> >
>     #############################################################################
>     >> >> >
>     >> >> > Here an extract from the logs:
>     >> >> >
>     >> >> >
>     >> >> >
>     #############################################################################
>     >> >> > Jun 23 14:31:47 ulxbwaf httpd[8103]: [error] [client
>     192.168.168.168 <http://192.168.168.168>]
>     >> >> > ModSecurity: Access denied with code 400 (phase 2). Pattern
>     match
>     >> >> > "^[\\d\\.]+$" at REQUEST_HEADERS:Host. [file
>     >> >> >
>     >> >> >
>     >> >> >
>     "/opt/jail/opt/waf/mod_security/prod/conf/core_rules/modsecurity_crs_21_protocol_anomalies.conf"]
>     >> >> > [line "60"] [id "960017"] [msg "Host header is a numeric IP
>     address"]
>     >> >> > [severity "CRITICAL"] [tag "PROTOCOL_VIOLATION/IP_HOST"]
>     [hostname
>     >> >> > "192.168.168.100 <http://192.168.168.100>"] [uri "/"]
>     [unique_id "SF <at> XssIL0NIAAB <at> ncMAAAACI"]
>     >> >> >
>     >> >> >
>     >> >> >
>     #############################################################################
>     >> >> >
>     >> >> > If I turn off modsecurity (SecRuleEngine Off) and I repeat
>     the test I
>     >> >> > don't
>     >> >> > have problem!
>     >> >> > If I disable the specific rule (SecRuleRemoveById "960017")
>     all work
>     >> >> > fine!
>     >> >> >
>     >> >> > So, have you some idea about this issue?
>     >> >> > How can I prevent this kind of "DOS attack"?
>     >> >> >
>     >> >> > Thanks a lot! Regards
>     >> >> >  Nick
>     >> >> >
>     >> >> > PS: sorry for my ridicolous english ;)
>     >> >> >
>     >> >> >
>     >> >> >
>     >> >> >
>     -------------------------------------------------------------------------
>     >> >> > Check out the new SourceForge.net Marketplace.
>     >> >> > It's the best place to buy or sell services for
>     >> >> > just about anything Open Source.
>     >> >> > http://sourceforge.net/services/buy/index.php
>     >> >> > _______________________________________________
>     >> >> > mod-security-users mailing list
>     >> >> > mod-security-users <at> lists.sourceforge.net
>     <mailto:mod-security-users <at> lists.sourceforge.net>
>     >> >> > https://lists.sourceforge.net/lists/listinfo/mod-security-users
>     >> >> >
>     >> >> >
>     >> >>
>     >> >>
>     >> >>
>     >> >> --
>     >> >> Ivan Ristic
>     >> >
>     >> >
>     >>
>     >>
>     >>
>     >> --
>     >> Ivan Ristic
>     >
>     >
>
>
>
>     --
>     Ivan Ristic
>
>


--
Brian Rectanus
Breach Security

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
mod-security-users mailing list
mod-security-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users
Ivan Ristic | 26 Jun 14:57

Re: Apache hang on https protocol violation

It appears that something is not working quite right there. I am
guessing that the messages Apache wants to send to mlogc are not
reaching their destination, causing the pipe between the two to become
congested--and that hangs Apache. Normally, mlogc makes sure the pipe
is always drained.

And, no, mlogc is not supposed to stay up after you stop Apache.

On Thu, Jun 26, 2008 at 9:52 AM, Nicola Bianchi
<bianchi.nicola <at> gmail.com> wrote:
> Brian,
> I use the console version 1.5.
> The logs/mlogc-queue.log file don't grow up.
>
> I still use the 8886 port because I'm lazy ? ... :-D  ..and beacuse I've
> some instance of modsecurity that use the old perl-logger...
>
> I still have problem working with mlogc... no data are send to the
> console... no error messages... (but locally the transaction are logged)
> ##################################################
> [Thu Jun 26 08:26:37 2008] [3] [29045/0] ModSecurity Audit Log Collector
> 1.4.4 delaying startup for 1000ms
> [Thu Jun 26 08:26:38 2008] [3] [29045/0] ModSecurity Audit Log Collector
> 1.4.4 started.
> [Thu Jun 26 08:26:38 2008] [3] [29048/0] ModSecurity Audit Log Collector
> 1.4.4 delaying startup for 1000ms
> [Thu Jun 26 08:26:39 2008] [3] [29048/0] ModSecurity Audit Log Collector
> 1.4.4 started.
> ##################################################
>
> If I stop apache some process of mlogc still alive? is it correct?
>
> Regards.
>   Nick
>
>
> On Wed, Jun 25, 2008 at 5:57 PM, Brian Rectanus <Brian.Rectanus <at> breach.com>
> wrote:
>>
>> Nick,
>>
>> During your load tests, does the logs/mlogc-queue.log file become large?
>>  This is the backlog of transactions to send to the console.  It sounds
>> like maybe you are just generating a huge backlog and not sending
>> requests.  It may be that Apache is hanging when sending data to mlogc.
>>
>>
>> One thing I noticed is that you are using non-ssl on port 8886 for the
>> console.  Is this an older console?  The newer console uses SSL on port
>> 8888.
>>
>> Make sure mlogc is working properly before load testing.  To do this,
>> you will want to shut down apache and then remove the
>> logs/mlogc-queue.log file so it does not process the backlog.  Start off
>> just sending a single request through, checking the mlogc-error.log to
>> see if it was sent, or there was an error.  You may want to up the log
>> level to 4 for more details.  Would you please send the relevent errors
>> (if any)?
>>
>> thanks,
>> -B
>>
>> Nicola Bianchi wrote:
>> > Hi Ivan,
>> > I use the version 2.5.5. <http://2.5.5.>..
>> > but...
>> > after a check it seems that the mlogc don't work... on the console I
>> > don't see anything, no connection initailized by the mlogc.
>> > With the old perl script it work.
>> >
>> > Here my configuration, for sure something is wrong :(
>> > ##########################
>> > #### grep -v "^#" mlogc.conf | grep ..
>> > CollectorRoot       "/opt/jail/opt/waf/mod_security/prod"
>> > ConsoleURI          "http://192.168.9.120:8886/rpc/auditLogReceiver"
>> > SensorUsername      "ulxbwaf2"
>> > SensorPassword      "xxxxxxx"
>> > LogStorageDir       "logs/modsec_audit"
>> > TransactionLog      "logs/mlogc-transaction.log"
>> > QueuePath           "logs/mlogc-queue.log"
>> > ErrorLog            "logs/mlogc-error.log"
>> > KeepEntries         0
>> > ErrorLogLevel       3
>> > MaxConnections      10
>> > TransactionDelay    50
>> > StartupDelay    1000
>> > CheckpointInterval  15
>> > ServerErrorTimeout  60
>> > ###########################
>> >
>> > However I think the apache server does not to hang for a problem with
>> > the console, right?
>> >
>> > Regards.
>> >   nick
>> >
>> > On Wed, Jun 25, 2008 at 1:01 PM, Ivan Ristic <ivan.ristic <at> gmail.com
>> > <mailto:ivan.ristic <at> gmail.com>> wrote:
>> >
>> >     Good, we've narrowed it down quickly.
>> >
>> >     Are you using the mlogc version that comes with ModSecurity 2.5.5?
>> > Is
>> >     not working as expected (when not under load)?
>> >
>> >     On Wed, Jun 25, 2008 at 8:26 AM, Nicola Bianchi
>> >     <bianchi.nicola <at> gmail.com <mailto:bianchi.nicola <at> gmail.com>> wrote:
>> >     > Hi Ivan,
>> >     > I've tested the environment with this line commented out:
>> >     > #SecAuditLog "|bin/mlogc
>> > /opt/waf/mod_security/prod/bin/mlogc.conf"
>> >     >
>> >     > And...
>> >     >
>> >     > ./ab -k -c 200 -n 2000 https://192.168.168.100/
>> >     > ##################################################################
>> >     > This is ApacheBench, Version 2.3 <$Revision: 655654 $>
>> >     > Copyright 1996 Adam Twiss, Zeus Technology Ltd,
>> >     http://www.zeustech.net/
>> >     > Licensed to The Apache Software Foundation, http://www.apache.org/
>> >     >
>> >     > Benchmarking 192.168.168.100 <http://192.168.168.100> (be patient)
>> >     > Completed 200 requests
>> >     > Completed 400 requests
>> >     > Completed 600 requests
>> >     > Completed 800 requests
>> >     > Completed 1000 requests
>> >     > Completed 1200 requests
>> >     > Completed 1400 requests
>> >     > Completed 1600 requests
>> >     > Completed 1800 requests
>> >     > Completed 2000 requests
>> >     > Finished 2000 requests
>> >     >
>> >     >
>> >     > Server Software:
>> >     > Server Hostname:        192.168.168.100 <http://192.168.168.100>
>> >     > Server Port:            443
>> >     > SSL/TLS Protocol:       TLSv1/SSLv3,DHE-RSA-AES256-SHA,1024,256
>> >     >
>> >     > Document Path:          /
>> >     > Document Length:        226 bytes
>> >     >
>> >     > Concurrency Level:      200
>> >     > Time taken for tests:   100.266 seconds
>> >     > Complete requests:      2000
>> >     > Failed requests:        0
>> >     > Write errors:           0
>> >     > Non-2xx responses:      2000
>> >     > Keep-Alive requests:    0
>> >     > Total transferred:      752000 bytes
>> >     > HTML transferred:       452000 bytes
>> >     > Requests per second:    19.95 [#/sec] (mean)
>> >     > Time per request:       10026.647 [ms] (mean)
>> >     > Time per request:       50.133 [ms] (mean, across all concurrent
>> >     requests)
>> >     > Transfer rate:          7.32 [Kbytes/sec] received
>> >     >
>> >     > Connection Times (ms)
>> >     >               min  mean[+/-sd] median   max
>> >     > Connect:       61 2570 2798.0   1659   15258
>> >     > Processing:    23 7299 14277.7   2397   62731
>> >     > Waiting:       23 2586 2898.5   1753   21923
>> >     > Total:         92 9869 15324.2   5277   67583
>> >     >
>> >     > Percentage of the requests served within a certain time (ms)
>> >     >   50%   5277
>> >     >   66%   9082
>> >     >   75%  10876
>> >     >   80%  12432
>> >     >   90%  24629
>> >     >   95%  54867
>> >     >   98%  59465
>> >     >   99%  61960
>> >     >  100%  67583 (longest request)
>> >     > ##################################################################
>> >     >
>> >     > Maybe a problem with mlogc is not to be excluded?
>> >     >
>> >     > Have a nice day!
>> >     >   Nick
>> >     >
>> >     >
>> >     > On Tue, Jun 24, 2008 at 7:44 PM, Ivan Ristic
>> >     <ivan.ristic <at> gmail.com <mailto:ivan.ristic <at> gmail.com>> wrote:
>> >     >>
>> >     >> I think the old Perl script was known to cause problems under
>> > load.
>> >     >>
>> >     >> Mlogc has been tested under heavy load, so that shouldn't be an
>> >     issue.
>> >     >> But testing without it will demonstrate that the problem is not
>> > in
>> >     >> mlogc.
>> >     >>
>> >     >> On Tue, Jun 24, 2008 at 6:34 PM, Nicola Bianchi
>> >     >> <bianchi.nicola <at> gmail.com <mailto:bianchi.nicola <at> gmail.com>>
>> > wrote:
>> >     >> > Hi Ivan,
>> >     >> > yes, I use mlogc to send logs to the console (via http).
>> >     >> > Maybe the problem is there ?
>> >     >> >
>> >     >> > Tomorrow I'll try to disable the remote logging ;)
>> >     >> >
>> >     >> > Thaks a lot. Regards.
>> >     >> >   Nicola
>> >     >> >
>> >     >> > On Tue, Jun 24, 2008 at 6:14 PM, Ivan Ristic
>> >     <ivan.ristic <at> gmail.com <mailto:ivan.ristic <at> gmail.com>>
>> >     >> > wrote:
>> >     >> >>
>> >     >> >> Hi Nicola,
>> >     >> >>
>> >     >> >> We'll have to try to reproduce your problem somehow, as it
>> > doesn't
>> >     >> >> happen in my tests. I've been using ab constantly over the
>> >     years for
>> >     >> >> testing, and I don't recall any problems either.
>> >     >> >>
>> >     >> >> Are you using mlogc or any other mechanism to transmit alerts
>> >     >> >> elsewhere?
>> >     >> >>
>> >     >> >>
>> >     >> >> On Mon, Jun 23, 2008 at 2:51 PM, Nicola Bianchi
>> >     >> >> <bianchi.nicola <at> gmail.com <mailto:bianchi.nicola <at> gmail.com>>
>> >     wrote:
>> >     >> >> > Hi people,
>> >     >> >> > I'm a new modsecurity user and I've a problem which maybe
>> >     some of you
>> >     >> >> > can
>> >     >> >> > resolve ;).
>> >     >> >> >
>> >     >> >> > My configuration is: reverse proxy (http/https) with apache
>> >     2.2.9 and
>> >     >> >> > modsecurity 2.5.5 (core rules 2.5-1.6.1) on Linux SUSE
>> > SLES10.
>> >     >> >> > Hardware: 2CPU dual core Intel(R) Xeon(R) @ 2.33GHz, 4GB of
>> > RAM
>> >     >> >> >
>> >     >> >> > If I try this benchmark all work fine, without problem:
>> >     >> >> >  ab -k -c 200 -n 8000 http://www.mysite.com/
>> >     >> >> >  ab -k -c 200 -n 8000 https://www.mysite.com/
>> >     >> >> >
>> >     >> >> > ... no lost requests, no particular delay.
>> >     >> >> >
>> >     >> >> > The problem come out if I try to do a "DOS attack" pointing
>> >     directly
>> >     >> >> > to
>> >     >> >> > the
>> >     >> >> > ip address of mysite in https
>> >     >> >> > After few request (~200) apache hang and stop responding ...
>> >     >> >> >
>> >     >> >> >  ab -k -c 200 -n 8000 https://192.168.168.100/).
>> >     >> >> >
>> >     >> >> >
>> >     >> >> >
>> >
>> > #############################################################################
>> >     >> >> > # This is ApacheBench, Version 2.3 <$Revision: 655654 $>
>> >     >> >> > # Copyright 1996 Adam Twiss, Zeus Technology Ltd,
>> >     >> >> > http://www.zeustech.net/
>> >     >> >> > # Licensed to The Apache Software Foundation,
>> >     http://www.apache.org/
>> >     >> >> > #
>> >     >> >> > # Benchmarking 192.168.168.100 <http://192.168.168.100> (be
>> >     patient)
>> >     >> >> > # Completed 200 requests
>> >     >> >> > # apr_poll: The timeout specified has expired (70007)
>> >     >> >> > # Total of 272 requests completed
>> >     >> >> >
>> >     >> >> >
>> >     >> >> >
>> >
>> > #############################################################################
>> >     >> >> >
>> >     >> >> > Here an extract from the logs:
>> >     >> >> >
>> >     >> >> >
>> >     >> >> >
>> >
>> > #############################################################################
>> >     >> >> > Jun 23 14:31:47 ulxbwaf httpd[8103]: [error] [client
>> >     192.168.168.168 <http://192.168.168.168