224 lines
12 KiB
HTML
224 lines
12 KiB
HTML
<!--startcut ==========================================================-->
|
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
|
<HTML>
|
|
<HEAD>
|
|
<title>More Linux Security Issue 16</title>
|
|
</HEAD>
|
|
<BODY BGCOLOR="#EEE1CC" TEXT="#000000" LINK="#0000FF" VLINK="#0020F0"
|
|
ALINK="#FF0000" >
|
|
<!--endcut ============================================================-->
|
|
|
|
<H4>
|
|
"Linux Gazette...<I>making Linux just a little more fun!</I>"
|
|
</H4>
|
|
|
|
<P> <HR> <P>
|
|
<!--===================================================================-->
|
|
|
|
<center>
|
|
<H2>More Linux Security</H2>
|
|
<H4>By Andrew Berkheimer, <A HREF="mailto:andy@tho.org">andy@tho.org</A>
|
|
</H4>
|
|
</center>
|
|
<P>
|
|
Here you go, yet another article on Linux security. Some new tidbits
|
|
for all to enjoy, reinforcement of some key points, and clarification of some
|
|
things which I though were a bit misrepresented in previous articles. Note
|
|
that this is geared towards a slightly novice audience, more experience users will
|
|
probably find themselves bored out of their minds at times.
|
|
|
|
So you've got your system up and running, connected to the net,
|
|
maybe running an ftp server or some other service. But you've heard all these
|
|
nasty stories of people having their computers cracked for no apparent reason,
|
|
and you're just a tad bit nervous. You want to start securing your system
|
|
from outside intruders, but where to begin? Contrary to popular belief,
|
|
securing your system can actually be fun, and if nothing else, informative.
|
|
So it's time to begin!
|
|
<P>
|
|
First and foremost, stay informed! Jay mentioned reading CERT, but
|
|
I would argue that this is not enough. CERT does not release information
|
|
until they have verified that it is a problem and most of the big-name
|
|
vendors have provided patches to fix the problem. This can often cause
|
|
lag times of months between a hole being found and the CERT announcement. There
|
|
are a number of good mailing lists which I would recommend subscribing to,
|
|
including bugtraq, linux-security, and linux-alert (subscription information
|
|
is at the end of the article), where security holes are often discussed and
|
|
found long before CERT starts talking about them - the crackers know about
|
|
these places, so should you.
|
|
<P>
|
|
Now onto some real meat. The first concern is to try and protect
|
|
yourself from attacks from unknown outsiders who may stumble upon your system
|
|
and see it as an invitation to test out their cracking skills. One of the first
|
|
things you want to check is for unused daemons running on you system. There's
|
|
really no reason to be running nfsd if you're not NFS serving to anywhere,
|
|
now is there? There are two places that you will need to check out: the
|
|
configuration file for the inet super server (typically /etc/inetd.conf),
|
|
and the system bootup scripts (located in /etc/rc.d, /etc/rc2.d, or some
|
|
similar directory).
|
|
<P>
|
|
In inetd.conf, comment out with a # the lines for any service you
|
|
don't really need to provide...the r* services (rlogind, rshd, rexecd, etc)
|
|
are good candidates, as well as other typically unused ones like echo,
|
|
daytime, and chargen. For most people, leaving in telnetd, ftpd, and maybe
|
|
pop3d should be sufficient for the moment. Maybe fingerd too, though be
|
|
careful, finger can give out a lot of information about your computer which can
|
|
be to a potential crackers advantage. Once you finish editing your
|
|
inetd.conf, restart inetd by running "killall -HUP inetd" to get it to reread
|
|
the configuration.
|
|
<P>
|
|
In your bootup scripts you may see references to things like portmap,
|
|
ypserv, rpc.mountd, and rpc.nfsd. Unless you are a NFS or NIS server, you have
|
|
no need for these and should not run them...in many cases the "out of the box"
|
|
versions of these programs have some pretty nasty security vulnerabilities.
|
|
Also look for sendmail (if you're not receiving mail directly you don't need
|
|
to run it), and httpd (only want this if you're running a web server).
|
|
<P>
|
|
So, you've worked hard to get the list of unnecessary servers down...
|
|
time to start adding/upgrading software again. First and foremost, make sure
|
|
you are running the most recent version of NetKit, which contains most of the
|
|
typically network servers for Linux like telnetd, fingerd, etc. The current
|
|
version as of this writing is 0.09, it is available in
|
|
ftp://ftp.uk.linux.org/pub/linux/Networking/base. The most recent version fixes
|
|
a few known security flaws in earlier versions.
|
|
<P>
|
|
In general, you want to try and keep everything else up to date too:
|
|
check http://www.sendmail.org for updates to sendmail (any time a new version
|
|
comes out nowadays, it is almost always to fix a security problem), as well
|
|
as http://www.apache.org for updates to the apache httpd server, etc.
|
|
<P>
|
|
However, there is still the problem of password sniffers grabbing
|
|
your password if you telnet to your system from some other outside network.
|
|
Telnet, FTP, POP, and just about any other standard protocol out there will
|
|
transmit your password in plaintext. There are a couple of ways around this
|
|
available in external software packages. I'll look at OPIE and ssh here.
|
|
<P>
|
|
First of all there's OPIE, also known as One-time Passwords In
|
|
Everything, a package created by the US Naval Research Labs and currently
|
|
maintained by The Inner Net. The idea behind one time passwords is that when
|
|
you login to a system from remote, it will give you a prompt like this:
|
|
<PRE>
|
|
stroke login: andy
|
|
otp-md5 271 st6747
|
|
Response:
|
|
</PRE>
|
|
Instead of just typing in your password right away over the connection, you
|
|
would instead run a key generating program on your local machine, with the
|
|
parameters given in the "challenge" of the login prompt (the challenge here
|
|
being otp-md5 271 st6747). You type your password into the local program
|
|
(where it can't be grabbed by packet sniffers), and the key generator
|
|
produces a unique password which you login with. This unique, one-time password
|
|
will only work once, so even if someone grabs it in a packet sniffer, it
|
|
won't do them any good. The OPIE package is available at
|
|
ftp://ftp.nrl.navy.mil/pub/security/opie/ with more information.
|
|
<P>
|
|
There's also another pretty popular package, ssh. The ssh package
|
|
replaces those evil rlogind, rexecd, rshd, etc. programs with sshd, which
|
|
has the same functionality, but it encrypts all communications, making it
|
|
very hard in deed for a packet sniffer to get anything useful. More information
|
|
about the package can be found at http://www.cs.hut.fi/ssh/.
|
|
<P>
|
|
In addition to these two, there are a number of more involved,
|
|
complicated methods designed for sitewide networks, labs, and the like, which
|
|
are a tad overkill for one single host (this includes things like
|
|
Kerberos V and the like).
|
|
<P>
|
|
That about wraps up the protecting yourself from outside crackers,
|
|
but you still have to worry about other users on your own system (or even
|
|
outside crackers if they manage to get access to a shell on your system).
|
|
Typically you will hear a lot about "buffer overflow" security holes. These
|
|
are essentially times when a binary doesn't check to see if the data it is
|
|
storing into a character buffer can fit into the memory it is being put into.
|
|
A carefully written program can take advantage of this and overwrite other
|
|
parts of memory, causing other programs to be executed. Normally this isn't
|
|
a problem until you get into setuid root binaries. Since setuid root binaries
|
|
will initially run with root privileges, then any binary executed by the
|
|
program will also be run as root. So if there is a buffer overflow which is
|
|
used to run /bin/sh as root, then blammo, any random joe suddenly has a root
|
|
shell to do what they please with.
|
|
<P>
|
|
There are also programs which have what are called race conditions,
|
|
or times when they are doing something which may be used to a crackers
|
|
advantage if the program happens to be running as root. Through some bit
|
|
of trickery, it might very well be possible for them to get a root shell.
|
|
The bottom line: setuid root binaries are not the greatest things in the world,
|
|
keep the number of setuid root binaries on your system to a bare minimum.
|
|
<P>
|
|
To protect yourself from buffer overflows, there isn't too much you can
|
|
do but keep up to date with information being made available about possible
|
|
security holes and fixing them ASAP. If you have some programming experience,
|
|
you also probably want to actually look through the source code and check for
|
|
buffer overflows yourself: you just may find one that no one else knows about
|
|
yet.
|
|
<P>
|
|
Also, an important point: you should very rarely trust binaries that
|
|
you just get off the net from an untrusted unknown source, especially if you
|
|
are going to be running those binaries as root. This is how the Bliss "virus"
|
|
spread, combined with a buffer overflow in some commonly found setuid root
|
|
games. Under any Unix, root is a very powerful user, so while normal viruses
|
|
can't exist under Unix because users typically cannot modify system binaries,
|
|
a program like Bliss is designed to try and exploit known buffer overflows to
|
|
get root access to be able to modify root owned binaries.
|
|
<P>
|
|
And just as a last reminder, here are some points I can't help but
|
|
reinforce.If you think you've been compromised, then disconnect from the net
|
|
immediately, analyze your logs, and replace any binaries which you think may
|
|
have been compromised, maybe even reinstalling your system (after backing up
|
|
important data). And always remember to keep your passwords hard to guess and
|
|
change them regularly.
|
|
|
|
Besides all this, I can't begin to emphasize the importance of
|
|
GETTING INFORMED and then STAYING INFORMED. There are many good books on the
|
|
topic of computer security, I'd especially recommend _Computer Security
|
|
Basics_ from O'Reilly and Associates for those with a beginning interest in
|
|
security. And keeping current with some of the more popular security mailing
|
|
lists will do you a world of good. There is also a Linux Security FAQ
|
|
available online at http://www.aoy.net/Linux/Security/, which is a good
|
|
source of information. Some final advice: never get the feeling that your
|
|
system is "perfectly secure" - you're just inviting a break-in that way.
|
|
<P>
|
|
Oh, about those mailing lists I mentioned earlier. Information about
|
|
linux-alert and linux-security can be found at the Linux Security WWW I just
|
|
mentioned (http://www.aoy.net/Linux/Security/). Information about bugtraq
|
|
may be found at http://www.geek-girl.com/bugtraq/index.html. There are also
|
|
a lot of other things which can be said about security, delving into firewalls
|
|
and other packet filtering, IP spoofing protection, more fine grained access
|
|
control to net services, and many other areas, but those are topics for
|
|
another place and time.
|
|
<P>
|
|
-Andrew Berkheimer
|
|
andy@tho.org, aberkhei@tjhsst.edu
|
|
<P>
|
|
<B>Summary of Resources Mentioned</B>
|
|
<PRE>
|
|
netkit: ftp://ftp.uk.linux.org/pub/linux/Networking/base/
|
|
sendmail: http://www.sendmail.org/
|
|
apache: http://www.apache.org/
|
|
opie: ftp://ftp.nrl.navy.mil/pub/security/opie/
|
|
ssh: http://www.cs.hut.fi/ssh/
|
|
linux security www: http://www.aoy.net/Linux/Security/
|
|
linux-alert list info: http://www.aoy.net/Linux/Security/LinuxAlertList.html
|
|
linux-security list info:
|
|
http://www.aoy.net/Linux/Security/LinuxSecurityList.html
|
|
bugtraq list info: http://www.geek-girl.com/bugtraq/
|
|
</PRE>
|
|
|
|
<!--===================================================================-->
|
|
<P> <hr> <P>
|
|
<center><H5>Copyright © 1997, Andrew Berkheimer <BR>
|
|
Published in Issue 16 of the Linux Gazette, April 1997</H5></center>
|
|
|
|
<!--===================================================================-->
|
|
<P> <hr> <P>
|
|
<A HREF="./index.html"><IMG ALIGN=BOTTOM SRC="../gx/indexnew.gif"
|
|
ALT="[ TABLE OF CONTENTS ]"></A>
|
|
<A HREF="../index.html"><IMG ALIGN=BOTTOM SRC="../gx/homenew.gif"
|
|
ALT="[ FRONT PAGE ]"></A>
|
|
<A HREF="./lgei.html"><IMG SRC="../gx/back2.gif"
|
|
ALT=" Back "></A>
|
|
<A HREF="./gv.html"><IMG SRC="../gx/fwd.gif" ALT=" Next "></A>
|
|
<P> <hr> <P>
|
|
<!--startcut ==========================================================-->
|
|
</BODY>
|
|
</HTML>
|
|
<!--endcut ============================================================-->
|