Thanks Joe. I'm fairly certain my issue was related to how I had the iptables rule written on the ossec server. After fixing the rule (adding -m state --state ESTABLISHED,RELATED,NEW) for now things seem to be working better.
Aaron On Thu, Dec 2, 2010 at 11:47 PM, Joe Gedeon <[email protected]> wrote: > 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 >
