● The High-Tech How Not to be Seen, Part 1 - 荔园在线 | 深圳大学学生论坛,荔园晨风BBS,深大在线网站

荔园之美，在春之萌芽，在夏之绽放，在秋之收获，在冬之沉淀

发信人: "Roy Guo" <roy@szu.edu.cn>, 信区: Linux
标  题: The High-Tech How Not to be Seen, Part 1
发信站: ShenZhen University (Sun Dec  5 19:32:36 1999)
转信站: ShenZhen-University!bbs.szu.edu.cn!not-for-mail
出  处: 210.39.3.71

The High-Tech How Not to be Seen, Part 1

                               by Marcel Gagn~{(&~} <mggagne@salmar.com>
                                           5-Nov-1999

Practical invisibility for system administrators (or anybody).

Welcome back, everyone, to another week of Linux system
administration--because a system administrator's job is never done.

Last week, I gave you an introduction to network sniffers. If you took the
time to play with sniffit, for instance, you noticed that
your telnet sessions are plaintext, and the sniffer program will display
everything coming from and going to your network
interface. Sure, you can spy on your users, but are they spying on you?

The problem is that while TCP/IP is truly wonderful and has given us this
bright, beautiful Internet of ours, it is inherently
insecure. You see, when the protocol was first created, we were a little
less worried about people looking over our electronic
shoulders and watching us work. After all, computers were big, magical,
scary things that only a handful of people really
understood. Not so any more.

Imagine you are the system administrator at BigCompanyInc and you've just
read my last six articles, tied down your Linux
server, did a pile of reading on your own, tied it down even further, and a
few days later you discover a break-in. What happened?
One possibility is Joe Cracker plugged into your 200-port network with his
Linux notebook (it's easy to hide in a 200-station
office), started a sniffer, and waited while people logged in and left their
plaintext user names and passwords. The grand prize
was the root password, which you let slip by as you telnetted to your SAMBA
server. Suddenly, Joe Cracker has full access to
your system all over again.

One way to avoid this is to never log in as root (or su to root) across
anything but a direct serial connection, or the console itself.
That's the idea behind the /etc/securetty file, which is simply a list of
terminals at which root is allowed to log in. This doesn't
stop you from logging in as yourself and doing a su - root in order to gain
root privileges, thus exposing yourself to our cracker.

What to do?

One way to beat this problem is with ssh, or the Secure Shell. For the
purpose of this article, I downloaded a copy of the
software (its URL is included later on) and built it on my system. This is
fairly simple. After ftp'ing the gzipped and tarred bundle,
I extracted the software and compiled it. Like this:

   # tar -xzvf ssh-2.0.13.tar.gz
   # cd ssh-2.0.13
   # ./configure
   # make install

There are several components to ssh; a client and server component,
utilities for generating public and private encrypted keys for
strong authentication, and a secure FTP server. For brevity's sake (whoever
he or she is), I will concentrate on the telnet or shell
client.

Before we can run a secure shell, we need to start a secure server. By
default, the sshd daemon (or server) runs on TCP port
22 (check it out by doing a more or less on your /etc/services file), but
you can specify a different port with the -p option.
I started my new sshd on my server from the command line with the default
port.

   # sshd

Before we try out my spiffy new secure shell, I'll just telnet to my server
and type pwd. This is your regular, run-of-the-mill,
telnet to port 23. Just for fun, I will also become root after I've logged
in. In my sniffer window, I get this result:

   pwd../mnt/data1/packages/ssh-2.0.13
   [root@server_name ssh-2.0.13#

Ouch! Kind of depressing. What I did not show you came before this little
tidbit. My user name and password, including the su to
root and its password, were displayed for anyone to see. A couple of weeks
ago, one reader commented that after reading the
"cracker" series, they were now almost afraid to turn on their computer.
After a demonstration like this, you can understand how
he feels.

Let's try that again, this time with emotion--er, encryption. From my
notebook (where I have also built and installed ssh), I initiated
a connection to my server.

   # ssh server_name

After responding to the password prompt, I went back to my sniffer session
and clicked on the new port 22 session and started
capturing the output. Here's what I saw this time:

   ..>.V.eC?q.\./...F.D.vR.._rl.j..k.U..;J...X....g*.
   KW..D.VSq.A.[Qy.E[.e...p`..s...1.n.....|.M..B..?..
   ...HE....,xB

Quite a difference, eh?

If you want to get your hands on a copy of ssh, you can visit the official
ssh web site at this address:
http://www.ssh.fi/sshprotocols2/download.html

You can also obtain Red Hat RPMs at http://www.replay.com/redhat/ssh.html if
you do not want to build from the source
distribution.

Keep in mind that ssh is a commercial product, and can be ordered on-line
from http://www.datafellows.com (you'll find a link on
the ssh web site as well). While the product is not free, this doesn't stop
you from downloading and evaluating it or experimenting
with it (evaluation period is 60 days). If you happen to qualify for the
non-commercial or educational use category, you may use
ssh without cost. Check the license agreement for details.

Although ssh is almost certainly the de facto standard, a freeware
implementation is on the horizon. While not quite ready for
prime time, it is worth your while to check it out and keep up with its
development. Written by Niels M?ller, the freeware version
is lsh, a GNU implementation of the ssh protocol. You can follow this
exciting development at http://www.net.lut.ac.uk/psst/.

As always, there's more to cover and I suspect there always will be.

Until next week, run silent, run encrypted!

Copyright ? 1999 Specialized Systems Consultants, Inc.

荔园在线首页友情链接：深圳大学深大招生荔园晨风BBS S-Term软件网络书店