Thanks for your response Santiago!
So the target system is actually a pfSense router (FreeBSD 10.3 based) and
the main problem I have is that the logs are not in plaintext format - they
use a "clog" format instead which OSSEC can't read. The only workaround at
the moment is to run a local Syslog server on the router and log everything
to localhost to get the logs in plaintext - I hate the idea of this really
:)
However, I do have the option of sending the logs via Syslog to the OSSIM
server directly but this bypasses OSSEC.
Your point about encryption and authentication is a good one but this won't
be an issue for me as the link between the OSSIM server and OSSEC client is
a physically separate, cabled interface used only for that purpose. I also
don't need e-mail notifications or active response.
That being said, do I still lose something by *not *sending the logs to the
OSSEC client first? In particular you mentioned: "detecting possible
security issues, misconfigurations, errors". Are you saying that OSSIM is
unable to give me the same functionality when sending the logs from the
client directly to the server via Syslog?
Is is still worth the effort setting up the local Syslog workaround I
mentioned above to be able to have the OSSEC client parse the local logs?
I appreciate your continued help.
On Wednesday, September 21, 2016 at 11:58:24 PM UTC+1, Santiago Bassett
wrote:
>
> Hi,
>
> I would advice to use OSSEC agents to collect system logs data, since you
> already have it there doing FIM and anomalies detection anyway. Also
> communications are authenticated and encrypted (as opposed to default
> Syslog).
>
> Other advantage is that you pre-process them through OSSEC decoders and
> rules (before it gets to OSSIM
> correlation engine), detecting possible security issues,
> misconfigurations, errors, As well you can trigger automatic emails and
> use active responses (if you need them).
>
> On the other hand, I don't see a lot of value in processing Snort logs
> through OSSEC (unless you want to use active-responses or use CDBs for
> white/black listing). I would advice to send them directly to OSSIM and
> enable snort-syslog plugin (unless you decide to use embedded Suricata).
>
> I hope that helps,
>
> Santiago.
>
> On Wed, Sep 21, 2016 at 2:13 PM, Eponymous - > wrote:
>
>> Hi,
>>
>> I'm new to OSSEC and also OSSIM and I've just set up a very simple
>> topology.
>>
>> I've got OSSIM on one machine and a single FreeBSD based machine running
>> OSSEC and Snort. I've added the agent in the Agents tab and I can see it
>> connects fine.
>>
>> I see OSSIM and OSSEC working together to schedule and run rootkit checks
>> and syschecks, but I also know that OSSEC can parse the system logs and
>> Snort logs looking for security issues. Currently, the OSSEC configuration
>> is not set up to look at logs and other than manually editing the
>> agent.conf I can't see any way to enable this functionality from OSSIM (I'm
>> using the agent.conf deployment feature).
>>
>> My question is:
>>
>> Should the OSSEC agent be parsing the system logs and Snort logs and then
>> send relevant data to the OSSIM server or should I set it up to send my
>> logs directly to the OSSIM server using Syslog, bypassing the OSSEC agent
>> all together?
>>
>> In each case what are the advantages and disadvantages?
>>
>> In my setup it would be the most simple for the OSSEC agent to handle
>> rootkit checking and syschecking only, with the system logs and Snort logs
>> being sent directly to the OSSIM server using Syslog.
>>
>> Thanks in advance.
>>
>> --
>>
>> ---
>> 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 ossec-list+...@googlegroups.com .
>> 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 ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.