If AR isn't working on the agents when the server AR block was removed start inveatigating the agents. Is ar enabled? Is execd running? If you turn on debug (-d) are there any interesting log messages? On Aug 1, 2012 8:59 PM, "cmlara" <[email protected]> wrote:
> 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</**comman**d> >>>> >> > <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</**comman**d> >>>> >> > <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</**comman**d> >>>> >> > <location>defined_aget</**locati**on> >>>> >> > <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-**r**esponse/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-**r**esponse/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, >>>> >> > >>>> >> > >>>> >>>
