ch23.htm

Maximum Security (First Edition) 网络安全 英文版

again and ran the hidden batch file. This immediately caused Linux to begin loading
on the second disk. Apparently, the user had found adequate time to lift the cover
and install a second IDE hard disk drive. Naturally, Windows didn't see the second
disk because the file system was exotic (at least, exotic to Windows). During lunch
hours (or other available times), the user would load Linux and roam a while. Bizarre.</P>
<P>For those of you who care: The employee was using a Slackware version of Linux.
That file system was crawling with many different files plundered from the network.
You may wondering how we, without having root, managed to peruse this disk. Make
a note: Always carry boot disks. They are the modern equivalent of a bazooka. Any
type of software that will circumvent the security of your system can effectively
be put on or within proximity of your system in a manner sufficient to produce that
breach. For example, suppose you have removed the floppy disk drive so that no one
can load software. Safe or not? No. If your operating system carries native drivers
for multiple devices, you have a problem. Perhaps another SCSI drive can be introduced.
Perhaps a Zip drive can be introduced.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>TIP:</B></FONT><B> </B>On networks that use some form of
	DOS, Plan 9 will soon become a likely hidden operating system. It is especially useful
	because the basic distribution is so small. It would also be popular because the
	system is exotic and not easily manipulated by a neophyte, even if he stumbles across
	it. Most PC users wouldn't know what they were looking at.</P>
	<P>However, for a cracker to implement this, he must either introduce a second disk
	or he must introduce Plan 9 when the workstation is established (for example, when
	the DOS installation occurs). The only other possibility is if he has adequate space
	to transfer the contents of the drive temporarily while he re-partitions and installs
	Plan 9. Depending on the speed of the network, drives, and processor, this could
	be done in a reasonable amount of time. Detecting this could be a problem if the
	cracker is skilled. The most reliable way would be to check the partition table or
	compare the reported size of the disk with the actual size. 
<HR>


</BLOCKQUOTE>

<P>Even if the native drivers do not exist, as long as you offer your users access
to the Internet, they can get that software in. For example, many systems may not
natively support a Zip interface, but iomega has a site with drives for all sorts
of systems. Here, even the existence of a serial port is a security risk.</P>
<P>Access to the Internet for local users presents such a wide range of security
problems, it would be difficult to fix on one particular thing. Security in this
situation is a two-way street. For example, you don't necessarily have to have your
network compromised. It could be your hard work instead. Here is a post to the mailing
list maintained at <TT>[e-mail]</TT>. The author was a system administrator
responsible for information security, and the date of the post was Friday, March
28, 1997. The author writes:

<DL>
	<DD>I'm up through the five month statistics on what was caught outbound via the
	firewall...over 400,000 lines of proprietary source code for one thing. All the people
	had legitimate access internally. It makes me feel (almost) that all the regular
	UNIX security work I've done had no meaning. Who cares if they break root if distributed
	thieves and idiots simply email out what they already have access to?
</DL>

<P>For crackers, that is the beauty of the Internet. The best way to get through
a firewall is to have someone inside send out the necessary information. I know individuals
who have taken passwords and other information from companies this way. Typically,
one member gets a contract (or a temp job) working inside. He shoots out information
that could not be easily acquired in any other way through the firewall. One group
I know did it to Pacific Bell. Another did it to Chevron. These are not your average
Mom and Pop outfits.</P>
<P>One thing that can at least stop these internal thieves from moving your valuable
data out is Secure Computing Corporation's Secure Network Server (SNS). This National
Security Agency-approved module filters e-mail. The system employs proprietary technology
and, according to documentation provided by Secure Computing Corporation, the system

<DL>
	<DD>...provides Multilevel Security (MLS) by allowing the exchange of SBU or unclassified
	information between Secret networks and SBU or Unclassified networks. The SNS customized
	filtering and FORTEZZA digital signature capability ensures only authorized e-mail
	is released from the protected environment.
</DL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>Check out SNS online
	at <A HREF="http://www.nsa.gov:8080/programs/missi/scc_sns.html"><TT>http://www.nsa.gov:8080/programs/missi/scc_sns.html</TT></A>.
	It's awesome. 
<HR>


</BLOCKQUOTE>

<P>Indeed, there are problems even if your local users are not actively trying to
crack your system. They may be cruising the Net as part of their job, not realizing
that some valuable or proprietary information has inadvertently slipped out of your
network. One example is the recent Shockwave controversy. It was recently learned
that Shockwave can be used to breach the security of networks cruising a page:

<DL>
	<DD>A developer can use Shockwave to access the user's Netscape email folders. This
	is done assuming the name and path to the mailbox on the users hard drive. For example
	names such as: Inbox, Outbox, Sent and Trash are all default names for mail folders.
	The default path to the `Inbox' on Win 95/NT would be: `C:/Program Files/Netscape/Navigator/Mail/Inbox'.
	Then the developer can use the Shockwave command GETNETTEXT to call Navigator to
	query the email folder for an email message. The results of this call can then be
	fed into a variable, and later processed and sent to a server.
</DL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>The previous paragraph
	is excerpted from an article by David de Vitry, titled &quot;Shockwave Can Read User's
	Email.&quot; It was originally posted online at <A HREF="http://www.webcomics.com/shockwave/"><TT>http://www.webcomics.com/shockwave/</TT></A>,
	and can also be found at <A HREF="http://www.ntsecurity.net/"><TT>http://www.ntsecurity.net/</TT></A>.
	
<HR>


</BLOCKQUOTE>

<H2><FONT COLOR="#000077"><B>Remote Local Users</B></FONT></H2>
<P>A <I>remote local user</I> is a user who possesses an account on your system but
has no physical access to it. In some respect, we are all remote local users because
we have accounts on boxes located within the offices of our ISPs. That is, we are
local because we are logged to the system and have a user ID and a password, but
we are physically remote to the box itself.</P>
<P>This is now becoming more common on private networks and is no longer simply an
issue for ISPs and software development firms. People all over the country (even
the world) are now doing much of their work at home or on the road. I, for one, haven't
seen the inside of an office for over two years. Indeed, this entire book was authored,
submitted, and edited without me ever meeting my editors; all of it was done over
the Internet. Large firms now have their employees telecommute on a regular basis.
AT&amp;T, for example, reported that in 1994, over 22,500 of its employees worked
at home.</P>
<P>A recent report titled &quot;Two Years Later A Report on the State of Telecommuting&quot;
was released on the subject. A sample of at least 13 Fortune 500 companies revealed
that formal telecommuting agreements between firms and employees were exceedingly
common:

<DL>
	<DD>11 of the 13 companies have or are in the process of implementing formal telecommuting
	programs. Two companies are conducting pilots while five companies have programs
	that have been in place four years or longer.
</DL>



<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>Cross Reference:</B></FONT><B> </B>&quot;Two Years Later
	A Report on the State of Telecommuting&quot; (1996, Smart Valley, Inc.) can be found
	online at <A HREF="http://www.svi.org/PROJECTS/TCOMMUTE/telrpt.pdf"><TT>http://www.svi.org/PROJECTS/TCOMMUTE/telrpt.pdf</TT></A>.
	
<HR>


</BLOCKQUOTE>

<P>Most of these telecommuters are logging into some type of server. These are what
I would characterize as remote local users. Naturally, these users will probably
have less power at a remote terminal than they would at their own. However, this
is not always the case. Much depends on the software they are using to connect. If
the software is identical to what they would be using without telecommuting, then
yes, they will have essentially the same power as they would if they were sitting
right in front of the server at the office.
<H2><FONT COLOR="#000077"><B>The Process</B></FONT></H2>
<P>Whether a user is a local user or a remote local user, his basic attack will be
pretty much the same. The only tactical advantage that a true local user has is that
he can manipulate hardware and perhaps gain access to certain tools that cannot be
used remotely.</P>
<P>Examples of such tools include any X applications. Although X applications can
be maintained nicely over the Internet, this is rarely done in practice. First, it
is a security risk; second, the client's transmission speed is usually insufficient
(if the remote user is cruising with a 28.8 modem). The same can be said for running
Windows or Windows NT over the Internet. Unless you have at least an ISDN at both
ends, it's not worth the trouble. True, some applications--notably those designed
by Microsoft--only move the underlying data as opposed to all that graphical material,
but the larger portion of applications aren't designed that way.


<BLOCKQUOTE>
	<P>
<HR>
<FONT COLOR="#000077"><B>NOTE:</B></FONT><B> </B>Note that a user's remoteness in
	no way alters his capability to use development tools that support a CLI. 
<HR>


</BLOCKQUOTE>

<P>Much depends on your topology and what the cracker is after. There are certain
situations in which even the cracker's user status may not assist him in taking a
direct route (a direct route being that of logging into his workstation at work and
marching off from that point throughout the network). In these instances, even a
semi-privileged user may have to come in using the same techniques as an attacker
without an account. This typically occurs when the cracker is seeking access to a
network segment in which he does not belong.</P>
<P>No matter what platform you use, the only cure for these types of intrusions is
to log heavily. Because these users have at least some level of access, there is
a good chance that you might not be able to easily discern an attack. Remember what
I said earlier: They have a reason and a right to be there. The following sections
introduce some tools that might assist you in preventing (or at worst, recording)
an internal intrusion.
<H3><FONT COLOR="#000077"><B>The Kane Security Monitor</B></FONT></H3>
<P>The Kane Security Monitor is available for Windows NT, and a sister application
is available for Novell NetWare. The Kane system is extremely flexible, offering
system administrators the ability to define their own security events. That is, you
can assign significance to a wide range of events that might occur that, in your
opinion, constitute a security breach. (This is in some ways the equivalent of the
access control alarm model available in VMS.) As reported by Intrusion Detection,
Inc., the company that developed the software:

<DL>
	<DD>A network administrator or security officer can easily set a system warning when
	security events occur. For example, the administrator might want to be notified if
	a new administrative account is created or deleted. Or if a user ID turned off the
	audit trail, reset a password or accessed the CEO's desktop and copied several sensitive
	files.
</DL>



<BLOCKQUOTE>