Just note that there is no magic here - it does not work because your
automated way does not 100% replicate the manual way (how to add an agent /
the client.keys / the ossec.conf / the agent installation...)
My guess is that the key file is not created correctly - preventing the
client-server to
1. I would troubleshoot by first trying to run it without realtime.
This will reduce all the INotify based tracking and will validate that your
paths are correct.
2. The event count is just a debug message, that should better be sent in
Debug level.
Cheers,
Roy
On Tuesday, June 24, 2014 2:52:
Just saw this thread and wish to add my 2 cents:
- Syscheck: there is a state that is in both memory and file system
regarding the agents that finished creating the initial baseline and are
ready. I suspect it might not trigger FIM alerts for new agents.
- Complex events (correlation). I'm not su
Gerard - You did not specify if the CPU hit is on the server or agent side.
Anyway, a *hack* you can try is deleting the relevant .cpt file located at
/var/ossec/queue/syscheck/AGENT_NAME
and restarting ossec server.
This file signals the server that this agent is ready to process and
generate
Agents can be silently installed.
Windows is nsis base and supports the /S flag (silent)
In Linux you can do binary install
: http://www.ossec.net/doc/manual/installation/
On Tuesday, February 11, 2014 3:23:10 PM UTC-8, David Montgomery wrote:
>
> Hi,
>
> Newbie trying to install agent and server
It is possible that you are scanning too many files/ folders that can cause
a very long scan time (many hours)
OSSEC limits the rate of the scans in order not to consume too many system
resources.
A new scan will not start while the prev one did not finish.
Please verify in the client log how mu
Sure.
https://bitbucket.org/jbcheng/ossec-hids/issue/57/syscheck-file-deleted-events-are-not
On Tuesday, October 1, 2013 10:03:36 AM UTC-7, Michael Starks wrote:
>
> On 01.10.2013 10:45, Roy Feintuch wrote:
> > Dan, I would like to note that I have never seen a file deleted even
Dan, I would like to note that I have never seen a file deleted event fired
without realtime=true.
I have also verified it by deleting a file when ossec agent was down. This
file was never reported as deleted again even after full scans (unlike new
files / updated file - that were reported afte
Just be aware that authd is not intended to constantly run as it provides
no client authentication.
The desired automation would be to start it upon provisioning of a new
client and then stop it once ossec agent was provisioned.
This is probably why it is not bundled with the startup scripts.
BT
Windows firewall varies between versions.
Logs are usually located
at: %systemroot%\system32\LogFiles\Firewall\pfirewall.log
They are enabled per active profile (domain / public / private) and you
need to specify if to log accepted connections and dropped packets.
Get the config app at:
Start->
me a huge space in disk if I add the webapps directory
> for report_changes as well.
> So, is it correct to do like this:
>
> report_changes="yes">/home/tomcat/conf
> /home/tomcat
>
> Is there another way for do that or its as simple as that?
>
> Best
Thanks Michael. was about to start writing this script...
On Fri, Sep 13, 2013 at 12:21 PM, Michael Starks <
ossec-l...@michaelstarks.com> wrote:
> On 13.09.2013 13:28, Roy Feintuch wrote:
>
>> Im not talking about solving someones specific issues. If people knew
>> wh
at 10:37 AM, dan (ddp) wrote:
> On Fri, Sep 13, 2013 at 1:36 PM, Roy Feintuch wrote:
> > Dan or anyone else - I see from time to time people reporting issues
> cause
> > by wrong permissions.
> > Is there any script somewhere to fix/rebuild all OSSEC related files
>
Dan or anyone else - I see from time to time people reporting issues cause
by wrong permissions.
Is there any script somewhere to fix/rebuild all OSSEC related files
permissions?
On Friday, September 13, 2013 8:06:15 AM UTC-7, ljf...@mdanderson.org wrote:
>
> Thanks Dan. That fixed that issue
Hi,
1. I think you are checking the wrong folder - queue/diff is used to store
the files where using 'report_changes' mode (full diff reporting)
The syscheck db folder is at queue/syscheck
2. If this is a new installation - then it takes ossec some time to start
triggering some events (~1 day /
Realtime does not work for new files detection - only for changes/deletions.
New files are detected using the standard scan - so reduce its interval
(frequency) if you want to have new files detections in a reasonable time.
-Roy
On Friday, August 30, 2013 10:30:01 AM UTC-7, Stephan Gomes Higuti
rming.
10x
On Wednesday, August 21, 2013 6:15:54 AM UTC-7, dan (ddpbsd) wrote:
>
> On Tue, Aug 20, 2013 at 5:55 PM, Roy Feintuch >
> wrote:
> > Hi all,
> > I have seem many threads about failure to detect file deletions, and
> think I
> > can add some insigh
V & D,
I would bet that the problem is with *not restarting the server after
adding the agent.*
I was chasing this myself and the thing is tricky because every server
conf/rule 'fix' that you apply (and restart the server) actually does fix
the issue for the agent you were inspecting.
Only new a
Hi all,
I have seem many threads about failure to detect file deletions, and think
I can add some insights to the reason.
Env:
OSSEC server 2.7 (
Windows agents (7,2008 R2)
Centos/RHEL Agents
Scenario:
- In the past we used realtime=true for the syscheck configuration. All
events (new file / ch
19 matches
Mail list logo
