ch17.htm

来自「Maximum Security (First Edition) 网络安全 英文」· HTM 代码 · 共 1,284 行 · 第 1/5 页

<UL>
	<LI>Extensive logging capabilities (including the logging of each session, such as
	the success or failure of a given password change).<BR>
	<BR>
	
	<LI>Specification of the number of significant characters in the password (that is,
	how many will be used in the test).
</UL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>Matt Bishop's passwd+
	is available at <A HREF="ftp://ftp.dartmouth.edu/pub/security/"><TT>ftp://ftp.dartmouth.edu/pub/security/</TT></A>.
	
<HR>


</BLOCKQUOTE>

<P>To learn more about this program (and the theory and practice Bishop applied to
it), you need to get the technical report <I>A Proactive Password Checker,</I> Dartmouth
Technical Report PCS-TR90-152. This is not available on the Net from Dartmouth. However,
you can request a hardcopy of it by mail from <A HREF="http://www.cs.dartmouth.edu/cgi-bin/mail_tr.pl?tr=TR90-152"><TT>http://www.cs.dartmouth.edu/cgi-bin/mail_tr.pl?tr=TR90-152</TT></A>.
<H2><FONT COLOR="#000077"><B>The Next Step: Examining Services</B></FONT></H2>
<P>So at this stage you have secured the workstation. It has shadowed passwords and
will accept only passwords that are reasonably secure. Later, after your users have
recorded their passwords into the database, you will attempt to crack them. The machine
is also located in a safe place and neither a console mode nor installation media
are available to local, malicious users. Now it is time to consider how this workstation
will interact with the outside world.
<H3><FONT COLOR="#000077"><B>The </B><TT>r</TT><B> Services</B></FONT></H3>
<P>Just what services do you need to run? For example, are you going to allow the
use of <TT>r</TT> services? These are <TT>rlogin</TT> and <TT>rsh</TT>, primarily.
These services are notorious for sporting security holes, not just in the distant
past, but throughout their history. For example, in August 1996, an advisory was
issued regarding an <TT>rlogin</TT> hole in certain distributions of Linux. The hole
was both a Class A and Class B security hole, allowing both local and remote users
to gain leveraged access:

<DL>
	<DD>A vulnerability exists in the <TT>rlogin</TT> program of NetKitB-0.6 This vulnerability
	affects several widely used Linux distributions, including Red Hat Linux 2.0, 2.1
	and derived systems including Caldera Network Desktop, Slackware 3.0 and others.
	This vulnerability is not limited to Linux or any other free UNIX systems. Both the
	information about this vulnerability and methods of its exploit were made available
	on the Internet.--Alan Cox, Marc Ewing (Red Hat), Ron Holt (Caldera, Inc.), and Adam
	J. Richter,<I> Official Update of the Linux security FAQ</I>; Alexander O. Yuriev,
	Moderator, Linux Security and Linux Alert Mailing Lists. (CIS Laboratories, Temple
	University, Philadelphia, PA.)
</DL>

<P>The problem is not confined to Linux. Many hard-line users of UNIX &quot;look
down&quot; on Linux, taking the position that Linux is not a &quot;real&quot; UNIX
operating system. So whenever holes crop up in Linux, the hard-line community takes
the &quot;I told you so&quot; position. This is an untenable view. Many distributions
of real UNIX have had similar bugs. Consider this IBM advisory (titled &quot;Urgent--AIX
Security Exposure&quot;):

<DL>
	<DD>IBM has just become aware of an AIX security exposure that makes it possible
	to remote login to any AIX Version 3 system as the root user without a password.
	IBM hopes its efforts to respond rapidly to this problem will allow customers to
	eliminate this security exposure with minimal disruption.
</DL>

<P>This hole was a <TT>rlogind</TT> problem. On affected versions of AIX, any remote
user could issue this command:</P>
<PRE><FONT COLOR="#0066FF">rlogin AIX.target.com -l -froot
</FONT></PRE>
<P>and immediately gain <TT>root</TT> access to the machine. This is, of course,
a Class A hole. And AIX is not the only distribution that has had problems with the
<TT>r</TT> services. In fact, nearly all UNIX distributions have had some problem
or another with these services. I recommend that you shut them down.</P>
<P>But what if you can't? What if you have to offer at least limited access using
the <TT>r</TT> services? Well, thanks to Wietse Venema, this is not a problem. Venema
has produced a collection of hacked utilities that will replace these daemons. These
replacements offer enhanced security features and logging capabilities. Moreover,
Venema provides an extensive history of their development.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>You can find Venema's
	hacked tools at <A HREF="ftp://ftp://ftp.win.tue.nl/pub/security/"><TT>ftp://ftp.win.tue.nl/pub/security/</TT></A>.<BR>
	
<HR>
</P>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>The errata, changes,
	fixes, improvements, and history of these utilities are located at <A HREF="ftp://ftp://ftp.win.tue.nl/pub/security/logdaemon-5.6.README"><TT>ftp://ftp.win.tue.nl/pub/security/logdaemon-5.6.README</TT></A>.
	
<HR>


</BLOCKQUOTE>

<P>Also, in the unlikely event that you grab the utilities on-the-fly and fail to
read the <TT>README</TT> file, please heed at least this warning authored by Venema:

<DL>
	<DD>Many programs in this kit replace system utilities. Don't replace system utilities
	unless you are an experienced system programmer and system administrator.
</DL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>Venema's <TT>README</TT>
	file can be found online at <A HREF="ftp://ftp.win.tue.nl/pub/security/logdaemon-5.6.README"><TT>ftp://ftp.win.tue.nl/pub/security/logdaemon-5.6.README</TT></A>.
	
<HR>
</P>
	<P>
<HR>
<FONT COLOR="#000077"><B>TIP:</B></FONT><B> </B>Many such utilities replace system
	daemons. I recommend that before using any such utility, you carefully read the installation
	and readme notes. If you fail to do so, you may end up with a system that doesn't
	work properly. 
<HR>
</P>
	<P>
<HR>
<FONT COLOR="#000077"><B>CAUTION:</B></FONT><B> </B>Venema has made some awesome
	contributions to Internet security and is highly respected. However, even he is capable
	of making minor mistakes. Note that versions of <TT>logdaemon</TT> prior to 4.9 have
	a flawed implementation of S/Key, a Bellcore product used for authentication. The
	hole is not critical (Class A) but local users can gain unauthorized access. For
	further background and links to patched versions, see CERT Vendor-Initiated Bulletin
	VB-95:04, which is located at <A HREF="http://www.beckman.uiuc.edu/groups/biss/VirtualLibrary/mail/cert/msg00012.html"><TT>http://www.beckman.uiuc.edu/groups/biss/VirtualLibrary/mail/cert/msg00012.html</TT></A>.
	
<HR>


</BLOCKQUOTE>

<P>There are also other solutions to the problem. There are ways, for example, to
disable the <TT>r</TT> services and still provide other forms of remote login. One
such solution is Secure shell (SSH). SSH is available at many locations over the
Internet. I prefer this site:</P>
<P><A HREF="http://escert.upc.es/others/ssh/"><B>http://escert.upc.es/others/ssh/</B></A></P>
<PRE></PRE>
<P>SSH is currently available for a wide range of platform. Here are a few:

<UL>
	<LI>AIX 3.2.5, 4.1; RS6000, PowerPC
	<LI>DGUX 5.4R2.10; DGUX
	<LI>FreeBSD 1.<I>x</I>, 2.<I>x</I>; Pentium
	<LI>HPUX 9.0<I>x</I>, 10.0; HPPA
	<LI>IRIX 5.2, 5.3; SGI Indy
	<LI>Linux 1.2.<I>x</I> Slackware 2.1.0, Red Hat 2.1; i486
	<LI>Solaris 2.3, 2.4, 2.5; Sparc, i386
	<LI>SunOS 4.1.1, 4.1.2, 4.1.3, 4.1.4; Sparc, Sun3
	<LI>Unicos 8.0.3; Cray C90
</UL>

<P>As I have discussed previously, SSH provides strong authentication and encryption
across remote sessions. It is an excellent replacement for <TT>rlogin</TT> and even
Telnet. Moreover, SSH will defeat many spoofing attacks over IP and DNS. Many administrators
suggest that if you are not providing <TT>r</TT> services, you should remove the
<TT>/etc/hosts.equiv</TT> and <TT>.rhosts</TT> files. Note that the SSH client supports
authentication via <TT>.rhosts</TT> and <TT>/etc/hosts.equiv</TT>. If you are going
to use SSH, it is recommended that you keep one or both of these files. Before actually
implementing SSH on your system, it would be wise to study the RFC related to this
issue. It is titled &quot;The SSH (Secure Shell) Remote Login Protocol.&quot;


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>&quot;The SSH (Secure
	Shell) Remote Login Protocol&quot; by T. Ylonen (Helsinki University of Technology)
	can be found online at <A HREF="http://www.cs.hut.fi/ssh/RFC"><TT>http://www.cs.hut.fi/ssh/RFC</TT></A>.
	
<HR>
</P>
	<P>
<HR>
<FONT COLOR="#000077"><B>CAUTION:</B></FONT><B> </B>The files <TT>/etc/hosts.equiv</TT>
	and <TT>.rhosts</TT> should be routinely checked. Any alteration of or aberration
	in these files is one indication of a possible compromise of your system security.
	Moreover, the file <TT>/etc/hosts.equiv</TT> should be examined closely. The symbols
	<TT>+</TT>, <TT>!</TT>, <TT>-</TT>, and <TT>#</TT> should not appear within this
	file. This file is different in construct than other files and these characters may
	permit remote individuals to gain unrestricted access. (See RFC 91:12 and related
	RFCs.) 
<HR>


</BLOCKQUOTE>

<P>Moreover, you will probably want to enforce a strict policy regarding <TT>.rhosts</TT>
files on your machine. That is, you should strictly forbid users on your machine
from establishing <TT>.rhosts</TT> files in their own <TT>/home</TT> directories.
You can apply all the security in the world to your personal use of <TT>.rhosts</TT>
and it will not matter if users spring a hole in your security with their own.
<H3><FONT COLOR="#000077"><B>Snooping Utilities: The </B><TT>finger</TT><B> Service</B></FONT></H3>
<P>There is disagreement in the security field on the <TT>finger</TT> utility issue.
Some administrators argue that leaving the <TT>finger</TT> service intact will have
an almost negligible effect on security. Their view is that on a large system, it
could take ages for a cracker to build a reliable database of users and processes.
Moreover, it is argued that with the introduction of dynamically allocated IP addresses,
this information may be flawed for the purposes of cracking (for example, making
the argument that the command <TT>finger @target.host.com</TT> will reveal only those
users currently logged to the machine. This may be true in many distributions of
<TT>fingerd</TT>, but not all. Still, administrators argue that crackers will meet
with much duplicate and useless information by attempting to build a database this
way. These contingencies would theoretically foil a cracker by frustrating their
quest. Plainly stated, this technique is viewed as too much trouble. Perhaps. But
as you will see soon, that is not really true. (Moreover, for certain distributions,
this is not even an issue.) Try issuing this command against an Ultrix <TT>fingerd</TT>:</P>
<PRE><FONT COLOR="#0066FF">finger @@target.host.com
</FONT></PRE>
<P>The listing you will receive in response will shock you. On certain versions of
the Ultrix <TT>fingerd</TT>, this command will call a list of <I>all</I> users in
the <TT>passwd</TT> file.</P>
<P>My feeling is that the functionality of remote <TT>finger</TT> queries should
be eliminated altogether (or at least restricted in terms of output). Experimentation
with <TT>finger</TT> queries (against your server or someone else's) will reveal
some very interesting things. First, know this: <TT>finger</TT>ing any character
that might appear in the structure of a path will reveal whole lists of people. For
example, suppose that you structure your directories for users as <TT>/u1</TT>, <TT>/u2</TT>,
<TT>/u3</TT>, and so on. If you do, try <TT>finger</TT>ing this:</P>
<PRE><FONT COLOR="#0066FF">
finger [e-mail]
</FONT></PRE>
<P>Alas, even though you have no users named <TT>4</TT>, and even though none of
these have the character <TT>4</TT> within their usernames, they still appear. If
a cracker knows that you structure your disk organization in this manner, he can
build your entire <TT>passwd</TT> file in less than an hour.</P>
<P>However, if you feel the need to allow <TT>finger</TT> services, I suggest using
some &quot;secure&quot; form of <TT>finger</TT>, such as the highly customizable
<TT>fingerd</TT> written by Laurent Demailly. One of its main features is that it
grants access to plan files through a <TT>chrooted</TT> directory. <TT>sfingerd</TT>
(which nearly always come with the full source) is available at <A HREF="ftp://hplyot.obspm.fr:/net/sfingerd-1.8.tar.gz"><TT>ftp://hplyot.obspm.fr:/net/sfingerd-1.8.tar.gz</TT></A>.</P>
<P>Other known <TT>finger</TT> daemons, varying in their ability to restrict certain
behavior, are listed in Table 17.2.
<H4><FONT COLOR="#000077"><B>Table 17.2. Alternative <TT>finger</TT> daemons.</B></FONT></H4>
<P>
<TABLE BORDER="1">
	<TR ALIGN="LEFT" rowspan="1">
		<TD ALIGN="LEFT" VALIGN="TOP"><I>Daemon</I></TD>
		<TD ALIGN="LEFT" VALIGN="TOP"><I>Locale and General Characteristics</I></TD>
	</TR>
	<TR ALIGN="LEFT" rowspan="1">
		<TD ALIGN="LEFT" VALIGN="TOP"><TT>fingerd-1.0</TT></TD>
		<TD ALIGN="LEFT" VALIGN="TOP"><A HREF="ftp://kiwi.foobar.com/pub/fingerd.tar.gz"><TT>ftp://kiwi.foobar.com/pub/fingerd.tar.gz</TT></A>.
			<BR>
			<BR>
			Offers extensive logging and allows restrictions on forwarding.</TD>
	</TR>