[ossec-list] Re: queue/ossec/queue' not accessible after fresh install
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 ossec-analysisd(1226): ERROR: Error reading XML file > 'etc/local_decoder.xml > ': XMLERR: File 'etc/local_decoder.xml' not found. (line 126). > 2017/03/08 08:06:38 ossec-analysisd(1202): ERROR: Configuration error at > 'etc/local_decoder.xml > '. Exiting. > > > > -- --- 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.
[ossec-list] Re: queue/ossec/queue' not accessible after fresh install
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, visit https://groups.google.com/d/optout.
[ossec-list] queue/ossec/queue' not accessible after fresh install
I just lost our instance the runs ossec. I tried to reconfigure using persistent disk, but ran into all kinds of queue problems. So I create a fresh install and am getting this error 2017/03/08 07:56:08 ossec-syscheckd(1210): ERROR: Queue '/data/ossec/queue/ossec/queue' not accessible: 'Queue not found'. 2 Indeed queue/ossec/queue does not exist. The queue/ossec directory is empty. What creates those queues? -- --- 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.
[ossec-list] Had to rebuild the server, now how to get agent to reconnect
The ec2 instance that was running the ossec server died. I rebuilt the instance, remounted the disk that had the ossec data files. The server is up, and 'bin/agent_control -l' shows all the agents. But agents cannot connect. I have tried restarting agents. I have also updated the client.key. And I have manually unregistered the client and tried to reregister. This last bit failed with ERROR: Queue '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'. I'm not sure which queue that is refering to, the one on the agent or the server. But when I start the server I do get these errors 2017/03/06 17:51:21 ossec-analysisd(1210): ERROR: Queue '/queue/alerts/ar' not accessible: 'Connectio 2017/03/06 17:51:21 ossec-analysisd(1301): ERROR: Unable to connect to active response queue. 2017/03/06 17:51:21 ossec-analysisd: INFO: Connected to '/queue/alerts/execq' (exec queue) Not sure why this is. Could it be file ownership srw-rw 1 ossecr ossec0 Mar 6 17:51 ar= srw-rw 1 root ossec0 Mar 6 17:51 execq= Should all the queues be owned by ossec? -- --- 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.
Re: [ossec-list] irregular structure in ossec.log
Cool, I'll dig into it this weekend. Should be fun -- haven't written any C code for almost 30 years. ;-) -- --- 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.
[ossec-list] System running out of memory...
I've been getting these alerts: System running out of memory. Availability of the system is in risk. But none of my hosts are even close to running out of memory. But I just realized that this is from docker containers that are about to be killed by the OOM killer. Anybody use docker? I would like to suppress these for docker, but not for the actual hosts. -- --- 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.
[ossec-list] irregular structure in ossec.log
I'm trying to ingest the ossec logs into ELK. But the logs seem a bit
irregular in that the log level is in a different position for different
messages, eg:
2016/07/06 18:01:48 ossec-syscheckd: INFO: Starting syscheck scan.
2016/07/06 18:09:35 ossec-syscheckd: INFO: Ending syscheck scan.
2016/07/06 18:54:35 rootcheck: INFO: Starting rootcheck scan.
2016/07/06 18:54:37 ERROR: statfs('/var/htdocs') produced error: No such
file or directory
2016/07/06 18:54:37 ERROR: statfs('/home/httpd') produced error: No such
file or directory
Is this on purpose? Could this be changed so the logs are more suitable for
automation?
--
---
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.
[ossec-list] active-response.log vs active-responses.log
In one our clients at /var/ossec/logs we have the following: root@ops-bastion-1:/var/ossec/logs# ll total 56 -rw-r- 1 root ossec 0 Jul 4 06:23 active-response.log -rw-r--r-- 1 root ossec 21296 Jul 5 10:33 active-responses.log -rw-rw-r-- 1 ossec ossec 17632 Jul 5 10:16 ossec.log >From what I can tell in all the ossec configs, only the singular active-response.log is defined. Where is the plural file coming from? On this host, in ossec.conf: ossec.conf:/var/ossec/logs/active-response.log -- --- 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.
[ossec-list] rule dependencies?
I made an attempt to trim down the rules but ended up with the following error: 2016/02/27 05:05:24 rules_list: Group 'authentication_success' not found. Invalid 'if_group' Do rules need to loaded in a specific order, or did I remove a file that is depended on by another file? In either case, is there way to determine the dependencies? -- --- 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.
Re: [ossec-list] Re: DNS caching for ?
Another question: My original scenario was when there was NO dns yet to resolve -- only later did the dns record get added. In that case. What I was seeing in that case was the agent would keep issue the error that it could not connect. But if the agent was not even able to resolve to an ip why would it bother to keep trying to connect? -- --- 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.
Re: [ossec-list] Re: DNS caching for ?
Is it expensive to restart an agent? For my case (the OP) I can use consul-template to watch for the when the ossec-remoted's IP has changed and rewrite the IP in the config file then restart the agent. Would the reconnects to the server need to spread out or can it handle the thundering herd of reconnects? As for AWS not giving stable IPs: This really makes no sense when using auto-scaling-groups inside a private CIDR address space. If three nodes are scaled down and later five more a scaled up which would get what IPs? (This is not my original use-case though. The ossec-server is a "well known" and stable instance.) -- --- 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.
[ossec-list] Re: Anybody using CIS controls with OSSEC? (https://github.com/awailly/cis-ubuntu-ansible)
Ok, here's a real CIS question. It looks like the CIS checks have only run on the ossec server. What does it take for these to run on the clients? Do I need to specify rootchecks on the client ossec.conf? Or should it get pushed down from the server? -- --- 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.
[ossec-list] Re: Anybody using CIS controls with OSSEC? (https://github.com/awailly/cis-ubuntu-ansible)
One thing I noticed in kibana, the rule.groups goes down as far rootcheck, but not CIS. rule.groups ossec, rootcheck Wait, I was just going to ask for an easier way to filter on CIS alerts. But then I found the CIS kibana dashboard. :-))) -- --- 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.
[ossec-list] Re: Anybody using CIS controls with OSSEC? (https://github.com/awailly/cis-ubuntu-ansible)
I'm pretty sure now this was a decoy wrt cis-ubuntu-ansible. Something was blocking access from the agent to server, but it was not cis-ubuntu-ansible. In any case, I could not reproduce the problem after rebuilding the [ossec agent] node. Pedro, thanks for the pointer to internal_options.conf -- that will certainly come in handy. Jesus, yes I am running wazuh. Only after asking about this did I notice that OSSEC had support for checking CIS compliance. I need to dig thru logs because until I started using cis-ubuntu-ansible I was definitely not CIS compliant. Now I install OSSEC after running cis-ubuntu-ansible and the only non-compliance OSSEC complains about is not having all the separate partitions. I think I said it before, but it warrants saying it again: OSSEC/wazuh is very, very nice. I really appreciate all the effort that has gone into it. -- --- 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.
[ossec-list] Anybody using CIS controls with OSSEC? (https://github.com/awailly/cis-ubuntu-ansible)
I am trying to harden up our instances, but I find that after applying these controls the agent can longer contact the agent via UDP. I'm still trying to figure out exactly which bit is to blame. Has anybody else used the CIS controls on the same instance as OSSEC? -- --- 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.
[ossec-list] Re: DNS caching for ?
Ok, is this something that would be considered for change? In our environment there is no guarantee that nodes will remain on the same IP. For this we use consul and dnsmasq to lookup DNS names. For now I will hard code server_hostname to the DNS of the ossec server. At least that value exists when the agent starts. But when the ossec server dies (AWS nodes die all the time) I will have update and restart every agent. -- --- 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.
[ossec-list] DNS caching for ?
I have a situation where ossec.conf is set with before the DNS entry is set. From what I can tell so far the result of the initial dns lookup is kept forever, requiring the agent to be restarted. Is it the case that a failed DNS will never be retried? BTW, I'm pretty sure it's not any caching outside of ossec, because the dns server in this case is consul. -- --- 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.
Re: [ossec-list] Re: active-response alerts?
Seems that wazuh already has a decoder and rules for active-response. (Not sure if these are also in ossec proper) https://github.com/wazuh/ossec-rules/blob/master/rules-decoders/ossec/rules/ossec_rules.xml -- --- 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.
Re: [ossec-list] Removing agent by deleting line in client.keys?
Ok, thanks Pedro. I have changed the role to use 'manage_agents -r' and to restart the ossec server. Much nicer. -- --- 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.
[ossec-list] Re: clamav?
On Tuesday, February 23, 2016 at 3:40:29 PM UTC+5:30, Jesus Linares wrote: > It seems your solution is working, but I give you others possible ways to > write in syslog: > >- freshclam: edit */etc/clamav/freshclam.conf* and set "LogSyslog yes" > > I had though that freshclam (which is running as service from the apt package) was already logging to syslog, but I see that it is not. >- clamscan: clamscan --infected -r $SCAN_DIRECTORY --log=$LOG_FILE >--stdout | logger -i -t clamav > > Very nice, I was not aware of logger. I will change over to this. (FYI, the ossec decoder expects the programto be 'clamd' not 'clamav'.) >- clamd: I think, clamd writes in syslog by default. > > Yes, this is what I started with, using clamdscan instead. But clamd runs as clamav user, and hence did not have privs to see pretty much anything. I tried configuring apparmor to give it access specified directories but that did not seem work. thanks much Jesus -- --- 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.
[ossec-list] Re: clamav?
Looks like the clamav rules are just fine.
Only the clamav daemon writes to syslog. So I added a rsyslog config:
$ModLoad imfile
$InputFileName {{ clamav_scan_log_file }}
$InputFileTag clamd:
$InputFileStateFile stat-{{ clamav_scan_log_file }}
$InputFileSeverity error
$InputFileFacility local7
$InputRunFileMonitor
Then some cron jobs to run clamscan on directories, eg (where I have the
EICAR test signature file in /tmp):
clamscan --log=/var/log/clamav/clamav.log --no-summary --infected --remove=
no --recursive=yes /tmp
And magically I get alerts in OSSEC. Very very nice.
--
---
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.
Re: [ossec-list] Re: active-response alerts?
So I'm confused then. The server decided to initiate these actions on the client, no? The server rules are what decided those actions. Should the server not log that it took this action, given the elevated level of the rules? I feel I am missing something understanding. -barry -- --- 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.
[ossec-list] clamav?
Anybody here using clamav? It seems the ossec rules for clamav depend on the syslog format. But clamav-daemon does not run as root, so really it can't scan much of anything. And the clamscan never writes to syslog and its output is in a different format than clamav-daemon. Not really an ossec question, but how is clamav useful it cannot see most files? -- --- 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.
[ossec-list] Re: active-response alerts?
Hmm, ok. On clients there are entries in active-response.log (eg, firewall-drop.sh). But on the server alerts.log there is no trace of those. If I understand the rules correctly they should be there. I don't see any errors in the ossec.log on client or server. What's the best way to debug this? Just up the log level to DEBUG? -- --- 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.
Re: [ossec-list] Removing agent by deleting line in client.keys?
Thanks! Of course it would be much nicer manage_agents was a little nicer to automation... -- --- 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.
[ossec-list] Removing agent by deleting line in client.keys?
Can I remove a registered agent by simply deleting the line in client.keys? That is, skipping the manage_agents program? I am just adding the last few edge cases to our ansible provisioning of ossec. My current edge case is when an instance has been destroyed and rebuilt. In this case the name would be the same but the IP address will almost certainly be different (this is on AWS). It would be way way easier to remove the line from client.keys that figure out to automate manage_agents. It seems that the environment variable mechanism does not support removing agents. -- --- 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.
[ossec-list] active-response alerts?
I see on my clients lots of active response ssh blocks in active-response.log. Should I expect to see some trace of those in the alerts.log? -- --- 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.
[ossec-list] Re: Troubles with manage_agents -f
Ok, I guess I just figured it out. The bulk file needs to be a relative directory $ /var/ossec/bin/manage_agents -f tmp/agent-ops-control-1 Bulk load file: tmp/agent-ops-control-1 Opening: [tmp/agent-ops-control-1] Agent information: ID:005 Name:ops-control-1 IP Address:10.0.196.133 Agent added. Why must this be? -- --- 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.
[ossec-list] Troubles with manage_agents -f
I am running (as root) $ /var/ossec/bin/manage_agents -f /var/ossec/tmp/agent-ops-control-1 Bulk load file: /var/ossec/tmp/agent-ops-control-1 Opening: [/var/ossec/tmp/agent-ops-control-1] Failed.: No such file or directory 2016/02/21 03:42:05 manage_agents(1103): ERROR: Could not open file '/var/ossec/tmp/agent-ops-control-1' due to [(2)-(No such file or directory)]. where $ ls -l /var/ossec/tmp/agent-ops-control-1 -rw-r--r-- 1 root ossec 26 Feb 21 03:35 /var/ossec/tmp/agent-ops-control-1 $ cat /var/ossec/tmp/agent-ops-control-1 10.0.196.133,ops-control-1 I can't figure out what might be wrong... -- --- 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.
Re: [ossec-list] remoted not starting
Well, I did what you did in the Dockerfile for OSSEC: Defined a dummy local agent. Ok for now, I'll watch for https://github.com/ossec/ossec-hids/pull/662. -- --- 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.
Re: [ossec-list] remoted not starting
Old post, sorry. I'm not sure I understand what to do in this case. Will remoted start again if an agent is registered some time after the server starts and remoted decides to shut down? -- --- 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.
Re: [ossec-list] Unattended install always asks...
On Saturday, February 20, 2016 at 3:43:59 AM UTC+5:30, Ryan Schulze wrote: > > Have you tried setting USER_NO_STOP="y" (we use ansible too for building > the binaries)? > > Yes, the problem was only when running install.sh a second time (this is run via ansible, so the playbook can get run a second time, see https://groups.google.com/forum/#!topic/ossec-list/UBkWpp9T9ec). When install.sh discovers an existing install it seems to always prompt no matter the USER_NO_STOP value. I had to explicitly set USER_UPDATE=y in that case -- but not in the case of the first install. I also had to set USER_CLEANINSTALL=y to get the seond run to actually make changes to the install. -- --- 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.
Re: [ossec-list] duplicate ossec processes
The problem was the install as run by ansible. Since tasks in ansible are meant to be idempotent (and ossec install.sh is not that) when ansible would run the install again, in my case with USER_DELETE_DIR=y, the pid would get lost. Changing USER_DELETE_DIR=n fixed this problem. Why does ossec use its own install directory for things like /var/ossec/var/* ? But other bits had to be tweaked to get the install to run without user input.I had to do what the install.sh does to detect if there is indeed already an install and set USER_UPDATE=y in that case only as otherwise the compile will happen. I also need to set USER_CLEANINSTALL=y. I should note that I don't really want to be deploying via source, but I'm using the wazuh fork as I want the ELK integration and they don't have any packages (yet?) -- --- 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.
[ossec-list] Unattended install always asks...
I cannot get the install to NOT ask You already have OSSEC installed. Do you want to update it? I am installing via ansible, the ./install.sh can get invoked more than once. That's ok, I just need to ossec to not prompt. I have set USER_UPDATE="n" and "y" -- but still get prompted. What am I missing? -- --- 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.
[ossec-list] duplicate ossec processes
Is this normal? Should there be duplicate processes running under ossec and root? When I run install.sh I think it starts processes. But then I also run "service ossec start" as part of the ansible playbook. [barry@ops-security-server]~❯ ps aux | grep ossec > root 15628 0.0 0.0 14992 584 ?S07:33 0:00 > /opt/ossec/bin/ossec-execd > ossec15632 0.1 0.0 20464 3236 ?S07:33 0:00 > /opt/ossec/bin/ossec-analysisd > root 15638 0.0 0.0 6624 620 ?S07:33 0:00 > /opt/ossec/bin/ossec-logcollector > root 15648 0.4 0.0 7368 1636 ?S07:33 0:02 > /opt/ossec/bin/ossec-syscheckd > ossec15652 0.0 0.0 18264 612 ?S07:33 0:00 > /opt/ossec/bin/ossec-monitord > root 15871 0.0 0.0 8264 960 pts/0S+ 07:37 0:00 less > ossec.log > root 18336 0.0 0.0 14992 576 ?S07:41 0:00 > /opt/ossec/bin/ossec-execd > ossec18340 0.0 0.0 20080 2904 ?S07:41 0:00 > /opt/ossec/bin/ossec-analysisd > root 18345 0.0 0.0 6612 600 ?S07:41 0:00 > /opt/ossec/bin/ossec-logcollector > root 18356 0.0 0.0 6856 744 ?S07:41 0:00 > /opt/ossec/bin/ossec-syscheckd > ossec18360 0.0 0.0 18264 612 ?S07:41 0:00 > /opt/ossec/bin/ossec-monitord -- --- 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.
