LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Security (https://www.linuxquestions.org/questions/linux-security-4/)
-   -   Securing SSH - am I missing something? Suggestions welcomed! (https://www.linuxquestions.org/questions/linux-security-4/securing-ssh-am-i-missing-something-suggestions-welcomed-4175436323/)

AkHolic 11-08-2012 07:05 PM

Securing SSH - am I missing something? Suggestions welcomed!
 
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?

unSpawn 11-08-2012 07:29 PM

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

Turbocapitalist 11-09-2012 07:56 AM

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

Code:

iptables -A INPUT -p TCP --dport 22 -m state --state NEW -m limit --limit 4/minute --limit-burst 5 -j ACCEPT
That assumes that your default is to REJECT the packets.

Noway2 11-09-2012 08:09 AM

Quote:

Modify pam_cracklib.so to enforce stronger password policies. Are there any better solutions for this?
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.

AkHolic 11-09-2012 10:56 AM

Quote:

Originally Posted by unSpawn (Post 4825407)

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.

Quote:

Originally Posted by Turbocapitalist (Post 4825761)
You can also use rate limiting in iptables to prevent bruteforce attacks.

Code:

iptables -A INPUT -p TCP --dport 22 -m state --state NEW -m limit --limit 4/minute --limit-burst 5 -j ACCEPT
That assumes that your default is to REJECT the packets.

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?

Quote:

Originally Posted by Noway2 (Post 4825778)
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 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)?

Noway2 11-09-2012 12:19 PM

Quote:

Originally Posted by AkHolic (Post 4825910)
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?

Turbocapitalist 11-09-2012 12:24 PM

Quote:

Originally Posted by AkHolic (Post 4825910)
... 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)?

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.

unSpawn 11-09-2012 01:03 PM

Quote:

Originally Posted by AkHolic (Post 4825910)
Thanks. I haven't heard of port knocking before reading that thread.

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

Noway2 11-09-2012 01:27 PM

Quote:

Originally Posted by Turbocapitalist (Post 4825959)
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 "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.

Turbocapitalist 11-09-2012 01:31 PM

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.

AkHolic 11-09-2012 03:22 PM

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.

Noway2 11-09-2012 04:19 PM

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.

AkHolic 11-11-2012 12:37 PM

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


All times are GMT -5. The time now is 06:48 PM.