Hack and crack proof SSH on Linux

User Rating: / 15
PoorBest 

by David M Williams

Friday, 03 August 2007

Page 2 of 3 iptables – plan A Fortunately, all modern Linux distros come standard with a built-in firewall package known as netfilter/iptables. Netfilter is the framework that interacts with the kernel to inspect network packets; iptables is a firewall component which uses netfilter to filter packets based on specified rules. (Previously, the predominant package for this purpose was ipchains.) Related stories Dell records boom growth in Asia Pac and Japan Broadcom backs 60GHz ultra broadband networking group Microsoft investment shows all is not well at Novell Google Gears up Safari support How Windows Vista is turning people to Linux Well and good, but unfortunately, iptables has no built-in rules to protect against brute force attacks. It’s installed, but it’s just sitting there idle. Recently, Kevin van Zonneveld faced this very problem. He solved his issue with two dead simple iptables rules that everyone can use. These are: sudo iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH sudo iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 8 --rttl --name SSH -j DROP This pair of commands rate-limits all incoming SSH connections to eight per minute. A valid user who knows their username and password won’t be inconvenienced at all, but brute-force crackers will have their connection attempts – each being a try at a username and password – dropped right down to eight from the lofty number otherwise offered by high-speed data networks. You can use iptables –L at any time to list your firewall rules and you can use iptables –F at any time to flush the rules. It’s definitely worthwhile checking Kevin’s blog for more detail on his rules, including how to make them take effect upon system boot. iptables – Plan B The rules above are clear and concise. The problem is they don’t really send a strong message to the cracker to go away. 2020Code strive for more protection with stricter iptables rules: -N SSH -N SSH_ABL -A SSH -m recent --name SSH_ABL --update --seconds 3600 -j REJECT -A SSH -m recent --name SSH --rcheck --seconds 60 --hitcount 5 -j SSH_ABL -A SSH_ABL -m recent --name SSH_ABL --set -j LOG --log-level warn --log-prefix "ABL: +SSH: " -A SSH_ABL -j REJECT -A SSH -m recent --name SSH --rcheck --seconds 2 -j LOG --log-level warn --log-prefix "RATE: " -A SSH -m recent --name SSH --update --seconds 2 -j REJECT -A SSH -m recent --name SSH_ABL --remove -j LOG --log-level warn --log-prefix "ABL: -SSH: " -A SSH -m recent --name SSH --set -j ACCEPT -A INPUT -m state --state NEW -p tcp -m tcp --dport 22 -j SSH The net effect of these rules is threefold. Firstly, a two-second pause is forced between successive SSH connections from the same host, slowing down login attempts. Secondly, if the same host attempts (and fails) connection five times within the span of one minute, the host is automatically blacklisted. Thirdly, this block lapses after a full hour passes with no connection attempts from the host. This is much more industrial strength. Now the cracker only gets five chances every sixty-one minutes. They’ll soon move on to other grounds. The downside is fat-fingered legitimate users can potentially lock themselves out, and this is especially problematic if you have possibly many users from behind a NAT’d network who legitimately need to connect to your system and some of the users are slightly forgetful or password-challenged. << First page <   1 2 3 Next page > Last page - Post your comment >>

 

< Next story in category		Previous story in the category >