ch17.htm

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

	<TR ALIGN="LEFT" rowspan="1">
		<TD ALIGN="LEFT" VALIGN="TOP"><TT>cfinger</TT></TD>
		<TD ALIGN="LEFT" VALIGN="TOP"><A HREF="ftp://sunsite.unc.edu:/pub/Linux/system/network/finger/cfingerd-1.3.2.lsm"><TT>ftp://sunsite.unc.edu:/pub/Linux/system/network/finger/cfingerd-1.3.2.lsm</TT></A>.
			<BR>
			<BR>
			Can be used to provide selective <TT>finger</TT> services, denying one user but allowing
			another. For queries from authorized users, scripts can be executed on a <TT>finger</TT>
			query.</TD>
	</TR>
	<TR ALIGN="LEFT" rowspan="1">
		<TD ALIGN="LEFT" VALIGN="TOP"><TT>rfingerd</TT></TD>
		<TD ALIGN="LEFT" VALIGN="TOP"><A HREF="ftp://ftp.technet.sg:/pub/unix/bsdi/rfingerd.tgz"><TT>ftp.technet.sg:/pub/unix/bsdi/rfingerd.tgz</TT></A>.
			<BR>
			<BR>
			An interesting twist: a Perl daemon. Allows a lot of conditional execution and restriction,
			for example, <TT>if {$user_finger_request eq `foo'} {perform_this_operation}</TT>.
			Easy to use, small, lightweight. (It is Perl, after all.)</TD>
	</TR>
</TABLE>
</P>
<P>There are other reasons to disable <TT>finger</TT>. The <TT>.plan</TT> file is
one. On ISP machines, the <TT>.plan</TT> file is usually of little significance and
is used for its most popularly known purpose: to provide a little extra info in response
to a <TT>finger</TT> inquiry. However, in networks connected to the Net as a matter
of course (especially in the corporate climate), the <TT>.plan</TT> file may serve
other purposes (for example, status reports on projects). This type of information
could be considered sensitive.</P>
<P>If you feel the need to run <TT>finger</TT>, restrict its use to people within
your network. Or, if that is not possible, download one of the secure <TT>finger</TT>
daemons and examine both the code and the documentation. Only then should you make
your choice.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>NOTE:</B></FONT><B> </B>It is reported in several documents,
	including the Arts and Sciences UNIX System Administrator Guidelines at Duke University,
	that you should not use GNU <TT>fingerd</TT> version 1.37. Apparently, there is a
	hole in that version that allows users to access privileged files. 
<HR>


</BLOCKQUOTE>

<H2><FONT COLOR="#000077"><B>Other Remote Services</B></FONT></H2>
<P>The next step is to examine what other remote services you will offer. Here are
some questions you should ask yourself:

<UL>
	<LI>Will you allow connections from the outside via Telnet?
	<LI>What about FTP?
	<LI>If so, will that FTP service be anonymous?
</UL>

<H3><FONT COLOR="#000077"><B>Telnet</B></FONT></H3>
<P>Telnet is not an inherently dangerous service to provide, but some versions are
not secure. Moreover, even in &quot;tight&quot; versions of Telnet, a minor problem
may exist.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>NOTE:</B></FONT><B> </B>One good example is Red Hat Linux
	4.0. The problem is not serious, but Telnet in that distribution may reveal more
	information than you want it to. Suppose that you have disabled <TT>finger</TT> services,
	<TT>r </TT>services, and the <TT>EXPN</TT> command in <TT>Sendmail</TT>. Suppose
	further, however, that you do allow Telnet sessions from untrusted addresses. (In
	other words, you are not running firewall software and have no other means of excluding
	untrusted, unknown, or suspicious addresses.) With this configuration, you feel reasonably
	confident that no one can identify valid usernames on your system. But is that really
	true? No. The Telnet package on Red Hat 4.0 distributions will cut the connection
	between the requesting address and the server if an invalid username is given. However,
	if the username is valid (but the password is incorrect), the server issues a subsequent
	login so that a retry can be initiated. By running a nicely hacked Perl script, a
	cracker can effectively determine valid user IDs on your system through a sort of
	&quot;brute force&quot; technique. True, you would recognize this in your logs from
	the run of connection requests from the remote host. However, even little things
	like this can assist an outsider in gleaning information about your system. 
<HR>


</BLOCKQUOTE>

<P>Telnet is not radically different from other system processes. It, too, has been
found vulnerable to a wide range of attacks. Such holes crop up periodically. One
was discovered in 1995 by Sam Hartman of MIT's Kerberos Development Team (with confirmation
and programming assistance provided by John Hawkinson, also at MIT). This hole was
rather obscure, but could provide a remote user with <TT>root</TT> access. As discussed
by Hartman in a public advisory (&quot;Telnet Vulnerability: Shared Libraries&quot;):

<DL>
	<DD>On Sunday, October 15, I discovered a bug in some versions of <TT>telnetd</TT>
	on some platforms that allows a user making a connection to cause <TT>login</TT>
	to load an alternate C library from an arbitrary location in the file system of the
	machine running <TT>telnetd</TT>. In the case of machines mounting distributed file
	spaces such as AFS or NFS, containing publicly writable anonymous FTP directories,
	or on which the user already has a non-root account, it is possible to gain root
	access.
</DL>

<P>The hole discovered by Hartman was common to not just one version of <TT>telnetd</TT>,
but several:

<UL>
	<LI>NetBSD
	<LI>FreeBSD
	<LI>SGI IRIX
	<LI>DEC UNIX
	<LI>Linux
</UL>

<P>Take note, then. If you are new to UNIX, or if you have been running your system
without frequently checking bug lists for vulnerabilities, your <TT>telnetd</TT>
could have this problem. If so, you will need to install the patch. Contact your
vendor or visit your vendor's site for patches.</P>
<P>Unfortunately, many of the locations for patches are no longer current. However,
the document does provide a scheme to &quot;test&quot; your <TT>telnetd</TT> to see
if it is vulnerable. For that reason alone, the document has significant value.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>You can read &quot;Telnet
	Vulnerability: Shared Libraries&quot; on the WWW at <A HREF="http://geek-girl.com/bugtraq/1995_4/0032.html"><TT>http://geek-girl.com/bugtraq/1995_4/0032.html</TT></A>.
	
<HR>


</BLOCKQUOTE>

<P>Earlier versions of Telnet have also had problems. It would not serve you well
for me to list them all here. Rather, it is better to suggest that you consider <I>why</I>
you are providing Telnet. Again, this breaks down to necessity. If you can avoid
offering Telnet services, then by all means do so. However, if you must offer some
form of remote login, consider SSH.</P>
<P>Also, SSH is not your only recourse. I am simply assuming at this stage that the
imaginary machine that we are securing does not yet have a firewall or other forms
of security applicable to Telnet. Other options <I>do</I> exist. These are two of
those options (to be discussed later):

<UL>
	<LI>Telnet authentication via Kerberos. Some distributions of Telnet are Kerberos
	aware. These support encryption and authentication. Some of these were in development
	in October 1995, when the Hartman hole was identified. One is at <A HREF="ftp://ftp.cray.com/src/telnet/"><TT>ftp://ftp.cray.com/src/telnet/</TT></A>.
	A distribution of the 4.4BSD &quot;Kerberized&quot; version is at <A HREF="http://andrew2.andrew.cmu.edu/dist/telnet.html"><TT>http://andrew2.andrew.cmu.edu/dist/telnet.html</TT></A>.<BR>
	<BR>
	
	<LI>Telnet proxy by firewall. For example, the <TT>tn-gw</TT> application available
	in the TIS Firewall Toolkit (referred to as the FWTK). These types of applications
	can permit or deny remote hosts explicitly. (Many of these applications allow the
	use of wildcards as well, where one can restrict entire networks from connecting.)
</UL>

<P>What you use will depend on your particular circumstances. In some instances (for
example, where you are an ISP), you really cannot use a blanket exclusionary scheme.
There is no guarantee that all Telnet connections will be initiated on your subnet,
nor that all will come from your PPP users. Some of these individuals will be at
work or other locations. They will be looking to check their mail at lunch hour and
so on. If you provide shell services, exclusionary schemes are therefore impractical.</P>
<P>The exception to this is if you have restricted shell use to one machine (perhaps
a box named <TT>shell.provider.com</TT>). In this situation, exclusionary schemes
can be implemented with a limited amount of hassle. Perhaps you only have 150 shell
users. If so, you can request that these individuals forward to you a list of likely
addresses that they will be coming from. These can be added to the list of allowable
hosts. In many instances, they may be coming from a dynamically allocated IP at a
different provider. In this case, you must make the choice if you want to allow all
users from that network. Generally, however, most shell users will be logging in
from work with a fixed IP. It would not be a significant amount of effort to allow
these addresses through your filter.</P>
<P>Without installing any of this software, making the decision to allow Telnet is
a difficult one. Like most TCP/IP services, Telnet affects the system at large. For
example, many cracking expeditions start with Telnet. Crackers can test your vulnerability
to overflow attacks and CGI exploits by initiating a Telnet session to port 80. They
can also attempt to glean valid usernames by initiating a Telnet session to port
25 and so on. (Moreover, Telnet is one way for a remote user to identify your operating
system type and version. This will tell the seasoned cracker which holes to try.)</P>
<P>For the moment, let us assume that <TT>telnetd</TT> has been disabled and that
your choice is to use SSH instead.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>NOTE:</B></FONT><B> </B>One hole worth noting is the environment
	variable passing technique. This hole emerged in November 1995 and therefore it is
	within the realm of possibility that your system may be affected. The bug affected
	even many &quot;secure&quot; versions of Telnet that used Kerberos-based authentication.
	Because the bug was so serious (allowing remote users to gain <TT>root</TT> access,
	yet another Class A hole), you should examine the full advisory about it. The technique
	involved passing local environment variables to the remote target using the <TT>ENVIRONMENT</TT>
	option in all Telnet versions conforming to RFC 1408 or RFC 1572. The full advisory
	is at <A HREF="http://ciac.llnl.gov/ciac/bulletins/g-01.shtml"><TT>http://ciac.llnl.gov/ciac/bulletins/g-01.shtml</TT></A>.
	
<HR>


</BLOCKQUOTE>

<H2><FONT COLOR="#000077"><B>FTP</B></FONT></H2>
<P>Deciding whether to provide FTP access is a bit less perplexing. There are few
reasons to allow totally unrestricted, anonymous FTP. Usually, this is done when
you are offering a software distribution, free or otherwise, or when you are maintaining
an archive of information that is of interest to the general Internet population.
In either case, you have almost certainly allocated a machine expressly for this
purpose, which doesn't run many other services and holds only information that has
already been backed up.
<H3><FONT COLOR="#000077"><B>Anonymous FTP</B></FONT></H3>
<P>I am against anonymous FTP unless you have a reason. This is mainly because FTP
(like Telnet and most other protocols) affects the entire system:

<DL>
	<DD>Some protocols are inherently difficult to filter safely (e.g., RPC and UDP services),
	thus providing more openings to the internal network. Services provided on the same
	machine can interact in catastrophic ways. For example, allowing anonymous FTP on
	the same machine as the WWW server may allow an intruder to place a file in the anonymous
	FTP area and cause the HTTP server to execute it.
</DL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>The previous paragraph
	is excerpted from Barbara Fraser's <I>Site Security Handbook</I> (update and draft
	version; June 1996, CMU. <TT>draft-ietf-ssh-handbook-04.txt</TT>), which can be found
	online at <A HREF="http://info.internet.isi.edu:80/in-drafts/files/draft-ietf-ssh-handbook-04.txt"><TT>http://info.internet.isi.edu:80/in-drafts/files/draft-ietf-ssh-handbook-04.txt</TT></A>.
	
<HR>


</BLOCKQUOTE>

<P>Clearly, the worst situation is anonymous FTP with a writable directory (for example,
<TT>/incoming</TT>). Fully anonymous FTP with a writable directory makes you a prime
stop for those practicing the FTP &quot;bounce&quot; attack technique.</P>
<P>Briefly, FTP bounce technique involves using one FTP server as a disguise to gain
access to another FTP server that has refused the cracker a connection. The typical
situation is where the target machine is configured to deny connections from a certain
IP address hierarchy. The cracker's machine has an IP address within that hierarchy
and therefore some or all of the FTP directories on the target machine are inaccessible
to him. So the cracker uses another machine (the &quot;intermediary&quot;) to access
the target. The cracker accomplishes this by writing to the intermediary's FTP directory
a file that contains commands to connect to the target and retrieve some file there.
When the intermediary connects to the target, it is coming from its own address (and
not the cracker's). The target therefore honors the connection request and forwards
the requested file.</P>
<P>FTP bounce attacks have not been a high-profile (or high-priority) issue within
security circles, mainly because they are rare and do not generally involve cracking
attempts. (Most bounce attacks probably originate overseas. The United States has
export restrictions on a variety of products, most commonly those with high-level
encryption written into the program. Bounce attacks are purportedly used to circumvent