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