[CCCure CISSP] Best Practices - SSH Configuration

Sat Mar 6 20:59:41 EST 2010

it's very useful!
Thank you!

Jack

2010/3/6 Clement Dupuis <clement.dupuis at cccure.com>

> 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
>>
>>
>
> _______________________________________________
> 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/20100307/8d2b581a/attachment.html>