[CCCure CISSP] Best Practices - SSH Configuration

[Clement Dupuis]

SSH is also a subject covered within the CBK.

Unfortunately most of the study books do not get into HOW to configure it
properly which is the most important thing.  The CBK talks about things in
many cases instead of showing how to do things.

Thanks for your contrib

Clement


Clément Dupuis, CD
CISSP, GCFW, GCIA, QEH, QSA, Security+, CEH, ECSA, LPT, CCSA, CCSE, MBNS,
MBIS, MBHS,  ACE
----------------------------------------------------------------------------------------------
In real life:
Senior Security Specialist and Instructor
Security University
>>  Call me to get the best CISSP training  <<
----------------------------------------------------------------------------------------------
In Cyberspace:
President/Security Evangelist/Chief Learning Officer (CLO)
The CCCure Family of Portals
----------------------------------------------------------------------------------------------
Business:  407 479 3903
Fax:          407 264 8396

Maintainer of :
The CCCure Family of Portals
http://www.cccure.org

The Professional Security Testers Warehouse
http://www.professionalsecuritytesters.org

Knowledge sharing and giving back to the community


On Sat, Mar 6, 2010 at 10:18, Leif Palmer <ldpalmer at sbcglobal.net> wrote:

> Prakash,
>
> This is a keeper!!! Thanks a bunch for sharing.
>
> lp
>
>  ------------------------------
> *From:* Prakash P <prakash2757g at yahoo.com>
> *To:* cisspstudy at cccure.org
> *Sent:* Sat, March 6, 2010 4:26:56 AM
> *Subject:* [CCCure CISSP] Best Practices - SSH Configuration
>
>   Hi 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
>
> ------------------------------
> The INTERNET now has a personality. YOURS! See your Yahoo! Homepage<http://in.rd.yahoo.com/tagline_yyi_1/*http://in.yahoo.com/>
> .
>
> _______________________________________________
> CISSPstudy mailing list
> CISSPstudy at cccure.org
> http://cccure.org/mailman/listinfo/cisspstudy_cccure.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cccure.org/pipermail/cisspstudy_cccure.org/attachments/20100306/bc11c7ca/attachment-0001.html>