syscheck - what am I doing wrong?

[de...@scratters.com]

I'm trying to get syscheck to work. Actually, not so much work as show any signs of life. :)

I've pared the task down to getting it to indicate something - anything - has changed in a directory I've created on the local installation machine: /etc/test.

My ossec.conf has this:

  <syscheck>
    <frequency>180</frequency>
    <auto_ignore>no</auto_ignore>
    <directories report_changes="yes" check_all="yes">/etc/test</directories>
...

Restarting OSSEC I see this in the ossec.log:

2014/10/16 04:26:31 ossec-syscheckd: INFO: Monitoring directory: '/etc/test'.

which looks encouraging. I then go to /etc/test and create a file, delete the file, and even remove the directory entirely. Nothing else of interest appears in the log. I've tried running syscheckd in debug mode in the foreground and it still doesn't indicate anything of interest has happened.

I've a feeling I've missed something, possibly just as simple as knowing where to look for an indication that syscheck has spotted something has happened. Can someone give me a clue what I'm doing wrong, or just give me a simple starting point configuration which should work?

[dan (ddp)]

On Thu, Oct 16, 2014 at 4:33 AM, <de...@scratters.com> wrote:
> I'm trying to get syscheck to work. Actually, not so much work as show any
> signs of life. :)
>
> I've pared the task down to getting it to indicate something - anything -
> has changed in a directory I've created on the local installation machine:
> /etc/test.
>
> My ossec.conf has this:
>
> <syscheck>
> <frequency>180</frequency>

This frequency seems way too short.

> <auto_ignore>no</auto_ignore>
> <directories report_changes="yes"
> check_all="yes">/etc/test</directories>
> ...
>
> Restarting OSSEC I see this in the ossec.log:
>
> 2014/10/16 04:26:31 ossec-syscheckd: INFO: Monitoring directory:
> '/etc/test'.
>
> which looks encouraging. I then go to /etc/test and create a file, delete
> the file, and even remove the directory entirely. Nothing else of interest

OSSEC doesn't report new files by default, and I'm unsure of the state
of deleted file alerts at this time. It's just not something I've
looked into lately.
Alert logs are stored in /var/ossec/logs/alerts/alerts.log, and that's
where notices of modified files will be.
Was a file ever detected (check /var/ossec/queue/syscheck/(agentname)\
ipaddress->syscheck)? Did you modify a file? Did you ensure that a
scan happened after you modified the file?

> appears in the log. I've tried running syscheckd in debug mode in the
> foreground and it still doesn't indicate anything of interest has happened.
>
> I've a feeling I've missed something, possibly just as simple as knowing
> where to look for an indication that syscheck has spotted something has
> happened. Can someone give me a clue what I'm doing wrong, or just give me a
> simple starting point configuration which should work?
>

> --
>
> ---
> 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.

[de...@scratters.com]

Right, time to have another look at this. I've switched to the AtomiCorp RPMs for CentOS, so everything should be in place. I've tried modifying a file in a monitored directory and alerts.log shows nothing.

I suppose the first thing to ask is whether the system check works for local installations? Syscheck docs refer to agents quite a lot, as does Dan's comment from a few days ago. I don't have any /var/ossec/queue/syscheck/(agentname) type files. I only have the syscheck database in that directory.

The FAQ says that in order to run a system check you use the command:

# /var/ossec/bin/agent_control -r -a

which runs it for all agents. I don't have any agents, and that command gives me:

# ./agent_control -r -a
2014/10/10 23:15:44 agent_control(1210): ERROR: Queue '/queue/alerts/ar' not accessible: 'Connection refused'.
2014/10/10 23:15:44 agent_control(1301): ERROR: Unable to connect to active response queue.

** Unable to connect to remoted.

Is this likely relevant to my problem?

[dan (ddp)]

On Wed, Oct 22, 2014 at 11:49 AM, <de...@scratters.com> wrote:
> Right, time to have another look at this. I've switched to the AtomiCorp
> RPMs for CentOS, so everything should be in place. I've tried modifying a
> file in a monitored directory and alerts.log shows nothing.
>

Was the file already in the syscheck database?
Did a syscheck scan run after you modified the file?

> I suppose the first thing to ask is whether the system check works for local
> installations? Syscheck docs refer to agents quite a lot, as does Dan's

Yes, syscheck works in a local installation. It'd be silly if it did
not. I usually refer to agent/manager installations rather than local
installations because I imagine they're the more "popular"
installation type. Also, having to mention both local and agent and
server everywhere would be tedious.

> comment from a few days ago. I don't have any
> /var/ossec/queue/syscheck/(agentname) type files. I only have the syscheck
> database in that directory.
>

Well that file will have to do (I didn't have a local installation
handy to find out what the file was called, I run a manager and agents
on my laptop to help me test things).

> The FAQ says that in order to run a system check you use the command:
>
> # /var/ossec/bin/agent_control -r -a
>
>
> which runs it for all agents. I don't have any agents, and that command
> gives me:
>
> # ./agent_control -r -a
> 2014/10/10 23:15:44 agent_control(1210): ERROR: Queue '/queue/alerts/ar' not
> accessible: 'Connection refused'.
> 2014/10/10 23:15:44 agent_control(1301): ERROR: Unable to connect to active
> response queue.
>
> ** Unable to connect to remoted.
>
> Is this likely relevant to my problem?
>

If you don't have any agents, why would you run something called
"agent_control?"

[de...@scratters.com]

Was the file already in the syscheck database?

Yes.
 

Did a syscheck scan run after you modified the file?

I don't know. That's the issue I'm confused about. How can I tell?

> The FAQ says that in order to run a system check you use the command:

>
> # /var/ossec/bin/agent_control -r -a
>
>
> which runs it for all agents. I don't have any agents, and that command
> gives me:
>
> # ./agent_control -r -a
> 2014/10/10 23:15:44 agent_control(1210): ERROR: Queue '/queue/alerts/ar' not
> accessible: 'Connection refused'.
> 2014/10/10 23:15:44 agent_control(1301): ERROR: Unable to connect to active
> response queue.
>
> ** Unable to connect to remoted.
>
> Is this likely relevant to my problem?
>

If you don't have any agents, why would you run something called
"agent_control?"

Because the FAQ says that's the thing to do! It doesn't make complete sense to me either, but running "agent_control" on the server, lists, under available agents, agent ID "000" as "Active/Local". It appears there's an agent of sorts running there so using "agent_control" kinda makes sense.

If "agent_control" isn't the answer, what is? What will trigger syscheck to go and have a look at the monitored directories to see if any have been changed?

[de...@scratters.com]

Aha, replying to self... It worked.

There's no clue it's found something from the ossec-syscheck stdout, even when you run it in foreground with -vv. I'd spent an hour wading through the code trying to see what it was doing, when the alerts log suddenly popped up a message about one of the files I'd changed. So it is working, even if I'm not yet in proper control of it. :)

Thanks for the help.

[dan (ddp)]

On Thu, Oct 23, 2014 at 2:55 AM, <de...@scratters.com> wrote:
>> Was the file already in the syscheck database?
>
>
> Yes.
>
>>
>> Did a syscheck scan run after you modified the file?
>
>
> I don't know. That's the issue I'm confused about. How can I tell?
>

Check the ossec.log. If I'm desperate I just restart OSSEC, syscheck
runs a scan by default on startup.

>> The FAQ says that in order to run a system check you use the command:
>>
>> >
>> > # /var/ossec/bin/agent_control -r -a
>> >
>> >
>> > which runs it for all agents. I don't have any agents, and that command
>> > gives me:
>> >
>> > # ./agent_control -r -a
>> > 2014/10/10 23:15:44 agent_control(1210): ERROR: Queue '/queue/alerts/ar'
>> > not
>> > accessible: 'Connection refused'.
>> > 2014/10/10 23:15:44 agent_control(1301): ERROR: Unable to connect to
>> > active
>> > response queue.
>> >
>> > ** Unable to connect to remoted.
>> >
>> > Is this likely relevant to my problem?
>> >
>>
>> If you don't have any agents, why would you run something called
>> "agent_control?"
>
>
> Because the FAQ says that's the thing to do! It doesn't make complete sense
> to me either, but running "agent_control" on the server, lists, under
> available agents, agent ID "000" as "Active/Local". It appears there's an
> agent of sorts running there so using "agent_control" kinda makes sense.
>
> If "agent_control" isn't the answer, what is? What will trigger syscheck to
> go and have a look at the monitored directories to see if any have been
> changed?
>

[de...@scratters.com]

The problem was I didn't realise how slowly the scans happen, or how quietly. When I saw the message in the log saying "INFO: Starting syscheck scan." I kind of expected something to happen - disk activity, log messages to start chugging by, etc. In fact, none of that happens. There's no clue it's doing anything. After trying repeatedly to get it to "work" I gave up and just left it while I got on with something else. 2 hours later it popped up a message.

Right now I'm trying to work out how to make an active response script run when a file is found to have been changed (example anyone?). The experimentation process appears to be to tweak the config, restart, wait 2 hours to see if it worked, repeat.

I would suggest that with debug flags the syscheckd process logs the directories and files it's scanning so the user can see what it's doing. Also, possibly, if it's run with double debug flags the pauses are skipped, thereby trading the low resource usage for more immediate feedback. At 4 test runs per day I'd take that trade right now!

[dan (ddp)]

On Fri, Oct 24, 2014 at 3:23 AM, <de...@scratters.com> wrote:
> The problem was I didn't realise how slowly the scans happen, or how
> quietly. When I saw the message in the log saying "INFO: Starting syscheck
> scan." I kind of expected something to happen - disk activity, log messages
> to start chugging by, etc. In fact, none of that happens. There's no clue
> it's doing anything. After trying repeatedly to get it to "work" I gave up
> and just left it while I got on with something else. 2 hours later it popped
> up a message.
>

If syscheck moves too quickly it can really bog the system down.

> Right now I'm trying to work out how to make an active response script run
> when a file is found to have been changed (example anyone?). The
> experimentation process appears to be to tweak the config, restart, wait 2
> hours to see if it worked, repeat.
>

When testing I usually use a very stripped down syscheck config, maybe just:
<directories check_all="yes">/etc,/var/testing</directories>
It makes the scans quicker.

> I would suggest that with debug flags the syscheckd process logs the
> directories and files it's scanning so the user can see what it's doing.
> Also, possibly, if it's run with double debug flags the pauses are skipped,
> thereby trading the low resource usage for more immediate feedback. At 4
> test runs per day I'd take that trade right now!
>

Submit a pull request: https://github.com/ossec/ossec-hids
I don't like the idea though, I generally run in debug mode and I feel
like this would crush my system.

>
> On Thursday, 23 October 2014 14:28:51 UTC+1, dan (ddpbsd) wrote:
>>
>> Check the ossec.log. If I'm desperate I just restart OSSEC, syscheck
>> runs a scan by default on startup.
>>