397 lines
16 KiB
HTML
397 lines
16 KiB
HTML
<HTML>
|
|
<HEAD>
|
|
<TITLE>Linux Security 101 Issue 14</TITLE>
|
|
</HEAD>
|
|
<BODY bgcolor="#FFFFFF">
|
|
|
|
<H4>
|
|
"Linux Gazette...<I>making Linux just a little more lovable!</I>"
|
|
<IMG ALIGN=MIDDLE SRC="../gx/heart.gif"> </H4>
|
|
|
|
<P> <HR> <P>
|
|
<!--===================================================================-->
|
|
|
|
<center>
|
|
<H2>Linux Security 101</H2>
|
|
<H4>By Kelley Spoon,
|
|
<a href="mailto:mars@loeffel.txdirect.net">
|
|
mars@loeffel.txdirect.net</a></H4>
|
|
</center>
|
|
<P> <HR> <P>
|
|
|
|
You can jump down to the section on<a href="#tcpd"> tcpd </a><br>
|
|
Or take a peek at the other<a href="#other"> stuff </a>you need to keep an
|
|
eye on.<p>
|
|
</center>
|
|
<hr>
|
|
<p>
|
|
Ok. You've got Linux beat. You finally got AfterStep set up the way you want
|
|
it, you've managed to set up ip masquerading for your home LAN, you've managed
|
|
to set up a cool issue for people to see when they log in, you managed to
|
|
convert a couple over to the One True OS, and chicks really dig you because,
|
|
as we all know, Linux geeks are sexy.
|
|
<p>
|
|
One night as you're peeking at <i>/var/adm/messages</i>, you notice that
|
|
someone from some place you've never heard of before tried to make 5 ftp
|
|
connections, 6 telnets, and even an nntp connection. What's up with that?
|
|
<p>
|
|
Well, Linux (and all Unix type OS's in general) were designed to be a
|
|
programmer's paradise. The same qualities that makes Linux such a wonderful
|
|
networking and hacking operating system also expose a few security holes.
|
|
There are a few programs that you probably rely on or use daily that can be
|
|
used to gain root access (which is a Bad Thing). What's worse, the commercial
|
|
distributions that many Linux users depend on have these programs with
|
|
security holes inside packages that are installed as part of the base
|
|
system.
|
|
<p>
|
|
That's the bad news. The good news is that we can make it tougher for the
|
|
Bad Guys to do their dirty deeds. By checking the
|
|
<a href="http://www.aoy.com/Linux/Security/"> Linux ALERTS </a>
|
|
page, you can find out what the holes we <b>know</b> about are, and how to
|
|
temporarily plug them up or even fix them up for good. There is also a nice
|
|
little tool that is probably on your system that we can use to keep them
|
|
from even having access to our machine.
|
|
<p>
|
|
And that's what I'm going to focus on. My belief here is that if we can
|
|
keep the Remote Bad Guys (people who don't have legitimate access to our
|
|
machines) out, then we only have to worry about the Local Bad Guys (if any).
|
|
Plus it gives us a chance to fix anything on our machine that is a security
|
|
hole the RBG's can use.
|
|
<p>
|
|
<hr>
|
|
<h2><center><a name="tcpd">tcpd</a></center></h2>
|
|
<hr>
|
|
<p>
|
|
There's a daemon that's probably been installed on your machine that you don't
|
|
know about. Or at least, you're not aware of what it can do. It's called
|
|
<i>tcpd</i>, and it's how we shut off access to some of the basic services
|
|
that the Bad Guys can use to get on our system.
|
|
<p>
|
|
Since <i>tcpd</i> can be pretty complex, I'm not going to go into all the
|
|
details and tell you how to do the fancy stuff. The goal here is to keep the
|
|
mischievous gibbons from knocking down what it took so long for use to set
|
|
up.
|
|
<p>
|
|
<i>tcpd</i> is called into action from another daemon, <i>inetd</i>, whenever
|
|
someone tries to access a service like in.telnetd, wu.ftpd, in.fingerd,
|
|
in.rshd, etc. <i>tcpd</i>'s job is to look at two files and determine if
|
|
the person who is trying to access the service has permission or not.
|
|
<p>
|
|
The files are <i>/etc/hosts.allow</i> and <i>/etc/hosts.deny</i>. Here's
|
|
how it all works:
|
|
<p>
|
|
<ol>
|
|
<li> Someone tries to use a service that <i>tcpd</i> is monitoring.
|
|
<li> <i>tcpd</i> wakes up, and makes a note of the attempt to the syslog.
|
|
<li> <i>tcpd</i> then looks <i>hosts.allow</i>
|
|
<ul>
|
|
<li> if it finds a match, <i>tcpd</i> goes back to sleep and lets the user
|
|
access the service.</li>
|
|
</ul>
|
|
<li> <i>tcpd</i> now takes a look at <i>hosts.deny</i></li>
|
|
<ul>
|
|
<li>if it finds a match, <i>tcpd</i> closes the user's connection</li>
|
|
</ul>
|
|
<li> If it can't find a match in either file, or if both files are empty,
|
|
<i>tcpd</i> shrugs, guesses it's OK to let the user on, and goes
|
|
back to sleep.</li>
|
|
</ol>
|
|
<p>
|
|
Now, there are a couple of things to note here. First, if you haven't edited
|
|
<i>hosts.allow</i> or <i>hosts.deny</i> since you installed Linux, then
|
|
<i>tcpd</i> assumes that you want to let everyone have access to your machine.
|
|
The second thing to note is that if <i>tcpd</i> finds a match in
|
|
<i>hosts.allow</i>, it stops looking. In other words, we can put an entry
|
|
in <i>hosts.deny</i> and deny access to all services from all machines, and
|
|
then list ``friendly'' machines in the <i>hosts.allow</i> file.
|
|
<p>
|
|
Let's take a look at the man page. You'll find the info you need by typing
|
|
<b>man 5 hosts_access</b> (don't forget the 5 and the underscore).
|
|
<p>
|
|
<pre>
|
|
daemon_list : client_list
|
|
|
|
daemon_list is a list of one or more daemon process names
|
|
or wildcards
|
|
|
|
client_list is a list of one or more host names, host
|
|
addresses, patterns or wildcards that will be matched
|
|
against the remote host name or address.
|
|
|
|
List elements should be separated by blanks and/or commas.
|
|
</pre>
|
|
<p>
|
|
Now, if you go take a look at the man page, you'll notice that I didn't show
|
|
you everything that was in there. The reason for that is because the extra
|
|
option (the shell_command) can be used to do some neat stuff, but *most
|
|
Linux distributions have not enabled the use of this option in their tcpd
|
|
binaries*. We'll save how to do this for an article on <i>tcpd</i> itself.
|
|
<p>
|
|
If you absolutely have to have this option, get the source from
|
|
<a href="ftp://ftp.funet.fi/pub/Linux/PEOPLE/Linus/net-source/base/tcp_wrappers_7.4.tar.gz">
|
|
here</a> and recompile.
|
|
<p>
|
|
Back to business. What the above section from the <i>hosts_access</i> man
|
|
page was trying to say is that the format of
|
|
<i>hosts.</i>[<i>allow</i>|<i>deny</i>] is made up of a list of services and
|
|
a list of host name patterns, separated by a ``:''
|
|
<p>
|
|
You'll find the name of the services you can use by looking in your
|
|
<i>/etc/inetd.conf</i>...they'll be the ones with <i>/usr/sbin/tcpd</i>
|
|
set as the server path.
|
|
<p>
|
|
The rules for determining host patterns are pretty simple, too:
|
|
<p>
|
|
<ul>
|
|
<li> if you want to match all hosts in a domain, put a ``.'' at the front.</li>
|
|
<ul>
|
|
<li>Ex: <i>.bar.com</i> will match "foo.bar.com", "sailors.bar.com",
|
|
"blue.oyster.bar.com", etc.</li>
|
|
</ul>
|
|
<p>
|
|
<li> if you want to match all IPs in a domain, put a "." at the end.</li>
|
|
<ul>
|
|
<li>Ex: <i>192.168.1.</i> will match "192.168.1.1", "192.168.1.2",
|
|
"192.168.1.3", etc.</li>
|
|
</ul>
|
|
</ul>
|
|
<p>
|
|
And finally, there are some wildcards you can use:
|
|
<ul>
|
|
<li><i>ALL</i> matches everything. If in daemon_list, matches all daemons;
|
|
if in client_list, it matches all host names.</li>
|
|
<ul>
|
|
<li> Ex: <i>ALL : ALL</i> would match any machine trying to get to any
|
|
service.</li>
|
|
</ul>
|
|
<p>
|
|
<li><i>LOCAL</i> matches host names that don't have a dot in them.</li>
|
|
<ul>
|
|
<li> Ex: <i>ALL : LOCAL</i> would match any machine that is inside the
|
|
domain or search aliases given in your <i>/etc/resolv.conf</i></li>
|
|
</ul>
|
|
<p>
|
|
<li><i>except</i> isn't really a wildcard, but it comes in useful. It excludes
|
|
a pattern from the list.</li>
|
|
<ul>
|
|
<li> Ex: <i> ALL : ALL except .leetin-haxor.org</i> would match all services
|
|
to anyone who is not from ``*.leetin-haxor.org'' </li>
|
|
</ul>
|
|
</ul>
|
|
<p>
|
|
Ok. Enough technical stuff. Let's get to some examples.
|
|
<p>
|
|
Let's pretend we have a home LAN, and a computer for each member of the family.
|
|
<p>
|
|
Our home network looks like this:
|
|
<p>
|
|
<pre>
|
|
linux.home.net 192.168.1.1
|
|
dad.home.net 192.168.1.2
|
|
mom.home.net 192.168.1.3
|
|
sis.home.net 192.168.1.4
|
|
bro.home.net 192.168.1.5
|
|
</pre>
|
|
<p>
|
|
Now, since no one in the family is likely to try and ``hack root,'' we can
|
|
assume they're all friendly. But....we're not so sure about the rest of
|
|
the people on the Internet. Here's how we go about setting things up so
|
|
people on home.net have full access to our machine, but no one else does.
|
|
<p>
|
|
In <i>/etc/hosts.allow</i>:
|
|
<p>
|
|
<pre>
|
|
# /etc/hosts.allow for linux.home.net
|
|
|
|
ALL: .home.net
|
|
</pre>
|
|
<p>
|
|
And in <i>/etc/hosts.deny</i>
|
|
<p>
|
|
<pre>
|
|
# /etc/hosts.deny for linux.home.net
|
|
|
|
ALL : ALL
|
|
</pre>
|
|
<p>
|
|
Since <i>tcpd</i> looks at <i>hosts.allow</i> first, we can safely deny
|
|
access to all services for everybody. If <i>tcpd</i> can't match the machine
|
|
sending the request to ``*.home.net'', the connection gets refused.
|
|
<p>
|
|
Now, let's pretend that Mom has been reading up on how Unix stuff works,
|
|
and she's started doing some unfriendly stuff on our machine. In order
|
|
to deny her access to our machine, we simply change the line in <i>
|
|
hosts.allow</i> to:
|
|
<p>
|
|
<pre>
|
|
ALL: .home.net except mom.home.net
|
|
</pre>
|
|
<p>
|
|
Now, let's pretend a friend from....uh....friend.com wants to get something
|
|
off our ftp server. No problem, just edit <i>hosts.allow</i> again:
|
|
<p>
|
|
<pre>
|
|
# /etc/hosts.allow for linux.home.net
|
|
|
|
ALL: .home.net except mom.home.net
|
|
wu.ftpd: .friend.com
|
|
</pre>
|
|
<p>
|
|
Things are looking good. The only problem is that the name server for
|
|
home.net is sometimes down, and the only way we can identify someone as
|
|
being on home.net is through their IP address. Not a problem:
|
|
<p>
|
|
<pre>
|
|
# /etc/hosts.allow for linux.home.net
|
|
|
|
ALL: .home.net except mom.home.net
|
|
ALL: 192.168.1. except 192.168.1.3
|
|
ALL: .friend.com
|
|
</pre>
|
|
<p>
|
|
And so on....
|
|
<p>
|
|
I have found that's it's easier to deny everybody access, and list your
|
|
friends in <i>hosts.allow</i> than it is to allow everybody access, and
|
|
deny only the people who you know are RBG's. If you are running a private
|
|
machine, this won't really be a problem, and you can rest easy.
|
|
<p>
|
|
However, if you're trying to run a public service (like an ftp archive of
|
|
Tetris games for different OS's) and you can't afford to be this paranoid,
|
|
then you need shouldn't put anything in <i>hosts.allow</i>, and just put
|
|
all of the people you don't want touching your machine in <i>hosts.deny</i>
|
|
<p>
|
|
You might also want to take a look at the next section.
|
|
<p>
|
|
<hr>
|
|
<h2><center><a name="other">Other things to keep in mind</a></center></h2>
|
|
<hr>
|
|
<p>
|
|
<h4>Security holes in software</h4>
|
|
<p>
|
|
Like I said earlier, a lot of the software that comes standard in CD-ROMs have
|
|
security holes in them which could let local or even remote users execute
|
|
commands as root on your system. Keep an eye on
|
|
<a href="http://bach.cis.temple.edu/linux/linux-security"> Linux ALERTS</a>
|
|
to find out about problems we know about and how to fix them.
|
|
<p>
|
|
<h4>What services you offer</h4>
|
|
<p>
|
|
Check to make sure that the services you have running on your machine are
|
|
what you really want to offer. For example, most of us don't have a need
|
|
to run <i>in.nntpd</i>, yet it's got an entry in <i>/etc/inetd.conf</i>.
|
|
Do you really want everyone on the Internet to have access to
|
|
<i>in.fingerd</i>? Do you really need to let everyone on the Internet have
|
|
access to your ftp server?
|
|
<p>
|
|
Find what you don't need (or don't want to offer to any passing stranger who
|
|
might happen across your machine) and either shut it down or deny outside
|
|
access to it.
|
|
<p>
|
|
<h4>Passwords</h4>
|
|
<p>
|
|
Yeah, yeah, yeah. Everyone's heard the speech about passwords, but they
|
|
are pretty important. Especially if you're not restricting access to your
|
|
machine. Remember, if they can get to your machine, they can get on your
|
|
machine. And if they can get on your machine, they can get root access.
|
|
<p>
|
|
In case you haven't heard the speech, here's the condensed version:
|
|
<ol>
|
|
<li>Make the passwords at least 6 characters long.</li>
|
|
<li>Mix the case of the passwords.</li>
|
|
<li>Use at least one numeral.</li>
|
|
<li>Use at least one non-alphanumeric character.</li>
|
|
<li><b>Change the passwords on a regular basis</b>. About once every<br>
|
|
two months should do for the casual user.</li>
|
|
</ol>
|
|
I have found that using "k-rad" or "leet-speak" helps when you need to
|
|
make up a password. For example, instead of using the password
|
|
"foobar", try using "f00b4R!".
|
|
<p>
|
|
Also, get and install shadow passwords. You might have to recompile a
|
|
few services, but it's worth the extra protection.
|
|
<p>
|
|
Finally, it is important to note that only the first 8 characters of the
|
|
password get used under Linux's login. In other words, if you have a password
|
|
that looks like <i>abcdefghijklmnopqrstuvwxyz</i>, you will only need to enter
|
|
<i>abcdefhg</i> in order to gain access to the account. This holds true
|
|
whether you are using shadowed passwords or not.
|
|
<p>
|
|
<pre>[ Thanks to Olav Wölfelschneider for pointing that out. ]</pre>
|
|
<p>
|
|
<h4>File Permissions</h4>
|
|
<p>
|
|
Many of the security holes that exist are because the files are "setuid".
|
|
That means that a non-root user can execute the files as root. Remove
|
|
this permission from any files that don't need it. Like <i>mount</i>.
|
|
It really isn't that much of a hassle to keep one of your virtual
|
|
consoles logged in as root, and flip over to it when you need to get
|
|
something done.
|
|
<p>
|
|
Also, if you have stuff sitting somewhere that you don't want anyone else
|
|
to see, don't give them world rwx permission on the dir.
|
|
<p>
|
|
<h4>Keep an eye on the syslog</h4>
|
|
<p>
|
|
At least once a day, you need to go check the syslog and see what's been
|
|
happening. You can find it <i>/var/adm/syslog</i>, and I'd also recommend
|
|
taking a peek at <i>/var/adm/messages</i>. You'll want to look for
|
|
multiple connections coming from places you don't know in a short period
|
|
of time. If they look suspicious, then don't hesitate to slap an entry
|
|
for the domain into <i>/etc/hosts.deny</i>
|
|
<p>
|
|
<h4>Who you trust</h4>
|
|
<p>
|
|
This is just common sense. It's not a wise idea to give out your root password
|
|
to someone you just met on IRC 5 minutes ago who claims they can get Apache
|
|
up and running on your system if you just tell them the root password.
|
|
<p>
|
|
Set up a guest account with limited read, write, execute abilities and let them
|
|
use that.
|
|
<p>
|
|
It's also not wise to let people just log in and fiddle around on your machine.
|
|
Despite common belief, it is possible to create Unix ``viruses,'' and all you
|
|
really need is the knowledge, the will, and an opportunity. For more
|
|
information, see the paper on
|
|
<a href="http://www.cyber.com/papers/plausibility.html">The Plausibility of
|
|
Unix Virus Attacks</a>
|
|
<p>
|
|
<hr>
|
|
<p>
|
|
<h3>Final Word</h3>
|
|
<p>
|
|
To be completely honest with you, the only way to be 100% sure your machine
|
|
can't be compromised is to physically deny access to it. That means get
|
|
rid of the modem and ethernet card, fill up any hole in the computer's case
|
|
with cement, and buy a big, mean pit bull to guard it while you are asleep.
|
|
<p>
|
|
Well, maybe that's going a bit far. But the point is, if they can't get to
|
|
your machine, they can't do anything to it. If you think your machine has
|
|
been compromised, disconnect it from the network, look through the
|
|
<i>syslog</i>, try to find out how it was compromised, fix the problem,
|
|
set all new passwords for your accounts, and then reconnect it.
|
|
<p>
|
|
We might not be able to make the machine 100% secure, but we can make
|
|
it hard for the Bad Guys to do their thing.
|
|
<hr>
|
|
Email:<a href="mailto:mars@loeffel.txdirect.net">
|
|
<i>mars@loeffel.txdirect.net</i></a>
|
|
|
|
<!--===================================================================-->
|
|
<P> <hr> <P>
|
|
<center><H5>Copyright © 1997, Marsala <BR>
|
|
Published in Issue 14 of the Linux Gazette</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="./linus.html"><IMG SRC="../gx/back2.gif"
|
|
ALT=" Back "></A>
|
|
<A HREF="./mutt.html"><IMG SRC="../gx/fwd.gif" ALT=" Next "></A>
|
|
<P> <hr> <P>
|
|
</BODY>
|
|
</HTML>
|