On Thu, Sep 8, 2016 at 11:08 AM, Dominik <[email protected]> wrote: > 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. >
What do you mean? How did you disable the active responses for those commands? You removed the "<active-response>" blocks referencing those commands? > > 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. -- --- 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.
