success! I ran the ossec-remoted in debug mode on the manager and found a stream of these:
2011/02/26 13:15:48 ossec-remoted(1403): ERROR: Incorrectly formated message from '192.168.0.1'. 2011/02/26 13:15:53 ossec-remoted(1403): ERROR: Incorrectly formated message from '192.168.0.1'. 2011/02/26 13:15:59 ossec-remoted(1403): ERROR: Incorrectly formated message from '192.168.0.1'. 2011/02/26 13:21:43 ossec-remoted(1403): ERROR: Incorrectly formated message from '192.168.0.1'. 2011/02/26 13:21:49 ossec-remoted(1403): ERROR: Incorrectly formated message from '192.168.0.1'. some googling told me that this is sometimes related to the keys for the agent. I looked at the client.keys file on both agent and manager and found that the manager had several entries for the 192.168.0.1 ip address (while troubleshooting, i removed the agent and re-added it once or twice). the deleted entries showed the IP address as "#######-0.1" or something like that. I should have kept a copy, but i just deleted those lines from the client.keys on the manager leaving only the current key/agent #. restarted both manager and agent, and poof, everything started working. so, lessons: ossec.conf on agent only needs the <server-ip> section. everything else can be done in the agent.conf. active-responses work when the agent is properly configured and properly communicating with the manager. running the manager daemons in debug mode can be very informative. definetly got to know ossec a bit better these last few days. cheers, J On Fri, Feb 25, 2011 at 9:25 PM, Joel Brooks <[email protected]> wrote: > 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. >> >
