SSH Configuration

i all,

 

I would like to share very good article on Best Practices - SSH Configuration for .. Hope you all find it useful.

 

SSH  has been around since around 1995.  In some ways it has become the backbone of remote network management and configuration in our enterprises.  Since everything from our Cisco routers to our Firewalls  and servers support this protocol, what do we need to know as an IT auditor to make sure it’s configured correctly?  Here are the top five items to check.. Credits to David

 

1: Use Version 2
SSH version 1 was shown to have significant flaws as early as 2001.  While some of these flaws were coding errors, others are flaws that can allow for replay and other forms of attacks against the protocol itself.  From time to time you may find that the administrators have configured the service as follows:

Protocol 2,1

What this means is that SSH version 2 is preferred, but the service can fall back to support version 1.  There is no reason any public facing system should have version 1 enabled in any form!

 

2: Verify IP Address Binding
The lazy way (default) of configuring SSH is to allow the service to run on all bound IP addresses.  On internal networks this may not be such a big deal, but for a public facing system this is a bad idea!  Your SSH service should be bound to a specific IP address, preferably one accessible only from the internal network.  If an administrator needs to get to something remotely, require that they log into the VPN first and then connect to the internal facing SSH service.

 

3: Use TCP Wrappers
The SSH daemon is perfectly capable of running by itself.  The trouble with this is that it doesn’t enforce any connection restrictions beyond the authentication system.  Requiring that TCP Wrappers be used to control access to SSH allows us to restrict connections to specific networks or hosts regardless of authentication credentials.  This creates an additional level of defense and also protects us should our service be inadvertently configured to run on all interfaces.

 

4: Require Key Based Authentication
SSH can be configured to use the local username/password database to authenticate users.  In fact, this is the default.  The problem is that this means that someone could potentially attempt to brute force entry into our system by repeatedly attempting passwords against a common user (like root).  If we require users to use key based authentication we leverage strong cryptographic mechanisms for authentication (asymmetric keys) and make it infeasible for a brute force attack.  Don’t just make sure that key authentication is turned on, make sure password based authentication is turned off!

 

5: Don’t Permit Root Logons
Why do administrators like to log in a root?  Let’s face facts:  it’s easy and everything works!  Of course, this is super bad because it can lead to all kinds of auditing and accountability issues.  Be aware that blocking root logins through things like securetty configurations and PAM adjustments is likely not enough to keep someone from logging in as root via SSH!
To verify that root is not permitted to log in directly, look for this line: PermitRootLogin no


- Prakash
http://www.linkedin.com/in/prakashp