When I first started using OSSEC, a big part of why I chose it as my institution's HIDS was its multi-platform support and ease of installation and use. The stock components that ship with OSSEC are everything a system administrator needs to get up and running quickly with FIM and log analysis. It works well out of the box, requiring only basic maintenance to suppress false positives. Furthermore, it has been easy to maintain and it has been reliable over the years.
My concern is that OSSEC development is NOT re-inventing the wheel by working on log shipping and logall functionality. Log analysis is just one of the core functions of OSSEC. It also performs audit checks and FIM on the agent. The list of systems that do all 3 is rather small and even then, choice is good. As such, the agent needs an out-of-the-box solution for getting logs safely and accurately from point A to point B. As soon as one starts recommending that admins use a different log shipping method or central log server, you start running into resource, compatibility, support, and complexity issues. How would one maintain control over OSSEC cross-platform compatibility when one recommends the use of 3rd party log shipping? For those sys admins that have the expertise, time, and desire to use a conglomerate of log analysis, FIM, and auditing tools, it is nice that 3rd party log shipping options exist and that integration with central log repositories is possible. I believe OSSEC needs to maintain a certain level of baseline functionality to preserve its usefulness to your average sys admin. In many cases, OSSEC system administrators are deploying agents to a large fleet of computers. For each additional 3rd party log tool that OSSEC requires, system admins are faced with a higher learning curve for deployment, configuration, and maintenance. As long as the OSSEC agent exists and as long as it is responsible for log shipping, it needs to do its job fully and correctly. It is touted as a security tool and as such it needs to behave like one. That is, it needs to provide options that guarantee accurate and safe delivery of log data and it needs to be able to preserve them in a standardized and open fashion. > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Jeremy Rossi > Sent: Wednesday, June 18, 2014 4:58 AM > To: ossec-list > Subject: [ossec-list] Logall > > Log all feature comes up all the time and is confusing I think and maybe > something we should solve better. But I am worried about turning ossec from > security to a log daemon as other tools have solved that problem. > > Currently logall just saves the raw messages without any metadata like file > path, filename, timezone, etc of the event. So basiclly it's a piss poor way of > saving all messages. Not to even talk about how messages are now ossec > master and agent communicate so you get api chat in the logs. > > Is this a problem space ossec should be solving? > > Just looking for feedback :) > > -- > > --- > You received this message because you are subscribed to the Google Groups > "ossec-list" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
