Pardon my inability to reply to the original post, but I just subscribed. Here is the version of the script I am considering, but have questions about. iptables -A INPUT -p tcp --dport 22 -s ! $My_Home_Firewall_IP -m state --state NEW -m recent --name SSH --set --rsource -j SSH_BF iptables -A SSH_BF -m recent ! --rcheck --seconds 60 --hitcount 3 --name SSH --rsource -j RETURN iptables -A SSH_BF -j LOG --log-prefix "SSH Brute Force Attempt: " iptables -A SSH_BF -p tcp -j TARPIT (1) First of all, why should there be a -p tcp in the TARPIT line? Somewhere in the original thread I think there was mention of nonTCP packets that would get into the script and that such packets shouldn't get dropped, but the rule that jumps to our SSH_BF script only matches TCP packets anyway. Looks like something's wrong if nonTCP packets get to the chain at all. (2) Next, people interested in implementing this sort of protection might consider changing the duration and number of matches. For example, the current 60:3 settings allow a total of 180 attempts in an hour but only in bursts of three per minute. We can consider two classes of people attempting to connect to the server: brute force attackers and legitimate scripts and human users. In the former case, attempts per unit time as time goes to infinity is what they are concerned about. In the latter case, access is usually bursty. Consider allowing 50 matches every hour, as in iptables -A SSH_Brute_Force -m recent ! --rcheck --seconds 3600 --hitcount 50 --name SSH --rsource -j RETURN Now attackers have fewer than a third of the attacks per hour they can mount on the system, but chatty backup scripts or admins are allowed the bursty access (like opening 5 shells/scp streams at once) that they might sometimes need or like to use. (Whether this legitimate but potentially disruptive behavior should be allowed is another thing.) (3) Also, is this the only position for the negation that makes the rule work as intended? It seems to say "Allow/return packets where it isn't the case that we've seen more than or equal to three connection attempts in the last 60 seconds." To me, the following is more intuitive: iptables -A SSH_Brute_Force -m recent --rcheck --seconds 60 ! --hitcount 3 --name SSH --rsource -j RETURN which reads "Allow/return packets from sources that have attempted connections less than three times in the past 60 seconds." This is totally a subjective preference, but in the interest of learning how the recent match really works and avoiding stupid mistakes, I want to verify that this revised rule would have the same effect in the context of this chain. Thanks!
