Hi,
I like your intention to create a whitelist for checksum using CDB lists, I
think it will be a great functionality. Unfortunately you won't be able to
do it, since OSSEC lists does not allow to match using "syscheck.md5_after"
field.
You can check here the available fields for matching a CDB
I am in EST and I absolutely agree with you. I think we should spend no
more than 30 minutes looking at your discovery, looking at logs in
archives.log then , as you noted, requesting an enhancement to ensure those
log values are sent over by the agent.
All the best
Grant Leonard
Castra
Hi Sushan,
I think that embedding a local OSSEC into every container is not the best
approach, IMHO. In fact, the Docker's "best practices" guideline recommends
to have one process per container, this could mean one service per
container.
Since agents can auto-register via ossec-authd, you
I am struggling to find a good read on pros and cons of running OSSEC on
Docker containers.
I am looking to implement intrusion detection on underlying hosts and not
on the containers. All applications run on containers but are orchestrated
by a orchestrator, therefore threat level is
Running the ossec server in a docker container, makes sense, and I run the
Wazuh fork of ossec in their provided container with logstash / kibana4.
Running ossec agent in a container makes no sense to me.
I would suggest instead that you use the docker logging driver to reroute
stdout from
Hi Barry,
File /var/ossec/etc/local_decoder.xml must exist and contain at less one
decoder, although it is a dummy one, for example:
local_decoder_example
Try to create that file and fill it with the content above and restar ossec
with: /var/ossec/bin/ossec-control restart.
Hope it
I am in EST and I absolutely agree with you. I think we should spend no
more than 30 minutes looking at your discovery, looking at logs in
archives.log then , as you noted, requesting an enhancement to ensure those
log values are sent over by the agent.
All the best
Grant Leonard
Castra
Thank you Pedro. That's good information.
With that in mind, I've decided to give this a
try:
https://blog.rootshell.be/2013/05/13/improving-file-integrity-monitoring-with-ossec/
Basically, he patched the code to make it look at a sqlite3 database prior
to alerting.
Unfortunately, the code
Actually all the queue directories are empty.
--
---
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,
Looks like the config entries for local_decor was the culprit. Not sure why
that did not cause a problem the first time ossec was installed.
On Wednesday, March 8, 2017 at 9:26:49 AM UTC+1, Barry Kaplan wrote:
>
> The only errors on ossec. log not about queues is
>
> 2017/03/08 08:06:38
10 matches
Mail list logo
