Thread: Re: [mod-security-users] mlogc not collecting
Brought to you by:
victorhora,
zimmerletw
From: N C <nc...@ya...> - 2010-06-26 00:28:31
|
--- On Fri, 6/25/10, N C <nc...@ya...> wrote: > I've upgraded an older mod_security > installation to 2.5.12. I copied the old SecAuditLog* > settings into the new modsecurity_crs_10_config.conf > file. Plenty of events are being written to > modsec_debug.log, but nothing is showing up in the console, > nor in /var/log/mlogc/data/. > > mlogc is using libcurl compiled with OpenSSL. > Turning mlogc logging up to 5 showed nothing of interest. mlogc appears to just be sitting there checking itself every 5 seconds. I reverted back to the old mlogc binary, with no improvement in the situation. That leads me to believe that I've somehow messed up on the 2.5.12 configuration pointing mod_security to mlogc. That configuration was copied from the old, functioning installation. The following was appended to the stock 2.5.12 modsecurity_crs_10_config.conf: SecAuditLogType Concurrent SecAuditLog "|/opt/mlogc/bin/mlogc /opt/mlogc/etc/mlogc.conf" SecAuditLogStorageDir /var/log/mlogc/data SecAuditLogParts "ABIDEFGHZ" SecDebugLog logs/modsec_debug.log SecDebugLogLevel 3 SecDataDir /tmp SecTmpDir /tmp I bumped mod_security logging up to 5, but haven't seen anything in modsec_debug.log that looks like it pertains to my problem. Would anything show up there? If so, what would it look like. Any ideas on tracking this down would be appreciated. |
From: N C <nc...@ya...> - 2010-06-26 03:35:30
|
--- On Sat, 6/26/10, N C <nc...@ya...> wrote: > --- On Fri, 6/25/10, N C <nc...@ya...> > wrote: > > I've upgraded an older mod_security > > installation to 2.5.12. I copied the old > SecAuditLog* > > settings into the new modsecurity_crs_10_config.conf > > file. Plenty of events are being written to > > modsec_debug.log, but nothing is showing up in the > console, > > nor in /var/log/mlogc/data/. > > > > mlogc is using libcurl compiled with OpenSSL. > > > > Turning mlogc logging up to 5 showed nothing of > interest. mlogc appears to just be sitting there > checking itself every 5 seconds. > > I reverted back to the old mlogc binary, with no > improvement in the situation. That leads me to believe > that I've somehow messed up on the 2.5.12 configuration > pointing mod_security to mlogc. That configuration was > copied from the old, functioning installation. The > following was appended to the stock 2.5.12 > modsecurity_crs_10_config.conf: > > SecAuditLogType Concurrent > SecAuditLog "|/opt/mlogc/bin/mlogc > /opt/mlogc/etc/mlogc.conf" > SecAuditLogStorageDir /var/log/mlogc/data > SecAuditLogParts "ABIDEFGHZ" > SecDebugLog > logs/modsec_debug.log > SecDebugLogLevel 3 > SecDataDir /tmp > SecTmpDir /tmp > > I bumped mod_security logging up to 5, but haven't seen > anything in modsec_debug.log that looks like it pertains to > my problem. Would anything show up there? If so, > what would it look like. Any ideas on tracking this > down would be appreciated. Well, I'm pretty much talking to myself, with the exception of out-of-office replies... I've discovered that my console's var/logs/stderr.log is filled with thousands of lines containing simply "java.util.NoSuchElementException". No stack traces are present. The last line before the exceptions is: Velocity message: 1 Velocity successfully started. It appears that an exception (or maybe two) are logged upon each com.thinkingstone.chronos.ChronosScheduler _scheduleTask execution. I'm running Console version 1.0.3. |
From: Ivan R. <iva...@gm...> - 2010-06-26 07:44:57
|
To troubleshoot your logging, you need to trace what happens from the moment an audit log entry is created, and until it is handled by mlogc. It looks as if you are either not logging anything, or mlogc is not being notified. Start by looking at the main (ModSecurity, not mlogc) debug log. You'll need to increase the debug log first, ideally to 9, but that's going to be difficult on a production server. Try 4 first. The last line for a transaction should have somethings like "Audit Log: Writing XYZ bytes to primary concurrent index". If there's a problem with logging, you'll see it there. You may also have disabled logging in configuration, in which case the logging subsystem will state that, or it will say that it is ignoring a non-relevant transaction. On Sat, Jun 26, 2010 at 4:35 AM, N C <nc...@ya...> wrote: > --- On Sat, 6/26/10, N C <nc...@ya...> wrote: >> --- On Fri, 6/25/10, N C <nc...@ya...> >> wrote: >> > I've upgraded an older mod_security >> > installation to 2.5.12. I copied the old >> SecAuditLog* >> > settings into the new modsecurity_crs_10_config.conf >> > file. Plenty of events are being written to >> > modsec_debug.log, but nothing is showing up in the >> console, >> > nor in /var/log/mlogc/data/. >> > >> > mlogc is using libcurl compiled with OpenSSL. >> > >> >> Turning mlogc logging up to 5 showed nothing of >> interest. mlogc appears to just be sitting there >> checking itself every 5 seconds. >> >> I reverted back to the old mlogc binary, with no >> improvement in the situation. That leads me to believe >> that I've somehow messed up on the 2.5.12 configuration >> pointing mod_security to mlogc. That configuration was >> copied from the old, functioning installation. The >> following was appended to the stock 2.5.12 >> modsecurity_crs_10_config.conf: >> >> SecAuditLogType Concurrent >> SecAuditLog "|/opt/mlogc/bin/mlogc >> /opt/mlogc/etc/mlogc.conf" >> SecAuditLogStorageDir /var/log/mlogc/data >> SecAuditLogParts "ABIDEFGHZ" >> SecDebugLog >> logs/modsec_debug.log >> SecDebugLogLevel 3 >> SecDataDir /tmp >> SecTmpDir /tmp >> >> I bumped mod_security logging up to 5, but haven't seen >> anything in modsec_debug.log that looks like it pertains to >> my problem. Would anything show up there? If so, >> what would it look like. Any ideas on tracking this >> down would be appreciated. > > Well, I'm pretty much talking to myself, with the exception of out-of-office replies... > > I've discovered that my console's var/logs/stderr.log is filled with thousands of lines containing simply "java.util.NoSuchElementException". No stack traces are present. > > The last line before the exceptions is: > > Velocity message: 1 Velocity successfully started. > > It appears that an exception (or maybe two) are logged upon each com.thinkingstone.chronos.ChronosScheduler _scheduleTask execution. > > I'm running Console version 1.0.3. > > > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > mod-security-users mailing list > mod...@li... > https://lists.sourceforge.net/lists/listinfo/mod-security-users > Commercial ModSecurity Appliances, Rule Sets and Support: > http://www.modsecurity.org/breach/index.html -- Ivan Ristic ModSecurity Handbook [http://www.modsecurityhandbook.com] SSL Labs [https://www.ssllabs.com/ssldb/] |
From: N C <nc...@ya...> - 2010-06-26 22:49:30
|
--- On Sat, 6/26/10, Ivan Ristic <iva...@gm...> wrote: > You may also have disabled logging in > configuration, in which case the logging subsystem will > state that, or it will say that it is ignoring a non-relevant > transaction. Indeed, when I merged the old configuration file with the new, I inadvertently left out the SecAuditEngine directive. Sometimes it is something really simple... Thanks. |