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