Hi Andre,

yes, unfortunately it happened again last night. But I couldn't find
anything strange in the logs. The log just stopped until I flushed the
IPTABLES and restarted OSSEC.

The List was huge - but I think this was because a mistake of my edit.
I should insert my "echo ... >> logfile" before executing the IPTABLES
string and not afterwards and before RES=$?. So the rules couldn't be
deleted, if iptables raises an error, because it won't repeat.

Now I edited the file again to this way: (I checked it and it is
working as it should).

   COUNT=0;
   while [ 1 ]; do
       echo ".."

        echo "[1] `date` $IPTABLES $ARG1" >> /root/ossec-execlog.log

        ${IPTABLES} ${ARG1} >>/root/ossec-execlog.log 2>&1

        RES=$?

        if [ $RES = 0 ]; then
            break;
        else
            COUNT=`expr $COUNT + 1`;
            echo "`date` Unable to run (iptables returning != $RES):
$COUNT - $0 $1 $2 $3 $4 $5" >> ${PWD}/../logs/active-responses.log
            sleep $COUNT;

            if [ $COUNT -gt 4 ]; then
                break;
            fi
        fi
   done

   while [ 1 ]; do

        echo "[2] `date` $IPTABLES $ARG2" >> /root/ossec-execlog.log
        ${IPTABLES} ${ARG2} >>/root/ossec-execlog.log 2>&1

        RES=$?

        if [ $RES = 0 ]; then
            break;
        else
            COUNT=`expr $COUNT + 1`;
            echo "`date` Unable to run (iptables returning != $RES):
$COUNT - $0 $1 $2 $3 $4 $5" >> ${PWD}/../logs/active-responses.log
            sleep $COUNT;

            if [ $COUNT -gt 4 ]; then
                break;
            fi
        fi
   done

And finally I cached already some "iptables: Resource temporarily
unavailable".

I wonder, if it is propably possible, that IPTABLES just have unter
some circumstances an internal problem and set up an 0.0.0.0/0 instead
of the given IP? Is there something known about?

btw: Kernel: 2.6.26-1-openvz-amd64

Greetings,

Oskar

Reply via email to