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

Reply via email to