[ossec-list] Method to determine if ACTIVE RESPONSE is enabled/disabled on several hundred servers running OSSEC Agent
All: The standard deployment instructions in our group for installation of the OSSEC (2.6) agents on servers is to set ACTIVE RESPONSE as disabled. There is some question/concern by our management that this was not done on all server. Are there any options available for checking each of our 600 servers to determine whether ACTIVE RESPONSE is enabled or disabled (short of parsing conf files on each)? Thanks Luckie Ford -- --- 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: Remoted issues
Any thoughts? A client.keys file issue? All files/permissions should as they were when OSSEC was running properly so it is perplexing to me what might be wrong. Since I have over 500 agents, a reinstall and new key deployment is a bit frightening. Thanks! On Wednesday, September 18, 2013 2:18:10 PM UTC-5, MDACC-Luckie wrote: Dan: Still following the issue of my ossec server that stopped running due to permissions that were changed on ossec directories and subdirectories. I opted to get our storage team to recover all files with appropriate permission from a given date/time. Things are coming along but now I am facing an issue with ossec-remoted not running. Everything appears to start when OSSEC starts but afer doing a status, I see the following: # /opt/ossec/bin/ossec-control status ossec-monitord is running... ossec-logcollector is running... ossec-remoted: Process 7541 not used by ossec, removing .. ossec-remoted not running... ossec-syscheckd is running... ossec-analysisd is running... ossec-maild is running... ossec-execd not running... Following recommendations you made to someone in another post in this group, I ran remoted in gdb. I really am not sure what I am looking at in the output of gdb below to further troubleshoot the issue. Any suggestions or recommendations would be greatly appreciated. GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-42.el5_8.1) Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-redhat-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /opt/ossec/bin/ossec-remoted...done. (gdb) set follow-fork-mode child (gdb) run -df Starting program: /opt/ossec/bin/ossec-remoted -df warning: no loadable sections found in added symbol-file system-supplied DSO at 0x2aaab000 [Thread debugging using libthread_db enabled] 2013/09/18 14:03:39 ossec-remoted: DEBUG: Starting ... 2013/09/18 14:03:39 ossec-remoted: INFO: Started (pid: 26892). [New process 26895] [Thread debugging using libthread_db enabled] 2013/09/18 14:03:39 ossec-remoted: DEBUG: Forking remoted: '0'. 2013/09/18 14:03:40 ossec-remoted: INFO: Started (pid: 26895). 2013/09/18 14:03:40 ossec-remoted: DEBUG: Running manager_init [New Thread 0x40a00940 (LWP 26896)] [New Thread 0x41401940 (LWP 26897)] 2013/09/18 14:03:40 ossec-remoted: INFO: (unix_domain) Maximum send buffer set to: '262144'. 2013/09/18 14:03:40 ossec-remoted(4111): INFO: Maximum number of agents allowed: '1024'. 2013/09/18 14:03:40 ossec-remoted(1410): INFO: Reading authentication keys file. 2013/09/18 14:03:40 ossec-remoted: DEBUG: OS_StartCounter. 2013/09/18 14:03:40 ossec-remoted: OS_StartCounter: keysize: 455 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x2aac5af0 (LWP 26895)] 0x0042191b in OS_StartCounter (keys=0x64e700) at msgs.c:88 88 if((keys-keyentries[i -1]-fp) (i 10)) (gdb) (gdb) bt #0 0x0042191b in OS_StartCounter (keys=0x64e700) at msgs.c:88 #1 0x0040421d in HandleSecure () at secure.c:84 #2 0x004040e1 in HandleRemote (position=0, uid=955) at remoted.c:101 #3 0x00402c90 in main (argc=2, argv=0x7fffe988) at main.c:150 -- --- 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] Remoted issues
Dan: Still following the issue of my ossec server that stopped running due to permissions that were changed on ossec directories and subdirectories. I opted to get our storage team to recover all files with appropriate permission from a given date/time. Things are coming along but now I am facing an issue with ossec-remoted not running. Everything appears to start when OSSEC starts but afer doing a status, I see the following: # /opt/ossec/bin/ossec-control status ossec-monitord is running... ossec-logcollector is running... ossec-remoted: Process 7541 not used by ossec, removing .. ossec-remoted not running... ossec-syscheckd is running... ossec-analysisd is running... ossec-maild is running... ossec-execd not running... Following recommendations you made to someone in another post in this group, I ran remoted in gdb. I really am not sure what I am looking at in the output of gdb below to further troubleshoot the issue. Any suggestions or recommendations would be greatly appreciated. GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-42.el5_8.1) Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-redhat-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /opt/ossec/bin/ossec-remoted...done. (gdb) set follow-fork-mode child (gdb) run -df Starting program: /opt/ossec/bin/ossec-remoted -df warning: no loadable sections found in added symbol-file system-supplied DSO at 0x2aaab000 [Thread debugging using libthread_db enabled] 2013/09/18 14:03:39 ossec-remoted: DEBUG: Starting ... 2013/09/18 14:03:39 ossec-remoted: INFO: Started (pid: 26892). [New process 26895] [Thread debugging using libthread_db enabled] 2013/09/18 14:03:39 ossec-remoted: DEBUG: Forking remoted: '0'. 2013/09/18 14:03:40 ossec-remoted: INFO: Started (pid: 26895). 2013/09/18 14:03:40 ossec-remoted: DEBUG: Running manager_init [New Thread 0x40a00940 (LWP 26896)] [New Thread 0x41401940 (LWP 26897)] 2013/09/18 14:03:40 ossec-remoted: INFO: (unix_domain) Maximum send buffer set to: '262144'. 2013/09/18 14:03:40 ossec-remoted(4111): INFO: Maximum number of agents allowed: '1024'. 2013/09/18 14:03:40 ossec-remoted(1410): INFO: Reading authentication keys file. 2013/09/18 14:03:40 ossec-remoted: DEBUG: OS_StartCounter. 2013/09/18 14:03:40 ossec-remoted: OS_StartCounter: keysize: 455 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x2aac5af0 (LWP 26895)] 0x0042191b in OS_StartCounter (keys=0x64e700) at msgs.c:88 88 if((keys-keyentries[i -1]-fp) (i 10)) (gdb) (gdb) bt #0 0x0042191b in OS_StartCounter (keys=0x64e700) at msgs.c:88 #1 0x0040421d in HandleSecure () at secure.c:84 #2 0x004040e1 in HandleRemote (position=0, uid=955) at remoted.c:101 #3 0x00402c90 in main (argc=2, argv=0x7fffe988) at main.c:150 -- --- 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] WARN: Process locked. Waiting for permission At Server When Trying To Start Server
I have dealt with issues with agents not connecting to the server with a WARN: Process locked. Waiting for permission message in the log but not at the server. When starting OSSEC on the primary OSSEC server, I am getting that message in the OSSEC log file. No agents appear to be able to connect to the server now. Any suggestions or thoughts on what to look at on the server to fix this? -- --- 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] Changes relating to email_alert_level not taking affect after restart of OSSEC
My original OSSEC configuration had the following settings for alert logging and email alert levels: alerts log_alert_level7/log_alert_level email_alert_level7/email_alert_level /alerts My team decided that receiving leve 7-9 alerts was not necessary so I changed my ossec.conf file to reflect the following: alerts log_alert_level7/log_alert_level email_alert_level10/email_alert_level /alerts After making this change, I restarted OSSEC but continue to receive emails on level 7-9 alerts. I have not configured any granular email alerts that would otherwise force this to happen like in this example: email_alerts email_toother_ad...@example.com/email_to level12/level/email_alerts Any thoughts on why this change is not taking affect?
[ossec-list] Re: Changes relating to email_alert_level not taking affect after restart of OSSEC
You are correct... thank you very much for your expertise and help for everyone! Been racking my brains for hours on this one. On Wednesday, August 29, 2012 12:59:02 PM UTC-5, MDACC-Luckie wrote: My original OSSEC configuration had the following settings for alert logging and email alert levels: alerts log_alert_level7/log_alert_level email_alert_level7/email_alert_level /alerts My team decided that receiving leve 7-9 alerts was not necessary so I changed my ossec.conf file to reflect the following: alerts log_alert_level7/log_alert_level email_alert_level10/email_alert_level /alerts After making this change, I restarted OSSEC but continue to receive emails on level 7-9 alerts. I have not configured any granular email alerts that would otherwise force this to happen like in this example: email_alerts email_toother_ad...@example.com/email_to level12/level/email_alerts Any thoughts on why this change is not taking affect?
[ossec-list] Re: OSSEC large scale deployment
Sakka: We have deployed to 600 servers, have modified rules and severity levels to meet the requirements of our environment and with the exception of a few minor (but workable) issues, all seems to be good.
[ossec-list] Re: OSSEC large scale deployment
Nate: We are split 50/50 between Windows and Redhat. I wrote some crude scripts to push the installation media along with the preconfigured ossec.conf files for each O/S out to each of our 600 boxes. Although there are numerous ways I have seen (on the Linux side especially) to do an automated deployment, we opted to deploy each manually. Since we have a staff of 10, we did a divide and conquer and let each take a representative share of the load to deploy over a weeks time. It was a bit tedious but since we touch our boxes regularly, it was just an additional task they performed as they were in the box. We used the ossec-batch-manager.pl (is downloadable) to generate and document the keys for each box.
[ossec-list] Re: OSSEC large scale deployment
It really wasn't. We could have deployed relatively easy using some of the tools at our disposal but opted to go the manual route just for piece of mind purposes. Our servers are high profile and provide application support to our 25k employees so we felt it was better to deploy individually rather than adversely impact devices with any potential unknowns that happend when you start pushing things automagically. Since deployment, it has been solid and have had relatively few issues at all, especially when compared to many tools and products that we pay premium dollars for. I am a huge proponent of the product. And it has been flawless in reporting the information we need.
[ossec-list] Windows Multiple authentication failures followed by a success available?
I have found references to Multiple authentication failures followed by a success on the SSH side but don't see anything similar on the Windows side. Has anyone successfully written anything to do this or have suggestions on how to accomplish this? We have 300+ servers and see this functionality as a necessity. Thanks Luckie Ford
[ossec-list] Question about alert generated by Windows Security Log event
We are working to refine the use of OSSEC for our monitoring of
security events on our systems and noticed something in the OSSEC
alerting that I have questions about. In the security event log of
the server, the information is displayed as follows (where x
\yy is to domain\userid of the user):
Security Enabled Local Group Member Removed:
Member Name:-
Member ID: x\yy
Target Account Name:Administrators
Target Domain: Builtin
Target Account ID: BUILTIN\Administrators
Caller User Name: DDSWx$
Caller Domain: MN
Caller Logon ID:(0x0,0x3E7)
Privileges: -
OSSEC displays that same event as:
Security Enabled Local Group Member Removed
Member Name: -
Member ID: %{S-1-5-21-xx-xx-
xx-1122}
Target Account Name: Administrators
Target Domain: Builtin
Target Account ID: %{S-1-5-xx-xxx}
Caller User Name: DDSWx$
Caller Domain: MN
Caller Logon ID: (0x0,0x3E7)
Privileges: -
Can we get OSSEC to display the Member ID: x\yy instead
of Member ID: %{S-1-5-21-xx-xx-xx-1122}?
Not having the domain\userid quickly visible to us delays our response
to security incidents.
Thanks in advance.
[ossec-list] Re: Problems with ossec-maild
Thanks Daniel. That definitely was it.
[ossec-list] Re: Problems with ossec-maild
[root@dcprpoemprddb1 bin]# diff -r /opt/ossec-hids-2.6/src/os_maild/ maild.h /opt/ossec-hids-2.6/src/os_maild/maild.h.11172011 31c31 #define MAIL_SUBJECTOSSEC Notification - Alert level %d - %s - Date %s --- #define MAIL_SUBJECTOSSEC Notification - %s - Alert level %d - Date %s
[ossec-list] Re: Problems with ossec-maild
I don't see any anomalies in my keys. As far as limits on the user running ossec, there are none. My max length server name is 15 characters. I am not proficient enough with my programming skills to go into the code and modify to provide any enhanced logging, mainly because I haven't had the need or the time to do it. I guess I could learn but definitely doesn't help with the immediate issue. How complicated is it or is it even possible for me to take a copy of specific files that might hold key information, reinstall, and then use that backed up key information in a vanilla installation to see if that fixes anything? If so, what files? Thanks again for all your help on this.
[ossec-list] Re: Problems with ossec-maild
Our config is pretty standard with respect to the ossec.conf. The only non-standard thing we have is that we are usiing port 9025 for SMTP on the mail server we are using rather than 25. We have that changed in the sendmail.c file that is used when everything is compiled: OSSEC.CONF global email_notificationyes/email_notification email_toos...@xx.xxx/email_to smtp_serverdcprpafszenoss2.xx.xxx/smtp_server email_fromoss...@xx.xxx/email_from email_maxperhour1000/email_maxperhour /global SENDMAIL.C /* Default values use to connect */ #define SMTP_DEFAULT_PORT 9025 #define HELOMSG Helo notify.ossec.net\r\n #define MAILFROMMail From: %s\r\n #define RCPTTO Rcpt To: %s\r\n #define DATAMSG DATA\r\n #define FROMFrom: OSSEC HIDS %s\r\n #define TO To: %s\r\n #define CC Cc: %s\r\n #define SUBJECT Subject: %s\r\n #define ENDDATA \r\n.\r\n #define QUITMSG QUIT\r\n It was working prior to the increase of the number of agents supported and the recompile. I ran a tcpdump on the manager and don't see the manager even attempting to try to connect to the SMTP host on port 9025, only using the agent/manager connection between the two boxes. On Mar 27, 3:36 pm, dan (ddp) ddp...@gmail.com wrote: What's your mail configuration in the manager's ossec.conf? I wish ossec was compiled with -ggdb by default. It might make the gdb information a bit easier to follow. On Thu, Mar 22, 2012 at 1:47 PM, MDACC-Luckie luckief...@gmail.com wrote: I increased the number of agents my installation was capable of supporting, reinstalled and then copied my saved ossec.conf file and internal_options.conf into the ossec/etc directory and restarted ossec. My ossec-maild daemon starts, runs for a few seconds and then dies. I ran the following based on a previous email thread I saw and have attached the results. Please let me know if anyone has ideas on why it is happening: [root@dcprpoemprddb1 logs]# gdb /opt/ossec/bin/ossec-maild GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-23.el5_5.2) Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/ gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-redhat-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /opt/ossec/bin/ossec-maild...done. (gdb) set follow-fork-mode child (gdb) run Starting program: /opt/ossec/bin/ossec-maild [New process 2615] [New process 2616] Program received signal SIGSEGV, Segmentation fault. [Switching to process 2616] 0x00387c879b60 in strlen () from /lib64/libc.so.6 (gdb) bt #0 0x00387c879b60 in strlen () from /lib64/libc.so.6 #1 0x00387c846cb9 in vfprintf () from /lib64/libc.so.6 #2 0x00387c8699da in vsnprintf () from /lib64/libc.so.6 #3 0x00387c84d5e3 in snprintf () from /lib64/libc.so.6 #4 0x00402d66 in OS_RecvMailQ (fileq=0x635640, p=0x387cb56cc0, Mail=0x7fffe870, msg_sms=0x7fffe7e0) at os_maild_client.c:96 #5 0x00402848 in OS_Run (mail=0x7fffe870) at maild.c:381 #6 0x004023d0 in main (argc=1, argv=0x7fffe9f8) at maild.c:171 (gdb)- Hide quoted text - - Show quoted text -
[ossec-list] Re: Problems with ossec-maild
Not long by max length standards 15 characters or so. Are there any other of those type of things I could check data corruption somewhere that I might need to look for that isnt obvious to me. I dont think it is with ossec-maild but something with the extra 60 or so agent keys I generated that might be causing some type of issue. The reason I ask is that used list_agents and saw a device name as being an agent but when I looked for it in a manage_agents listed of keys, it wasnt there. Some type of consistency check that can be run that looks for possible issues? On Mar 27, 3:58 pm, dan (ddp) ddp...@gmail.com wrote: Kind of off the wall: Do you have very long agent names? On Tue, Mar 27, 2012 at 4:46 PM, MDACC-Luckie luckief...@gmail.com wrote: Our config is pretty standard with respect to the ossec.conf. The only non-standard thing we have is that we are usiing port 9025 for SMTP on the mail server we are using rather than 25. We have that changed in the sendmail.c file that is used when everything is compiled: OSSEC.CONF global email_notificationyes/email_notification email_toos...@xx.xxx/email_to smtp_serverdcprpafszenoss2.xx.xxx/smtp_server email_fromoss...@xx.xxx/email_from email_maxperhour1000/email_maxperhour /global SENDMAIL.C /* Default values use to connect */ #define SMTP_DEFAULT_PORT 9025 #define HELOMSG Helo notify.ossec.net\r\n #define MAILFROM Mail From: %s\r\n #define RCPTTO Rcpt To: %s\r\n #define DATAMSG DATA\r\n #define FROM From: OSSEC HIDS %s\r\n #define TO To: %s\r\n #define CC Cc: %s\r\n #define SUBJECT Subject: %s\r\n #define ENDDATA \r\n.\r\n #define QUITMSG QUIT\r\n It was working prior to the increase of the number of agents supported and the recompile. I ran a tcpdump on the manager and don't see the manager even attempting to try to connect to the SMTP host on port 9025, only using the agent/manager connection between the two boxes. On Mar 27, 3:36 pm, dan (ddp) ddp...@gmail.com wrote: What's your mail configuration in the manager's ossec.conf? I wish ossec was compiled with -ggdb by default. It might make the gdb information a bit easier to follow. On Thu, Mar 22, 2012 at 1:47 PM, MDACC-Luckie luckief...@gmail.com wrote: I increased the number of agents my installation was capable of supporting, reinstalled and then copied my saved ossec.conf file and internal_options.conf into the ossec/etc directory and restarted ossec. My ossec-maild daemon starts, runs for a few seconds and then dies. I ran the following based on a previous email thread I saw and have attached the results. Please let me know if anyone has ideas on why it is happening: [root@dcprpoemprddb1 logs]# gdb /opt/ossec/bin/ossec-maild GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-23.el5_5.2) Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/ gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-redhat-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /opt/ossec/bin/ossec-maild...done. (gdb) set follow-fork-mode child (gdb) run Starting program: /opt/ossec/bin/ossec-maild [New process 2615] [New process 2616] Program received signal SIGSEGV, Segmentation fault. [Switching to process 2616] 0x00387c879b60 in strlen () from /lib64/libc.so.6 (gdb) bt #0 0x00387c879b60 in strlen () from /lib64/libc.so.6 #1 0x00387c846cb9 in vfprintf () from /lib64/libc.so.6 #2 0x00387c8699da in vsnprintf () from /lib64/libc.so.6 #3 0x00387c84d5e3 in snprintf () from /lib64/libc.so.6 #4 0x00402d66 in OS_RecvMailQ (fileq=0x635640, p=0x387cb56cc0, Mail=0x7fffe870, msg_sms=0x7fffe7e0) at os_maild_client.c:96 #5 0x00402848 in OS_Run (mail=0x7fffe870) at maild.c:381 #6 0x004023d0 in main (argc=1, argv=0x7fffe9f8) at maild.c:171 (gdb)- Hide quoted text - - Show quoted text -- Hide quoted text - - Show quoted text -
[ossec-list] Re: Issues with not being able to start OSSEC-REMOTED
Thanks for the info Dan. Your question about agents configured triggered the in my mind that even though I had bumped up my agents it was configured to handle, I had actually not increased it to acconodate as many as was configure. I bumped up the number of agents again and it is all working well now. Thanks!
[ossec-list] Problems with ossec-maild
I increased the number of agents my installation was capable of supporting, reinstalled and then copied my saved ossec.conf file and internal_options.conf into the ossec/etc directory and restarted ossec. My ossec-maild daemon starts, runs for a few seconds and then dies. I ran the following based on a previous email thread I saw and have attached the results. Please let me know if anyone has ideas on why it is happening: [root@dcprpoemprddb1 logs]# gdb /opt/ossec/bin/ossec-maild GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-23.el5_5.2) Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/ gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-redhat-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /opt/ossec/bin/ossec-maild...done. (gdb) set follow-fork-mode child (gdb) run Starting program: /opt/ossec/bin/ossec-maild [New process 2615] [New process 2616] Program received signal SIGSEGV, Segmentation fault. [Switching to process 2616] 0x00387c879b60 in strlen () from /lib64/libc.so.6 (gdb) bt #0 0x00387c879b60 in strlen () from /lib64/libc.so.6 #1 0x00387c846cb9 in vfprintf () from /lib64/libc.so.6 #2 0x00387c8699da in vsnprintf () from /lib64/libc.so.6 #3 0x00387c84d5e3 in snprintf () from /lib64/libc.so.6 #4 0x00402d66 in OS_RecvMailQ (fileq=0x635640, p=0x387cb56cc0, Mail=0x7fffe870, msg_sms=0x7fffe7e0) at os_maild_client.c:96 #5 0x00402848 in OS_Run (mail=0x7fffe870) at maild.c:381 #6 0x004023d0 in main (argc=1, argv=0x7fffe9f8) at maild.c:171 (gdb)
[ossec-list] Issues with not being able to start OSSEC-REMOTED
We have had a very successful deployment of OSSEC so I got really gung- ho and decided to add the final handful of servers and generate keys for them. I generated keys for about 60 extra servers consecutively. Since that happened and I restarted the OSSEC processes, ossec-remoted is dying. In my digging around, I noticed the following: - When I (L)ist already added agents using manage_agents, my full list of devices I generated keys for appears BUT - When I do a ./agent_control -l, only the OSSEC server using ID: 000 is listed and no others. As well, when I look in my ossec.log file, I see entries for ossec- remoted starting but never any other info about issues. Is there some enhanced logging that I can turn on to see why it is failing? Or any suggestions for troubleshooting this issue? Thanks Luckie
