0399-0400.html
来自「linux-unix130.linux.and.unix.ebooks130 l」· HTML 代码 · 共 240 行
HTML
240 行
<HTML>
<HEAD>
<TITLE>Developer.com - Online Reference Library - 0672311739:RED HAT LINUX 2ND EDITION:System Security</TITLE>
<META NAME="ROBOTS" CONTENT="NOINDEX, NOFOLLOW">
<SCRIPT>
<!--
function displayWindow(url, width, height) {
var Win = window.open(url,"displayWindow",'width=' + width +
',height=' + height + ',resizable=1,scrollbars=yes');
}
//-->
</SCRIPT>
</HEAD>
-->
<!-- ISBN=0672311739 //-->
<!-- TITLE=RED HAT LINUX 2ND EDITION //-->
<!-- AUTHOR=DAVID PITTS ET AL //-->
<!-- PUBLISHER=MACMILLAN //-->
<!-- IMPRINT=SAMS PUBLISHING //-->
<!-- PUBLICATION DATE=1998 //-->
<!-- CHAPTER=20 //-->
<!-- PAGES=0395-0410 //-->
<!-- UNASSIGNED1 //-->
<!-- UNASSIGNED2 //-->
<P><CENTER>
<a href="0395-0398.html">Previous</A> | <a href="../ewtoc.html">Table of Contents</A> | <a href="0401-0402.html">Next</A>
</CENTER></P>
<A NAME="PAGENUM-399"><P>Page 399</P></A>
<TABLE WIDTH="360">
<TR><TD>
xp-beta
</TD><TD>
An application gateway of X11 protocol. It is designed to
be used at a site that has a firewall and uses SOCKS
and/or CERN WWW Proxy.
</TD></TR>
<TR><TD>
xroute
</TD><TD>
Routes X packets from one machine to another.
</TD></TR>
</TABLE>
<P>There are, as you can see, a few tools for your use. If you want a second reason for looking
at these tools, keep in mind that people trying to break into your system know how to, and
do, use these tools. This is where the knowledge
comes in.
</P>
<H4><A NAME="ch20_ 6">
Knowledge Gathering
</A></H4>
<P>Someone once said a little knowledge goes a long way. As stated in the chapter opening, all
the bells and whistles can be there, but if they are not active, they do no good. It is,
therefore, important that the system staff, the users, and the keepers of the sacred root password all
follow the security procedures put in place—that they gather all the knowledge necessary to
adhere to those procedures.
</P>
<P>I was at the bank the other day, filling out an application for a car loan. The person
assisting me at the bank was at a copy machine in another room (I could see her through the
window). Another banking person, obviously new, could be heard from his office. He was having
problems logging in to the bank's computer. He came out and looked around for the bank
employee helping me. He did not see her. I got his attention and pointed him toward the
copy area. He thanked me and went to her and asked for the system's password because he
could not remember it. She could not remember the password. He went back to his desk, checked
a list of telephone numbers hanging on the wall by his phone, entered something into the
computer, and was in. About that time, my bank person came out of the copy area, stuck her
head in his office, and said that she recalled the password. He said he had it. She asked if he
had done with the password what they normally do. He looked at his phone list and said yes.
She left and returned to me at her desk.
</P>
<P>This scenario is true. The unfortunate thing about it, besides the fact that at least two
customers, the person with the employee trying to log in to the system, and I, saw the whole thing,
is that they didn't know, nor did they care that others might be listening. To them it was
business as usual. What can be learned from this? DON'T WRITE DOWN PASSWORDS!!!!!
</P>
<P>Not only should passwords not be written down, but they should also not
be easily associated with the user. I'll give you two examples that illustrate this point. The first involves a
wonderful man from the Middle East with whom I worked on a client site. He has three boys. As
a proud father, he talks about them often. When referring to them individually, he uses
their first names. When referring to them cumulatively, he calls them "three boys." His
password (actually, he uses the same password for all his accounts) is
threeboys.
</P>
<P>The second example comes from one of the sweetest people I have met in the industry. She
is an unmarried person with no children. On her desk is a little stuffed cow, named Chelsea. I
do
</P>
<A NAME="PAGENUM-400"><P>Page 400</P></A>
<P>not remember the significance of the name, but I remember that she really likes dairy
cows. Her password is, you guessed it, chelsea. These peoples' passwords are probably
still threeboys and chelsea.
</P>
<P>File security is another big issue. The use of
umask (file creation masks) should be mandated. It should also be set to the maximum amount possible. It is easy to change a particular file to
give someone else access to it. It is difficult, if not impossible, to know who is looking at your
files. The sensitivity of the data, of course, would certainly determine the exact level of security
placed on the file. In extremely sensitive cases, such as employees' personnel records, it might be
necessary to also encrypt the files.
</P>
<P>After an audit has been done, you should have an excellent idea of what security issues
you need to be aware of and which issues you need to track. The next section shows you how
to track intruders.
</P>
<H3><A NAME="ch20_ 7">
Danger, Will Robins, Danger!
</A></H3>
<P>I used to love watching Lost in Space. On that show there was a life-sized robot that
would declare, "Danger, Will Robins, danger!" when there was some danger. Unfortunately, there
is no such robot to declare when there is danger on our systems. (There are some tools, but
they are nowhere near as consistent as the robot was!)
</P>
<P>If you have a lot of extra disk space, you can turn on auditing. Auditing records all user
connects and disconnects from your system. If you don't rely on auditing, you should scan
the logs often. As an alternative, it might be worthwhile to write a quick summary script that
gives an account of the amount of time each user is on the system.
</P>
<P>Unfortunately, there are too many holes to block them all. Measures can be placed to plug
the biggest of them, but locking a computer in a vault, allowing no one access to it and no
connectivity outside of the vault, is the only way to keep a system secure. The bottom line is, if
users want into your system, and they are good enough, they can get in. What you have to do
is prepare for the worst.
</P>
<H4><A NAME="ch20_ 8">
Preparing for the Worst
</A></H4>
<P>There are basically three things that can be done to a system, short of physically removing
it. These are stealing data, destroying data, and providing easier access for next time.
Physically, an intruder can destroy or remove equipment, or, if very creative, could even add
hardware. Short of chaining the system to the desk, there is not much that can be done about theft.
The physical security is beyond the scope of this book, anyway. What is within the scope of
this book is dealing with the data, and dealing with additional access measures.
</P>
<P>Data should be backed up on a regular basis. The backed-up information, depending on
how secure it needs to be, can be kept on a shelf next to the system or kept in a locked vault at
an alternative location. This is the best way of getting back data that has been destroyed.
</P>
<P><CENTER>
<a href="0395-0398.html">Previous</A> | <a href="../ewtoc.html">Table of Contents</A> | <a href="0401-0402.html">Next</A>
</CENTER></P>
</td>
</tr>
</table>
<!-- begin footer information -->
</body></html>⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?