[ossec-list] Error in the ossec.conf documentation
I was reading the OSSEC 2.7.1 documentation online for using agent profiles. In OSSEC 2.7.1 documentationhttp://ossec-docs.readthedocs.org/en/latest/index.html» Syntax and Options http://ossec-docs.readthedocs.org/en/latest/syntax/index.html» ossec.conf: syntax and options http://ossec-docs.readthedocs.org/en/latest/syntax/ossec_config.htmlthe Options have server-ip keyword listed twice, once to Specify the IP address of the analysis server and again to Specifies the agent.confprofiles to be used by the agent. Obviously, this is not even wrong. What's the correct option keyword to specify which profile to use? And on a (semi-)related topic, what and how does the agent_config os=value need to match? Is it the value that's shown in Operating system: as returned by agent_control -i id? Thanks. -- --- 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] ossec-maild segfault
From /var/log/messages Jul 30 13:11:12 server name kernel: ossec-maild[10096]: segfault at rip 2add4f72322c rsp 7fff577262e0 error 4 Jul 30 13:11:32 server name kernel: ossec-maild[10097]: segfault at rip 2add4f72322c rsp 7fff577262e0 error 4 Jul 30 16:00:04 server name kernel: ossec-maild[10188]: segfault at rip 2add4f72322c rsp 7fff577262e0 error 4 Jul 30 16:00:04 server name kernel: ossec-maild[10189]: segfault at rip 2add4f72322c rsp 7fff577262e0 error 4 Jul 30 16:00:04 server name kernel: ossec-maild[10190]: segfault at rip 2add4f72322c rsp 7fff577262e0 error 4 Jul 30 16:00:04 server name kernel: ossec-maild[10191]: segfault at rip 2add4f72322c rsp 7fff577262e0 error 4 Jul 30 16:00:04 server name kernel: ossec-maild[10192]: segfault at rip 2add4f72322c rsp 7fff577262e0 error 4 Jul 30 16:00:04 server name kernel: ossec-maild[10193]: segfault at rip 2add4f72322c rsp 7fff577262e0 error 4 Running OSSEC HIDS v2.7 on CentOS 6.4 server. No other messages relating to ossec-maild in any other log. The only change I had made was in ossec.conf, I commented out the default email address in global global email_notificationyes/email_notification !-- email_tof...@bar.com/email_to -- smtp_serverbaz-mailer/smtp_server email_fromfoo...@baz.com/email_from /global Other than that, I made no other changes. There are alerts that meet the email thresholds at or about the time of segfaults. Any ideas? -- --- 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/groups/opt_out.
Re: [ossec-list] ossec-maild segfault
On Thursday, August 1, 2013 9:33:50 AM UTC-4, dan (ddpbsd) wrote: On Thu, Aug 1, 2013 at 7:52 AM, biciunas pa...@biciunas.com javascript: wrote: From /var/log/messages Jul 30 13:11:12 server name kernel: ossec-maild[10096]: segfault at rip 2add4f72322c rsp 7fff577262e0 error 4 Jul 30 13:11:32 server name kernel: ossec-maild[10097]: segfault at rip 2add4f72322c rsp 7fff577262e0 error 4 Jul 30 16:00:04 server name kernel: ossec-maild[10188]: segfault at rip 2add4f72322c rsp 7fff577262e0 error 4 Jul 30 16:00:04 server name kernel: ossec-maild[10189]: segfault at rip 2add4f72322c rsp 7fff577262e0 error 4 Jul 30 16:00:04 server name kernel: ossec-maild[10190]: segfault at rip 2add4f72322c rsp 7fff577262e0 error 4 Jul 30 16:00:04 server name kernel: ossec-maild[10191]: segfault at rip 2add4f72322c rsp 7fff577262e0 error 4 Jul 30 16:00:04 server name kernel: ossec-maild[10192]: segfault at rip 2add4f72322c rsp 7fff577262e0 error 4 Jul 30 16:00:04 server name kernel: ossec-maild[10193]: segfault at rip 2add4f72322c rsp 7fff577262e0 error 4 Running OSSEC HIDS v2.7 on CentOS 6.4 server. No other messages relating to ossec-maild in any other log. The only change I had made was in ossec.conf, I commented out the default email address in global If you correct that mistake does it work? I reverted the file so the email_to element is no longer commented out, and restarted ossec; it's been running for over 3 hours without segfaulting. I guess my question now is, why would commenting out that line cause a segfault (assuming that that's the cause)? global email_notificationyes/email_notification !-- email_tof...@bar.com javascript:/email_to -- smtp_serverbaz-mailer/smtp_server email_fromfoo...@baz.com javascript:/email_from /global Other than that, I made no other changes. There are alerts that meet the email thresholds at or about the time of segfaults. Any ideas? -- --- 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 javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- --- 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/groups/opt_out.
[ossec-list] Re: WARN: Waiting for server reply (not started). Tried: 'server-ip'.
If this is a new agent, did you restart ossec on the server? If not new, did you delete the corresponding id in /var/ossec/queue/rids directory? What does tcpdump or tshark show for 1514 traffic between the server and the agent? On Wednesday, May 15, 2013 6:46:40 AM UTC-4, Kyle Vorster wrote: Hey there, I'm having issues getting a agent connected to the server, I've followed all the docs in resolving this issue but just cant get it to work. Error I get 2013/05/15 12:43:50 ossec-logcollector: INFO: Monitoring full output of command(360): netstat -tan |grep LISTEN |grep -v 127.0.0.1 | sort 2013/05/15 12:43:50 ossec-logcollector: INFO: Monitoring full output of command(360): last -n 5 2013/05/15 12:43:50 ossec-logcollector: INFO: Started (pid: 20948). 2013/05/15 12:43:52 ossec-logcollector: WARN: Process locked. Waiting for permission... 2013/05/15 12:44:05 ossec-agentd(4101): WARN: Waiting for server reply (not started). Tried: 'server-ip'. 2013/05/15 12:44:07 ossec-agentd: INFO: Trying to connect to server (server-ip:1514). 2013/05/15 12:44:07 ossec-agentd: INFO: Using IPv4 for: server-ip . 2013/05/15 12:44:28 ossec-agentd(4101): WARN: Waiting for server reply (not started). Tried: 'server-ip'. Followed the advice at http://www.ossec.net/doc/faq/unexpected.html#how-do-i-troubleshoot-ossecbut still no luck, anyone have an idea of what I can do to troubleshoot or resolve this issue. - Kyle -- --- 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/groups/opt_out.
[ossec-list] 2.7 windows agent communication problem
I upgraded my OSSEC server from 2.6 to 2.7. My 2.6 agents have no problems sending data to the OSSEC server. I started to upgrade the OSSEC agents. I stopped a 2.6 windows agent, uninstalled it, and installed a 2.7 agent. I extracted the existing key from the server (./manage_agents) and used it in the newly installed agent. When I start the agent, I get a Trying to connect to server INFO message. I bounced the server, the agent, still no connection. tethereal shows the request coning in from the agent box to the server, so I know the server is receiving the request. Any ideas? Do I need to generate new keys for the 2.7 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/groups/opt_out.
Re: [ossec-list] 2.7 windows agent communication problem
No, there were no interesting entries in the server's ossec.log. I deleted the rids file, restarted the server, and got a connection. Thanks, Dan. On Friday, March 8, 2013 9:33:52 AM UTC-5, dan (ddpbsd) wrote: On Fri, Mar 8, 2013 at 9:19 AM, biciunas pa...@biciunas.com javascript: wrote: I upgraded my OSSEC server from 2.6 to 2.7. My 2.6 agents have no problems sending data to the OSSEC server. I started to upgrade the OSSEC agents. I stopped a 2.6 windows agent, uninstalled it, and installed a 2.7 agent. I extracted the existing key from the server (./manage_agents) and used it in the newly installed agent. When I start the agent, I get a Trying to connect to server INFO message. I bounced the server, the agent, still no connection. tethereal shows the request coning in from the agent box to the server, so I know the server is receiving the request. Any ideas? Do I need to generate new keys for the 2.7 agents? You shouldn't need to, and I don't think you should have had to re-add the key. Are there any log messages in the ossec server's ossec.log about this agent? Have you tried clearing the rids on the server for this 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+...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- --- 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/groups/opt_out.
[ossec-list] After upgrade to 2.7, ossec-remoted not started by ossec-control start
I upgraded a CentOS 5.9 server from 2.6 to 2.7 using yum. After the upgrade, running ossec-control start results in: [root@foobar bin]# ./ossec-control start Starting OSSEC HIDS v2.7 (by Trend Micro Inc.)... Started ossec-maild... Started ossec-execd... Started ossec-analysisd... [root@foobar bin]# ./ossec-control status ossec-monitord not running... ossec-logcollector not running... *ossec-remoted not running*... ossec-syscheckd not running... ossec-analysisd is running... ossec-maild is running... ossec-execd is running... However, running ossec-remoted will work just fine: [root@foobar bin]# ./ossec-remoted [root@foobar bin]# ossec-control status ossec-monitord not running... ossec-logcollector not running... *ossec-remoted is running*... ossec-syscheckd not running... ossec-analysisd is running... ossec-maild is running... ossec-execd is running... The log shows nothing interesting, even when using ossec-control enable debug. the ossec-server.sh script was not touched. Any ideas? -- --- 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/groups/opt_out.
[ossec-list] After upgrading to 2.7, one agent does not finish server handshake
I upgraded a CentOS 5.9 server from OSSEC 2.6 to 2.7 After restarting OSSEC server, all the 2.6 agents (both Windows and Linux) resumed their connections except for 1 Windows agent. The ossec.log showed: 2013/02/25 18:18:24 ossec-agent: INFO: Started (pid: 3580). 2013/02/25 18:18:34 ossec-agent: WARN: Process locked. Waiting for permission... 2013/02/25 18:18:45 ossec-agent(4101): WARN: Waiting for server reply (not started). Tried: '10.xxx.xxx.xxx'. 2013/02/25 18:18:47 ossec-agent: INFO: Trying to connect to server (10.xxx.xxx.xxx:1514). 2013/02/25 18:18:47 ossec-agent: INFO: Using IPv4 for: 10.xxx.xxx.xxx . 2013/02/25 18:19:08 ossec-agent(4101): WARN: Waiting for server reply (not started). Tried: '10.xxx.xxx.xxx'. 2013/02/25 18:19:28 ossec-agent: INFO: Trying to connect to server (10.xxx.xxx.xxx:1514). 2013/02/25 18:19:28 ossec-agent: INFO: Using IPv4 for: 10.xxx.xxx.xxx . etc. Wireshark on the windows agent box shows UDP messages going to the correct IP address, The strangest part is that running tethereal on the OSSEC server shows the requests coming in, But unlike any of the agentt conversations, there's no outbound messages from the OSSEC server. I can't find anything that remotely looks like a log entry that may shed any relevant information as to why the agent request is ignored. Starting OSSEC in debug mode does not shed any light on this. Anyone have any ideas? -- --- 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/groups/opt_out.
[ossec-list] OSSEC server segfaults in ossec-monitord
I am running OSSEC 2.6 on a CentOS 5.5 server. It is the server that
receives all the ossec data from various and sundry servers. I don't want
it to monitor itself - it's purpose in life is to collect data and email
alerts. However, when I remove the syscheck) stanza from ossec.conf, my
startup looks like:
OSSEC HIDS v2.6 Stopped
Starting OSSEC HIDS v2.6 (by Trend Micro Inc.)...
Started ossec-maild...
Started ossec-execd...
Started ossec-analysisd...
2012/08/17 19:06:46 ossec-logcollector(1905): INFO: No file configured to
monitor.
Started ossec-logcollector...
Started ossec-remoted...
2012/08/17 19:06:46 ossec-syscheckd(1702): INFO: No directory provided for
syscheck to monitor.
../bin/ossec-control: line 218: 10307 Segmentation fault
${DIR}/bin/${i} ${DEBUG_CLI}
[root@x etc]# ../bin/ossec-control status
ossec-monitord not running...
ossec-logcollector is running...
ossec-remoted is running...
ossec-syscheckd not running...
ossec-analysisd is running...
ossec-maild is running...
ossec-execd is running...
Should I simply remove syscheckd from the list of DAEMONS in the startup
script, or should syscheckd quit gracefully, like monitord?
[ossec-list] WinEventLog:Security events
I'm running a Splunk 4.2.5 server on CentOS. On a Win2k3 server I've installed Universal SplunkForwarder 4.3, collecting Application, Security, and System events. I don't want to see Security Success Audit events, since there are about anywhere from 1000-3500 per minute. (And I need to have the Audit Success flags turned on the server since we need to be CIS server compliant.) On the server, I have defined props.conf [WinEventLog:Security] TRANSFORMS-set=dropevents transforms.conf [dropevents] REGEX = (?msi)^EventCode=(560|562|567).*^(Type=Audit Success) DEST_KEY = queue FORMAT = nullQueue I've tried various forms of the REGEX, including just the EventCodes, one EventCode, etc. Nothing seems to work; no events are dropped. I read that this was a known issue before 4.2.1, but it is not listed in the 4.3 known issues. Can anyone enlighten me as to what I may be doing wrong?
[ossec-list] Re: WinEventLog:Security events
In fact, I do have the wrong list. My apologies. My only (weak) defense is that I'm using OSSEC agents to feed data to Splunk. Please disregard this post (unless you can help with my problem). On Feb 1, 3:17 pm, Paul Southerington sout...@gmail.com wrote: I think you have the wrong mailing list. :-) This is for OSSEC - if you have Splunk questions, tryhttp://splunk-base.splunk.com/answers/ On Wed, Feb 1, 2012 at 3:04 PM, biciunas p...@biciunas.com wrote: I'm running a Splunk 4.2.5 server on CentOS. On a Win2k3 server I've installed Universal SplunkForwarder 4.3, collecting Application, Security, and System events. I don't want to see Security Success Audit events, since there are about anywhere from 1000-3500 per minute. (And I need to have the Audit Success flags turned on the server since we need to be CIS server compliant.) On the server, I have defined props.conf [WinEventLog:Security] TRANSFORMS-set=dropevents transforms.conf [dropevents] REGEX = (?msi)^EventCode=(560|562|567).*^(Type=Audit Success) DEST_KEY = queue FORMAT = nullQueue I've tried various forms of the REGEX, including just the EventCodes, one EventCode, etc. Nothing seems to work; no events are dropped. I read that this was a known issue before 4.2.1, but it is not listed in the 4.3 known issues. Can anyone enlighten me as to what I may be doing wrong?
