{"id":19,"date":"2005-08-19T18:22:05","date_gmt":"2005-08-19T22:22:05","guid":{"rendered":"http:\/\/blogs.law.harvard.edu\/zeroday\/2005\/08\/19\/joys-of-administration-blocking-ssh-b"},"modified":"2005-08-19T18:22:05","modified_gmt":"2005-08-19T22:22:05","slug":"joys-of-administration-blocking-ssh-brute-force","status":"publish","type":"post","link":"https:\/\/archive.blogs.harvard.edu\/zeroday\/2005\/08\/19\/joys-of-administration-blocking-ssh-brute-force\/","title":{"rendered":"Joys of Administration: Blocking SSH brute force"},"content":{"rendered":"

<\/a><\/p>\n

There are some excellent articles out there on how to keep your servers from allowing brute force tactics. Brute forcing an SSH server is fairly simple. Setup a bot to try a dictionary worth of passwords against some common usernames. My logs were filled with these attempts.
\nAside from obvious password policy rules there are some other nifty ideas to limit the damage here. I don’t think anyone will succeed in brute forcing the passwords I choose but I’m still not setup to use certificates for authentication. This is perhaps the best way to defeat this type of brute force attack of course.
\nThe article I’ve listed shows a method of using iptables to limit the amount of incoming attempts for the ssh protocol.
\nThe two rules below check when a new connection for port 22 (the default sshd port) is established and if the hit count for logins exceeds 10 in one minute the IP is dropped. <\/p>\n

iptables -I INPUT -p tcp –dport 22 -i eth0 -m state –state NEW -m recent –set
\n<\/i><\/p>\n

iptables -I INPUT -p tcp –dport 22 -i eth0 -m state –state NEW -m recent –update –seconds 60 –hitcount 11 -j DROP<\/i><\/p>\n

To tweak these settings you can try adjusting the –hitcount<\/b> parameter and the –seconds<\/b> parameter.<\/p>\n

This is not bulletproof. If the attacker has a bot army then each zombie can send one or two password attempts and then shift IP and let the next bot try three and four, then shift again, etc.
\nThat’s a fairly complicated attack and if someone is that organized and attacking you trouble is coming regardless. Again the best thing to do would be:
\n1) use cert authentication only
\n2) add your ip’s into ssh.allow<\/p>\n","protected":false},"excerpt":{"rendered":"

There are some excellent articles out there on how to keep your servers from allowing brute force tactics. Brute forcing an SSH server is fairly simple. Setup a bot to try a dictionary worth of passwords against some common usernames. My logs were filled with these attempts. Aside from obvious password policy rules there are […]<\/p>\n","protected":false},"author":214,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[],"tags":[],"class_list":["post-19","post","type-post","status-publish","format-standard","hentry"],"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/archive.blogs.harvard.edu\/zeroday\/wp-json\/wp\/v2\/posts\/19","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/archive.blogs.harvard.edu\/zeroday\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/archive.blogs.harvard.edu\/zeroday\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/archive.blogs.harvard.edu\/zeroday\/wp-json\/wp\/v2\/users\/214"}],"replies":[{"embeddable":true,"href":"https:\/\/archive.blogs.harvard.edu\/zeroday\/wp-json\/wp\/v2\/comments?post=19"}],"version-history":[{"count":0,"href":"https:\/\/archive.blogs.harvard.edu\/zeroday\/wp-json\/wp\/v2\/posts\/19\/revisions"}],"wp:attachment":[{"href":"https:\/\/archive.blogs.harvard.edu\/zeroday\/wp-json\/wp\/v2\/media?parent=19"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/archive.blogs.harvard.edu\/zeroday\/wp-json\/wp\/v2\/categories?post=19"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/archive.blogs.harvard.edu\/zeroday\/wp-json\/wp\/v2\/tags?post=19"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}