[ossec-list] Re: Windows agents not connecting to OSSEC server
I got most everything to work except at one site. After looking through everything on that server, I noticed that the sender_counter file is missing from rids directory. I know that keeps track/count of something...could that be what's causing some of my agents to not be able to connect? On Sunday, October 12, 2014 4:34:03 AM UTC-5, 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 04:16:13 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows'. 2014/10/12 04:16:14 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon'. 2014/10/12 04:16:14 ossec-agent: INFO
Re: [ossec-list] Windows agents not connecting to OSSEC server
This is the output from the tcpdump on one of the non-communicating IP addresses: tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes 11:05:16.550625 IP (tos 0x0, ttl 127, id 8096, offset 0, flags [none], proto UDP (17), length 106) 10.50.102.17.63040 fri-security1.247intouchpci.local.1514: [udp sum ok] UDP, length 78 11:05:22.586977 IP (tos 0x0, ttl 127, id 8106, offset 0, flags [none], proto UDP (17), length 106) 10.50.102.17.63040 fri-security1.247intouchpci.local.1514: [udp sum ok] UDP, length 78 11:05:26.596125 IP (tos 0x0, ttl 127, id 8112, offset 0, flags [DF], proto UDP (17), length 106) 10.50.102.17.63040 fri-security1.247intouchpci.local.1514: [udp sum ok] UDP, length 78 11:05:31.603664 IP (tos 0x0, ttl 127, id 8113, offset 0, flags [DF], proto UDP (17), length 106) 10.50.102.17.63040 fri-security1.247intouchpci.local.1514: [udp sum ok] UDP, length 78 11:05:37.609694 IP (tos 0x0, ttl 127, id 8114, offset 0, flags [DF], proto UDP (17), length 106) 10.50.102.17.63040 fri-security1.247intouchpci.local.1514: [udp sum ok] UDP, length 78 On Monday, October 13, 2014 7:54:13 PM UTC-5, David Masters wrote: 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 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
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] 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: 'HKEY_LOCAL_MACHINE\Software
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.
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
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
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
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
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.
[ossec-list] Windows agents not connecting to OSSEC server
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 04:16:13 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows'. 2014/10/12 04:16:14 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon'. 2014/10/12 04:16:14 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Software\Microsoft\Active Setup\Installed Components'. 2014/10/12 04:16:14 ossec-agent: INFO: Monitoring directory: 'C:\Windows/win.ini'. 2014/10/12 04:16:14 ossec-agent: INFO: Monitoring directory: 'C:\Windows/system.ini'. 2014/10/12 04:16:14 ossec-agent: INFO: Monitoring directory: 'C:\autoexec.bat'. 2014/10/12 04:16:14 ossec-agent: INFO: Monitoring directory: 'C:\config.sys'. 2014/10/12
Re: [ossec-list] Windows agents not connecting to OSSEC server
/drwtsn32.exe'. 2014/10/12 17:07:10 ossec-agent: INFO: Monitoring directory: 'C:\Windows/System32/edlin.exe'. 2014/10/12 17:07:10 ossec-agent: INFO: Monitoring directory: 'C:\Windows/System32/eventcreate.exe'. 2014/10/12 17:07:10 ossec-agent: INFO: Monitoring directory: 'C:\Windows/System32/eventtriggers.exe'. 2014/10/12 17:07:10 ossec-agent: INFO: Monitoring directory: 'C:\Windows/System32/ftp.exe'. 2014/10/12 17:07:10 ossec-agent: INFO: Monitoring directory: 'C:\Windows/System32/net.exe'. 2014/10/12 17:07:10 ossec-agent: INFO: Monitoring directory: 'C:\Windows/System32/net1.exe'. 2014/10/12 17:07:10 ossec-agent: INFO: Monitoring directory: 'C:\Windows/System32/netsh.exe'. 2014/10/12 17:07:10 ossec-agent: INFO: Monitoring directory: 'C:\Windows/System32/rcp.exe'. 2014/10/12 17:07:10 ossec-agent: INFO: Monitoring directory: 'C:\Windows/System32/reg.exe'. 2014/10/12 17:07:10 ossec-agent: INFO: Monitoring directory: 'C:\Windows/regedit.exe'. 2014/10/12 17:07:10 ossec-agent: INFO: Monitoring directory: 'C:\Windows/System32/regedt32.exe'. 2014/10/12 17:07:10 ossec-agent: INFO: Monitoring directory: 'C:\Windows/System32/regsvr32.exe'. 2014/10/12 17:07:10 ossec-agent: INFO: Monitoring directory: 'C:\Windows/System32/rexec.exe'. 2014/10/12 17:07:10 ossec-agent: INFO: Monitoring directory: 'C:\Windows/System32/rsh.exe'. 2014/10/12 17:07:10 ossec-agent: INFO: Monitoring directory: 'C:\Windows/System32/runas.exe'. 2014/10/12 17:07:10 ossec-agent: INFO: Monitoring directory: 'C:\Windows/System32/sc.exe'. 2014/10/12 17:07:10 ossec-agent: INFO: Monitoring directory: 'C:\Windows/System32/subst.exe'. 2014/10/12 17:07:10 ossec-agent: INFO: Monitoring directory: 'C:\Windows/System32/telnet.exe'. 2014/10/12 17:07:10 ossec-agent: INFO: Monitoring directory: 'C:\Windows/System32/tftp.exe'. 2014/10/12 17:07:10 ossec-agent: INFO: Monitoring directory: 'C:\Windows/System32/tlntsvr.exe'. 2014/10/12 17:07:10 ossec-agent: INFO: Monitoring directory: 'C:\Windows/System32/drivers/etc'. 2014/10/12 17:07:10 ossec-agent: INFO: Monitoring directory: 'C:\Documents and Settings/All Users/Start Menu/Programs/Startup'. 2014/10/12 17:07:10 ossec-agent: INFO: Started (pid: 2864). 2014/10/12 17:07:20 ossec-agent: WARN: Process locked. Waiting for permission... 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? On Sunday, October 12, 2014 8:51:41 AM UTC-5, Michael Starks wrote: On 10/12/2014 04:34 AM, 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. This could be the problem. It's likely that the rids are our of order and ossec sees this as a replay attack. Delete the rids on the agent as part of the installation process so that when it checks in, ossec will not send a higher rids count than the manager knows about. For systems that have already checked in, delete the rids on the manager in /queue. -- --- 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.
