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: >>>>>> >>>>>> 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+...@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+...@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.