Getting back to this old issue.... I finally found time to do some more 
testing.

My own script was apparently not called because the active-response was 
disabled for the commands "host-deny" and "firewall-drop" (or maybe one of 
them - I did not check). After enabling the two, it works.

Not sure why ossec behaves this way.

Am Freitag, 29. Juli 2016 16:45:49 UTC+2 schrieb Dominik:
>
>
>
> Am Freitag, 29. Juli 2016 14:20:41 UTC+2 schrieb dan (ddpbsd):
>>
>> On Fri, Jul 29, 2016 at 2:50 AM, Dominik <[email protected]> wrote: 
>> > 
>> > 
>> > Am Donnerstag, 28. Juli 2016 17:51:23 UTC+2 schrieb dan (ddpbsd): 
>> >> 
>> >> On Thu, Jul 28, 2016 at 11:25 AM, Dominik <[email protected]> wrote: 
>> >> > Dear all 
>> >> > somehow I'm missing something fundamental on Active Response - it 
>> just 
>> >> > does 
>> >> > not work for me. 
>> >> > 
>> >> > I'm working on an ubuntu ossec server V2.8.3 
>> >> > 
>> >> > I want to run an active response on rule 2902. So I changed the 
>> >> > configuration the following way: 
>> >> > 
>> >> >   <command> 
>> >> >     <name>purge-integrity</name> 
>> >> >     <executable>purge-integrity.sh</executable> 
>> >> >     <expect /> 
>> >> >     <timeout_allowed>no</timeout_allowed> 
>> >> >   </command> 
>> >> > 
>> >> > 
>> >> >   <!-- Active Response Config --> 
>> >> >   <active-response> 
>> >> >     <disabled>no</disabled> 
>> >> >     <command>purge-integrity</command> 
>> >> >     <location>server</location> 
>> >> >     <rules_id>2902</rules_id> 
>> >> >   </active-response> 
>> >> > 
>> >> > 
>> >> > 
>> >> > Since I want to run the script on the server, I just modified the 
>> ossec 
>> >> > server. 
>> >> > 
>> >> > I created a script with exec rights: 
>> >> >> ls -l active-response/bin/purge-integrity.sh 
>> >> > -rwxr-xr-x 1 root ossec 363 Jul 28 16:31 
>> >> > active-response/bin/purge-integrity.sh 
>> >> > 
>> >> > 
>> >> > 
>> >> > The script creates a simple entry in logs/active-responses.log: 
>> >> >> active-response/bin/purge-integrity.sh 
>> >> >> cat logs/active-responses.log 
>> >> > Thu Jul 28 16:42:47 CEST 2016 active-response/bin/purge-integrity.sh 
>> >> > 
>> >> > 
>> >> > 
>> >> > After restarting ossec, the active response appears to be available: 
>> >> >> bin/agent_control -L 
>> >> > 
>> >> > 
>> >> > OSSEC HIDS agent_control. Available active responses: 
>> >> > 
>> >> >    Response name: purge-integrity0, command: purge-integrity.sh 
>> >> > 
>> >> > 
>> >> > 
>> >> > (why is there a 0 after purge-integrity?) 
>> >> > 
>> >> > It also appears possible to start the response: 
>> >> >> bin/agent_control -u 000 -b 1.2.3.4 -f purge-integrity 
>> >> > 
>> >> > OSSEC HIDS agent_control: Running active response 'purge-integrity' 
>> on: 
>> >> > 000 
>> >> > 
>> >> >>bin/agent_control -u 000 -b 1.2.3.4 -f purge-integrity0 
>> >> > 
>> >> > OSSEC HIDS agent_control: Running active response 'purge-integrity0' 
>> on: 
>> >> > 000 
>> >> > 
>> >> > 
>> >> > 
>> >> > However, the script is not called and the active-responses.log 
>> remains 
>> >> > unchanged (similarly, nothing happens if rule 2902 fires): 
>> >> > cat logs/active-responses.log 
>> >> > Thu Jul 28 16:42:47 CEST 2016 active-response/bin/purge-integrity.sh 
>> >> > 
>> >> > 
>> >> > 
>> >> > I set the agent to run in debug mode (agent.debug=2 in 
>> >> > internal_options.conf) but do not see related messages in 
>> logs/ossec.log 
>> >> > 
>> >> > At this point, I'm out of ideas on how to further track this down. 
>> So, 
>> >> > how 
>> >> > do I go about further debugging this? 
>> >> > 
>> >> 
>> >> Is ossec-execd running? 
>> > 
>> > 
>> > Yes, it is: 
>> >> ps -A | grep ossec 
>> > 64637 ?        00:00:00 ossec-maild 
>> > 64641 ?        00:00:00 ossec-execd 
>> > 64645 ?        00:00:21 ossec-analysisd 
>> > 64649 ?        00:00:01 ossec-logcollec 
>> > 64654 ?        00:00:18 ossec-remoted 
>> > 64660 ?        00:00:10 ossec-syscheckd 
>> > 64663 ?        00:00:06 ossec-monitord 
>> > 
>> > 
>> > 
>> > 
>> >> 
>> >> Do you use the full paths for files in the script? 
>> > 
>> > 
>> > Not for the binaries - but otherwise yes: 
>> > 
>>
>> Try using the full paths. I don't know what the PATH is for the execd 
>> process. 
>>
>>
> Still no success with the following script:
>
> #!/bin/bash
> # Deletes the checksum table for the integrity upon installs 
> # Author: Dominik Reusser
>
> ACTION=$1
> USER=$2
> IP=$3
> ALERTID=$4
> RULEID=$5
> AGENT=$6
> FILENAME=$7
>
> LOCAL=`/usr/bin/dirname $0`;
> cd $LOCAL
> cd ../
> PWD=`/bin/pwd`
>
> /bin/echo "Hello world" >> /var/ossec/test.log
>
>
> # Logging the call
> /bin/echo "`date` $0 $1 $2 $3 $4 $5 $6 $7 $8" >> ${PWD}/../logs/active-
> responses.log
>
>
>
> bin/agent_control -u 000 -b 1.2.3.4 -f purge-integrity
>
> does not create the expected output.
>
> Can I debug the communication between agent_control and the local process 
> receiving the commands (ossec-execd? are messages created? where?)
> Are active-response calls logged?
> Can I run a service in foreground-mode to receive more messages?
>
> How could I go more basic than this?
>
> Greetings
> Dominik
>
>  
>
>> > #!/bin/bash 
>> > # Deletes the checksum table for the integrity upon installs 
>> > # Author: Dominik Reusser 
>> > 
>> > ACTION=$1 
>> > USER=$2 
>> > IP=$3 
>> > ALERTID=$4 
>> > RULEID=$5 
>> > AGENT=$6 
>> > FILENAME=$7 
>> > 
>> > LOCAL=`dirname $0`; 
>> > cd $LOCAL 
>> > cd ../ 
>> > PWD=`pwd` 
>> > 
>> > echo "Hello world" >> /var/ossec/test.log 
>> > 
>> > 
>> > # Logging the call 
>> > echo "`date` $0 $1 $2 $3 $4 $5 $6 $7 $8" >> 
>> > ${PWD}/../logs/active-responses.log 
>> > 
>> > 
>> > 
>> > 
>> >> 
>> >> > 
>> >> > While I'm posting this problem, I can also share the broader idea: 
>> >> > The messages about changing integrity checksums on every update 
>> makes it 
>> >> > hard to detect real issues. To avoid these messages, I had the 
>> following 
>> >> > idea: 
>> >> > 
>> >> > rule 2902 is triggered when software is installed. I can use active 
>> >> > response 
>> >> > to remember the system on which new software is installed. After 
>> some 
>> >> > delay, 
>> >> > I would then (for example with a cron job) run 
>> >> >  /var/ossec/bin/syscheck_control -u AGENT_ID 
>> >> > 
>> >> > as suggested on the FAQ: 
>> >> > 
>> >> > 
>> http://ossec-docs.readthedocs.io/en/latest/manual/syscheck/#how-do-i-stop-syscheck-alerts-during-system-updates
>>  
>> >> > 
>> >> > Does anybody have experience with connecting rule 2902 to purging 
>> the 
>> >> > database with integrity check sums? 
>> >> > 
>> >> > -- 
>> >> > 
>> >> > --- 
>> >> > You received this message because you are subscribed to the Google 
>> >> > Groups 
>> >> > "ossec-list" group. 
>> >> > To unsubscribe from this group and stop receiving emails from it, 
>> send 
>> >> > an 
>> >> > email to [email protected]. 
>> >> > For more options, visit https://groups.google.com/d/optout. 
>> > 
>> > -- 
>> > 
>> > --- 
>> > You received this message because you are subscribed to the Google 
>> Groups 
>> > "ossec-list" group. 
>> > To unsubscribe from this group and stop receiving emails from it, send 
>> an 
>> > email to [email protected]. 
>> > For more options, visit https://groups.google.com/d/optout. 
>>
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to