It's actually the other way around. The agent will talk to the server via udp 1514 from a high port. When the server needs to talk to the agent it uses the same path. State Tables will normally keep this connection open to pass. Example below.
Agent_001:31128 -> Server:1514 Normal check keep alive traffic. Server:1514 -> Agent_001:31128 Server to agent communication for active response or etc/shared/<files> Think of it when you request a webpage: Client:29635 -> Webserver:80 Request Webserver:80 -> Client:29635 Content requested from webserver. On Thu, Dec 2, 2010 at 23:41, 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 >> > -- Registered Linux User # 379282
