i can get the active response to fire by passing "-b 1.2.3.4 -f firewall-drop600 -u 000"
firewall-drop600 is in the ar.conf. I guess i don't (yet) understand what uses ar.conf and what uses ossec.conf. --------brain dump------------- from what i think i understand then, the ossec.conf on the manager controls that manager config. the manager decides when an active response should run and simply tells an agent to block an ip address by using a script (much like calling agent_control -b... by hand). the ossec.conf on the agent controls the agent config. It can be as simple as the <server-ip> configuration parameter telling the agent to get it's config from the manager, or as complex as defining local configuration parameters (including active response rules, etc). the agent.conf on the manager controls the agents' config. it can essentially contain any of the client config parameters.. syscheck, rootcheck, etc. the agent.conf is modified on the manager and distributed to the agents on some time based schedule (1-2 hours?) unless both manager and agents are restarted. the agent.conf on an agent should be exactly the same as the agent.conf on the manager (and can be verified by the md5sum). ----------------- I will try in debug mode, and i will make sure i'm firing a rule that is level 6 or higher. thanks for your patience Dan. J On Fri, Feb 25, 2011 at 9:02 PM, dan (ddp) <[email protected]> wrote: > Hi Joel, > > On Fri, Feb 25, 2011 at 7:59 PM, Joel Brooks <[email protected]> wrote: >> i still haven't got it working. >> >> I've tried moving the <command> definitions and the <active-response> >> sections to the agent.conf, and still no joy. >> > > No joy because the MANAGER doesn't use the agent.conf. > >> i just can't get active response to work in central management mode. >> >> I found that executing >> >> bin/agent_control -b 1.2.3.4 -f firewall-drop -u 000 >> >> from the manager results in the following in the ossec.log on the agent. >> >> 2011/02/25 19:53:01 ossec-execd: INFO: Active response command not >> present: '/var/ossec/active-response/bin/restart-ossec.cmd'. Not using >> it on this system. >> > > The restart-ossec.cmd is a Windows AR, this message can be ignored. > >> 2011/02/25 19:53:01 ossec-execd(1311): ERROR: Invalid command name >> 'firewall-drop' provided. >> > > That's strange. I see it in the ossec.conf you sent to the mailing > list (or this could be asking for the actual command > /var/ossec/active-response/bin/firewall-drop.sh, I can't test to find > out at the moment). > > Can you turn on debugging on the agents? I'm hoping that might help. > > I don't think the firewall-drop command would be the one to fire, > since the host-deny command is used in the first active-response block > and they use the same parameters. > >> any further insights / thoughts would be greatly appreciated! >> >> J >> > > When you try testing this with SSH, which alert is firing? Your AR > configuration requires that it be level 6+. > It looks like most of the (single) ssh authentication failure alerts > are level 5 or lower. >
