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