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.
