Even tho /some/ of the technical stuff eludes me, I've tried to follow this thread.
I set up ssh for myself (I own the machines); I haven't yet actually made a connection (probably will this weekend).
I'd like to know what threats exits for ssh - are there webpages that discuss this? I *thought* that using an arbitrary port and putting 'AllowUsers ...' into sshd_config would handle these things (along with a password other than 'abcd' :) ).
Michael Klinosky mpk2@enter.net writes:
I'd like to know what threats exits for ssh - are there webpages that discuss this? I *thought* that using an arbitrary port and putting 'AllowUsers ...' into sshd_config would handle these things (along with a password other than 'abcd' :) ).
The problem with passwords is that you have to trust all your users to pick good ones that aren't in any attacker's dictionary. The only somewhat safe passwords are the ones that are computer generated random numbers/letters/symbols. All the others that are easy to remember for users are potential candidates for someone to put into a dictionary of passwords to try. You are in effect betting that your passwords all aren't in any attacker's dictionary yet.
If you are going to go to computer generated numbers/letters/symbols for somewhat strong passwords, you might as will go all the way and let your computer generate a 1 kbit long password for you called RSA. The attackers aren't going to be able to guess that in reasonable time and the computer has all the machinery in place to remember that 1k password for you automatically, so you never ever have to ever memorize it.
I already posted this in a different sub-thread, but I'll repeat it here. This is how to setup sshd for RSA/DSA only and avoid any password guessing attacks: http://www.wsrcc.com/wolfgang/sshd-config.html
-wolfgang
El Sábado, 26 de Mayo de 2007 16:25, Wolfgang S. Rupprecht escribió:
Michael Klinosky mpk2@enter.net writes:
I'd like to know what threats exits for ssh - are there webpages that discuss this? I *thought* that using an arbitrary port and putting 'AllowUsers ...' into sshd_config would handle these things (along with a password other than 'abcd' :) ).
The problem with passwords is that you have to trust all your users to pick good ones that aren't in any attacker's dictionary. The only somewhat safe passwords are the ones that are computer generated random numbers/letters/symbols. All the others that are easy to remember for users are potential candidates for someone to put into a dictionary of passwords to try. You are in effect betting that your passwords all aren't in any attacker's dictionary yet.
If you want to keep all your systems and users password under control, and this mean, to know when some user choose a weak or a password which matchs a dictionary word, you might want to take a look at Babel Enterprise http://babel.sf.net it's quite useful for all those administrators who wanna to keep all the system security in just one webpage (a webconsole, basically)
Cheers
On Sat, 2007-05-26 at 09:17 -0400, Michael Klinosky wrote:
Even tho /some/ of the technical stuff eludes me, I've tried to follow this thread.
I set up ssh for myself (I own the machines); I haven't yet actually made a connection (probably will this weekend).
I'd like to know what threats exits for ssh - are there webpages that discuss this? I *thought* that using an arbitrary port and putting 'AllowUsers ...' into sshd_config would handle these things (along with a password other than 'abcd' :) ).
The best thing I've found to protect against brute-force SSH attacks is something called fail2ban:
http://www.fail2ban.org/wiki/index.php/Main_Page
It watches your log files for failed attempts to gain access through services like SSH, VSFTPD, and Apache. If it sniffs trouble, it issues an IPTables command to ban the offending IP. The configuration files allow you to set the threshold for action as well as the punishment to dish out. It will even email you to let you know what has happened.
You can find it in RPM form for RHEL and Fedora. I highly recommend it because it's simple and effective.
Tom
Tom Rivers tom@impact-crater.com writes:
The best thing I've found to protect against brute-force SSH attacks is something called fail2ban:
Such programs help you save the CPU time of sshd answering the connection from a single abusive host, but would do little against a distributed botnet attack. Luckily botnets aren't really used against sshd yet, but it they were you'd potentially be seeing distributed guessing attacks from 10,000 different hosts. If they all took turns to guess a single password in round-robin fashion, the filters would never trip. I don't know if any of the attacking hosts are cooperating, but I already see a few time-adaptive attacks, where the attacker returns after an increasing amount of time to try to stay under the wire.
(Right now spam pays off more, so the money is in using botnets to send direct spam. At some point it may pay off more to use compromised sshd hosts, so the economics may change.)
-wolfgang
On Sat, 2007-05-26 at 13:16 -0700, Wolfgang S. Rupprecht wrote:
Such programs help you save the CPU time of sshd answering the connection from a single abusive host, but would do little against a distributed botnet attack. Luckily botnets aren't really used against sshd yet, but it they were you'd potentially be seeing distributed guessing attacks from 10,000 different hosts. If they all took turns to guess a single password in round-robin fashion, the filters would never trip.
You're right. What do you recommend to protect against this sort of attack?
Tom
On Sun, May 27, 2007 at 08:02:29 -0400, Tom Rivers tom@impact-crater.com wrote:
On Sat, 2007-05-26 at 13:16 -0700, Wolfgang S. Rupprecht wrote:
Such programs help you save the CPU time of sshd answering the connection from a single abusive host, but would do little against a distributed botnet attack. Luckily botnets aren't really used against sshd yet, but it they were you'd potentially be seeing distributed guessing attacks from 10,000 different hosts. If they all took turns to guess a single password in round-robin fashion, the filters would never trip.
You're right. What do you recommend to protect against this sort of attack?
A good relationship with your ISP. 10K hosts could just swamp your link and you will need upstream help to block it before it gets to your link. If you are worried about slow guessing attacks from multiple IPs, the same advice previously give will work. Either use strong passwords or public keys for authentication. (Presumably, if you are asking this question there isn't a small set of IP address that legitimate ssh connections can come from.)
Tom Rivers tom@impact-crater.com writes:
On Sat, 2007-05-26 at 13:16 -0700, Wolfgang S. Rupprecht wrote:
Such programs help you save the CPU time of sshd answering the connection from a single abusive host, but would do little against a distributed botnet attack. Luckily botnets aren't really used against sshd yet, but it they were you'd potentially be seeing distributed guessing attacks from 10,000 different hosts. If they all took turns to guess a single password in round-robin fashion, the filters would never trip.
You're right. What do you recommend to protect against this sort of attack?
There are two things to defend against, 1) attackers actually guessing a working password 2) the system resources wasted answering the attacks.
For the first one is easily taken care of by having the computer pick a random number as a password for you. Remembering and typing gibberish passwords is hard, so it is best to have the computer's machinery do the drudge work. This is what ssh's RSA (and DSA) mechanism does. It chooses a 1kbit long password for you and effectively stores it for you so you never have to type it. It then encrypts that 1kbit password with a "human" password you chose. This password can be a really *bad* password (pets name, mother's maiden name etc.) without any ill effects. The human-password is never used by ssh for anything but decoding it's 1k-bit password on the local machine when ssh starts up. The 1k-bit password is the one ssh uses "on the wire". The fact that the attacker now has to guess the 1kbit password is what makes the whole thing so safe. Doing an exhaustive search on that takes many, many times the life of the universe.
(I didn't want to post this link in the last message, I've posted it twice already and was afraid someone would think I was spamming the same link repeatedly. SSH RSA setup: http://www.wsrcc.com/wolfgang/sshd-config.html )
As for the defense against the DDOS resource exhaustion of a theoretical botnet sshd attack. I'm not sure you can do much but try to change your IP address. Ultimately legislation will probably be needed to fine the fools running virus-riddled computers that are supplying the computer workforce for the botnets.
-wolfgang
On Sun, 2007-05-27 at 08:59 -0700, Wolfgang S. Rupprecht wrote:
Tom Rivers tom@impact-crater.com writes:
On Sat, 2007-05-26 at 13:16 -0700, Wolfgang S. Rupprecht wrote:
Such programs help you save the CPU time of sshd answering the connection from a single abusive host, but would do little against a distributed botnet attack. Luckily botnets aren't really used against sshd yet, but it they were you'd potentially be seeing distributed guessing attacks from 10,000 different hosts. If they all took turns to guess a single password in round-robin fashion, the filters would never trip.
You're right. What do you recommend to protect against this sort of attack?
There are two things to defend against, 1) attackers actually guessing a working password 2) the system resources wasted answering the attacks.
For the first one is easily taken care of by having the computer pick a random number as a password for you. Remembering and typing gibberish passwords is hard, so it is best to have the computer's machinery do the drudge work. This is what ssh's RSA (and DSA) mechanism does. It chooses a 1kbit long password for you and effectively stores it for you so you never have to type it. It then encrypts that 1kbit password with a "human" password you chose. This password can be a really *bad* password (pets name, mother's maiden name etc.) without any ill effects. The human-password is never used by ssh for anything but decoding it's 1k-bit password on the local machine when ssh starts up. The 1k-bit password is the one ssh uses "on the wire". The fact that the attacker now has to guess the 1kbit password is what makes the whole thing so safe. Doing an exhaustive search on that takes many, many times the life of the universe.
(I didn't want to post this link in the last message, I've posted it twice already and was afraid someone would think I was spamming the same link repeatedly. SSH RSA setup: http://www.wsrcc.com/wolfgang/sshd-config.html )
As for the defense against the DDOS resource exhaustion of a theoretical botnet sshd attack. I'm not sure you can do much but try to change your IP address. Ultimately legislation will probably be needed to fine the fools running virus-riddled computers that are supplying the computer workforce for the botnets.
Hi, Wolfgang, I am sur e you didn't mean to insult the folks who use our efforts, the users, but instead the designers of the bots themselves should be the ones in deep trouble. Even those who study and work dilligently at defense get hacked sometimes via the combination of total effort expended against them, and the fact that the hackers only need to "get it right once" as has been said by Rumsfeld in connection with terrorists. I believe that it is possible to have good security and still get hit. I mean, we have had banks for thousands of years, and they still get robbed. Do we blame the bankers?
Regards, Les H
On Sun, May 27, 2007 at 09:50:06 -0700, Les hlhowell@pacbell.net wrote:
Hi, Wolfgang, I am sur e you didn't mean to insult the folks who use our efforts, the users, but instead the designers of the bots themselves should be the ones in deep trouble. Even those who study and work dilligently at defense get hacked sometimes via the combination of total effort expended against them, and the fact that the hackers only need to "get it right once" as has been said by Rumsfeld in connection with terrorists. I believe that it is possible to have good security and still get hit. I mean, we have had banks for thousands of years, and they still get robbed. Do we blame the bankers?
People can still be held responsible for being negligent. I'd actually like to see the ISPs held more accountable. They don't have a lot of incentive to cut their own users off as they will either leave or need more help desk support than they are worth to keep as customers.
Les hlhowell@pacbell.net writes:
Hi, Wolfgang, I am sur e you didn't mean to insult the folks who use our efforts, the users, but instead the designers of the bots themselves should be the ones in deep trouble.
Les, the number of bots running on DSL and cable modems is totally out of control. I'm seeing many hundreds of thousands of connection attempts per month to the SMTP port for spammers buying services from bot-masters that are trying to stuff my mailbox. The time for ignoring the user's culpability in this is long over.
Even those who study and work dilligently at defense get hacked sometimes via the combination of total effort expended against them, and the fact that the hackers only need to "get it right once" as has been said by Rumsfeld in connection with terrorists. I believe that it is possible to have good security and still get hit. I mean, we have had banks for thousands of years, and they still get robbed. Do we blame the bankers?
People that run virus riddled systems for the most part aren't folks hit by zero-day exploits for code that has been inspected by competent eyes and simply had something slip by. We are talking about gross negligence with systems that haven't been maintained and updated in years. This collective negligence is costing other folks substantial amounts in bandwidth and time spent to deal with resource exhaustion issues.
A system of stiff fines (such as used to prevent operation of unsafe automobiles) will do wonders to light a fire under folks to keep their systems up to current standards.
-wolfgang
On Sunday 27 May 2007, Wolfgang S. Rupprecht wrote:
A system of stiff fines (such as used to prevent operation of unsafe automobiles) will do wonders to light a fire under folks to keep their systems up to current standards.
That is assuming that those who can do something about it actually want the systems effected to be secured so no one can access the system without the owners knowledge. Maybe they like it that people can be monitored through their computer without their knowledge. The government is all about gaining more control over the citizens' lives especially when the citizen does not know about it. That makes for less resistance from the citizen.
On Sun, 2007-05-27 at 10:54 -0700, Wolfgang S. Rupprecht wrote:
Les hlhowell@pacbell.net writes:
Hi, Wolfgang, I am sur e you didn't mean to insult the folks who use our efforts, the users, but instead the designers of the bots themselves should be the ones in deep trouble.
Les, the number of bots running on DSL and cable modems is totally out of control. I'm seeing many hundreds of thousands of connection attempts per month to the SMTP port for spammers buying services from bot-masters that are trying to stuff my mailbox. The time for ignoring the user's culpability in this is long over.
Even those who study and work dilligently at defense get hacked sometimes via the combination of total effort expended against them, and the fact that the hackers only need to "get it right once" as has been said by Rumsfeld in connection with terrorists. I believe that it is possible to have good security and still get hit. I mean, we have had banks for thousands of years, and they still get robbed. Do we blame the bankers?
People that run virus riddled systems for the most part aren't folks hit by zero-day exploits for code that has been inspected by competent eyes and simply had something slip by. We are talking about gross negligence with systems that haven't been maintained and updated in years. This collective negligence is costing other folks substantial amounts in bandwidth and time spent to deal with resource exhaustion issues.
A system of stiff fines (such as used to prevent operation of unsafe automobiles) will do wonders to light a fire under folks to keep their systems up to current standards.
-wolfgang
Wolfgang S. Rupprecht http://www.wsrcc.com/wolfgang/ Hints for IPv6 on FC6 http://www.wsrcc.com/wolfgang/fedora/ipv6-tunnel.html
But the true cost of those fines is the increase in the cost of the automobile, automobile insurance, and so forth. Nothing is free. If there are no users, we won't have a job, nor would this be as interesting and varied as it is today. Get the writers of this nonsense. Hang a couple of bot writers publically, make the penalty irreversible and things will improve immediately far better than ragging on the users. Get windows to patch their security, make users not admins by default, and make the systems tighter will do far more with less effort and not hurt the folks that pay our way.
Regards, Les H
On Sun, 2007-05-27 at 09:50 -0700, Les wrote:
we have had banks for thousands of years, and they still get robbed. Do we blame the bankers?
Yes, if they don't make any sensible efforts to make it hard to rob them.
From: "Wolfgang S. Rupprecht" wolfgang.rupprecht+gnus200705@gmail.com
Tom Rivers tom@impact-crater.com writes:
On Sat, 2007-05-26 at 13:16 -0700, Wolfgang S. Rupprecht wrote:
Such programs help you save the CPU time of sshd answering the connection from a single abusive host, but would do little against a distributed botnet attack. Luckily botnets aren't really used against sshd yet, but it they were you'd potentially be seeing distributed guessing attacks from 10,000 different hosts. If they all took turns to guess a single password in round-robin fashion, the filters would never trip.
You're right. What do you recommend to protect against this sort of attack?
There are two things to defend against, 1) attackers actually guessing a working password 2) the system resources wasted answering the attacks.
For the first one is easily taken care of by having the computer pick a random number as a password for you. Remembering and typing gibberish passwords is hard, so it is best to have the computer's machinery do the drudge work. This is what ssh's RSA (and DSA) mechanism does. It chooses a 1kbit long password for you and effectively stores it for you so you never have to type it. It then encrypts that 1kbit password with a "human" password you chose. This password can be a really *bad* password (pets name, mother's maiden name etc.) without any ill effects. The human-password is never used by ssh for anything but decoding it's 1k-bit password on the local machine when ssh starts up. The 1k-bit password is the one ssh uses "on the wire". The fact that the attacker now has to guess the 1kbit password is what makes the whole thing so safe. Doing an exhaustive search on that takes many, many times the life of the universe.
(I didn't want to post this link in the last message, I've posted it twice already and was afraid someone would think I was spamming the same link repeatedly. SSH RSA setup: http://www.wsrcc.com/wolfgang/sshd-config.html )
As for the defense against the DDOS resource exhaustion of a theoretical botnet sshd attack. I'm not sure you can do much but try to change your IP address. Ultimately legislation will probably be needed to fine the fools running virus-riddled computers that are supplying the computer workforce for the botnets.
I am sure there will be representatives of ISPs that will squeal like stuck pigs when I suggest that the ISPs should be sued for leaving the virus laden machine on the network after a documented complaint. Or even better the ISP's upstream should cut off the offending ISP if the spewing machine is not off the net within an hour of first detection.
{^_^} (Has also toyed with the idea of an ssh block list similar to the block lists for spam. I've not copyrighted it or patented it so take the idea and run if you wish. Just don't try patenting it.)
Tom Rivers wrote:
On Sat, 2007-05-26 at 13:16 -0700, Wolfgang S. Rupprecht wrote:
Such programs help you save the CPU time of sshd answering the connection from a single abusive host, but would do little against a distributed botnet attack. Luckily botnets aren't really used against sshd yet, but it they were you'd potentially be seeing distributed guessing attacks from 10,000 different hosts. If they all took turns to guess a single password in round-robin fashion, the filters would never trip.
You're right. What do you recommend to protect against this sort of attack?
Don't make a lot of enemies???
From: "Les Mikesell" lesmikesell@gmail.com
Tom Rivers wrote:
On Sat, 2007-05-26 at 13:16 -0700, Wolfgang S. Rupprecht wrote:
Such programs help you save the CPU time of sshd answering the connection from a single abusive host, but would do little against a distributed botnet attack. Luckily botnets aren't really used against sshd yet, but it they were you'd potentially be seeing distributed guessing attacks from 10,000 different hosts. If they all took turns to guess a single password in round-robin fashion, the filters would never trip.
You're right. What do you recommend to protect against this sort of attack?
Don't make a lot of enemies???
More like, "don't look like a very juicy target."
A tarpit machine with a redirection based on recent might be a really fun trick if you want some entertainment.
{^_-}
From: "Tom Rivers" tom@impact-crater.com
On Sat, 2007-05-26 at 13:16 -0700, Wolfgang S. Rupprecht wrote:
Such programs help you save the CPU time of sshd answering the connection from a single abusive host, but would do little against a distributed botnet attack. Luckily botnets aren't really used against sshd yet, but it they were you'd potentially be seeing distributed guessing attacks from 10,000 different hosts. If they all took turns to guess a single password in round-robin fashion, the filters would never trip.
You're right. What do you recommend to protect against this sort of attack?
You could detect a large number of ssh failures total within a short period of time and lock out ssh altogether for a period of seconds. That would be a use for your script. Of course, it would leave you stuck with a DoS condition. Now, if you figure out how to do it you open a second ssh daemon on a different port you know but is randomly numbered. So if you are DoSed out of the box you go to the security through obscurity port that's been opened up. (Of course, that port should have the same rules as the primary ssh port.)
{^_^}
From: "Tom Rivers" tom@impact-crater.com
On Sat, 2007-05-26 at 09:17 -0400, Michael Klinosky wrote:
Even tho /some/ of the technical stuff eludes me, I've tried to follow this thread.
I set up ssh for myself (I own the machines); I haven't yet actually made a connection (probably will this weekend).
I'd like to know what threats exits for ssh - are there webpages that discuss this? I *thought* that using an arbitrary port and putting 'AllowUsers ...' into sshd_config would handle these things (along with a password other than 'abcd' :) ).
The best thing I've found to protect against brute-force SSH attacks is something called fail2ban:
http://www.fail2ban.org/wiki/index.php/Main_Page
It watches your log files for failed attempts to gain access through services like SSH, VSFTPD, and Apache. If it sniffs trouble, it issues an IPTables command to ban the offending IP. The configuration files allow you to set the threshold for action as well as the punishment to dish out. It will even email you to let you know what has happened.
You can find it in RPM form for RHEL and Fedora. I highly recommend it because it's simple and effective.
If the bans do not time out in a timely fashion you've potentially locked yourself out of your machine.
{^_^}
On Sat, 2007-05-26 at 22:40 -0700, jdow wrote:
If the bans do not time out in a timely fashion you've potentially locked yourself out of your machine.
{^_^}
That's a good point, however you can set up IP addresses that it will ignore so that won't be a problem. ;)
Tom
From: "Michael Klinosky" mpk2@enter.net
Even tho /some/ of the technical stuff eludes me, I've tried to follow this thread.
I set up ssh for myself (I own the machines); I haven't yet actually made a connection (probably will this weekend).
I'd like to know what threats exits for ssh - are there webpages that discuss this? I *thought* that using an arbitrary port and putting 'AllowUsers ...' into sshd_config would handle these things (along with a password other than 'abcd' :) ).
At the moment ssh is considered to be safe. Periodically bugs are reported. So I figure that it is prudent to be multiply covered.
{^_^}
-
Bruno Wolff III -
Howard Howell -
jdow -
Les Mikesell -
linuxmaillists＠charter.net -
Manuel Aróstegui -
Michael Klinosky -
Tim -
Tom Rivers -
Wolfgang S. Rupprecht