Joe, Here is the base firewall rule (ossec server side) I'm using now -A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED,NEW -p udp -s 10.0.0/24 --dport 1514 -j ACCEPT
The rule sample I submitted was from the Windows client that reported the dropped ossec traffic, however I believe that is because the IPtables rule was using on the ossec server didn't include any state information which was resulting in communication loss between ossec clients and the server; i.e. it looked like this: -A RH-Firewall-1-INPUT -p udp -s 10.0.0/24 --dport 1514 -j ACCEPT On Fri, Dec 3, 2010 at 12:31 AM, Joe Gedeon <[email protected]> wrote: > 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 >
