<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><DIV>Prakash,</DIV>
<DIV> </DIV>
<DIV>This is a keeper!!! Thanks a bunch for sharing.</DIV>
<DIV> </DIV>
<DIV>lp<BR></DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif"><BR>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: times new roman, new york, times, serif"><FONT face=Tahoma size=2>
<HR SIZE=1>
<B><SPAN style="FONT-WEIGHT: bold">From:</SPAN></B> Prakash P <prakash2757g@yahoo.com><BR><B><SPAN style="FONT-WEIGHT: bold">To:</SPAN></B> cisspstudy@cccure.org<BR><B><SPAN style="FONT-WEIGHT: bold">Sent:</SPAN></B> Sat, March 6, 2010 4:26:56 AM<BR><B><SPAN style="FONT-WEIGHT: bold">Subject:</SPAN></B> [CCCure CISSP] Best Practices - SSH Configuration<BR></FONT><BR>
<TABLE cellSpacing=0 cellPadding=0 border=0>
<TBODY>
<TR>
<TD vAlign=top>
<DIV><FONT face="verdana, helvetica, sans-serif">Hi all,</FONT></DIV>
<DIV><FONT face="verdana, helvetica, sans-serif"> </FONT></DIV>
<DIV><FONT face="verdana, helvetica, sans-serif">I would like to share very good article on Best Practices - SSH Configuration for .. Hope you all find it useful.</FONT></DIV>
<DIV><FONT face="verdana, helvetica, sans-serif"> </FONT></DIV>
<DIV><FONT face="verdana, helvetica, sans-serif">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</FONT></DIV>
<DIV><FONT face="verdana, helvetica, sans-serif"> </FONT></DIV>
<DIV><FONT face="verdana, helvetica, sans-serif"><STRONG>1: Use Version 2<BR></STRONG>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:</FONT></DIV>
<DIV><FONT face="verdana, helvetica, sans-serif">Protocol 2,1</FONT></DIV>
<DIV><FONT face="verdana, helvetica, sans-serif">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!</FONT></DIV>
<DIV><FONT face="verdana, helvetica, sans-serif"> </FONT></DIV>
<DIV><FONT face="verdana, helvetica, sans-serif"><STRONG>2: Verify IP Address Binding</STRONG><BR>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.</FONT></DIV>
<DIV><FONT face="verdana, helvetica, sans-serif"> </FONT></DIV>
<DIV><FONT face="verdana, helvetica, sans-serif"><STRONG>3: Use TCP Wrappers</STRONG><BR>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.</FONT></DIV>
<DIV><FONT face="verdana, helvetica, sans-serif"> </FONT></DIV>
<DIV><FONT face="verdana, helvetica, sans-serif"><STRONG>4: Require Key Based Authentication</STRONG><BR>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!</FONT></DIV>
<DIV><FONT face="verdana, helvetica, sans-serif"> </FONT></DIV>
<DIV><FONT face="verdana, helvetica, sans-serif"><STRONG>5: Don’t Permit Root Logons</STRONG><BR>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! <BR>To verify that root is not permitted to log in directly, look for this line: PermitRootLogin no<BR><BR><BR>- Prakash<BR></FONT><A href="http://www.linkedin.com/in/prakashp" target=_blank rel=nofollow><FONT face="verdana, helvetica, sans-serif">http://www.linkedin.com/in/prakashp</FONT></A></DIV></TD></TR></TBODY></TABLE><BR>
<HR SIZE=1>
The INTERNET now has a personality. YOURS! <A href="http://in.rd.yahoo.com/tagline_yyi_1/*http://in.yahoo.com/" target=_blank rel=nofollow>See your Yahoo! Homepage</A>.</DIV></DIV></div></body></html>