As far as I can tell it isn't but I am far from the expert here. I know I'm not seeing packets outbound so it for sure isn't network related must be config somewhere. Will run a few more tests on that tonight and try and trace it down. If anyone else has more info let me know.
On Wednesday, August 1, 2012 2:30:45 PM UTC-7, dan (ddpbsd) wrote: > I thought it was first come first served. > On Aug 1, 2012 5:26 PM, "cmlara" <> wrote: > >> Hello Dan, >> It sounds like you are saying the rule is "only one AR block per command >> name"? >> >> I know the stock conig has Host.deny and firewall-drop as stock configs >> on level 6 and I see both of these triggering on the server.. >> >> To test this though I went ahead and dropped the firewall-drop that goes >> to the server, so the only entires are the ALL followed by the AGENT id >> 001 firewall-drop commands >> >> The firewall rule does not execute on the local server now nor does it >> activate on the agent >> >> Doesn't sound like its a 'one AR block per command name" limit but >> perhaps I misunderstood your comment about "what is not handled" >> >> >> >> On Wednesday, August 1, 2012 1:40:29 PM UTC-7, dan (ddpbsd) wrote: >> >>> On Wed, Aug 1, 2012 at 4:34 PM, cmlara wrote: >>> > Thanks for the response dan. >>> > >>> > The configs look right to me the problem is that per the logs the >>> Automated >>> > Responses are NOT going across to the agent they are only running on >>> the >>> > server which is not what I need. >>> > >>> > I need the firewall to block on the agents. >>> > >>> >>> You didn't set it up to do that. >>> >>> > I put some inline notes about the config below but it boils down to : >>> > >>> > "server" according to posts I've seen -- Runs the command on >>> Managment >>> > Server only >>> > "all" -- Runs on all agents and excludes the managment server (the >>> source >>> > code seems to back this up on quick glance) -- Really should be called >>> 'all >>> > agents' >>> >>> Don't disagree, but that won't be changing. >>> >>> > ID 001 -- this was a fallback testing. >>> > >>> > So I have good contact to the agent (according to agent_control manual >>> > testing run from the command line by me not by OSSEC itself) >>> > >>> > AR inside OSSEC it is only executing on the local server (as >>> configured in >>> > the first AR block) and is ignoring the 2nd and 3rd AR blocks that >>> say to >>> > execute the responses on the agents themselves. >>> > >>> > On Wednesday, August 1, 2012 1:07:02 PM UTC-7, dan (ddpbsd) wrote: >>> >> >>> >> I don't see a problem with the config, it sounds like it's doing what >>> >> you've configured it to do. >>> >> >>> >> On Wed, Aug 1, 2012 at 3:56 PM, cmlara <> wrote: >>> >> > Hello All, >>> >> > >>> >> > I have setup a new server with OSSEC 2.6 on it running FreeBSD 9.0 >>> >> > 64bit >>> >> > >>> >> > I have a single agent (ID: 001) running on a Linux node (Ubuntu >>> 12.04 >>> >> > LTS >>> >> > 32bit 3.4 kernel) >>> >> > >>> >> > I feed all my logs back via syslog to the central logging server >>> that is >>> >> > the >>> >> > same server urnning ossec. >>> >> > >>> >> > OSSEC is configured to monitor the log files >>> >> > >>> >> > >>> >> > AR is setup with: >>> >> > >>> >> > <active-response> >>> >> > <!-- Firewall Drop response. Block the IP for >>> >> > - 600 seconds on the firewall (iptables, >>> >> > - ipfilter, etc). >>> >> > --> >>> >> > <command>firewall-drop</**command> >>> >> > <location>server</location> >>> >> > <level>6</level> >>> >> > <timeout>600</timeout> >>> >> > </active-response> >>> >> > >>> >> >>> >> Ok, so everything at level 6+ gets triggered above. Everything. >>> >> >>> >> >>> >> > <active-response> >>> >> > <!-- Firewall Drop response. Block the IP for >>> >> > - 600 seconds on the firewall (iptables, >>> >> > - ipfilter, etc). >>> >> > --> >>> >> > <command>firewall-drop</**command> >>> >> > <location>all</location> >>> >> > <level>6</level> >>> >> > <timeout>600</timeout> >>> >> > </active-response> >>> >> > >>> >> >>> >> We don't get to this one, everything level 6+ is handled in the >>> previous >>> >> AR. >>> >> >>> > Actually the previous one only runs the processing on the managment >>> server >>> > only. This one runs 'all' which actually exculdes the server >>> according to >>> > other web posts and the source code. It really should be called 'all >>> > agents' >>> > >>> >>> The first AR block handles everything level 6+. What alerts does this >>> AR block handle that the previous block did not? (hint: none) >>> >>> >> >>> >> > >>> >> > <active-response> >>> >> > <!-- Firewall Drop response. Block the IP for >>> >> > - 600 seconds on the firewall (iptables, >>> >> > - ipfilter, etc). >>> >> > --> >>> >> > <command>firewall-drop</**command> >>> >> > <location>defined_aget</**location> >>> >> > <agent_id>001</agent_id> >>> >> > <level>6</level> >>> >> > <timeout>600</timeout> >>> >> > </active-response> >>> >> > >>> >> >>> >> We don't worry about this one either, everything this one handles is >>> >> taken care of in the first AR block. >>> >> >>> > Agreed this is a last ditch effort to see if 'all' is broken as well >>> >> >>> >> > >>> >> > >>> >> > I know the 'all' will not trigger on the server but it should >>> trigger >>> >> > the >>> >> > agent. That failed to work on the agent so i added the extra >>> agent_id >>> >> > 001 >>> >> > to be sure. >>> >> > >>> >> > Looking at the logs/active-responses.log on the server: >>> >> > >>> >> > Wed Aug 1 19:41:36 UTC 2012 >>> >> > /usr/local/ossec-hids/active-**response/bin/host-deny.sh add - >>> >> > 61.135.137.2 >>> >> > 1343850096.1242729 5712 >>> >> > Wed Aug 1 19:41:36 UTC 2012 >>> >> > /usr/local/ossec-hids/active-**response/bin/firewall-drop.sh add - >>> >> > 61.135.137.2 1343850096.1242729 5712 >>> >> > >>> >> > (more entries below and above them) >>> >> > >>> >> > On the Agent N no log entires show up. The only log entires are >>> where I >>> >> > manually ran ./bin/agent_control to test server to agent >>> >> > communications >>> >> > which does work: >>> >> > >>> >> > Wed Aug 1 16:53:19 UTC 2012 >>> >> > /var/ossec/active-response/**bin/echoalert.sh >>> >>> >> > add >>> >> > - 9.9.9.9 (from_the_server) (no_rule_id) >>> >> > Wed Aug 1 17:03:49 UTC 2012 >>> >> > /var/ossec/active-response/**bin/echoalert.sh >>> >>> >> > delete - 9.9.9.9 (from_the_server) (no_rule_id) >>> >> > >>> >> > >>> >> > Anyone have any idea why the action is triggering on the server but >>> not >>> >> > on >>> >> > the agents? >>> >> > >>> >> > This is basicaly I have a number of frontend servers who are >>> publicly >>> >> > exposed that do not have their own firewalls in front of them so >>> each >>> >> > one >>> >> > will need to firewall itself and should firewall based on the >>> reports >>> >> > of >>> >> > the other frontends. >>> >> > Best Regards, >>> >> > >>> >> > >>> >>
