Hello, My organization is currently under an ssh brute force attack (over a week in duration, so far). We are encountering a problem with the firewall-drop.sh script and iptables under RHE and SuSE.
First, we have increased the active response duration from 10 minutes to 24 hours because the attacker is re-using IP addresses. We are seeing something like a memory leak in a program. If we shut down the OSSEC agent on a RHE or SuSE host, we are seeing a lot of rules still in the iptables filter table when there should be none since the agent terminates all active responses when it shuts down. We are seeing something similar on our OSSEC server which runs on a RHE host. Meanwhile, this problem does not appear on our Solaris hosts running OSSEC agents. I investigated the firewall-drop.sh script and found that when the OS is Linux, the script retries 5 times both for adding a rule to the input and forward chains and for removing a rule from the input and forward chains. Under Solaris and AIX no such retry or error detection scheme is used. During the brute force attack, I monitored the active-response logs on agents running under SuSE and RHE. There were frequent times when this retry mechanism was activated, sometimes running out of the 5 retry attempts on one or both chains. Is iptables not synchronous? Is that why the retry logic exists in firewall-drop.sh? Is ipf (Solaris equivalent) synchronous? Is that why there is no retry logic or even error checking logic in firewall-drop.sh? I have tried to remedy the situation by wrapping a flock() around the Linux part of firewall-drop.sh. So far, this fix seems to be working. Does anyone else have similar experiences with iptables in a busy environment such as an ssh brute force attack? Thanks, Trevor
