I'm not really a programmer and I recently came across this hack to insert a short sleep statement into auth-passwd.c within sshd. It seems to quickly confuse automated dictionary attacks. I've moved sshd to higher ports but apparently the cretins are now scanning to look for that and attacking on whatever port sshd shows up on.
Anyway, the link to the hack is here:
http://www.aerospacesoftware.com/ssh-kiddies.html
Just wondering if any of the wizened programmers out there can think of any reason why this would be a bad thing to do.
Cheers,
On Fri, 2006-03-10 at 16:32 -0500, Chris Mauritz wrote:
I'm not really a programmer and I recently came across this hack to insert a short sleep statement into auth-passwd.c within sshd. It seems to quickly confuse automated dictionary attacks. I've moved sshd to higher ports but apparently the cretins are now scanning to look for that and attacking on whatever port sshd shows up on.
Anyway, the link to the hack is here:
http://www.aerospacesoftware.com/ssh-kiddies.html
Just wondering if any of the wizened programmers out there can think of any reason why this would be a bad thing to do.
Cheers,
Other than remembering to put it back in when you upgrade each time?
Probably a better course of action is to use strong passwords or better yet setup keys. Then it does not matter much how long or hard they guess passwords. You just have to ignore the noise in your log files.
You could try port knocking. There are few implementations of that available and should reduce or eliminate the problem.
But IMHO the best thing to do is make sure you use keys or at least good strong passwords, disable root ssh access, limit ssh to specific users. And ignore the noise in the logs.
On 3/10/06, Chris Mauritz chrism@imntv.com wrote:
I'm not really a programmer and I recently came across this hack to insert a short sleep statement into auth-passwd.c within sshd. It seems to quickly confuse automated dictionary attacks. I've moved sshd to higher ports but apparently the cretins are now scanning to look for that and attacking on whatever port sshd shows up on.
Anyway, the link to the hack is here:
http://www.aerospacesoftware.com/ssh-kiddies.html
Just wondering if any of the wizened programmers out there can think of any reason why this would be a bad thing to do.
Messing with sshd source isn't something I'm ready to play around with. I'd rather farm it out to a 3rd party wrapper like denyhosts to block this crap.
-- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety'' Benjamin Franklin 1775
Do a search for "ssh-faker" - I've found this very effective.
Daveh
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Jim Perrin Sent: 10 March 2006 21:44 To: CentOS mailing list Subject: Re: [CentOS] sshd hack
On 3/10/06, Chris Mauritz chrism@imntv.com wrote:
I'm not really a programmer and I recently came across this hack to insert a short sleep statement into auth-passwd.c within sshd. It seems to quickly confuse automated dictionary attacks. I've moved sshd to higher ports but apparently the cretins are now scanning to look for that and attacking on whatever port sshd shows up on.
Anyway, the link to the hack is here:
http://www.aerospacesoftware.com/ssh-kiddies.html
Just wondering if any of the wizened programmers out there can think of any reason why this would be a bad thing to do.
Messing with sshd source isn't something I'm ready to play around with. I'd rather farm it out to a 3rd party wrapper like denyhosts to block this crap.
-- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety'' Benjamin Franklin 1775 _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
I'll just show my solution (again):
/etc/sysconfig/iptables:
:ssh - [0:0]
-A INPUT -p tcp --dport 12345 -m recent --name SSHAUTH --set -A INPUT -p tcp --dport ssh -m state --state NEW -j ssh
-A ssh -m recent --name SSHAUTH --update --seconds 43200 -j ACCEPT -A ssh -s GOOD_IP/MASK -j ACCEPT ... -A ssh -j REJECT --with-with tcp-reset
Which lets local networks (and any special hosts you specify like computers you often use) connect to ssh (GOOD_IP/MASK) and requires any other machine to first issue any request to a random high port (here 12345, use something more random) before ssh is even let through the firewall.
Depends on your users. In my experience users can be educated :)
Cheers, MaZe.
Chris Mauritz wrote:
I'm not really a programmer and I recently came across this hack to insert a short sleep statement into auth-passwd.c within sshd. It seems to quickly confuse automated dictionary attacks. I've moved sshd to higher ports but apparently the cretins are now scanning to look for that and attacking on whatever port sshd shows up on. Anyway, the link to the hack is here:
http://www.aerospacesoftware.com/ssh-kiddies.html
Just wondering if any of the wizened programmers out there can think of any reason why this would be a bad thing to do.
Cheers,
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
you can try this :
http://la-samhna.de/library/brutessh.html#3
Leonel
Because I am the only one who needs ssh access, I just install apf as a firewall, permit the ports I need the public to access, and deny ssh. Then I whitelist my own source IP "apf -a myip" and that ends the problem.
On Fri, 2006-03-10 at 16:32 -0500, Chris Mauritz wrote:
I'm not really a programmer and I recently came across this hack to insert a short sleep statement into auth-passwd.c within sshd. It seems to quickly confuse automated dictionary attacks. I've moved sshd to higher ports but apparently the cretins are now scanning to look for that and attacking on whatever port sshd shows up on.
I dealt with these attacks by only allowing PubkeyAuthentication.
# Authentication types PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys PasswordAuthentication no ChallengeResponseAuthentication no
This requires you to put your public key in .ssh/authorized_keys on remote servers. Make sure it's working before you set "PasswordAuthentication no" or you will lock yourself out.
-David
On Sat, Mar 11, 2006 at 10:20:16AM -0500, David Johnston wrote:
I dealt with these attacks by only allowing PubkeyAuthentication.
# Authentication types PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys PasswordAuthentication no ChallengeResponseAuthentication no
This requires you to put your public key in .ssh/authorized_keys on remote servers. Make sure it's working before you set "PasswordAuthentication no" or you will lock yourself out.
David, I really like the idea of using keys since I believe they are more resistant to being cracked, but I have one question:
If your ssh keys are in a file on a remote server, does that mean anyone who has root on that system can use them to gain access to ssh into your home system?
Jeff Kinz wrote:
If your ssh keys are in a file on a remote server, does that mean anyone who has root on that system can use them to gain access to ssh into your home system?
It depends. There are two types of keys..public and private keys. Obviously, you only need to upload the public key to the server you want to login (as authorized_keys with OpenSSH). The private key should be password protected (i.e. NO BLANK PASSWORDS dsa/rsa keys).
If someone has root on a server where the private key is located, they can see the key. But after seeing the key, they need to know the IP/FQDN of the remote SSH server "AND" know the password of the private key (which is why having a pass-"phrase" is a better idea than pass-"word").
Not only that, but newer versions of SSH allow you to encrypt your known_hosts file. From Damien Miller's Post:
Added the ability to store hostnames added to ~/.ssh/known_hosts in a hashed format. This is a privacy feature that prevents a local attacker from learning other hosts that a user has accounts on from their known_hosts file.
So instead of hostnames being stored in plain text like:
yourhost.example.com ssh-rsa
AAAB3NzaC1yc2EAAAABIwAAAIEAp832eeMwYH…
They are hashed first, so they don’t reveal the hostname. E.g.:
|1|bRGYyrC+bfKZGGd5GZH4wo1AnsI=|xcQ+54QNVwQ+fBCldn0= ssh-rsa
AAA…
We added at the request of some MIT researchers who found that a substantial number of user private keys on shared systems are not encrypted (a really dumb thing to do, BTW). This lack of user care, coupled with the information in the known_hosts files, allowed attackers to spread their attacks to multiple systems.
Right now this is disabled by default, but administrators of sites with lazy users can turn it on with the HashKnownHosts config flag.
If you do this, you should probably also hash your existing known_hosts file (ssh-keygen -H).
Warm Regards,
-- Bruno Delbono Open-Systems Group http://www.open-systems.org/users/bruno/
On Sat, 2006-03-11 at 09:32 -0800, Bruno S. Delbono wrote:
Not only that, but newer versions of SSH allow you to encrypt your known_hosts file. From Damien Miller's Post:
Added the ability to store hostnames added to ~/.ssh/known_hosts in a hashed format. This is a privacy feature that prevents a local attacker from learning other hosts that a user has accounts on from their known_hosts file.
Interesting option. How do you sort out the problem when the remote host key changes (such as reloading the OS) and you need to delete the entry in the known_hosts file so ssh will work again with that system?
I understand the purpose of the option, just not sure how it would work when such changes occur. Deleting the entire known_hosts file would not be a good option IMHO.
And how secure does this make the known_hosts file? Is it a simple hash that can be obtained from the source?
On 11/03/06, Scot L. Harris webid@cfl.rr.com wrote:
On Sat, 2006-03-11 at 09:32 -0800, Bruno S. Delbono wrote:
Not only that, but newer versions of SSH allow you to encrypt your known_hosts file. From Damien Miller's Post:
Added the ability to store hostnames added to ~/.ssh/known_hosts in a hashed format. This is a privacy feature that prevents a local attacker from learning other hosts that a user has accounts on from their known_hosts file.
Interesting option. How do you sort out the problem when the remote host key changes (such as reloading the OS) and you need to delete the entry in the known_hosts file so ssh will work again with that system?
I understand the purpose of the option, just not sure how it would work when such changes occur. Deleting the entire known_hosts file would not be a good option IMHO.
And how secure does this make the known_hosts file? Is it a simple hash that can be obtained from the source?
For sake of clarity let us not use remote or local but client and server. You an be client sitting on local machine logging into remote server or client on remote logging in to server which is local.
AFAIK You can just copy the .ssh/authorized_keys2 file from old server to new server As this includs public key of clinet the remote log in from client would still work.
SSH method of setting up keys in the first place assumes you can generate key at client (only if you have access) and then export the public key to server (only if you have access there to). Once this is done you can log in from that unique client to the server. However if the client changes then you need to go through the process of regenerating publc key and installing it on server. -- Sudev Barar Learning Linux
On Sun, 2006-03-12 at 06:12 +0530, Sudev Barar wrote:
On 11/03/06, Scot L. Harris webid@cfl.rr.com wrote:
On Sat, 2006-03-11 at 09:32 -0800, Bruno S. Delbono wrote:
Not only that, but newer versions of SSH allow you to encrypt your known_hosts file. From Damien Miller's Post:
Added the ability to store hostnames added to ~/.ssh/known_hosts in a hashed format. This is a privacy feature that prevents a local attacker from learning other hosts that a user has accounts on from their known_hosts file.
Interesting option. How do you sort out the problem when the remote host key changes (such as reloading the OS) and you need to delete the entry in the known_hosts file so ssh will work again with that system?
I understand the purpose of the option, just not sure how it would work when such changes occur. Deleting the entire known_hosts file would not be a good option IMHO.
And how secure does this make the known_hosts file? Is it a simple hash that can be obtained from the source?
For sake of clarity let us not use remote or local but client and server. You an be client sitting on local machine logging into remote server or client on remote logging in to server which is local.
AFAIK You can just copy the .ssh/authorized_keys2 file from old server to new server As this includs public key of clinet the remote log in from client would still work.
SSH method of setting up keys in the first place assumes you can generate key at client (only if you have access) and then export the public key to server (only if you have access there to). Once this is done you can log in from that unique client to the server. However if the client changes then you need to go through the process of regenerating publc key and installing it on server.
I understand this with the authorized_keys file. The original question was regarding the hashing of the known_hosts file. In my experience there have been many times when I have had to remove entries in the known_hosts file due to the host key changing on a system. My question was, if the known_hosts file is hashed how do you identify the entry for the particular host so it can be removed when needed?
On 12/03/06, Scot L. Harris webid@cfl.rr.com wrote:
I understand this with the authorized_keys file. The original question was regarding the hashing of the known_hosts file. In my experience there have been many times when I have had to remove entries in the known_hosts file due to the host key changing on a system. My question was, if the known_hosts file is hashed how do you identify the entry for the particular host so it can be removed when needed?
Sorry, my comment was on general topic going on.
AFAIK you can not know unless you keep record of hosts additions. The first host added is the first entry and so on. Since that is really a pain so I just delete all entries. Then the first time you connect to a server all you have to do is answer "yes" to addition of new host. :-( Keys stored will still work and you do not have to do anything :-)
-- Sudev Barar Learning Linux
-
Bruno S. Delbono -
Chris Mason (Lists) -
Chris Mauritz -
Dave Hatton -
David Johnston -
Jeff Kinz -
Jim Perrin -
Leonel Nunez -
Maciej Żenczykowski -
Scot L. Harris -
Sudev Barar