Thanks Dan.
UDP 1514 is enabled between the clients and servers, however according
to this documentation page, "keeping the state" is necessary.  On the
server (running iptables) I didn't have the state defined in the
firewall rule that was allowing UDP 1514, so I'm wondering if this is
the issue.

Aaron

http://www.ossec.net/doc/faq/unexpected.html#the-communication-between-my-agent-and-the-server-is-not-working-what-to-do

On Thu, Dec 2, 2010 at 11:41 PM, dan (ddp) <[email protected]> wrote:
> The OSSEC communications protocol is 2 way. The server talks to the
> client from a random port to 1514, and the server responds to that
> port.
> Traffic to and from the agent to port 1514 on the manager should be allowed.
>
> On Thu, Dec 2, 2010 at 11:14 PM, Aaron Bliss <[email protected]> wrote:
>> Hi all
>> I've noticed that in several Windows' clients firewall logs that the
>> ossec server is attempting to connect to the client on random UDP
>> ports.  The clients are firewalled which is why I noticed the dropped
>> packets.  The source port is always UDP 1514, so this points to ossec
>> related traffic (ossec even reported the dropped packets on the
>> client, see below for a sample).  Any idea why the ossec server would
>> be attempting to talk to the client on a random UDP port?  On those
>> same clients, I've noticed as well that they don't always execute an
>> active response that should have been initiated by the ossec server.
>> ossec.log file on the client doesn't show any errors, ossec-execd
>> process is running and all other ossec functions and communication
>> between the agent and server seem to be working.  Any ideas?  Is there
>> are necessary firewall rule/port that needs to be opened on the client
>> side?
>>
>> Aaron
>>
>> 2010-12-02 19:31:45 DROP UDP 10.0.0.1 10.0.0.2 1514 50564 181 - - - -
>> - - - RECEIVE
>>
>> Received From: (box1)
>> 10.0.0.2->\Windows\system32\logfiles\firewall\pfirewall.log
>> Rule: 4151 fired (level 10) -> "Multiple Firewall drop events from same 
>> source."
>> Portion of the log(s):
>>
>> 2010-12-02 19:31:45 DROP UDP 10.0.0.1 10.0.0.2 1514 50564 181 - - - -
>> - - - RECEIVE
>> 2010-12-02 19:31:45 DROP UDP 10.0.0.1 10.0.0.2 1514 50564 181 - - - -
>> - - - RECEIVE
>> 2010-12-02 19:31:45 DROP UDP 10.0.0.1 10.0.0.2 1514 50564 181 - - - -
>> - - - RECEIVE
>> 2010-12-02 19:31:14 DROP UDP 10.0.0.1 10.0.0.3 1514 60010 181 - - - -
>> - - - RECEIVE
>> 2010-12-02 19:31:14 DROP UDP 10.0.0.1 10.0.0.3 1514 60010 181 - - - -
>> - - - RECEIVE
>> 2010-12-02 19:31:14 DROP UDP 10.0.0.1 10.0.0.3 1514 60010 181 - - - -
>> - - - RECEIVE
>> 2010-12-02 19:31:14 DROP UDP 10.0.0.1 10.0.0.3 1514 60010 173 - - - -
>> - - - RECEIVE
>>
>

Reply via email to