ESTABLISHED,RELATED should have already been set. The firewall is already obviously allowing outbound connections. The new on a -m state --state for a default inbound rule will only open a huge hole in you firewall. What is the base rule you are adding the NEW to?
On the server: IPTABLES -A INPUT -s 10.0.0.0/24 -p udp --dport 1514 -j ACCEPT Will accept all inbound traffic from the 10.0.0.0/24 network to the destination port udp 1514 for the client to server connection. The outbound connection should be covered in the default outbound policy which is more than likely set to ACCEPT. The logs that you show for the alerts look to be based on a windows firewall log. Which is the firewall dropping the connection. On Fri, Dec 3, 2010 at 00:16, Aaron Bliss <[email protected]> wrote: > 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 >> > -- Registered Linux User # 379282
