I guessed at your eth interface the command is sound, I just dont know what your OS looks like
SO tcpdump -i <replace this with the interface name, like eth0> host <replace this with the IP of the sending WIn7 platform> and port 1514 -vvv Make sense? Grant Leonard Castra Consulting, LLC <http://castraconsulting.com/#/> 919-949-4002 On Mon, Oct 13, 2014 at 8:32 PM, David Masters <dmast...@24-7intouch.com> wrote: > client is installed on Win7 machine with admin credentials (logged in as > domain admin and "ran as administrator" to install, group policy > installation runs under system credentials before login). > > tcpdump gives me a : syntax error on each IP address I have tried it on. > > > On Monday, October 13, 2014 6:18:08 PM UTC-5, Grant L wrote: >> >> Do this for about 5 non communicating servers at random. >> >> On the OSSEC-SERVER >> >> run 'tcpdump -i eth0 host <ip of server in question> port 1514' >> >> see if the connection even makes it to the server >> >> Also, note that OSSEC has to be installed as local admin or domain admin, >> else UAC kind of kills the application. >> >> Grant Leonard >> Castra Consulting, LLC <http://castraconsulting.com/#/> >> 919-949-4002 >> >> On Mon, Oct 13, 2014 at 6:55 PM, David Masters <dmas...@24-7intouch.com> >> wrote: >> >>> This is what we did last year.... >>> >>> Entered in the machines manually to the server to create the account/key >>> on the ossec server >>> once all of the machines were entered, we ran cat client.keys on the >>> ossec server, which reads/prints out all the keys to the screen >>> the session was being recorded to the putty.log (using putty to connect >>> to the ossec server) >>> the key list was copied from the putty.log (txt file) to a spreadsheet >>> this spreadsheet was used to manually enter each key into each >>> individual system when the agent was installed. >>> >>> This year we have roughly 2/3 again as many systems as we did last year, >>> so are trying to automate as much of this as possible. >>> We wrote a script that reads the computer names from a CSV to create the >>> machine accounts on the OSSEC server (utilizing manage_agents (which we >>> wrote before it was found out that they had added that functionality to the >>> 2.8.1 version). This creates the individual machine accounts. Then we >>> read the keys from the server (cat client.keys) just like we did last year, >>> copying the keys from the putty.log file into a spreadsheet. I then copy >>> out those keys into individual text files named with the individual >>> computer name (ie: each line is a computer account/key which then gets >>> copied into its own text file named after itself and with the proper .keys >>> file format)(computer1.keys, computer2.keys, computer3.keys, etc). I have >>> a group policy that uninstalls any previous version of ossec agent, then >>> installs the current version (2.8), copies over the ossec.conf file with >>> the proper server info and copies over the computer name file into a >>> client.keys file on the machine (reads the machine name from the BIOS, then >>> finds the proper computername.keys file and copies it over to that machine >>> into the ossec folder as client.keys, then starts the ossec agent. The >>> machine boots and the agent contains all the proper information except that >>> it won't communicate with the server. The file structure is identical with >>> a freshly installed local agent with the manually entered information, >>> except for the communication errors. >>> >>> Which part of that process is screwing me up? >>> >>> On Monday, October 13, 2014 5:31:09 PM UTC-5, gr...@castraconsulting.com >>> wrote: >>>> >>>> David >>>> >>>> You wrote -- "The key files I am creating are being created directly >>>> from the spreadsheet" >>>> >>>> You are not creating the keys yourself are you? >>>> >>>> when you run manage-agents and add a new agent, a key gets put into >>>> client.keys, that key is associated with the hostname of the sending device >>>> and can only be used one. >>>> >>>> You don't have to have an IP of the remote agent, you can use "any" >>>> instead of 1.1.1.1 in case IP overlap is occuring. >>>> >>>> I have to ask, port 1514 is accessible from the Windows servers in >>>> question, right? They can actually send UDP 1514 packets to the >>>> Ossec-server? >>>> >>>> The scripts we wrote literally just loop through a csv file of >>>> "ip,hostname" and create the placeholder in manage-agent, then map a share >>>> connection to the target, move the agent over and attempt to run the agent >>>> with the creds provided and I don't do batches larger than 100 at a time >>>> just to make sure the ossec-server is keeping up. >>>> >>>> Has any of this helped you sir? >>>> >>>> On Monday, October 13, 2014 3:47:12 PM UTC-4, David Masters wrote: >>>>> >>>>> I am acquiring the keys originally from the server (cat client.keys) >>>>> then copying that information directly from the putty.log file into a >>>>> spreadsheet. The key files I am creating are being created directly from >>>>> the spreadsheet. I manually verify the information in the keys file >>>>> before >>>>> it is copied down to the computer. Same with the ossec.conf file...it was >>>>> copied originally from a machine that was communicating properly with the >>>>> server. >>>>> >>>>> If you guys 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+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.
