Hi guys,

I'm working on completing an assignment and would like some input from the Linux security community. The ultimate goal is to reduce the number of brute-force SSH authentication attempts for my assigned VM. I only have access to my centOS VM, so network firewalls and other network devices cannot be configured.

Steps I plan on taking:

Disable login to root
Run ssh on a different port
Install DenyHosts or fail2ban. Which one would you suggest?
Modify pam_cracklib.so to enforce stronger password policies. Are there any better solutions for this?

Does anyone have any other suggestions? Also, are there any changes to config files to ensure the same configuration exists after a reboot?

Maybe start with this thread: http://www.linuxquestions.org/questi...tempts-340366/ ?

1 members found this post helpful.

You can also use rate limiting in iptables to prevent bruteforce attacks.

That assumes that your default is to REJECT the packets.

2 members found this post helpful.

Instead of trying to reduce the availability of brute force password attacks, why not simply eliminate them as a possibility by using key based authentication? The problem with passwords is that the cracker only has to get lucky once but you have to get lucky every time. All of the methods you have chosen to employ are good and will help cut down on the "noise" meaning that what remains is what you truly need to worry about, but with passwords your still just as vulnerable as if you had none of these measures in place.

Thanks. I haven't heard of port knocking before reading that thread. Has anyone used port knocking? It seems like a difficult measure to implement for someone with my limited unix skill, and I'm worried about locking myself out of the VM multiple times to try and get it to work. I don't have physical or vSphere access.

Thanks. I was under the impression DenyHosts will provide the rate limiting. Will this rule simply add another layer of security to rate limiting or does it do something DenyHosts doesn't?

Thanks. I considered doing this, but how would I generate keys for legitimate users without having them login (with a pw) first and generating the key themselves? I searched google, no luck. If there's a way to generate keys for users, how do you suggest I issue the keys to them without creating other vulnerabilities (and with sneakernet out the question)?

Why not have the user create their own keys and you can put it in their home directory for them as part of creating their account? In order to have an account, an administrative user would need to create it, so adding the step of placing their public key in the .ssh sub folder under their home directory would be a miniscule effort compared to the massive boost in security?

1 members found this post helpful.

You would generate the keys with ssh-keygen(1) just like you would generate keys for yourself. You can use -f to save it under a unique file name if you're doing a lot at once. Then you choose a way to copy the key pair or at least the private key to the user's remote account. You can use sftp or sneakernet.

The thread is more of an overview of essential measures to take but port knocking is not one of the essential measures.

The "gotcha" with this method is the sneaker net, which the OP said that wanted to or needed to avoid, or other secure means of transfer for the private key. Unless there is an already secure means of transport an encryption method would need to be used. If for example, the private key were encrypted with openSSL, you would still need a means to transfer the decryption pass phrase. This is where the PSK part of SSH comes into play, which is the initial problem were trying to solve. This is why I suggested have the user create their key pair. They get to keep the private key, private, they can use SSH-Keygen, or even create a PUTTY key if they are using a Windows client. All they need to do is email or otherwise transfer the public key, which can be safely done in plain text.

1 members found this post helpful.

Yes, having the user create the key pairs would be the easiest option of all. It would eliminate the trouble of finding a secure way to transfering the private key. In transfering the public key, the user can verify the integrity on the first login attempt. In that case even e-mail would work for transfering the public keys.

1 members found this post helpful.

The reason why I originally dismissed key based authentication is because the instructor will need to login to my VM, and verify my configuration. I guess it wouldn't be too much to ask him to generate a key for himself before I disable password authentication in sshd_config.

Think of it this way. You can write your report mention all the things that you can do to try to secure a password based system, only to then show that it doesn't provide true security, leaving you with the need to still use keys. What you can do is show how the techniques will cut down on the "script kiddie" noise and how fail2ban will elongate the time required for a brute-force attack, but not eliminate it. Also, keys eliminate the weakest link in the whole chain: users selecting crappy passwords like 'passw0rd' and 'abc123', granted you can address this with PAM.

1 members found this post helpful.

Thanks for all the feedback! I should be all set.