Comments on: Stopping SSH Brute Force Attacks http://www.longren.org/stopping-ssh-brute-force-attacks/ Certified & Decorated Thu, 09 Feb 2012 16:01:05 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: kruku http://www.longren.org/stopping-ssh-brute-force-attacks/comment-page-1/#comment-225333 kruku Fri, 19 Dec 2008 08:44:53 +0000 http://www.longren.org/2006/08/21/stopping-ssh-brute-force-attacks/#comment-225333 Yeo fail2ban do what must to do :) Yeo
fail2ban do what must to do :)

]]> By: Claudio http://www.longren.org/stopping-ssh-brute-force-attacks/comment-page-1/#comment-134720 Claudio Tue, 23 Oct 2007 05:07:33 +0000 http://www.longren.org/2006/08/21/stopping-ssh-brute-force-attacks/#comment-134720 guys, it's quite easy to avoid this entirely yes, you can go about installing scripts to do the job (deny.hosts, bruteforce blocker, sshdfilter, sshdguard) or you can just get rid of password-authentication altogether (My solution.) Use two-form factor authentication (private/public key) exchange instead. use PuttyGen to generate the keys, or ssh-keygen on Unix, and put them in /etc/ssh/sshd_host_dsa_key or $HOME/.ssh/authorized_keys2 (or whatever is specified in /etc/ssh/sshd_config) ... this way, brute-force wordlists attempts are thwarted... also, consider changing the default sshd port, from 22 to something high. i chose 12586. third, why not get rid of sshd entirely if you're the only one administering the server?? you can install webmin instead. Now you can administer your server through a browser GUI. guys, it’s quite easy to avoid this entirely

yes, you can go about installing scripts to do the job (deny.hosts, bruteforce blocker, sshdfilter, sshdguard) or you can just get rid of password-authentication altogether (My solution.) Use two-form factor authentication (private/public key) exchange instead. use PuttyGen to generate the keys, or ssh-keygen on Unix, and put them in /etc/ssh/sshd_host_dsa_key or $HOME/.ssh/authorized_keys2 (or whatever is specified in /etc/ssh/sshd_config) … this way, brute-force wordlists attempts are thwarted… also, consider changing the default sshd port, from 22 to something high. i chose 12586. third, why not get rid of sshd entirely if you’re the only one administering the server?? you can install webmin instead. Now you can administer your server through a browser GUI.

]]> By: Ed http://www.longren.org/stopping-ssh-brute-force-attacks/comment-page-1/#comment-45281 Ed Fri, 16 Mar 2007 23:11:57 +0000 http://www.longren.org/2006/08/21/stopping-ssh-brute-force-attacks/#comment-45281 I've hacked together a similar script myself, that scans the logs and adds ips to iptables on the fly. Although it was a fun project, I have come to the obvious conclusion that it is always better to adopt a deny all by default policy on your firewall and just open it up for ips that you will be connecting from. The other method, which is brilliant, is called port knocking that involves running a sniffer that listens for a 'magic' packet and then opens up port 22(or whatever) as and when. I’ve hacked together a similar script myself, that scans the logs and adds ips to iptables on the fly. Although it was a fun project, I have come to the obvious conclusion that it is always better to adopt a deny all by default policy on your firewall and just open it up for ips that
you will be connecting from. The other method, which is brilliant, is called port knocking that involves running a sniffer that listens for a ‘magic’ packet and then opens up port 22(or whatever) as and when.

]]> By: Scott http://www.longren.org/stopping-ssh-brute-force-attacks/comment-page-1/#comment-30254 Scott Thu, 24 Aug 2006 03:21:58 +0000 http://www.longren.org/2006/08/21/stopping-ssh-brute-force-attacks/#comment-30254 I was fed up with ssh brute force attacks, but I didn't want to install software to automate blocking via iptables (I really think this should be an option in sshd itself). Instead, I've configured sshd on *all* of the systems I'm responsible for to listen on a single port that is not port 22. You'd think this would be a hassle, as there are some machines that I don't have control over that still listen on port 22. Instead of specifying the -p flag when connecting when using ssh clients, I simply added entries to my .ssh/config file so that the hosts listening on other the other port had the Port parameter set properly. This means I can connect to port 22 or the 'other port' completely transparently. In one year, I have had ZERO brute force attacks. I was fed up with ssh brute force attacks, but I didn’t want to install software to automate blocking via iptables (I really think this should be an option in sshd itself). Instead, I’ve configured sshd on *all* of the systems I’m responsible for to listen on a single port that is not port 22. You’d think this would be a hassle, as there are some machines that I don’t have control over that still listen on port 22. Instead of specifying the -p flag when connecting when using ssh clients, I simply added entries to my .ssh/config file so that the hosts listening on other the other port had the Port parameter set properly. This means I can connect to port 22 or the ‘other port’ completely transparently. In one year, I have had ZERO brute force attacks.

]]> By: More SSH Brute Force Protection at T. Longren http://www.longren.org/stopping-ssh-brute-force-attacks/comment-page-1/#comment-30252 More SSH Brute Force Protection at T. Longren Thu, 24 Aug 2006 01:18:06 +0000 http://www.longren.org/2006/08/21/stopping-ssh-brute-force-attacks/#comment-30252 [...] Stopping SSH Brute Force Attacks resulted in some really great comments and suggestions from readers. [...] [...] Stopping SSH Brute Force Attacks resulted in some really great comments and suggestions from readers. [...]

]]> By: Tyler http://www.longren.org/stopping-ssh-brute-force-attacks/comment-page-1/#comment-30240 Tyler Wed, 23 Aug 2006 13:03:57 +0000 http://www.longren.org/2006/08/21/stopping-ssh-brute-force-attacks/#comment-30240 Ilan Schnell, I really like that option as it gives an instant look at what IP's have been attempting to login. Any chance I could get the script you use to generate that page? Ilan Schnell, I really like that option as it gives an instant look at what IP’s have been attempting to login. Any chance I could get the script you use to generate that page?

]]> By: Ilan Schnell http://www.longren.org/stopping-ssh-brute-force-attacks/comment-page-1/#comment-30236 Ilan Schnell Wed, 23 Aug 2006 07:16:14 +0000 http://www.longren.org/2006/08/21/stopping-ssh-brute-force-attacks/#comment-30236 From October 2005 until May 2006 I was at Georgetown University and had a machine which was online 24/7 with the same IP. I also noticed SSH attacks, and wrote a small script to get an overview of the IPs used by the attacker(s) and the login names being tryed. Here is a link to my overview: <a href="http://ilan.schnell-web.net/test/ssh.html" rel="nofollow">http://ilan.schnell-web.net/test/ssh.html</a> Notice that sometimes the same login names are tryed on different day from diffenrt IPs, so the attacker uses the same script. From October 2005 until May 2006 I was at Georgetown University and had a
machine which was online 24/7 with the same IP. I also noticed SSH attacks,
and wrote a small script to get an overview of the IPs used by the attacker(s)
and the login names being tryed. Here is a link to my overview:
http://ilan.schnell-web.net/test/ssh.html

Notice that sometimes the same login names are tryed on different day from diffenrt IPs,
so the attacker uses the same script.

]]> By: pwyll http://www.longren.org/stopping-ssh-brute-force-attacks/comment-page-1/#comment-30224 pwyll Wed, 23 Aug 2006 01:51:14 +0000 http://www.longren.org/2006/08/21/stopping-ssh-brute-force-attacks/#comment-30224 A complementary approach is configure sshd to require crytographic keys instead of passwords. No amount of brute force would suffice to guess a key. Properly set up, this approach is actually more convenient (IMO) than passwords. The setup is nicely explained at <a href="http://kimmo.suominen.com/docs/ssh/" rel="nofollow">Setting up ssh</a> A complementary approach is configure sshd to require crytographic keys instead of passwords. No amount of brute force would suffice to guess a key. Properly set up, this approach is actually more convenient (IMO) than passwords. The setup is nicely explained at Setting up ssh

]]> By: kuriharu http://www.longren.org/stopping-ssh-brute-force-attacks/comment-page-1/#comment-30217 kuriharu Tue, 22 Aug 2006 17:18:26 +0000 http://www.longren.org/2006/08/21/stopping-ssh-brute-force-attacks/#comment-30217 Looks good. I'm using a program called authfail that does the same thing, and it's also written in PERL. Looks good. I’m using a program called authfail that does the same thing, and it’s also written in PERL.

]]> By: Tyler http://www.longren.org/stopping-ssh-brute-force-attacks/comment-page-1/#comment-30215 Tyler Tue, 22 Aug 2006 15:52:17 +0000 http://www.longren.org/2006/08/21/stopping-ssh-brute-force-attacks/#comment-30215 Thanks for the info Canuck! Fail2Ban looks great!! I am probably going to switch my breakinguard box over to Fail2Ban simply because Fail2Ban looks like it still gets regular updates, where breakinguard does not. Many thanks for the link! Thanks for the info Canuck! Fail2Ban looks great!! I am probably going to switch my breakinguard box over to Fail2Ban simply because Fail2Ban looks like it still gets regular updates, where breakinguard does not.

Many thanks for the link!

]]>