Re: [ossec-list] Windows agents not connecting to OSSEC server

[dan (ddp)]

On Oct 12, 2014 6:28 AM, "David Masters" <dmas...@24-7intouch.com> 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\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 04:16:14 ossec-agent: INFO: Monitoring directory: 'C:\boot.ini'.
>
> 2014/10/12 04:16:14 ossec-agent: INFO: Monitoring directory: 'C:\Windows/System32/CONFIG.NT'.
>
> 2014/10/12 04:16:14 ossec-agent: INFO: Monitoring directory: 'C:\Windows/System32/AUTOEXEC.NT'.
>
> 2014/10/12 04:16:14 ossec-agent: INFO: Monitoring directory: 'C:\Windows/System32/at.exe'.
>
> 2014/10/12 04:16:14 ossec-agent: INFO: Monitoring directory: 'C:\Windows/System32/attrib.exe'.
>
> 2014/10/12 04:16:14 ossec-agent: INFO: Monitoring directory: 'C:\Windows/System32/cacls.exe'.
>
> 2014/10/12 04:16:14 ossec-agent: INFO: Monitoring directory: 'C:\Windows/System32/debug.exe'.
>
> 2014/10/12 04:16:14 ossec-agent: INFO: Monitoring directory: 'C:\Windows/System32/drwatson.exe'.
>
> 2014/10/12 04:16:14 ossec-agent: INFO: Monitoring directory: 'C:\Windows/System32/drwtsn32.exe'.
>
> 2014/10/12 04:16:14 ossec-agent: INFO: Monitoring directory: 'C:\Windows/System32/edlin.exe'.
>
> 2014/10/12 04:16:14 ossec-agent: INFO: Monitoring directory: 'C:\Windows/System32/eventcreate.exe'.
>
> 2014/10/12 04:16:14 ossec-agent: INFO: Monitoring directory: 'C:\Windows/System32/eventtriggers.exe'.
>
> 2014/10/12 04:16:14 ossec-agent: INFO: Monitoring directory: 'C:\Windows/System32/ftp.exe'.
>
> 2014/10/12 04:16:14 ossec-agent: INFO: Monitoring directory: 'C:\Windows/System32/net.exe'.
>
> 2014/10/12 04:16:14 ossec-agent: INFO: Monitoring directory: 'C:\Windows/System32/net1.exe'.
>
> 2014/10/12 04:16:14 ossec-agent: INFO: Monitoring directory: 'C:\Windows/System32/netsh.exe'.
>
> 2014/10/12 04:16:14 ossec-agent: INFO: Monitoring directory: 'C:\Windows/System32/rcp.exe'.
>
> 2014/10/12 04:16:14 ossec-agent: INFO: Monitoring directory: 'C:\Windows/System32/reg.exe'.
>
> 2014/10/12 04:16:14 ossec-agent: INFO: Monitoring directory: 'C:\Windows/regedit.exe'.
>
> 2014/10/12 04:16:14 ossec-agent: INFO: Monitoring directory: 'C:\Windows/System32/regedt32.exe'.
>
> 2014/10/12 04:16:14 ossec-agent: INFO: Monitoring directory: 'C:\Windows/System32/regsvr32.exe'.
>
> 2014/10/12 04:16:14 ossec-agent: INFO: Monitoring directory: 'C:\Windows/System32/rexec.exe'.
>
> 2014/10/12 04:16:14 ossec-agent: INFO: Monitoring directory: 'C:\Windows/System32/rsh.exe'.
>
> 2014/10/12 04:16:14 ossec-agent: INFO: Monitoring directory: 'C:\Windows/System32/runas.exe'.
>
> 2014/10/12 04:16:14 ossec-agent: INFO: Monitoring directory: 'C:\Windows/System32/sc.exe'.
>
> 2014/10/12 04:16:14 ossec-agent: INFO: Monitoring directory: 'C:\Windows/System32/subst.exe'.
>
> 2014/10/12 04:16:14 ossec-agent: INFO: Monitoring directory: 'C:\Windows/System32/telnet.exe'.
>
> 2014/10/12 04:16:14 ossec-agent: INFO: Monitoring directory: 'C:\Windows/System32/tftp.exe'.
>
> 2014/10/12 04:16:14 ossec-agent: INFO: Monitoring directory: 'C:\Windows/System32/tlntsvr.exe'.
>
> 2014/10/12 04:16:14 ossec-agent: INFO: Monitoring directory: 'C:\Windows/System32/drivers/etc'.
>
> 2014/10/12 04:16:14 ossec-agent: INFO: Monitoring directory: 'C:\Documents and Settings/All Users/Start Menu/Programs/Startup'.
>
> 2014/10/12 04:16:14 ossec-agent: INFO: Started (pid: 6800).
>
> 2014/10/12 04:16:24 ossec-agent: WARN: Process locked. Waiting for permission...
>
> 2014/10/12 04:16:34 ossec-agent(4101): WARN: Waiting for server reply (not started). Tried: '10.50.3.4'.
>
> 2014/10/12 04:16:36 ossec-agent: INFO: Trying to connect to server (10.50.3.4:1514).
>
> 2014/10/12 04:16:36 ossec-agent: INFO: Using IPv4 for: 10.50.3.4 .
>
> 2014/10/12 04:16:58 ossec-agent(4101): WARN: Waiting for server reply (not started). Tried: '10.50.3.4'.
>
> 2014/10/12 04:17:18 ossec-agent: INFO: Trying to connect to server (10.50.3.4:1514).
>
> 2014/10/12 04:17:18 ossec-agent: INFO: Using IPv4 for: 10.50.3.4 .
>
> 2014/10/12 04:17:39 ossec-agent(4101): WARN: Waiting for server reply (not started). Tried: '10.50.3.4'.
>
> 2014/10/12 04:18:17 ossec-agent: INFO: Trying to connect to server (10.50.3.4:1514).
>
> 2014/10/12 04:18:17 ossec-agent: INFO: Using IPv4 for: 10.50.3.4 .
>
> 2014/10/12 04:18:38 ossec-agent(4101): WARN: Waiting for server reply (not started). Tried: '10.50.3.4'.
>
> 2014/10/12 04:19:34 ossec-agent: INFO: Trying to connect to server (10.50.3.4:1514).
>
> 2014/10/12 04:19:34 ossec-agent: INFO: Using IPv4 for: 10.50.3.4 .
>
> 2014/10/12 04:19:55 ossec-agent(4101): WARN: Waiting for server reply (not started). Tried: '10.50.3.4'.
>
> 2014/10/12 04:21:09 ossec-agent: INFO: Trying to connect to server (10.50.3.4:1514).
>
> 2014/10/12 04:21:09 ossec-agent: INFO: Using IPv4 for: 10.50.3.4 .
>
> 2014/10/12 04:21:30 ossec-agent(4101): WARN: Waiting for server reply (not started). Tried: '10.50.3.4'.
>
> 2014/10/12 04:23:02 ossec-agent: INFO: Trying to connect to server (10.50.3.4:1514).
>
> 2014/10/12 04:23:02 ossec-agent: INFO: Using IPv4 for: 10.50.3.4 .
>
> 2014/10/12 04:23:23 ossec-agent(4101): WARN: Waiting for server reply (not started). Tried: '10.50.3.4'.
>
> 2014/10/12 04:25:13 ossec-agent: INFO: Trying to connect to server (10.50.3.4:1514).
>
> 2014/10/12 04:25:13 ossec-agent: INFO: Using IPv4 for: 10.50.3.4 .
>
> 2014/10/12 04:25:34 ossec-agent(4101): WARN: Waiting for server reply (not started). Tried: '10.50.3.4'.
>
> 2014/10/12 04:27:42 ossec-agent: INFO: Trying to connect to server (10.50.3.4:1514).
>
> 2014/10/12 04:27:42 ossec-agent: INFO: Using IPv4 for: 10.50.3.4 .
>
> 2014/10/12 04:28:03 ossec-agent(4101): WARN: Waiting for server reply (not started). Tried: '10.50.3.4'.
>
> 2014/10/12 04:30:29 ossec-agent: INFO: Trying to connect to server (10.50.3.4:1514).
>
> 2014/10/12 04:30:30 ossec-agent: INFO: Using IPv4 for: 10.50.3.4 .
>
> 2014/10/12 04:30:51 ossec-agent(4101): WARN: Waiting for server reply (not started). Tried: '10.50.3.4'.
>
>
>
> I have verified that the information contained in the ossec.conf and client.keys files that were copied over to the local machine is correct.  
>
> Can anyone tell me why this is occurring and how to fix it?  Please?
>
> Thank you for all your help,
> David
>
> --
>
> ---
> 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.

[Michael Starks]

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.

[Antonio Querubin]

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

[gr...@castraconsulting.com]

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

[dan (ddp)]

On Mon, Oct 13, 2014 at 10:32 AM, David Masters
<dmas...@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?

>

[dan (ddp)]

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

[dan (ddp)]

On Mon, Oct 13, 2014 at 12:18 PM, David Masters
<dmas...@24-7intouch.com> 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

My apologies, I was trying to troubleshoot a problem. I'll stop. good luck. :)

> 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.

[Grant L]

That is kind of how it works for Windows, my company wrote a tool that will deploy them automatically for you.

On Oct 13, 2014 12:20 PM, "David Masters" <dmas...@24-7intouch.com> 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).  

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:

--

---
You received this message because you are subscribed to a topic in the Google Groups "ossec-list" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ossec-list/Zmfag8ajU3s/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ossec-list+...@googlegroups.com.

[LostInTheTubez]

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:

[gr...@castraconsulting.com]

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.

[Grant L]

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

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?

--

---
You received this message because you are subscribed to a topic in the Google Groups "ossec-list" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ossec-list/Zmfag8ajU3s/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ossec-list+...@googlegroups.com.

[Roy Feintuch]

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):

[Grant L]

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

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.

[Michael Starks]

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.

[Grant L]

You need the "and" before port

Sorry sent from my phone

On Oct 13, 2014 8:59 PM, "David Masters" <dmas...@24-7intouch.com> 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?

[Rick McClinton]

David,

I'm not confident that notepad, wordpad, or notepad++ wouldn't hide the byte order marker at the start of a Unicode file.

You mentioned scripting the creation of the key files; did you use Powershell for this? In one of our (unrelated) projects, we learned we needed to be sure to use the '-Encoding UTF-8' parameter to the 'out-file' commandlet; as the default 'Unicode' would insert the byte order marker in the output file. We were able to see the BOM when I opened the file with GVIM and (IIRC) using the 'type' command, but some other editors did not show it.

 

HTH;

Rick McClinton

On Monday, October 13, 2014 8:58:07 PM UTC-4, David Masters wrote:

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.

[Grant L]

Great point David

Grant Leonard

Castra Consulting, LLC

919-949-4002

--

---
You received this message because you are subscribed to a topic in the Google Groups "ossec-list" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ossec-list/Zmfag8ajU3s/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ossec-list+...@googlegroups.com.

[Grant L]

That file is definitely required, though I am not sure it has anything to do with the agent connecting in.

You showed earlier connections on port 1514 from the devices in question right?

Does the ossec.log note any issues with those devices?

for what it is worth, here is a sender_counter file from an active working lab install


silly-lab-box:/var/ossec/queue/rids# pwd
/var/ossec/queue/rids

silly-lab-box:/var/ossec/queue/rids# date
Fri Oct 17 19:06:38 UTC 2014

silly-lab-box:/var/ossec/queue/rids# ls -lahrt
total 28K
drwxrwx--- 11 ossec  ossec 4.0K Dec  7  2013 ..
drwxrwx---  2 ossec  ossec 4.0K Sep 23 18:26 .
-rw-r--r--  1 ossecr ossec    8 Oct 17 15:19 4
-rwxrwx---  1 ossec  ossec    8 Oct 17 19:03 3
-rwxrwx---  1 ossec  ossec   16 Oct 17 19:06 sender_counter
-rwxrwx---  1 ossec  ossec   10 Oct 17 19:06 2
-rwxrwx---  1 ossec  ossec   10 Oct 17 19:06 001

silly-lab-box:/var/ossec/queue/rids# more sender_counter
81:5072:70:4350:

Grant Leonard

Castra Consulting, LLC

919-949-4002

On Fri, Oct 17, 2014 at 2:52 PM, David Masters <dmas...@24-7intouch.com> wrote:

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?

--