Hi Christopher,

There is a segmentation fault every time you start it? If so, you can have a look on the dump file.

First you have to follow to compilation steps described here:
https://github.com/SpiderLabs/ModSecurity/wiki/Debugging-ModSecurity

After that you can either attach the gdb to the process:
$ gdb --pid <number of the process>
(if you have the chance to.)

Or you can open the core file:
$ gdb path/to/the/binary path/to/the/core

Once the gdb shell is opened, you can try the "bt full":
(gdb) bt full

Use Gist (or pastebin) to share the "bt full" output with us so that we can help you to read the output and fix any issue.

Br.,
Felipe "Zimmerle" Costa
Security Researcher, SpiderLabs

Trustwave | SMART SECURITY ON DEMAND
www.trustwave.com


On May 8, 2014, at 1:21 PM, Christopher Jay Manders <cmanders@apple.com> wrote:


More information.

On my target system I used netcat to test:
nc -lk 8080

Then on the miscreant system I do a:
nc <target system IP> 8080

That works just fine.

In fact, if I leave it going like that on the target mlogc system and fire up any tool like nikto pointing at any of the other 3 systems I see plenty of messages scroll by on the target system with netcat running.

It is really rather sad to not have any log files show connections failing…but it is certainly clear that they are not going to the correct system.

The configuration is exactly the same on all 4 systems. 

In fact, they are all 4 VMs that were cloned, with no differences in OS, rev of software, or anything else that I can see.

I just replaced mlogc in my modsecurity config with netcat instead of mlogc and the packets and logging is now making it to the logging target system.

SecAuditLog "|/usr/bin/nc 10.1.2.45 8080"

Very interesting,

What other things are left to troubleshoot the mlogc utility?

At this point I feel I have isolated the problem to mlogc.

Thoughts?

Any assistance would be appreciated.

Thanks!
Christopher



On 7May, 2014, at 6:00 PM, Christopher Jay Manders <cmanders@apple.com> wrote:

Greetings,

I have compiled mlogc and distributed it on 4 systems that are exactly the same.

One is getting an Apache error_log message:

[notice] child pid 7217 exit signal Segmentation fault (11), possible coredump in /usr/bin
piped log program ‘/usr/bin/mlogc /etc/mlogc/mlogc.conf' failed unexpectedly

None of the other 3 systems exhibits this issue, and actually the 1 was working until a reboot.

I have turned the mlogc Debug level to 5  and see nothing out of the ordinary:
[Wed May 07 22:44:17 2014] [4] [3006/1b37878] Signal thread: Starting.
[Wed May 07 22:44:17 2014] [4] [3006/1ba9868] Worker thread starting.
[Wed May 07 22:44:17 2014] [4] [3006/1ba9868] We were told to shut down.
[Wed May 07 22:44:17 2014] [4] [3006/1ba9868] Worker shutdown locking thread mutex.
[Wed May 07 22:44:17 2014] [4] [3006/1ba9868] Worker shutdown unlocking thread mutex.
[Wed May 07 22:44:17 2014] [4] [3006/1ba9868] Worker thread completed.
[Wed May 07 22:44:17 2014] [4] [3006/1b377e8] Management thread: Starting.
[Wed May 07 22:44:17 2014] [4] [3006/1b377e8] Management thread: Waiting for worker threads to finish.
[Wed May 07 22:44:17 2014] [3] [3006/1b377e8] Running final transaction checkpoint.
[Wed May 07 22:44:17 2014] [4] [3006/0] Checkpoint locking global mutex.
[Wed May 07 22:44:17 2014] [4] [3006/0] Checkpoint started.
[Wed May 07 22:44:17 2014] [5] [3006/0] Checkpoint wrote 1 queued entries to new queue.
[Wed May 07 22:44:17 2014] [5] [3006/0] Checkpoint wrote 0 additional entries to new queue.
[Wed May 07 22:44:17 2014] [4] [3006/0] Checkpoint completed.
[Wed May 07 22:44:17 2014] [4] [3006/0] Checkpoint unlocking global mutex.
[Wed May 07 22:44:17 2014] [4] [3006/1b377e8] Management thread: Exiting.
[Wed May 07 22:44:17 2014] [3] [3006/0] ModSecurity Audit Log Collector 2.7.7 terminating normally.

The thing that is most odd is that there is only one error about the Segmentation Fault, and the mlogc logs all look OK.

But no packets leave the system. 

I have confirmed that with tcpdump.

Any ideas as to what caused this and the fix?

Input welcome.

TIA!
Christopher
------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
&#149; 3 signs your SCM is hindering your productivity
&#149; Requirements for releasing software faster
&#149; Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce_______________________________________________
mod-security-users mailing list
mod-security-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users
Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
http://www.modsecurity.org/projects/commercial/rules/
http://www.modsecurity.org/projects/commercial/support/

------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
&#149; 3 signs your SCM is hindering your productivity
&#149; Requirements for releasing software faster
&#149; Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce_______________________________________________
mod-security-users mailing list
mod-security-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users
Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
http://www.modsecurity.org/projects/commercial/rules/
http://www.modsecurity.org/projects/commercial/support/




This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.