ossec-execd is running on the agents.

The strangest part of all this is that I can successfully issue
`agent-control -u...` and get the null-route command to work manually. But
for some reason it won't work the normal way, even though the relevant rule
ID is getting triggered.

On Mon, Feb 7, 2011 at 6:33 AM, dan (ddp) <[email protected]> wrote:

> On Fri, Feb 4, 2011 at 7:15 PM, jplee3 <[email protected]> wrote:
> > I also tried with <location>all</location> and it did not work.
> >
> >
> > Something I did notice: on the OSSEC server the "/var/ossec/queue/
> > alerts/ar" file exists while on the agents I'm trying to get this to
> > work on, that file does not exist. Is this the cause of the problem?
> > If so, what would have caused the ar file to go away? And how can I
> > get it back?
> >
>
> That file does not exist on my agents:
> [ddp@junction] :; sudo -s
> # ls -l /var/ossec/queue/alerts/
> total 0
> srw-rw----  1 root  ossec  0 Jan 26 22:26 execq
>
> Is ossec-execd running on the agents? Does it work on any agents?
>
> > On Feb 4, 3:02 pm, jplee3 <[email protected]> wrote:
> >> Hey guys,
> >>
> >> I'm not exactly sure what happened but it seems my Active Response
> >> stopped working. I've verified the rule behind the AR gets triggered
> >> and I also manually tested the rule via the agent_control command.
> >>
> >> Here's the configs/logs:
> >>
> >> ossec.conf:
> >>   <command>
> >>     <name>route-null</name>
> >>     <executable>route-null.sh</executable>
> >>     <expect>srcip</expect>
> >>     <timeout_allowed>yes</timeout_allowed>
> >>   </command>
> >>
> >>   <active-response>
> >>     <command>route-null</command>
> >>     <location>defined-agent</location>
> >>     <agent_id>108</agent_id>
> >>     <rules_id>300042</rules_id>
> >>     <timeout>1800</timeout>
> >>   </active-response>
> >>
> >>   <active-response>
> >>     <command>route-null</command>
> >>     <location>defined-agent</location>
> >>     <agent_id>109</agent_id>
> >>     <rules_id>300042</rules_id>
> >>     <timeout>1800</timeout>
> >>   </active-response>
> >>
> >> alert.log (sanitized):
> >> ** Alert 1296859856.1087142244: mail  - local,syslog,
> >> 2011 Feb 04 14:50:56 lxapp5->/nas/logs/attack/attack.log
> >> Rule: 300042 (level 8) -> 'Multiple scripted attack'
> >> Src IP: 192.168.1.45
> >> User: user2
> >> [blah blah blah blah blah 192.168.45 blah blah blah user2]
> >>
> >> So the alert is definitely being triggered here...
> >>
> >> To test that AR is functional:
> >> server:
> >> /var/ossec/bin/agent_control -u 109 -b 1.2.3.4 -f route-null1800
> >>
> >> OSSEC HIDS agent_control: Running active response 'route-null1800' on:
> >> 109
> >>
> >> agent (active-responses.log):
> >> Fri Feb  4 14:58:29 PST 2011 /var/ossec/active-response/bin/route-
> >> null.sh add - 1.2.3.4 (from_the_server) (no_rule_id)
> >>
> >> So for some reason it seems OSSEC is not paying attention to the
> >> portion of the conf regarding active responses... it might just be a
> >> dumb typo but is there anyway to debug further to find the root cause?
> >> Or does anyone see anything wrong with the snippet of the conf? I also
> >> tried removing "<disabled>no</disabled" to no avail. I have made no
> >> changes to the route-null.sh AR script either. This was all working
> >> previously and I had to stop it due to issues back in January. I just
> >> got back to playing around with this again and it's not working.
> >>
> >> Any ideas?
>

Reply via email to