Re: [ossec-list] Windows agents not connecting to OSSEC server
On Sun, 12 Oct 2014, David Masters wrote: Ok...here is the log file from a freshly installed agent (shutdown ossec server, removed all rid files, no rid files on agent system, manually entererd key and server address): This is the log file from same machine after pushing out key file/ossec.conf file and deleting rid files (no change to any other part of the machine or configuration): Verified all information in both files was exactly the same as before and files in rids directory were deleted before service was restarted. Any ideas? Did you remove the corresponding rids file on the server? Antonio Querubin e-mail: t...@lavanauts.org xmpp: antonioqueru...@gmail.com -- --- 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] how do import rules into database for posegresql?
Hi,ALL i use posegresql database for ossec,but i look the tables signature is null,so how do i import all rules into signature -- --- 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] how do import rules into database for posegresql?
On Mon, Oct 13, 2014 at 5:02 AM, r...@cnmoker.org wrote: Hi,ALL i use posegresql database for ossec,but i look the tables signature is null,so how do i import all rules into signature Perhaps that functionality doesn't exist yet. Are there alerts in the database? If yes, that's pretty much the extent of the database support AFAIK. -- --- 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. -- --- 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] Windows agents not connecting to OSSEC server
Assuming agent key and IP are distinct for each server, please put the ossec-control into debug on the server and look for errors such as not allowed and so forth On Monday, October 13, 2014 8:04:41 AM UTC-4, Antonio Querubin wrote: On Sun, 12 Oct 2014, David Masters wrote: Ok...here is the log file from a freshly installed agent (shutdown ossec server, removed all rid files, no rid files on agent system, manually entererd key and server address): This is the log file from same machine after pushing out key file/ossec.conf file and deleting rid files (no change to any other part of the machine or configuration): Verified all information in both files was exactly the same as before and files in rids directory were deleted before service was restarted. Any ideas? Did you remove the corresponding rids file on the server? Antonio Querubin e-mail: to...@lavanauts.org javascript: xmpp: antonio...@gmail.com javascript: -- --- 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] Does a single machine scenario use an agent?
I'm exploring the use of OSSEC and I've got a question the docs I've read aren't yet answering. I think it's going to be quicker to just ask... I have a single Linux box which runs in the DMZ. It has a few services, with Apache and Squid being the main ones. I want to put OSSEC on it primarily in a log monitoring role. The thing that just won't click from reading the docs and presentations so far is whether a single machine scenario uses an agent or not. There appear to be these possibilities: * the manager and agent run together and the agent talks to its local manager using localhost based communications; * the manager sort of runs the agent's processes itself, and hence there is no communications between the two pieces; * something else. :) I know the answer is in there somewhere, but I've been wading though docs for 3 hours now and I've probably missed it. Can someone point me at the answer? -- --- 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] Does a single machine scenario use an agent?
Hello Derek, just install ossec in local mode, this should be best for you. Brgds Jan On Mon, Oct 13, 2014 at 3:06 PM, de...@scratters.com wrote: I'm exploring the use of OSSEC and I've got a question the docs I've read aren't yet answering. I think it's going to be quicker to just ask... I have a single Linux box which runs in the DMZ. It has a few services, with Apache and Squid being the main ones. I want to put OSSEC on it primarily in a log monitoring role. The thing that just won't click from reading the docs and presentations so far is whether a single machine scenario uses an agent or not. There appear to be these possibilities: * the manager and agent run together and the agent talks to its local manager using localhost based communications; * the manager sort of runs the agent's processes itself, and hence there is no communications between the two pieces; * something else. :) I know the answer is in there somewhere, but I've been wading though docs for 3 hours now and I've probably missed it. Can someone point me at the answer? -- --- 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. -- --- 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] Windows agents not connecting to OSSEC server
Yes, removed all rid files before restarting the server On Monday, October 13, 2014 7:04:41 AM UTC-5, Antonio Querubin wrote: On Sun, 12 Oct 2014, David Masters wrote: Ok...here is the log file from a freshly installed agent (shutdown ossec server, removed all rid files, no rid files on agent system, manually entererd key and server address): This is the log file from same machine after pushing out key file/ossec.conf file and deleting rid files (no change to any other part of the machine or configuration): Verified all information in both files was exactly the same as before and files in rids directory were deleted before service was restarted. Any ideas? Did you remove the corresponding rids file on the server? Antonio Querubin e-mail: to...@lavanauts.org javascript: xmpp: antonio...@gmail.com javascript: -- --- 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] Does a single machine scenario use an agent?
On Mon, Oct 13, 2014 at 9:06 AM, de...@scratters.com wrote: I'm exploring the use of OSSEC and I've got a question the docs I've read aren't yet answering. I think it's going to be quicker to just ask... I have a single Linux box which runs in the DMZ. It has a few services, with Apache and Squid being the main ones. I want to put OSSEC on it primarily in a log monitoring role. The thing that just won't click from reading the docs and presentations so far is whether a single machine scenario uses an agent or not. There appear to be these possibilities: * the manager and agent run together and the agent talks to its local manager using localhost based communications; * the manager sort of runs the agent's processes itself, and hence there is no communications between the two pieces; * something else. :) I know the answer is in there somewhere, but I've been wading though docs for 3 hours now and I've probably missed it. Can someone point me at the answer? I think you're looking for a local installation. I have server/agent installations on a local machine, but that's mostly for testing purposes. If you could point out where in the documentation I could explain this better, I'll submit an improved version by tonight. -- --- 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. -- --- 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] Windows agents not connecting to OSSEC server
On Mon, Oct 13, 2014 at 10:32 AM, David Masters dmast...@24-7intouch.com wrote: Yes, removed all rid files before restarting the server Have you checked the ossec.log on the manager? Is each agent key unique? Are the packets making it to the manager? So they appear to be coming from the correct ip address? Is the manager reaponding? Are the responses making it to the agent? On Monday, October 13, 2014 7:04:41 AM UTC-5, Antonio Querubin wrote: On Sun, 12 Oct 2014, David Masters wrote: Ok...here is the log file from a freshly installed agent (shutdown ossec server, removed all rid files, no rid files on agent system, manually entererd key and server address): This is the log file from same machine after pushing out key file/ossec.conf file and deleting rid files (no change to any other part of the machine or configuration): Verified all information in both files was exactly the same as before and files in rids directory were deleted before service was restarted. Any ideas? Did you remove the corresponding rids file on the server? Antonio Querubin e-mail: to...@lavanauts.org xmpp: antonio...@gmail.com -- --- 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. -- --- 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] Does a single machine scenario use an agent?
Goodness, I'm nowhere near clued up enough to suggest how to improve things just yet. I haven't read enough of it! But note that neither yours nor Jan's posts actually answer my question (although I completely appreciate your good intentions). When I look at the basic information, here: http://ossec-docs.readthedocs.org/en/latest/manual/ossec-architecture.html I learn about the manager and agents, and the concept of agentless. The description of the agent says The agent is a small program, or collection of programs, installed on the systems to be monitored. OK, well the system to be monitored in my case is the one with the manager on it, so I'm expecting to see both the manager and agent processes on my box. Is that incorrect? Following Jan's prompt I've made a local installation.I wouldn't yet know how to recognise an agent process on it, but at first glance there doesn't seem to be one. That seems to imply I've got an agentless install on my server. Is that incorrect? I think at this stage, as a newbie, I'd appreciate a brief description of the concept of local installation on that architecture page. Hard to be sure at the moment though. :) On Monday, 13 October 2014 15:34:03 UTC+1, dan (ddpbsd) wrote: On Mon, Oct 13, 2014 at 9:06 AM, de...@scratters.com javascript: wrote: I'm exploring the use of OSSEC and I've got a question the docs I've read aren't yet answering. I think it's going to be quicker to just ask... I have a single Linux box which runs in the DMZ. It has a few services, with Apache and Squid being the main ones. I want to put OSSEC on it primarily in a log monitoring role. The thing that just won't click from reading the docs and presentations so far is whether a single machine scenario uses an agent or not. There appear to be these possibilities: * the manager and agent run together and the agent talks to its local manager using localhost based communications; * the manager sort of runs the agent's processes itself, and hence there is no communications between the two pieces; * something else. :) I know the answer is in there somewhere, but I've been wading though docs for 3 hours now and I've probably missed it. Can someone point me at the answer? I think you're looking for a local installation. I have server/agent installations on a local machine, but that's mostly for testing purposes. If you could point out where in the documentation I could explain this better, I'll submit an improved version by tonight. -- --- 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/d/optout. -- --- 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] Does a single machine scenario use an agent?
On Mon, Oct 13, 2014 at 10:50 AM, de...@scratters.com wrote: Goodness, I'm nowhere near clued up enough to suggest how to improve things just yet. I haven't read enough of it! But note that neither yours nor Jan's posts actually answer my question (although I completely appreciate your good intentions). When I look at the basic information, here: http://ossec-docs.readthedocs.org/en/latest/manual/ossec-architecture.html I learn about the manager and agents, and the concept of agentless. The description of the agent says The agent is a small program, or collection of programs, installed on the systems to be monitored. OK, well the system to be monitored in my case is the one with the manager on it, so I'm expecting to see both the manager and agent processes on my box. Is that incorrect? If you choose a local installation you get some of each. Obviously you won't need remoted or agentd. In a server(manager) installation the processes that monitor log files and file integrity still run, giving the manager the same benefits that an agent receives. This is also true in a local installation. Following Jan's prompt I've made a local installation.I wouldn't yet know how to recognise an agent process on it, but at first glance there doesn't seem to be one. That seems to imply I've got an agentless install on my server. Is that incorrect? I'm going to say that is incorrect. If you installed something on the system it's not agentless. You should also notice logcollectord and syscheckd which are a couple of the big processes on an agent. I think at this stage, as a newbie, I'd appreciate a brief description of the concept of local installation on that architecture page. Hard to be sure at the moment though. :) I'll play around with it. Thanks! On Monday, 13 October 2014 15:34:03 UTC+1, dan (ddpbsd) wrote: On Mon, Oct 13, 2014 at 9:06 AM, de...@scratters.com wrote: I'm exploring the use of OSSEC and I've got a question the docs I've read aren't yet answering. I think it's going to be quicker to just ask... I have a single Linux box which runs in the DMZ. It has a few services, with Apache and Squid being the main ones. I want to put OSSEC on it primarily in a log monitoring role. The thing that just won't click from reading the docs and presentations so far is whether a single machine scenario uses an agent or not. There appear to be these possibilities: * the manager and agent run together and the agent talks to its local manager using localhost based communications; * the manager sort of runs the agent's processes itself, and hence there is no communications between the two pieces; * something else. :) I know the answer is in there somewhere, but I've been wading though docs for 3 hours now and I've probably missed it. Can someone point me at the answer? I think you're looking for a local installation. I have server/agent installations on a local machine, but that's mostly for testing purposes. If you could point out where in the documentation I could explain this better, I'll submit an improved version by tonight. -- --- 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. -- --- 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. -- --- 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] Windows agents not connecting to OSSEC server
2014/10/13 10:19:11 ossec-remoted(1403): ERROR: Incorrectly formated message from 'any'. 2014/10/13 10:19:13 ossec-remoted(1408): ERROR: Invalid ID for the source ip: '10.50.107.21'. 2014/10/13 10:19:16 ossec-remoted(1408): ERROR: Invalid ID for the source ip: '10.50.107.20'. 2014/10/13 10:19:16 ossec-remoted(1403): ERROR: Incorrectly formated message from 'any'. 2014/10/13 10:19:17 ossec-remoted(1408): ERROR: Invalid ID for the source ip: '10.50.107.21'. 2014/10/13 10:19:22 ossec-remoted(1408): ERROR: Invalid ID for the source ip: '10.50.107.20'. 2014/10/13 10:19:22 ossec-remoted(1403): ERROR: Incorrectly formated message from 'any'. 2014/10/13 10:19:22 ossec-remoted(1408): ERROR: Invalid ID for the source ip: '10.50.107.21'. 2014/10/13 10:19:28 ossec-remoted(1408): ERROR: Invalid ID for the source ip: '10.50.107.21'. 2014/10/13 10:19:54 ossec-remoted(1408): ERROR: Invalid ID for the source ip: '10.50.111.64'. On Monday, October 13, 2014 7:52:05 AM UTC-5, gr...@castraconsulting.com wrote: Assuming agent key and IP are distinct for each server, please put the ossec-control into debug on the server and look for errors such as not allowed and so forth On Monday, October 13, 2014 8:04:41 AM UTC-4, Antonio Querubin wrote: On Sun, 12 Oct 2014, David Masters wrote: Ok...here is the log file from a freshly installed agent (shutdown ossec server, removed all rid files, no rid files on agent system, manually entererd key and server address): This is the log file from same machine after pushing out key file/ossec.conf file and deleting rid files (no change to any other part of the machine or configuration): Verified all information in both files was exactly the same as before and files in rids directory were deleted before service was restarted. Any ideas? Did you remove the corresponding rids file on the server? Antonio Querubin e-mail: to...@lavanauts.org xmpp: antonio...@gmail.com -- --- 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] Windows agents not connecting to OSSEC server
No not allowed messages. Saw it run through a debug scan. Only error messages coming up are: 2014/10/13 10:15:56 ossec-remoted(1403): ERROR: Incorrectly formated message from 'any'. 2014/10/13 10:16:02 ossec-remoted(1403): ERROR: Incorrectly formated message from 'any'. 2014/10/13 10:16:06 ossec-remoted(1403): ERROR: Incorrectly formated message from 'any'. 2014/10/13 10:16:11 ossec-remoted(1403): ERROR: Incorrectly formated message from 'any'. 2014/10/13 10:16:17 ossec-remoted(1403): ERROR: Incorrectly formated message from 'any'. along with various other IP addresses. On Monday, October 13, 2014 7:52:05 AM UTC-5, gr...@castraconsulting.com wrote: Assuming agent key and IP are distinct for each server, please put the ossec-control into debug on the server and look for errors such as not allowed and so forth On Monday, October 13, 2014 8:04:41 AM UTC-4, Antonio Querubin wrote: On Sun, 12 Oct 2014, David Masters wrote: Ok...here is the log file from a freshly installed agent (shutdown ossec server, removed all rid files, no rid files on agent system, manually entererd key and server address): This is the log file from same machine after pushing out key file/ossec.conf file and deleting rid files (no change to any other part of the machine or configuration): Verified all information in both files was exactly the same as before and files in rids directory were deleted before service was restarted. Any ideas? Did you remove the corresponding rids file on the server? Antonio Querubin e-mail: to...@lavanauts.org xmpp: antonio...@gmail.com -- --- 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] Windows agents not connecting to OSSEC server
Yes, each agent key is unique, appears to be coming from the correct ip address. Error message from log: 2014/10/13 10:15:56 ossec-remoted(1403): ERROR: Incorrectly formated message from 'any'. 2014/10/13 10:16:02 ossec-remoted(1403): ERROR: Incorrectly formated message from 'any'. 2014/10/13 10:16:06 ossec-remoted(1403): ERROR: Incorrectly formated message from 'any'. 2014/10/13 10:16:11 ossec-remoted(1403): ERROR: Incorrectly formated message from 'any'. 2014/10/13 10:16:17 ossec-remoted(1403): ERROR: Incorrectly formated message from 'any'. On Sunday, October 12, 2014 5:36:07 AM UTC-5, dan (ddpbsd) wrote: On Oct 12, 2014 6:28 AM, David Masters dmas...@24-7intouch.com javascript: wrote: I have searched through the listings and the internet and cannot seem to find a solution to this issue. We have approximately 3200 computers (Windows 7) that we are trying to get configured with OSSEC. The agent is part of the image that we are rolling out to the machines. All the machines have been added to the server (Ubuntu 12.04.4 LTS, OSSEC server v. 2.8) via manage_agents. I have written a script that runs via group policy that stops the ossec service, removes the client.keys and ossec.conf files from the machine, then copies over a new ossec.conf and client.keys file with the correct information (server IP and client key) and restarts the ossec service. If the windows client (v 2.8) is installed clean, it connects to the server and communicates properly. If it is done via the group policy (utilizing the exact same information), the following occurs (pulled from a log file on a clean machine): Have you checked the ossec.log on the manager? Is each agent key unique? Are the packets making it to the manager? So they appear to be coming from the correct ip address? Is the manager reaponding? Are the responses making it to the agent? 2014/10/12 04:16:13 ossec-agent: Using notify time: 600 and max time to reconnect: 1800 2014/10/12 04:16:13 ossec-execd(1350): INFO: Active response disabled. Exiting. 2014/10/12 04:16:13 ossec-agent(1410): INFO: Reading authentication keys file. 2014/10/12 04:16:13 ossec-agent: INFO: No previous counter available for 'FRI-COMPUTER1'. 2014/10/12 04:16:13 ossec-agent: INFO: Assigning counter for agent FRI-COMPUTER1: '0:0'. 2014/10/12 04:16:13 ossec-agent: INFO: Assigning sender counter: 0:179 2014/10/12 04:16:13 ossec-agent: INFO: Trying to connect to server ( 10.50.3.4:1514). 2014/10/12 04:16:13 ossec-agent: INFO: Using IPv4 for: 10.50.3.4 . 2014/10/12 04:16:13 ossec-agent: Starting syscheckd thread. 2014/10/12 04:16:13 ossec-rootcheck: INFO: Started (pid: 6800). 2014/10/12 04:16:13 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Software\Classes\batfile'. 2014/10/12 04:16:13 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Software\Classes\cmdfile'. 2014/10/12 04:16:13 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Software\Classes\comfile'. 2014/10/12 04:16:13 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Software\Classes\exefile'. 2014/10/12 04:16:13 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Software\Classes\piffile'. 2014/10/12 04:16:13 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Software\Classes\AllFilesystemObjects'. 2014/10/12 04:16:13 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Software\Classes\Directory'. 2014/10/12 04:16:13 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Software\Classes\Folder'. 2014/10/12 04:16:13 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Software\Classes\Protocols'. 2014/10/12 04:16:13 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Software\Policies'. 2014/10/12 04:16:13 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Security'. 2014/10/12 04:16:13 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer'. 2014/10/12 04:16:13 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services'. 2014/10/12 04:16:13 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\KnownDLLs'. 2014/10/12 04:16:13 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurePipeServers\winreg'. 2014/10/12 04:16:13 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run'. 2014/10/12 04:16:13 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce'. 2014/10/12 04:16:13 ossec-agent: INFO: Monitoring registry entry:
Re: [ossec-list] Windows agents not connecting to OSSEC server
On Mon, Oct 13, 2014 at 11:21 AM, David Masters dmast...@24-7intouch.com wrote: 2014/10/13 10:19:11 ossec-remoted(1403): ERROR: Incorrectly formated message from 'any'. 2014/10/13 10:19:13 ossec-remoted(1408): ERROR: Invalid ID for the source ip: '10.50.107.21'. Try readding the key to one of these agents manually (not one of the any agents, but the ones with the IP address specifically). 2014/10/13 10:19:16 ossec-remoted(1408): ERROR: Invalid ID for the source ip: '10.50.107.20'. 2014/10/13 10:19:16 ossec-remoted(1403): ERROR: Incorrectly formated message from 'any'. 2014/10/13 10:19:17 ossec-remoted(1408): ERROR: Invalid ID for the source ip: '10.50.107.21'. 2014/10/13 10:19:22 ossec-remoted(1408): ERROR: Invalid ID for the source ip: '10.50.107.20'. 2014/10/13 10:19:22 ossec-remoted(1403): ERROR: Incorrectly formated message from 'any'. 2014/10/13 10:19:22 ossec-remoted(1408): ERROR: Invalid ID for the source ip: '10.50.107.21'. 2014/10/13 10:19:28 ossec-remoted(1408): ERROR: Invalid ID for the source ip: '10.50.107.21'. 2014/10/13 10:19:54 ossec-remoted(1408): ERROR: Invalid ID for the source ip: '10.50.111.64'. On Monday, October 13, 2014 7:52:05 AM UTC-5, gr...@castraconsulting.com wrote: Assuming agent key and IP are distinct for each server, please put the ossec-control into debug on the server and look for errors such as not allowed and so forth On Monday, October 13, 2014 8:04:41 AM UTC-4, Antonio Querubin wrote: On Sun, 12 Oct 2014, David Masters wrote: Ok...here is the log file from a freshly installed agent (shutdown ossec server, removed all rid files, no rid files on agent system, manually entererd key and server address): This is the log file from same machine after pushing out key file/ossec.conf file and deleting rid files (no change to any other part of the machine or configuration): Verified all information in both files was exactly the same as before and files in rids directory were deleted before service was restarted. Any ideas? Did you remove the corresponding rids file on the server? Antonio Querubin e-mail: to...@lavanauts.org xmpp: antonio...@gmail.com -- --- 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. -- --- 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] how do import rules into database for posegresql?
yes,alert is Normal insertinto the database。but if i want wirte WUI for ossec,can not acquire rule description。。 在 2014年10月13日星期一UTC+8下午8时11分47秒，dan (ddpbsd)写道： On Mon, Oct 13, 2014 at 5:02 AM, ro...@cnmoker.org javascript: wrote: Hi,ALL i use posegresql database for ossec,but i look the tables signature is null,so how do i import all rules into signature Perhaps that functionality doesn't exist yet. Are there alerts in the database? If yes, that's pretty much the extent of the database support AFAIK. -- --- 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/d/optout. -- --- 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] how do import rules into database for posegresql?
On Mon, Oct 13, 2014 at 11:35 AM, r...@cnmoker.org wrote: yes,alert is Normal insertinto the database。but if i want wirte WUI for ossec,can not acquire rule description。。 Then work on ossec-dbd first. :) 在 2014年10月13日星期一UTC+8下午8时11分47秒，dan (ddpbsd)写道： On Mon, Oct 13, 2014 at 5:02 AM, ro...@cnmoker.org wrote: Hi,ALL i use posegresql database for ossec,but i look the tables signature is null,so how do i import all rules into signature Perhaps that functionality doesn't exist yet. Are there alerts in the database? If yes, that's pretty much the extent of the database support AFAIK. -- --- 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. -- --- 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. -- --- 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] Windows agents not connecting to OSSEC server
The whole purpose of this exercise is to not have to go to each individual machine to input the key and configuration. We have over 3000 machines so that really is just not feasible. If the key server is input manually when the software is installed it works fine. When the key file and config file are pushed out over the network (containing the exact same information that would have been input manually), it does not. This would be to the same machine, same configuration, no changes between manual input and pushed input. (except that it is not done manually). If this is not possible, I would like to know this as soon as possible so that we can find a different solution for our IPS/IDS/FIM system. Thank you. On Monday, October 13, 2014 10:33:59 AM UTC-5, dan (ddpbsd) wrote: On Mon, Oct 13, 2014 at 11:21 AM, David Masters dmas...@24-7intouch.com javascript: wrote: 2014/10/13 10:19:11 ossec-remoted(1403): ERROR: Incorrectly formated message from 'any'. 2014/10/13 10:19:13 ossec-remoted(1408): ERROR: Invalid ID for the source ip: '10.50.107.21'. Try readding the key to one of these agents manually (not one of the any agents, but the ones with the IP address specifically). 2014/10/13 10:19:16 ossec-remoted(1408): ERROR: Invalid ID for the source ip: '10.50.107.20'. 2014/10/13 10:19:16 ossec-remoted(1403): ERROR: Incorrectly formated message from 'any'. 2014/10/13 10:19:17 ossec-remoted(1408): ERROR: Invalid ID for the source ip: '10.50.107.21'. 2014/10/13 10:19:22 ossec-remoted(1408): ERROR: Invalid ID for the source ip: '10.50.107.20'. 2014/10/13 10:19:22 ossec-remoted(1403): ERROR: Incorrectly formated message from 'any'. 2014/10/13 10:19:22 ossec-remoted(1408): ERROR: Invalid ID for the source ip: '10.50.107.21'. 2014/10/13 10:19:28 ossec-remoted(1408): ERROR: Invalid ID for the source ip: '10.50.107.21'. 2014/10/13 10:19:54 ossec-remoted(1408): ERROR: Invalid ID for the source ip: '10.50.111.64'. On Monday, October 13, 2014 7:52:05 AM UTC-5, gr...@castraconsulting.com wrote: Assuming agent key and IP are distinct for each server, please put the ossec-control into debug on the server and look for errors such as not allowed and so forth On Monday, October 13, 2014 8:04:41 AM UTC-4, Antonio Querubin wrote: On Sun, 12 Oct 2014, David Masters wrote: Ok...here is the log file from a freshly installed agent (shutdown ossec server, removed all rid files, no rid files on agent system, manually entererd key and server address): This is the log file from same machine after pushing out key file/ossec.conf file and deleting rid files (no change to any other part of the machine or configuration): Verified all information in both files was exactly the same as before and files in rids directory were deleted before service was restarted. Any ideas? Did you remove the corresponding rids file on the server? Antonio Querubin e-mail: to...@lavanauts.org xmpp: antonio...@gmail.com -- --- 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/d/optout. -- --- 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] check that a service is running
Hi, I've googled this a lot and looked through a lot of the group's posts but I can find if there's a way to check that a given service is running. It would be a service that has an init script. Is there a way to do this? Many thanks :) Felicity -- --- 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] check that a service is running
On Mon, Oct 13, 2014 at 12:27 PM, felicity.ratcli...@missguided.co.uk wrote: Hi, I've googled this a lot and looked through a lot of the group's posts but I can find if there's a way to check that a given service is running. It would be a service that has an init script. Is there a way to do this? `/var/ossec/bin/ossec-control status` should check all of the processes. Many thanks :) Felicity -- --- 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. -- --- 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] Windows agents not connecting to OSSEC server
Many people have created an automated deployment script successfully, so no need to worry there. How are you exporting the agent keys from the manager? More to the point, WHICH key are you using in your group policy script? If you really are using the same key that you would use in the GUI, as you state, then that’s the problem. Here’s an exercise to illustrate the point: manually install an agent, such that it is communicating with the manager successfully. Open client.keys on the agent and look at the key. Now compare that key to the one in /var/ossec/etc/client.keys on the manager. They should be the same. When manually shuffling keys about using scripts, there is no need to extract the key using manage_agents. From: ossec-list@googlegroups.com [mailto:ossec-list@googlegroups.com] On Behalf Of David Masters Sent: Monday, October 13, 2014 9:19 AM To: ossec-list@googlegroups.com Subject: Re: [ossec-list] Windows agents not connecting to OSSEC server The whole purpose of this exercise is to not have to go to each individual machine to input the key and configuration. We have over 3000 machines so that really is just not feasible. If the key server is input manually when the software is installed it works fine. When the key file and config file are pushed out over the network (containing the exact same information that would have been input manually), it does not. This would be to the same machine, same configuration, no changes between manual input and pushed input. (except that it is not done manually). If this is not possible, I would like to know this as soon as possible so that we can find a different solution for our IPS/IDS/FIM system. Thank you. On Monday, October 13, 2014 10:33:59 AM UTC-5, dan (ddpbsd) wrote: On Mon, Oct 13, 2014 at 11:21 AM, David Masters dmas...@24-7intouch.com javascript: wrote: 2014/10/13 10:19:11 ossec-remoted(1403): ERROR: Incorrectly formated message from 'any'. 2014/10/13 10:19:13 ossec-remoted(1408): ERROR: Invalid ID for the source ip: '10.50.107.21'. Try readding the key to one of these agents manually (not one of the any agents, but the ones with the IP address specifically). 2014/10/13 10:19:16 ossec-remoted(1408): ERROR: Invalid ID for the source ip: '10.50.107.20'. 2014/10/13 10:19:16 ossec-remoted(1403): ERROR: Incorrectly formated message from 'any'. 2014/10/13 10:19:17 ossec-remoted(1408): ERROR: Invalid ID for the source ip: '10.50.107.21'. 2014/10/13 10:19:22 ossec-remoted(1408): ERROR: Invalid ID for the source ip: '10.50.107.20'. 2014/10/13 10:19:22 ossec-remoted(1403): ERROR: Incorrectly formated message from 'any'. 2014/10/13 10:19:22 ossec-remoted(1408): ERROR: Invalid ID for the source ip: '10.50.107.21'. 2014/10/13 10:19:28 ossec-remoted(1408): ERROR: Invalid ID for the source ip: '10.50.107.21'. 2014/10/13 10:19:54 ossec-remoted(1408): ERROR: Invalid ID for the source ip: '10.50.111.64'. On Monday, October 13, 2014 7:52:05 AM UTC-5, gr...@castraconsulting.com wrote: Assuming agent key and IP are distinct for each server, please put the ossec-control into debug on the server and look for errors such as not allowed and so forth On Monday, October 13, 2014 8:04:41 AM UTC-4, Antonio Querubin wrote: On Sun, 12 Oct 2014, David Masters wrote: Ok...here is the log file from a freshly installed agent (shutdown ossec server, removed all rid files, no rid files on agent system, manually entererd key and server address): This is the log file from same machine after pushing out key file/ossec.conf file and deleting rid files (no change to any other part of the machine or configuration): Verified all information in both files was exactly the same as before and files in rids directory were deleted before service was restarted. Any ideas? Did you remove the corresponding rids file on the server? Antonio Querubin e-mail: to...@lavanauts.org xmpp: antonio...@gmail.com -- --- 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/d/optout. -- --- 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. -- --- 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] Windows agents not connecting to OSSEC server
I am acquiring the keys originally from the server (cat client.keys) then copying that information directly from the putty.log file into a spreadsheet. The key files I am creating are being created directly from the spreadsheet. I manually verify the information in the keys file before it is copied down to the computer. Same with the ossec.conf file...it was copied originally from a machine that was communicating properly with the server. If you guys know of any scripts or automation help you can offer, I would be most appreciative. I've been banging my head against a wall on this one. On Monday, October 13, 2014 12:30:10 PM UTC-5, LostInThe Tubez wrote: Many people have created an automated deployment script successfully, so no need to worry there. How are you exporting the agent keys from the manager? More to the point, WHICH key are you using in your group policy script? If you really are using the same key that you would use in the GUI, as you state, then that’s the problem. Here’s an exercise to illustrate the point: manually install an agent, such that it is communicating with the manager successfully. Open client.keys on the agent and look at the key. Now compare that key to the one in /var/ossec/etc/client.keys on the manager. They should be the same. When manually shuffling keys about using scripts, there is no need to extract the key using manage_agents. *From:* ossec...@googlegroups.com javascript: [mailto: ossec...@googlegroups.com javascript:] *On Behalf Of *David Masters *Sent:* Monday, October 13, 2014 9:19 AM *To:* ossec...@googlegroups.com javascript: *Subject:* Re: [ossec-list] Windows agents not connecting to OSSEC server The whole purpose of this exercise is to not have to go to each individual machine to input the key and configuration. We have over 3000 machines so that really is just not feasible. If the key server is input manually when the software is installed it works fine. When the key file and config file are pushed out over the network (containing the exact same information that would have been input manually), it does not. This would be to the same machine, same configuration, no changes between manual input and pushed input. (except that it is not done manually). If this is not possible, I would like to know this as soon as possible so that we can find a different solution for our IPS/IDS/FIM system. Thank you. On Monday, October 13, 2014 10:33:59 AM UTC-5, dan (ddpbsd) wrote: On Mon, Oct 13, 2014 at 11:21 AM, David Masters dmas...@24-7intouch.com wrote: 2014/10/13 10:19:11 ossec-remoted(1403): ERROR: Incorrectly formated message from 'any'. 2014/10/13 10:19:13 ossec-remoted(1408): ERROR: Invalid ID for the source ip: '10.50.107.21'. Try readding the key to one of these agents manually (not one of the any agents, but the ones with the IP address specifically). 2014/10/13 10:19:16 ossec-remoted(1408): ERROR: Invalid ID for the source ip: '10.50.107.20'. 2014/10/13 10:19:16 ossec-remoted(1403): ERROR: Incorrectly formated message from 'any'. 2014/10/13 10:19:17 ossec-remoted(1408): ERROR: Invalid ID for the source ip: '10.50.107.21'. 2014/10/13 10:19:22 ossec-remoted(1408): ERROR: Invalid ID for the source ip: '10.50.107.20'. 2014/10/13 10:19:22 ossec-remoted(1403): ERROR: Incorrectly formated message from 'any'. 2014/10/13 10:19:22 ossec-remoted(1408): ERROR: Invalid ID for the source ip: '10.50.107.21'. 2014/10/13 10:19:28 ossec-remoted(1408): ERROR: Invalid ID for the source ip: '10.50.107.21'. 2014/10/13 10:19:54 ossec-remoted(1408): ERROR: Invalid ID for the source ip: '10.50.111.64'. On Monday, October 13, 2014 7:52:05 AM UTC-5, gr...@castraconsulting.com wrote: Assuming agent key and IP are distinct for each server, please put the ossec-control into debug on the server and look for errors such as not allowed and so forth On Monday, October 13, 2014 8:04:41 AM UTC-4, Antonio Querubin wrote: On Sun, 12 Oct 2014, David Masters wrote: Ok...here is the log file from a freshly installed agent (shutdown ossec server, removed all rid files, no rid files on agent system, manually entererd key and server address): This is the log file from same machine after pushing out key file/ossec.conf file and deleting rid files (no change to any other part of the machine or configuration): Verified all information in both files was exactly the same as before and files in rids directory were deleted before service was restarted. Any ideas? Did you remove the corresponding rids file on the server? Antonio Querubin e-mail: to...@lavanauts.org xmpp: antonio...@gmail.com -- --- You received this message because you are subscribed to the Google Groups ossec-list group. To
Re: [ossec-list] Windows agents not connecting to OSSEC server
David You wrote -- The key files I am creating are being created directly from the spreadsheet You are not creating the keys yourself are you? when you run manage-agents and add a new agent, a key gets put into client.keys, that key is associated with the hostname of the sending device and can only be used one. You don't have to have an IP of the remote agent, you can use any instead of 1.1.1.1 in case IP overlap is occuring. I have to ask, port 1514 is accessible from the Windows servers in question, right? They can actually send UDP 1514 packets to the Ossec-server? The scripts we wrote literally just loop through a csv file of ip,hostname and create the placeholder in manage-agent, then map a share connection to the target, move the agent over and attempt to run the agent with the creds provided and I don't do batches larger than 100 at a time just to make sure the ossec-server is keeping up. Has any of this helped you sir? On Monday, October 13, 2014 3:47:12 PM UTC-4, David Masters wrote: I am acquiring the keys originally from the server (cat client.keys) then copying that information directly from the putty.log file into a spreadsheet. The key files I am creating are being created directly from the spreadsheet. I manually verify the information in the keys file before it is copied down to the computer. Same with the ossec.conf file...it was copied originally from a machine that was communicating properly with the server. If you guys know of any scripts or automation help you can offer, I would be most appreciative. I've been banging my head against a wall on this one. On Monday, October 13, 2014 12:30:10 PM UTC-5, LostInThe Tubez wrote: Many people have created an automated deployment script successfully, so no need to worry there. How are you exporting the agent keys from the manager? More to the point, WHICH key are you using in your group policy script? If you really are using the same key that you would use in the GUI, as you state, then that’s the problem. Here’s an exercise to illustrate the point: manually install an agent, such that it is communicating with the manager successfully. Open client.keys on the agent and look at the key. Now compare that key to the one in /var/ossec/etc/client.keys on the manager. They should be the same. When manually shuffling keys about using scripts, there is no need to extract the key using manage_agents. *From:* ossec...@googlegroups.com [mailto:ossec...@googlegroups.com] *On Behalf Of *David Masters *Sent:* Monday, October 13, 2014 9:19 AM *To:* ossec...@googlegroups.com *Subject:* Re: [ossec-list] Windows agents not connecting to OSSEC server The whole purpose of this exercise is to not have to go to each individual machine to input the key and configuration. We have over 3000 machines so that really is just not feasible. If the key server is input manually when the software is installed it works fine. When the key file and config file are pushed out over the network (containing the exact same information that would have been input manually), it does not. This would be to the same machine, same configuration, no changes between manual input and pushed input. (except that it is not done manually). If this is not possible, I would like to know this as soon as possible so that we can find a different solution for our IPS/IDS/FIM system. Thank you. On Monday, October 13, 2014 10:33:59 AM UTC-5, dan (ddpbsd) wrote: On Mon, Oct 13, 2014 at 11:21 AM, David Masters dmas...@24-7intouch.com wrote: 2014/10/13 10:19:11 ossec-remoted(1403): ERROR: Incorrectly formated message from 'any'. 2014/10/13 10:19:13 ossec-remoted(1408): ERROR: Invalid ID for the source ip: '10.50.107.21'. Try readding the key to one of these agents manually (not one of the any agents, but the ones with the IP address specifically). 2014/10/13 10:19:16 ossec-remoted(1408): ERROR: Invalid ID for the source ip: '10.50.107.20'. 2014/10/13 10:19:16 ossec-remoted(1403): ERROR: Incorrectly formated message from 'any'. 2014/10/13 10:19:17 ossec-remoted(1408): ERROR: Invalid ID for the source ip: '10.50.107.21'. 2014/10/13 10:19:22 ossec-remoted(1408): ERROR: Invalid ID for the source ip: '10.50.107.20'. 2014/10/13 10:19:22 ossec-remoted(1403): ERROR: Incorrectly formated message from 'any'. 2014/10/13 10:19:22 ossec-remoted(1408): ERROR: Invalid ID for the source ip: '10.50.107.21'. 2014/10/13 10:19:28 ossec-remoted(1408): ERROR: Invalid ID for the source ip: '10.50.107.21'. 2014/10/13 10:19:54 ossec-remoted(1408): ERROR: Invalid ID for the source ip: '10.50.111.64'. On Monday, October 13, 2014 7:52:05 AM UTC-5, gr...@castraconsulting.com wrote: Assuming agent key and IP are distinct for each server, please put the ossec-control into debug on the server and look for
Re: [ossec-list] Windows agents not connecting to OSSEC server
This is what we did last year Entered in the machines manually to the server to create the account/key on the ossec server once all of the machines were entered, we ran cat client.keys on the ossec server, which reads/prints out all the keys to the screen the session was being recorded to the putty.log (using putty to connect to the ossec server) the key list was copied from the putty.log (txt file) to a spreadsheet this spreadsheet was used to manually enter each key into each individual system when the agent was installed. This year we have roughly 2/3 again as many systems as we did last year, so are trying to automate as much of this as possible. We wrote a script that reads the computer names from a CSV to create the machine accounts on the OSSEC server (utilizing manage_agents (which we wrote before it was found out that they had added that functionality to the 2.8.1 version). This creates the individual machine accounts. Then we read the keys from the server (cat client.keys) just like we did last year, copying the keys from the putty.log file into a spreadsheet. I then copy out those keys into individual text files named with the individual computer name (ie: each line is a computer account/key which then gets copied into its own text file named after itself and with the proper .keys file format)(computer1.keys, computer2.keys, computer3.keys, etc). I have a group policy that uninstalls any previous version of ossec agent, then installs the current version (2.8), copies over the ossec.conf file with the proper server info and copies over the computer name file into a client.keys file on the machine (reads the machine name from the BIOS, then finds the proper computername.keys file and copies it over to that machine into the ossec folder as client.keys, then starts the ossec agent. The machine boots and the agent contains all the proper information except that it won't communicate with the server. The file structure is identical with a freshly installed local agent with the manually entered information, except for the communication errors. Which part of that process is screwing me up? On Monday, October 13, 2014 5:31:09 PM UTC-5, gr...@castraconsulting.com wrote: David You wrote -- The key files I am creating are being created directly from the spreadsheet You are not creating the keys yourself are you? when you run manage-agents and add a new agent, a key gets put into client.keys, that key is associated with the hostname of the sending device and can only be used one. You don't have to have an IP of the remote agent, you can use any instead of 1.1.1.1 in case IP overlap is occuring. I have to ask, port 1514 is accessible from the Windows servers in question, right? They can actually send UDP 1514 packets to the Ossec-server? The scripts we wrote literally just loop through a csv file of ip,hostname and create the placeholder in manage-agent, then map a share connection to the target, move the agent over and attempt to run the agent with the creds provided and I don't do batches larger than 100 at a time just to make sure the ossec-server is keeping up. Has any of this helped you sir? On Monday, October 13, 2014 3:47:12 PM UTC-4, David Masters wrote: I am acquiring the keys originally from the server (cat client.keys) then copying that information directly from the putty.log file into a spreadsheet. The key files I am creating are being created directly from the spreadsheet. I manually verify the information in the keys file before it is copied down to the computer. Same with the ossec.conf file...it was copied originally from a machine that was communicating properly with the server. If you guys know of any scripts or automation help you can offer, I would be most appreciative. I've been banging my head against a wall on this one. On Monday, October 13, 2014 12:30:10 PM UTC-5, LostInThe Tubez wrote: Many people have created an automated deployment script successfully, so no need to worry there. How are you exporting the agent keys from the manager? More to the point, WHICH key are you using in your group policy script? If you really are using the same key that you would use in the GUI, as you state, then that’s the problem. Here’s an exercise to illustrate the point: manually install an agent, such that it is communicating with the manager successfully. Open client.keys on the agent and look at the key. Now compare that key to the one in /var/ossec/etc/client.keys on the manager. They should be the same. When manually shuffling keys about using scripts, there is no need to extract the key using manage_agents. *From:* ossec...@googlegroups.com [mailto:ossec...@googlegroups.com] *On Behalf Of *David Masters *Sent:* Monday, October 13, 2014 9:19 AM *To:* ossec...@googlegroups.com *Subject:* Re: [ossec-list] Windows agents not connecting to OSSEC server
Re: [ossec-list] Windows agents not connecting to OSSEC server
All agents are using the any IP address now because our systems move subnets quite a bit depending on client load. Port 1514 is open because I can manually install the client on a machine and manually enter the information and the client will connect with the server. The same machine (with no changes to any other setup other than automating the client install) will not connect with the server, even after verifying that the information contained in the client.keys and ossec.conf files is correct. On Monday, October 13, 2014 5:31:09 PM UTC-5, gr...@castraconsulting.com wrote: David You wrote -- The key files I am creating are being created directly from the spreadsheet You are not creating the keys yourself are you? when you run manage-agents and add a new agent, a key gets put into client.keys, that key is associated with the hostname of the sending device and can only be used one. You don't have to have an IP of the remote agent, you can use any instead of 1.1.1.1 in case IP overlap is occuring. I have to ask, port 1514 is accessible from the Windows servers in question, right? They can actually send UDP 1514 packets to the Ossec-server? The scripts we wrote literally just loop through a csv file of ip,hostname and create the placeholder in manage-agent, then map a share connection to the target, move the agent over and attempt to run the agent with the creds provided and I don't do batches larger than 100 at a time just to make sure the ossec-server is keeping up. Has any of this helped you sir? On Monday, October 13, 2014 3:47:12 PM UTC-4, David Masters wrote: I am acquiring the keys originally from the server (cat client.keys) then copying that information directly from the putty.log file into a spreadsheet. The key files I am creating are being created directly from the spreadsheet. I manually verify the information in the keys file before it is copied down to the computer. Same with the ossec.conf file...it was copied originally from a machine that was communicating properly with the server. If you guys know of any scripts or automation help you can offer, I would be most appreciative. I've been banging my head against a wall on this one. On Monday, October 13, 2014 12:30:10 PM UTC-5, LostInThe Tubez wrote: Many people have created an automated deployment script successfully, so no need to worry there. How are you exporting the agent keys from the manager? More to the point, WHICH key are you using in your group policy script? If you really are using the same key that you would use in the GUI, as you state, then that’s the problem. Here’s an exercise to illustrate the point: manually install an agent, such that it is communicating with the manager successfully. Open client.keys on the agent and look at the key. Now compare that key to the one in /var/ossec/etc/client.keys on the manager. They should be the same. When manually shuffling keys about using scripts, there is no need to extract the key using manage_agents. *From:* ossec...@googlegroups.com [mailto:ossec...@googlegroups.com] *On Behalf Of *David Masters *Sent:* Monday, October 13, 2014 9:19 AM *To:* ossec...@googlegroups.com *Subject:* Re: [ossec-list] Windows agents not connecting to OSSEC server The whole purpose of this exercise is to not have to go to each individual machine to input the key and configuration. We have over 3000 machines so that really is just not feasible. If the key server is input manually when the software is installed it works fine. When the key file and config file are pushed out over the network (containing the exact same information that would have been input manually), it does not. This would be to the same machine, same configuration, no changes between manual input and pushed input. (except that it is not done manually). If this is not possible, I would like to know this as soon as possible so that we can find a different solution for our IPS/IDS/FIM system. Thank you. On Monday, October 13, 2014 10:33:59 AM UTC-5, dan (ddpbsd) wrote: On Mon, Oct 13, 2014 at 11:21 AM, David Masters dmas...@24-7intouch.com wrote: 2014/10/13 10:19:11 ossec-remoted(1403): ERROR: Incorrectly formated message from 'any'. 2014/10/13 10:19:13 ossec-remoted(1408): ERROR: Invalid ID for the source ip: '10.50.107.21'. Try readding the key to one of these agents manually (not one of the any agents, but the ones with the IP address specifically). 2014/10/13 10:19:16 ossec-remoted(1408): ERROR: Invalid ID for the source ip: '10.50.107.20'. 2014/10/13 10:19:16 ossec-remoted(1403): ERROR: Incorrectly formated message from 'any'. 2014/10/13 10:19:17 ossec-remoted(1408): ERROR: Invalid ID for the source ip: '10.50.107.21'. 2014/10/13 10:19:22 ossec-remoted(1408): ERROR: Invalid ID for the source ip: '10.50.107.20'. 2014/10/13
Re: [ossec-list] Windows agents not connecting to OSSEC server
Do this for about 5 non communicating servers at random. On the OSSEC-SERVER run 'tcpdump -i eth0 host ip of server in question port 1514' see if the connection even makes it to the server Also, note that OSSEC has to be installed as local admin or domain admin, else UAC kind of kills the application. Grant Leonard Castra Consulting, LLC http://castraconsulting.com/#/ 919-949-4002 On Mon, Oct 13, 2014 at 6:55 PM, David Masters dmast...@24-7intouch.com wrote: This is what we did last year Entered in the machines manually to the server to create the account/key on the ossec server once all of the machines were entered, we ran cat client.keys on the ossec server, which reads/prints out all the keys to the screen the session was being recorded to the putty.log (using putty to connect to the ossec server) the key list was copied from the putty.log (txt file) to a spreadsheet this spreadsheet was used to manually enter each key into each individual system when the agent was installed. This year we have roughly 2/3 again as many systems as we did last year, so are trying to automate as much of this as possible. We wrote a script that reads the computer names from a CSV to create the machine accounts on the OSSEC server (utilizing manage_agents (which we wrote before it was found out that they had added that functionality to the 2.8.1 version). This creates the individual machine accounts. Then we read the keys from the server (cat client.keys) just like we did last year, copying the keys from the putty.log file into a spreadsheet. I then copy out those keys into individual text files named with the individual computer name (ie: each line is a computer account/key which then gets copied into its own text file named after itself and with the proper .keys file format)(computer1.keys, computer2.keys, computer3.keys, etc). I have a group policy that uninstalls any previous version of ossec agent, then installs the current version (2.8), copies over the ossec.conf file with the proper server info and copies over the computer name file into a client.keys file on the machine (reads the machine name from the BIOS, then finds the proper computername.keys file and copies it over to that machine into the ossec folder as client.keys, then starts the ossec agent. The machine boots and the agent contains all the proper information except that it won't communicate with the server. The file structure is identical with a freshly installed local agent with the manually entered information, except for the communication errors. Which part of that process is screwing me up? On Monday, October 13, 2014 5:31:09 PM UTC-5, gr...@castraconsulting.com wrote: David You wrote -- The key files I am creating are being created directly from the spreadsheet You are not creating the keys yourself are you? when you run manage-agents and add a new agent, a key gets put into client.keys, that key is associated with the hostname of the sending device and can only be used one. You don't have to have an IP of the remote agent, you can use any instead of 1.1.1.1 in case IP overlap is occuring. I have to ask, port 1514 is accessible from the Windows servers in question, right? They can actually send UDP 1514 packets to the Ossec-server? The scripts we wrote literally just loop through a csv file of ip,hostname and create the placeholder in manage-agent, then map a share connection to the target, move the agent over and attempt to run the agent with the creds provided and I don't do batches larger than 100 at a time just to make sure the ossec-server is keeping up. Has any of this helped you sir? On Monday, October 13, 2014 3:47:12 PM UTC-4, David Masters wrote: I am acquiring the keys originally from the server (cat client.keys) then copying that information directly from the putty.log file into a spreadsheet. The key files I am creating are being created directly from the spreadsheet. I manually verify the information in the keys file before it is copied down to the computer. Same with the ossec.conf file...it was copied originally from a machine that was communicating properly with the server. If you guys know of any scripts or automation help you can offer, I would be most appreciative. I've been banging my head against a wall on this one. On Monday, October 13, 2014 12:30:10 PM UTC-5, LostInThe Tubez wrote: Many people have created an automated deployment script successfully, so no need to worry there. How are you exporting the agent keys from the manager? More to the point, WHICH key are you using in your group policy script? If you really are using the same key that you would use in the GUI, as you state, then that’s the problem. Here’s an exercise to illustrate the point: manually install an agent, such that it is communicating with the manager successfully. Open client.keys on the agent and look at the key. Now compare that key to
[ossec-list] Re: Windows agents not connecting to OSSEC server
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 communicate. I suggest you to verify with a text editor that display all special characters or a diff program. I also suggest to break the troubleshooting into pieces - automating the first phase (for example agents installation) and continuing manually. Then progressing until 100% of the process is automated. On Sunday, October 12, 2014 2:34:03 AM UTC-7, David Masters wrote: I have searched through the listings and the internet and cannot seem to find a solution to this issue. We have approximately 3200 computers (Windows 7) that we are trying to get configured with OSSEC. The agent is part of the image that we are rolling out to the machines. All the machines have been added to the server (Ubuntu 12.04.4 LTS, OSSEC server v. 2.8) via manage_agents. I have written a script that runs via group policy that stops the ossec service, removes the client.keys and ossec.conf files from the machine, then copies over a new ossec.conf and client.keys file with the correct information (server IP and client key) and restarts the ossec service. If the windows client (v 2.8) is installed clean, it connects to the server and communicates properly. If it is done via the group policy (utilizing the exact same information), the following occurs (pulled from a log file on a clean machine): 2014/10/12 04:16:13 ossec-agent: Using notify time: 600 and max time to reconnect: 1800 2014/10/12 04:16:13 ossec-execd(1350): INFO: Active response disabled. Exiting. 2014/10/12 04:16:13 ossec-agent(1410): INFO: Reading authentication keys file. 2014/10/12 04:16:13 ossec-agent: INFO: No previous counter available for 'FRI-COMPUTER1'. 2014/10/12 04:16:13 ossec-agent: INFO: Assigning counter for agent FRI-COMPUTER1: '0:0'. 2014/10/12 04:16:13 ossec-agent: INFO: Assigning sender counter: 0:179 2014/10/12 04:16:13 ossec-agent: INFO: Trying to connect to server ( 10.50.3.4:1514). 2014/10/12 04:16:13 ossec-agent: INFO: Using IPv4 for: 10.50.3.4 . 2014/10/12 04:16:13 ossec-agent: Starting syscheckd thread. 2014/10/12 04:16:13 ossec-rootcheck: INFO: Started (pid: 6800). 2014/10/12 04:16:13 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Software\Classes\batfile'. 2014/10/12 04:16:13 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Software\Classes\cmdfile'. 2014/10/12 04:16:13 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Software\Classes\comfile'. 2014/10/12 04:16:13 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Software\Classes\exefile'. 2014/10/12 04:16:13 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Software\Classes\piffile'. 2014/10/12 04:16:13 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Software\Classes\AllFilesystemObjects'. 2014/10/12 04:16:13 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Software\Classes\Directory'. 2014/10/12 04:16:13 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Software\Classes\Folder'. 2014/10/12 04:16:13 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Software\Classes\Protocols'. 2014/10/12 04:16:13 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Software\Policies'. 2014/10/12 04:16:13 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Security'. 2014/10/12 04:16:13 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer'. 2014/10/12 04:16:13 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services'. 2014/10/12 04:16:13 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\KnownDLLs'. 2014/10/12 04:16:13 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurePipeServers\winreg'. 2014/10/12 04:16:13 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run'. 2014/10/12 04:16:13 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce'. 2014/10/12 04:16:13 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnceEx'. 2014/10/12 04:16:13 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\URL'. 2014/10/12 04:16:13 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies'. 2014/10/12
Re: [ossec-list] Windows agents not connecting to OSSEC server
client is installed on Win7 machine with admin credentials (logged in as domain admin and ran as administrator to install, group policy installation runs under system credentials before login). tcpdump gives me a : syntax error on each IP address I have tried it on. On Monday, October 13, 2014 6:18:08 PM UTC-5, Grant L wrote: Do this for about 5 non communicating servers at random. On the OSSEC-SERVER run 'tcpdump -i eth0 host ip of server in question port 1514' see if the connection even makes it to the server Also, note that OSSEC has to be installed as local admin or domain admin, else UAC kind of kills the application. Grant Leonard Castra Consulting, LLC http://castraconsulting.com/#/ 919-949-4002 On Mon, Oct 13, 2014 at 6:55 PM, David Masters dmas...@24-7intouch.com javascript: wrote: This is what we did last year Entered in the machines manually to the server to create the account/key on the ossec server once all of the machines were entered, we ran cat client.keys on the ossec server, which reads/prints out all the keys to the screen the session was being recorded to the putty.log (using putty to connect to the ossec server) the key list was copied from the putty.log (txt file) to a spreadsheet this spreadsheet was used to manually enter each key into each individual system when the agent was installed. This year we have roughly 2/3 again as many systems as we did last year, so are trying to automate as much of this as possible. We wrote a script that reads the computer names from a CSV to create the machine accounts on the OSSEC server (utilizing manage_agents (which we wrote before it was found out that they had added that functionality to the 2.8.1 version). This creates the individual machine accounts. Then we read the keys from the server (cat client.keys) just like we did last year, copying the keys from the putty.log file into a spreadsheet. I then copy out those keys into individual text files named with the individual computer name (ie: each line is a computer account/key which then gets copied into its own text file named after itself and with the proper .keys file format)(computer1.keys, computer2.keys, computer3.keys, etc). I have a group policy that uninstalls any previous version of ossec agent, then installs the current version (2.8), copies over the ossec.conf file with the proper server info and copies over the computer name file into a client.keys file on the machine (reads the machine name from the BIOS, then finds the proper computername.keys file and copies it over to that machine into the ossec folder as client.keys, then starts the ossec agent. The machine boots and the agent contains all the proper information except that it won't communicate with the server. The file structure is identical with a freshly installed local agent with the manually entered information, except for the communication errors. Which part of that process is screwing me up? On Monday, October 13, 2014 5:31:09 PM UTC-5, gr...@castraconsulting.com wrote: David You wrote -- The key files I am creating are being created directly from the spreadsheet You are not creating the keys yourself are you? when you run manage-agents and add a new agent, a key gets put into client.keys, that key is associated with the hostname of the sending device and can only be used one. You don't have to have an IP of the remote agent, you can use any instead of 1.1.1.1 in case IP overlap is occuring. I have to ask, port 1514 is accessible from the Windows servers in question, right? They can actually send UDP 1514 packets to the Ossec-server? The scripts we wrote literally just loop through a csv file of ip,hostname and create the placeholder in manage-agent, then map a share connection to the target, move the agent over and attempt to run the agent with the creds provided and I don't do batches larger than 100 at a time just to make sure the ossec-server is keeping up. Has any of this helped you sir? On Monday, October 13, 2014 3:47:12 PM UTC-4, David Masters wrote: I am acquiring the keys originally from the server (cat client.keys) then copying that information directly from the putty.log file into a spreadsheet. The key files I am creating are being created directly from the spreadsheet. I manually verify the information in the keys file before it is copied down to the computer. Same with the ossec.conf file...it was copied originally from a machine that was communicating properly with the server. If you guys know of any scripts or automation help you can offer, I would be most appreciative. I've been banging my head against a wall on this one. On Monday, October 13, 2014 12:30:10 PM UTC-5, LostInThe Tubez wrote: Many people have created an automated deployment script successfully, so no need to worry there. How are you exporting the agent keys from the
Re: [ossec-list] Windows agents not connecting to OSSEC server
I guessed at your eth interface the command is sound, I just dont know what your OS looks like SO tcpdump -i replace this with the interface name, like eth0 host replace this with the IP of the sending WIn7 platform and port 1514 -vvv Make sense? Grant Leonard Castra Consulting, LLC http://castraconsulting.com/#/ 919-949-4002 On Mon, Oct 13, 2014 at 8:32 PM, David Masters dmast...@24-7intouch.com wrote: client is installed on Win7 machine with admin credentials (logged in as domain admin and ran as administrator to install, group policy installation runs under system credentials before login). tcpdump gives me a : syntax error on each IP address I have tried it on. On Monday, October 13, 2014 6:18:08 PM UTC-5, Grant L wrote: Do this for about 5 non communicating servers at random. On the OSSEC-SERVER run 'tcpdump -i eth0 host ip of server in question port 1514' see if the connection even makes it to the server Also, note that OSSEC has to be installed as local admin or domain admin, else UAC kind of kills the application. Grant Leonard Castra Consulting, LLC http://castraconsulting.com/#/ 919-949-4002 On Mon, Oct 13, 2014 at 6:55 PM, David Masters dmas...@24-7intouch.com wrote: This is what we did last year Entered in the machines manually to the server to create the account/key on the ossec server once all of the machines were entered, we ran cat client.keys on the ossec server, which reads/prints out all the keys to the screen the session was being recorded to the putty.log (using putty to connect to the ossec server) the key list was copied from the putty.log (txt file) to a spreadsheet this spreadsheet was used to manually enter each key into each individual system when the agent was installed. This year we have roughly 2/3 again as many systems as we did last year, so are trying to automate as much of this as possible. We wrote a script that reads the computer names from a CSV to create the machine accounts on the OSSEC server (utilizing manage_agents (which we wrote before it was found out that they had added that functionality to the 2.8.1 version). This creates the individual machine accounts. Then we read the keys from the server (cat client.keys) just like we did last year, copying the keys from the putty.log file into a spreadsheet. I then copy out those keys into individual text files named with the individual computer name (ie: each line is a computer account/key which then gets copied into its own text file named after itself and with the proper .keys file format)(computer1.keys, computer2.keys, computer3.keys, etc). I have a group policy that uninstalls any previous version of ossec agent, then installs the current version (2.8), copies over the ossec.conf file with the proper server info and copies over the computer name file into a client.keys file on the machine (reads the machine name from the BIOS, then finds the proper computername.keys file and copies it over to that machine into the ossec folder as client.keys, then starts the ossec agent. The machine boots and the agent contains all the proper information except that it won't communicate with the server. The file structure is identical with a freshly installed local agent with the manually entered information, except for the communication errors. Which part of that process is screwing me up? On Monday, October 13, 2014 5:31:09 PM UTC-5, gr...@castraconsulting.com wrote: David You wrote -- The key files I am creating are being created directly from the spreadsheet You are not creating the keys yourself are you? when you run manage-agents and add a new agent, a key gets put into client.keys, that key is associated with the hostname of the sending device and can only be used one. You don't have to have an IP of the remote agent, you can use any instead of 1.1.1.1 in case IP overlap is occuring. I have to ask, port 1514 is accessible from the Windows servers in question, right? They can actually send UDP 1514 packets to the Ossec-server? The scripts we wrote literally just loop through a csv file of ip,hostname and create the placeholder in manage-agent, then map a share connection to the target, move the agent over and attempt to run the agent with the creds provided and I don't do batches larger than 100 at a time just to make sure the ossec-server is keeping up. Has any of this helped you sir? On Monday, October 13, 2014 3:47:12 PM UTC-4, David Masters wrote: I am acquiring the keys originally from the server (cat client.keys) then copying that information directly from the putty.log file into a spreadsheet. The key files I am creating are being created directly from the spreadsheet. I manually verify the information in the keys file before it is copied down to the computer. Same with the ossec.conf file...it was copied originally from a machine that was communicating properly with the server. If you guys
Re: [ossec-list] Windows agents not connecting to OSSEC server
On 10/13/2014 11:18 AM, David Masters wrote: The whole purpose of this exercise is to not have to go to each individual machine to input the key and configuration. We have over 3000 machines so that really is just not feasible. If the key server is input manually when the software is installed it works fine. When the key file and config file are pushed out over the network (containing the exact same information that would have been input manually), it does not. This would be to the same machine, same configuration, no changes between manual input and pushed input. (except that it is not done manually). Rest assured, this is possible (albeit I have not tried a mass deployment with 'any'). I have deployed 2.8 to about 150 Windows systems via a psexec script, so I know it works. - Are there any duplicate IPs or agent IDs in client.keys on the manager? -Is the line on both the manager and agent in this format: 004 hostname any key -Are there any issues with CR/LF or other non-printing characters due to your script? You might want to try this: 1. Install the agent manually 2. Verify it works 3. Copy the key file somewhere else 4. Uninstall the agent 5. Remove the rids from the manager and restart the manager 6. Push via your deployment method to the agent 7. If it doesn't work, then stop the agent service, delete the key file and replace it with the one you know worked. 8. Start OSSEC If it works, then you know the problem is with the agent keys file. If it doesn't, then the issue is probably with the manager's key file. -- --- 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] Windows agents not connecting to OSSEC server
The exact command I typed is was: tcpdump -i eth1 host xxx.xxx.xxx.xxx port 1514 No other ethernet ports are active on the machine. Did I miss something when I typed it in? On Monday, October 13, 2014 7:43:23 PM UTC-5, Grant L wrote: I guessed at your eth interface the command is sound, I just dont know what your OS looks like SO tcpdump -i replace this with the interface name, like eth0 host replace this with the IP of the sending WIn7 platform and port 1514 -vvv Make sense? Grant Leonard Castra Consulting, LLC http://castraconsulting.com/#/ 919-949-4002 On Mon, Oct 13, 2014 at 8:32 PM, David Masters dmas...@24-7intouch.com javascript: wrote: client is installed on Win7 machine with admin credentials (logged in as domain admin and ran as administrator to install, group policy installation runs under system credentials before login). tcpdump gives me a : syntax error on each IP address I have tried it on. On Monday, October 13, 2014 6:18:08 PM UTC-5, Grant L wrote: Do this for about 5 non communicating servers at random. On the OSSEC-SERVER run 'tcpdump -i eth0 host ip of server in question port 1514' see if the connection even makes it to the server Also, note that OSSEC has to be installed as local admin or domain admin, else UAC kind of kills the application. Grant Leonard Castra Consulting, LLC http://castraconsulting.com/#/ 919-949-4002 On Mon, Oct 13, 2014 at 6:55 PM, David Masters dmas...@24-7intouch.com wrote: This is what we did last year Entered in the machines manually to the server to create the account/key on the ossec server once all of the machines were entered, we ran cat client.keys on the ossec server, which reads/prints out all the keys to the screen the session was being recorded to the putty.log (using putty to connect to the ossec server) the key list was copied from the putty.log (txt file) to a spreadsheet this spreadsheet was used to manually enter each key into each individual system when the agent was installed. This year we have roughly 2/3 again as many systems as we did last year, so are trying to automate as much of this as possible. We wrote a script that reads the computer names from a CSV to create the machine accounts on the OSSEC server (utilizing manage_agents (which we wrote before it was found out that they had added that functionality to the 2.8.1 version). This creates the individual machine accounts. Then we read the keys from the server (cat client.keys) just like we did last year, copying the keys from the putty.log file into a spreadsheet. I then copy out those keys into individual text files named with the individual computer name (ie: each line is a computer account/key which then gets copied into its own text file named after itself and with the proper .keys file format)(computer1.keys, computer2.keys, computer3.keys, etc). I have a group policy that uninstalls any previous version of ossec agent, then installs the current version (2.8), copies over the ossec.conf file with the proper server info and copies over the computer name file into a client.keys file on the machine (reads the machine name from the BIOS, then finds the proper computername.keys file and copies it over to that machine into the ossec folder as client.keys, then starts the ossec agent. The machine boots and the agent contains all the proper information except that it won't communicate with the server. The file structure is identical with a freshly installed local agent with the manually entered information, except for the communication errors. Which part of that process is screwing me up? On Monday, October 13, 2014 5:31:09 PM UTC-5, gr...@castraconsulting.com wrote: David You wrote -- The key files I am creating are being created directly from the spreadsheet You are not creating the keys yourself are you? when you run manage-agents and add a new agent, a key gets put into client.keys, that key is associated with the hostname of the sending device and can only be used one. You don't have to have an IP of the remote agent, you can use any instead of 1.1.1.1 in case IP overlap is occuring. I have to ask, port 1514 is accessible from the Windows servers in question, right? They can actually send UDP 1514 packets to the Ossec-server? The scripts we wrote literally just loop through a csv file of ip,hostname and create the placeholder in manage-agent, then map a share connection to the target, move the agent over and attempt to run the agent with the creds provided and I don't do batches larger than 100 at a time just to make sure the ossec-server is keeping up. Has any of this helped you sir? On Monday, October 13, 2014 3:47:12 PM UTC-4, David Masters wrote: I am acquiring the keys originally from the server (cat client.keys) then copying that information directly from the putty.log file into a
Re: [ossec-list] Windows agents not connecting to OSSEC server
I will try the process you suggest tomorrow. As for the rest: there are no duplicate IP's (all agents have been added with the any IP configuration) or ID's (all keys were deleted from the client.keys file (except 001) in order to prevent duplicates)(all rid's were deleted afterwards to make sure there weren't any issues there either, all done while the ossec services were stopped)). both files (client.keys and ossec.conf being pushed out) were examined in notepad, wordpad and notepad++ (multiple languanges) to verify there were no extra non-visible characters/line breaks/carriage returns present. On Monday, October 13, 2014 7:43:26 PM UTC-5, Michael Starks wrote: On 10/13/2014 11:18 AM, David Masters wrote: The whole purpose of this exercise is to not have to go to each individual machine to input the key and configuration. We have over 3000 machines so that really is just not feasible. If the key server is input manually when the software is installed it works fine. When the key file and config file are pushed out over the network (containing the exact same information that would have been input manually), it does not. This would be to the same machine, same configuration, no changes between manual input and pushed input. (except that it is not done manually). Rest assured, this is possible (albeit I have not tried a mass deployment with 'any'). I have deployed 2.8 to about 150 Windows systems via a psexec script, so I know it works. - Are there any duplicate IPs or agent IDs in client.keys on the manager? -Is the line on both the manager and agent in this format: 004 hostname any key -Are there any issues with CR/LF or other non-printing characters due to your script? You might want to try this: 1. Install the agent manually 2. Verify it works 3. Copy the key file somewhere else 4. Uninstall the agent 5. Remove the rids from the manager and restart the manager 6. Push via your deployment method to the agent 7. If it doesn't work, then stop the agent service, delete the key file and replace it with the one you know worked. 8. Start OSSEC If it works, then you know the problem is with the agent keys file. If it doesn't, then the issue is probably with the manager's key file. -- --- 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.
