I thought it was first come first served. On Aug 1, 2012 5:26 PM, "cmlara" <[email protected]> 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 <[email protected]> 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 <[email protected]> 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, >> >> > >> >> > >> >
