LinuxQuestions.org
Register a domain and help support LQ
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices

Reply
 
Search this Thread
Old 11-08-2012, 07:05 PM   #1
AkHolic
LQ Newbie
 
Registered: Nov 2012
Posts: 4

Rep: Reputation: Disabled
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?
 
Old 11-08-2012, 07:29 PM   #2
unSpawn
Moderator
 
Registered: May 2001
Posts: 27,462
Blog Entries: 54

Rep: Reputation: 2899Reputation: 2899Reputation: 2899Reputation: 2899Reputation: 2899Reputation: 2899Reputation: 2899Reputation: 2899Reputation: 2899Reputation: 2899Reputation: 2899
Maybe start with this thread: http://www.linuxquestions.org/questi...tempts-340366/ ?
 
1 members found this post helpful.
Old 11-09-2012, 07:56 AM   #3
Turbocapitalist
Member
 
Registered: Apr 2005
Distribution: Ubuntu, Debian, OS X (bsd)
Posts: 152

Rep: Reputation: 28
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.
 
2 members found this post helpful.
Old 11-09-2012, 08:09 AM   #4
Noway2
Senior Member
 
Registered: Jul 2007
Distribution: Ubuntu 10.10, Slackware 64-current
Posts: 2,124

Rep: Reputation: 776Reputation: 776Reputation: 776Reputation: 776Reputation: 776Reputation: 776Reputation: 776
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.
 
Old 11-09-2012, 10:56 AM   #5
AkHolic
LQ Newbie
 
Registered: Nov 2012
Posts: 4

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by unSpawn View Post
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 View Post
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 View Post
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)?
 
Old 11-09-2012, 12:19 PM   #6
Noway2
Senior Member
 
Registered: Jul 2007
Distribution: Ubuntu 10.10, Slackware 64-current
Posts: 2,124

Rep: Reputation: 776Reputation: 776Reputation: 776Reputation: 776Reputation: 776Reputation: 776Reputation: 776
Quote:
Originally Posted by AkHolic View Post
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.
Old 11-09-2012, 12:24 PM   #7
Turbocapitalist
Member
 
Registered: Apr 2005
Distribution: Ubuntu, Debian, OS X (bsd)
Posts: 152

Rep: Reputation: 28
Quote:
Originally Posted by AkHolic View Post
... 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.
 
Old 11-09-2012, 01:03 PM   #8
unSpawn
Moderator
 
Registered: May 2001
Posts: 27,462
Blog Entries: 54

Rep: Reputation: 2899Reputation: 2899Reputation: 2899Reputation: 2899Reputation: 2899Reputation: 2899Reputation: 2899Reputation: 2899Reputation: 2899Reputation: 2899Reputation: 2899
Quote:
Originally Posted by AkHolic View Post
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.
 
Old 11-09-2012, 01:27 PM   #9
Noway2
Senior Member
 
Registered: Jul 2007
Distribution: Ubuntu 10.10, Slackware 64-current
Posts: 2,124

Rep: Reputation: 776Reputation: 776Reputation: 776Reputation: 776Reputation: 776Reputation: 776Reputation: 776
Quote:
Originally Posted by Turbocapitalist View Post
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.
 
1 members found this post helpful.
Old 11-09-2012, 01:31 PM   #10
Turbocapitalist
Member
 
Registered: Apr 2005
Distribution: Ubuntu, Debian, OS X (bsd)
Posts: 152

Rep: Reputation: 28
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.
Old 11-09-2012, 03:22 PM   #11
AkHolic
LQ Newbie
 
Registered: Nov 2012
Posts: 4

Original Poster
Rep: Reputation: Disabled
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.
 
Old 11-09-2012, 04:19 PM   #12
Noway2
Senior Member
 
Registered: Jul 2007
Distribution: Ubuntu 10.10, Slackware 64-current
Posts: 2,124

Rep: Reputation: 776Reputation: 776Reputation: 776Reputation: 776Reputation: 776Reputation: 776Reputation: 776
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.
Old 11-11-2012, 12:37 PM   #13
AkHolic
LQ Newbie
 
Registered: Nov 2012
Posts: 4

Original Poster
Rep: Reputation: Disabled
Thanks for all the feedback! I should be all set.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] securing ssh logins dinakumar12 Linux - Server 2 09-15-2010 01:40 AM
Securing SSH via Webmin scottt20 Linux - Server 3 01-28-2010 02:22 PM
Securing SSH ZilverZtream Linux - Security 5 12-10-2004 03:33 PM
securing ssh robberttheman Linux - Security 8 08-27-2004 07:36 AM
Securing SSH tarballedtux Linux - Security 3 11-16-2002 04:45 AM


All times are GMT -5. The time now is 02:56 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration