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 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 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. >>>> > 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+...@googlegroups.com. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> -- > > --- > 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+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.
