802 lines
42 KiB
HTML
802 lines
42 KiB
HTML
<!--startcut ==============================================-->
|
|
<!-- *** BEGIN HTML header *** -->
|
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
|
<HTML><HEAD>
|
|
<title>A Private Home Network LG #65</title>
|
|
</HEAD>
|
|
<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#0000AF"
|
|
ALINK="#FF0000">
|
|
<!-- *** END HTML header *** -->
|
|
|
|
<CENTER>
|
|
<A HREF="http://www.linuxgazette.com/">
|
|
<H1><IMG ALT="LINUX GAZETTE" SRC="../gx/lglogo.png"
|
|
WIDTH="600" HEIGHT="124" border="0"></H1></A>
|
|
|
|
<!-- *** BEGIN navbar *** -->
|
|
<IMG ALT="" SRC="../gx/navbar/left.jpg" WIDTH="14" HEIGHT="45" BORDER="0" ALIGN="bottom"><A HREF="steffler.html"><IMG ALT="[ Prev ]" SRC="../gx/navbar/prev.jpg" WIDTH="16" HEIGHT="45" BORDER="0" ALIGN="bottom"></A><A HREF="index.html"><IMG ALT="[ Table of Contents ]" SRC="../gx/navbar/toc.jpg" WIDTH="220" HEIGHT="45" BORDER="0" ALIGN="bottom" ></A><A HREF="../index.html"><IMG ALT="[ Front Page ]" SRC="../gx/navbar/frontpage.jpg" WIDTH="137" HEIGHT="45" BORDER="0" ALIGN="bottom"></A><A HREF="http://www.linuxgazette.com/cgi-bin/talkback/all.py?site=LG&article=http://www.linuxgazette.com/issue65/stumpel.html"><IMG ALT="[ Talkback ]" SRC="../gx/navbar/talkback.jpg" WIDTH="121" HEIGHT="45" BORDER="0" ALIGN="bottom" ></A><A HREF="../faq/index.html"><IMG ALT="[ FAQ ]" SRC="./../gx/navbar/faq.jpg"WIDTH="62" HEIGHT="45" BORDER="0" ALIGN="bottom"></A><A HREF="sunil.html"><IMG ALT="[ Next ]" SRC="../gx/navbar/next.jpg" WIDTH="15" HEIGHT="45" BORDER="0" ALIGN="bottom" ></A><IMG ALT="" SRC="../gx/navbar/right.jpg" WIDTH="15" HEIGHT="45" ALIGN="bottom">
|
|
<!-- *** END navbar *** -->
|
|
<P>
|
|
</CENTER>
|
|
|
|
<!--endcut ============================================================-->
|
|
|
|
<H4 ALIGN="center">
|
|
"Linux Gazette...<I>making Linux just a little more fun!</I>"
|
|
</H4>
|
|
|
|
<P> <HR> <P>
|
|
<!--===================================================================-->
|
|
|
|
<center>
|
|
<H1><font color="maroon">A Private Home Network</font></H1>
|
|
<H4>By <a href="mailto:jstumpel from zonnet dot nl">Jan Stumpel</a></H4>
|
|
</center>
|
|
<P> <HR> <P>
|
|
|
|
<!-- END header -->
|
|
|
|
|
|
|
|
|
|
<h3>
|
|
1. Introduction</h3>
|
|
Until recently I paid little attention to the security of my home network
|
|
for the following reasons:
|
|
<ul>
|
|
<li>
|
|
A dial-up home installation will not attract much attention from crackers.</li>
|
|
|
|
<li>
|
|
Linux is safe anyhow, compared to MS Windows.</li>
|
|
|
|
<li>
|
|
The people who put together my Linux distribution have surely taken
|
|
security into account.</li>
|
|
|
|
<li>
|
|
I took some security measures (hosts.allow, hosts.deny, ipchains) following
|
|
the examples in the HOWTO's.</li>
|
|
|
|
<li>
|
|
I don't understand this security business anyway.</li>
|
|
</ul>
|
|
Common human psychology suggests that this is how many ordinary Linux users
|
|
think. In my case, unfortunately, all these points turned out to be pure
|
|
wishful thinking, apart from the last one. <i>Because of </i>the
|
|
last one.
|
|
<p>How did I find this out? In order to prepare for the happy day in the
|
|
future when permanent, high-speed connections to the Internet will be offered
|
|
in my area, I decided it was a good idea to start investigating security
|
|
issues. The results were shocking.
|
|
<p>The first shock came from looking at my long-neglected <tt>/var/log/syslog*
|
|
</tt>files.
|
|
A few 'refused connect from' entries. One 'connect from' to ftp which apparently
|
|
succeeded. Oops. Dial-up Internet users are not overlooked by the crackers
|
|
after all. And my security is not bullet-proof. Better to spend some time
|
|
really looking at security. And to try to <i>understand</i> something of
|
|
it this time. So this meant reading books, FAQ's, HOWTO's, and a lot of
|
|
articles on the Web; and doing some experiments.
|
|
<p>This is the result of my investigations. Mind: I am not an expert, but
|
|
just an amateur, a home user trying to make things work. Nothing of this
|
|
comes with any guarantee.
|
|
<h3>
|
|
2. The system</h3>
|
|
I have a very simple home network with two machines:
|
|
<ul>
|
|
<li>
|
|
<b>earth</b> is a Win 95 machine without printer or modem.</li>
|
|
|
|
<li>
|
|
<b>heaven</b> runs Debian Linux 2.1 (with various upgrades). It runs exim
|
|
(for local mail service and for sending mail <i>to</i> the outside world),
|
|
qpopper (pop3 server for use by <b>earth</b>), and samba (to provide file
|
|
sharing and printing to <b>earth</b>). <b>heaven</b> connects on-demand
|
|
to the ISP, opening a modem (ppp) link. Mail <i>from</i> the outside world
|
|
is collected by means of fetchmail.</li>
|
|
</ul>
|
|
This local network uses one of the IP address ranges reserved for private
|
|
networks, 192.168.1.0/24. <b>heaven</b> is 192.168.1.1, <b>earth</b> is
|
|
192.168.1.2.
|
|
<p>The contents of <tt>/etc/hosts</tt> on <b>heaven</b>, and <tt>c:\windows\hosts</tt>
|
|
on <b>earth</b>, is:
|
|
<blockquote><tt>127.0.0.1
|
|
localhost</tt>
|
|
<br><tt>192.168.1.1
|
|
heaven.my.home heaven</tt>
|
|
<br><tt>192.168.1.2
|
|
earth.my.home earth</tt></blockquote>
|
|
This shows that my network uses the domain name <tt>my.home</tt>. This
|
|
name is unregistered and meant only for local use. Mail to the outside
|
|
will have its 'message from' and 'envelope from' addresses translated (in
|
|
the <a href="#jwexim">July</a> and <a href="#jwsmtp">September</a> issues,
|
|
1999, of <i>LG</i> I described how to do this).
|
|
<h3>
|
|
3. 'Private' home networks</h3>
|
|
My notion of security is to have a private network. By this I mean a network
|
|
that provides <i>no public functions</i>. It does not serve WWW pages or
|
|
files. You cannot telnet into it. It does not even <i>listen</i> to anything
|
|
coming in from the outside. If anyone comes knocking, there is simply <i>no
|
|
response</i>. This idea was recently put forward by <i>Sander Plomp</i>,
|
|
whose <a href="#fortress1">articles</a> at rootprompt.org provided much
|
|
of the inspiration for this piece.
|
|
<p>A LAN which is not connected to the Internet is a private network by
|
|
definition. Unplug your modem, and you make your network private. But that
|
|
is a not the kind of private network that I mean. I want to use the Net,
|
|
send and receive mail, browse the Web, download files, etc. I just do not
|
|
want anyone from the outside to <i>enter</i> my network.
|
|
<p>Linux systems generally <i>aren't</i> private networks. By default,
|
|
the installation procedure of a Linux distribution sets up all sort of
|
|
nice network services (like telnet, ftp, finger, etc.) which are accessible
|
|
by anyone in the world, protected (if at all) only by a password. Also,
|
|
Microsoft Windows home LAN's are generally
|
|
<i>not</i> private. Connect
|
|
two Win95 computers and enable 'file sharing', and the whole world can
|
|
share your files while your Internet connection is up.
|
|
<p>To make non-private networks safe, various techniques are used; passwords
|
|
of course, and also other security techniques that have been discussed
|
|
in the Linux Gazette many times, like tcpd (alias tcp wrappers) and kernel-level
|
|
packet filtering (with ipchains as the user interface). These techniques
|
|
give some privacy to a system which is essentially
|
|
<i>public</i>. They
|
|
are like guards at the door, put there to keep out unwanted characters,
|
|
while letting the desirable customers in. But why should there be doors
|
|
<i>at
|
|
all</i>? I don't <i>want</i> any customers. My network is <i>private</i>!
|
|
<p>If we have servers running, reachable by the outside world, we always
|
|
have to worry about having made some configuration mistake which can be
|
|
exploited. Also, server programs often have bugs in them which offer openings
|
|
to crackers. Only recently one was discovered in <tt>named</tt>. OK, it
|
|
was later patched, so people who got the newest version of <tt>named</tt>
|
|
do not have to worry anymore about <i>this</i> bug. But what about the
|
|
next one? Better not to to have any doors at all!
|
|
<p>If you really <i>want</i> to enable services (mp3 distribution, or whatever)
|
|
for use by computers outside your home, you must study more advanced security
|
|
techniques. But if you simply want a <i>private</i> network for the home,
|
|
read on.
|
|
<h3>
|
|
4. How safe <i>is</i> your network?</h3>
|
|
To test the safety of a home network, you can have it 'scanned' from the
|
|
outside, for instance by <i><a href="http://www.sdesign.com/securitytest">Secure
|
|
Design</a></i>. Click 'scan me now' and 'basic scan'. Try it both from
|
|
the gateway machine and from the other machines on your network. When I
|
|
did this, I got the second shock. It was embarrassing. A long list showing
|
|
possible entry points into my system: Samba shares, telnet, the print service,
|
|
X, the mail server, ftp, finger, etc. I had some rudimentary safety measures
|
|
in place, so the system was somewhat protected from serious intrusion (I
|
|
hope). But I consider it a breach of my privacy that the outside world
|
|
even <i>knows</i> that I have a mail server (let alone letting them break
|
|
into it). These services were meant for use within my home network. They
|
|
are not the business of the outside world in any way.
|
|
<p>So: have your system scanned! Apart from Secure Design, other scan services
|
|
exist, e.g. <i><a href="https://grc.com/x/ne.dll?bh0bkyd2">Shields Up!</a></i>,
|
|
<i><a href="http://www.dslreports.com/scan">DSL
|
|
Reports</a></i>,
|
|
<i><a href="http://scan.sygatetech.com">Sygate Online
|
|
Services</a></i>, and many others. A whole lot of them can be found at
|
|
an Austrian site,
|
|
<i><a href="http://www.home.pages.at/heaven/sec0185.htm">Sicherheit
|
|
im Kabelnetzwerk</a></i> ('Security in the Cable Network'; there is also
|
|
an English version with almost the same information). Use several scan
|
|
services. Print the results. What this 'scanning' actually means will hopefully
|
|
become clearer in the course of this article.
|
|
<p>You can also 'scan' your system yourself by calling (after <tt>su</tt>-ing
|
|
to <tt>root</tt>) <tt>netstat -pan --inet</tt>. Use a wide xterm window
|
|
when doing this, because the output consists of rather long lines. Programs
|
|
which have 0.0.0.0 in the 'Local Address' column are visible to the whole
|
|
world!
|
|
<h3>
|
|
5. Servers and clients</h3>
|
|
The distinction between servers and clients is not always clear to users.
|
|
If you want to use ftp, for instance (getting files from, and putting files
|
|
into, another computer) you use an ftp <i>client program</i> to connect
|
|
to the other computer. If that is all you want to do with ftp, the client
|
|
program is all you need. An ftp <i>server</i> is only needed if you want
|
|
to allow others to get files from, or put them into, <i>your</i> computer.
|
|
Similarly with telnet: a client program for your <i>own</i> use, a server
|
|
program for <i>other</i> peoples' use. The client and server programs are
|
|
completely different and have different names; for instance <tt>/usr/bin/telnet</tt>
|
|
for the telnet client, <tt>/usr/sbin/in.telnetd</tt> for the server. For
|
|
novices, the distinction is not always clear. If a Linux setup program
|
|
asks 'shall I set up the ftp server?', users may think 'well eh.. yes,
|
|
I certainly want to use ftp, so go ahead'. Often you are not even asked,
|
|
and an ftp server is installed by default.
|
|
<p>One way of creating a private network is not to install servers at all,
|
|
just clients. But that is too simple if you have a network at home connecting
|
|
two or more computers. <i>Inside</i> your network you want to telnet from
|
|
one machine to another, you want to run an internal mail service, etc.
|
|
In other words you can't do without servers.
|
|
<p>What servers do is <i>listen.</i> They listen for a signal that says:
|
|
<i>I
|
|
want your service</i>. The signal (at least for the TCP-based services)
|
|
is a special IP packet, called a SYN packet, that enters your computer
|
|
and specifies the number of a service. For instance, the number of the
|
|
telnet service (that the
|
|
<tt>in.telnetd</tt> program, if it is running,
|
|
listens to) is 23. These numbers are usually called 'port numbers'. If
|
|
the <tt>in.telnetd</tt> program is <i>not</i> running, no one listens to
|
|
SYN packets with the number 23. So, as they say, 'port 23 is closed'.
|
|
<p>Ports do not exist by themselves, like little doors in your computer
|
|
that you can open or close. A port is open if a server listens to it. Otherwise
|
|
it is closed. A TCP port comes into existence if there is a program which
|
|
listens to it, and if not, it does not exist!
|
|
<p>How do the SYN packets get into your computer? In the case of <b>heaven</b>,
|
|
a packet can get 'into' it in three different ways:
|
|
<ul>
|
|
<li>
|
|
packets sent from <b>earth</b> come in via the Ethernet card (also called
|
|
the eth0 interface); they are addressed to the fixed IP address 192.168.1.1.</li>
|
|
|
|
<li>
|
|
packets from the outside world come in through the ppp link, or ppp0 interface;
|
|
that also has an IP address, but is is not fixed. At every Internet session
|
|
the ISP hands out a 'dynamic' address, valid for this session only.</li>
|
|
|
|
<li>
|
|
packets can also be sent from <b>heaven</b> itself, addressed to itself
|
|
as it were. This way of sending packets is often used for testing; the
|
|
packets are addressed to the so-called loopback interface with address
|
|
127.0.0.1. The name <b>localhost</b> refers to this loopback interface,
|
|
while the name <b>heaven</b> refers to 192.168.1.1. (This is a rather important
|
|
point: names and IP addresses refer to <i>interfaces</i>, not to computers,
|
|
although in daily usage this distinction is often blurred.)</li>
|
|
</ul>
|
|
Now the key point is that servers normally listen for any packets with
|
|
'their' port number, <i>no matter which way they enter the system</i>.
|
|
If we want to make a private network, offering no services to the outside
|
|
world, we must somehow change this.
|
|
<p>It would be nice if all the server programs available on Linux systems
|
|
had options specifying <i>which</i> interfaces they will listen to. In
|
|
that case you could just tell all your servers never to listen to the ppp
|
|
line, and you'd be all set. Hardly any security measures would be needed
|
|
at all (tcpd, firewalls, etc.); you would only use them 'for good measure',
|
|
as an extra precaution. Maybe this will happen at some time in the future,
|
|
but at the moment only a few server programs have this (including the important
|
|
cases of exim and samba). So we have to do several things to make our network
|
|
private:
|
|
<ol>
|
|
<li>
|
|
it never hurts to follow the commonly-heard advice to 'close unneeded ports',
|
|
in other words not to run servers that you do not need.</li>
|
|
|
|
<li>
|
|
for services that have the option, make them listen to internal interfaces
|
|
(eth0 and, if necessary, loopback) only.</li>
|
|
|
|
<li>
|
|
the 'super-server' <tt>inetd</tt> (which is used for 'waking up' a lot
|
|
of different servers on a Linux system) should be replaced by <b><tt><a href="http://www.xinetd.org">xinetd</a></tt></b>,
|
|
which has the option to listen to internal interfaces only. <i>NOTE</i>:
|
|
apparently, Red Hat Linux 7.0 installs <tt>xinetd</tt> by default.</li>
|
|
|
|
<li>
|
|
unsafe servers which cannot run from <tt>xinetd</tt> (like the print server
|
|
<tt>lpd)</tt>
|
|
should, where possible, be replaced.</li>
|
|
|
|
<li>
|
|
for the remaining difficult cases you need a firewall that blocks SYN packets
|
|
from the outside. This could also be used for blocking unwanted UDP and
|
|
ICMP access.</li>
|
|
|
|
<li>
|
|
for 'advanced' security, a few other possibilities suggest themselves.
|
|
One is <i>not</i> to use IP masquerading and forwarding on your network.</li>
|
|
</ol>
|
|
|
|
<h3>
|
|
6. Removing unneeded services</h3>
|
|
|
|
<h4>
|
|
6.1 Unnecessary <tt>inetd</tt> services</h4>
|
|
First, there are some services which run 'from inetd.conf'. Almost all
|
|
Linux systems have a 'super-server' called <tt>inetd</tt>, whose job it
|
|
is to listen to a lot of ports at the same time, and to 'wake up' services
|
|
when needed. However, it will also wake up services which you do
|
|
<i>not
|
|
</i>need.
|
|
<p>Examples of unneeded services are:
|
|
<ul>
|
|
<li>
|
|
the ftp server. I do not plan to serve any files to the outside world,
|
|
and internally on my network I can use Samba (and smbfs) to transfer files.
|
|
Not having an ftp <i>server</i> in no way stops you from running an ftp
|
|
<i>client</i>
|
|
when you want to, and to exchange files with the outside world. But most
|
|
distributions, including Debian, install an ftp server by default.</li>
|
|
|
|
<li>
|
|
the portmapper and anything related to RPC calls (same reason). The portmapper
|
|
is used for allowing remote procedure calls. Basically you need this if
|
|
you use NFS. But I do not use NFS (Samba, which I need anyway because there
|
|
is a Win95 machine on the network, provides enough file sharing facilities).
|
|
So anything related to the portmapper and RPC can be commented out from
|
|
inetd.conf.</li>
|
|
|
|
<li>
|
|
finger and ident. About the usefulness or otherwise of 'ident', opinions
|
|
seem to be divided. I removed it, and did not suffer any ill effects.</li>
|
|
|
|
<li>
|
|
several other obviously unnecessary things that can be started up from
|
|
<tt>inetd.conf</tt> (like <tt>saft</tt>).</li>
|
|
|
|
<li>
|
|
several services in <tt>inetd.conf</tt> which are used only for testing
|
|
networks: <tt>echo</tt>, <tt>chargen</tt> (pronounced <i>kargen,</i> 'character
|
|
generator'), <tt>discard</tt>, <tt>daytime</tt>, and <tt>time</tt>. The
|
|
last two (in case you are worried) have nothing to do with <i>timekeeping</i>
|
|
on your system; they are just services which will tell your system's time
|
|
to others. You don't need them, nor any of the other 'test' services.</li>
|
|
</ul>
|
|
These services can all be disabled by commenting out (putting a # character
|
|
at the beginning of) the corresponding lines in <tt>/etc/inetd.conf</tt>,
|
|
and restarting <tt>inetd</tt> (in Debian: <tt>/etc/init.d/inetd restart</tt>).
|
|
<h4>
|
|
6.2 Other unnecessary services</h4>
|
|
If a service is not woken up by <tt>inetd</tt>, it runs independently,
|
|
as a 'daemon' or background program. Among the daemons which you
|
|
may not need, apart from the portmapper (if run as a daemon) is a local
|
|
nameserver (<tt>named</tt>, pronounced <i>name-dee</i>). There is no reason
|
|
why a small home network should run such a thing. <tt>/etc/hosts</tt> and
|
|
<tt>C:\windows\hosts</tt>
|
|
files on your machines, and the addresses of your ISP's name servers in
|
|
<tt>/etc/resolv.conf</tt>
|
|
will enable address lookup on your network.
|
|
<p>There is usually a command to prevent a service from starting automatically
|
|
upon boot-up, by removing it from the start-up directories; for instance
|
|
I got rid of a <i>tamagotchi server</i>, automatically installed by Debian
|
|
2.1, by calling
|
|
<blockquote><tt>update-rc.d -f /etc/init.d/tama remove</tt></blockquote>
|
|
|
|
<h3>
|
|
7. Securing wanted services: non-<tt>inetd</tt></h3>
|
|
Now we tackle services that we <i>do</i> want to use, but do not want to
|
|
be visible to the outside world. Often there is some configuration option
|
|
that will keep the service 'private'. Examples follow.
|
|
<h4>
|
|
7.1 X</h4>
|
|
X was designed as a network-oriented window system, but in fact the network
|
|
features are never used in most setups, and present a security risk. You
|
|
can eliminate X's network capabilities by starting X with a command-line
|
|
option: <tt>startx -- -nolisten tcp</tt>. Secure Design now no longer reports
|
|
that 'X11 is open'. To make this permanent, you can make an alias
|
|
for <tt>startx</tt> in<tt> ~/.bashrc, /etc/profile</tt>, or some other
|
|
good location, like this:
|
|
<blockquote><tt>alias startx="startx -- -nolisten tcp"</tt></blockquote>
|
|
The <tt>-nolisten tcp</tt> command should really be in one of the X11 resource
|
|
files, but so far I haven't found out which one. The 'alias' approach works
|
|
in any case. To test, run (as root) <tt>netstat -pan --inet</tt>. X should
|
|
no longer be mentioned. Of course it would be nicer if we could keep X's
|
|
network abilities for the local network, only blocking them against outside
|
|
access, but I couldn't find a way to do that.
|
|
<h4>
|
|
7.2 Samba</h4>
|
|
In a Debian system, the configuration file for Samba is <tt>/etc/samba/smb.conf</tt>
|
|
(on other systems, it may be <tt>/etc/smb.conf</tt>).<tt> </tt>When installing
|
|
Samba, I chose 'let Samba run as daemons'; it did not work properly from
|
|
<tt>inetd</tt>.
|
|
Any lines referring to netbios (which is what Samba uses) in <tt>/etc/inetd.conf</tt>
|
|
must therefore be commented out. Then in <tt>/etc/samba/smb.conf</tt>,
|
|
section <tt>[global]</tt>, I added
|
|
<blockquote><tt> bind interfaces only = True</tt>
|
|
<br><tt> interfaces = 192.168.1.1</tt></blockquote>
|
|
After <tt>/etc/init.d/samba restart</tt>, the Samba daemons only listen
|
|
to our home LAN. They are no longer visible to the outside world. Check
|
|
with <tt>netstat -pan --inet</tt>, and by having the system scanned.
|
|
<h4>
|
|
7.3 Exim</h4>
|
|
Exim is the mail server (or Mail Transport Agent, MTA) on my system. You
|
|
may have something else (like sendmail or postfix) but then the same principle
|
|
applies: your private mail agent should <i>not listen</i> to the outside
|
|
world. People who send mail to you, and to the other users in your home,
|
|
send it to mail accounts at the ISP (or to several mail accounts at different
|
|
ISP's). You retrieve it from there using, e.g., <tt>fetchmail</tt>. People
|
|
cannot send mail to your network <i>directly</i>.
|
|
<p>Exim turns out to have an option <tt>local_interfaces</tt> (which goes
|
|
into the <tt>MAIN CONFIGURATION</tt> section of <tt>/etc/exim.conf</tt>).
|
|
This is a list of (IP addresses of) interfaces that exim will listen to.
|
|
This only works when exim runs as a daemon, independent of <tt>inetd</tt>.
|
|
To set this up:
|
|
<ul>
|
|
<li>
|
|
In <tt>/etc/exim.conf</tt>, in the <tt>MAIN CONFIGURATION</tt> section,
|
|
enter a line:</li>
|
|
|
|
<br><tt>local_interfaces = 192.168.1.1:127.0.0.1</tt>
|
|
<br>(apart from the local net, also loopback must be specified, otherwise
|
|
fetchmail won't work; or you must call <tt>fetchmail -S <i>yourmachinename</i></tt>).
|
|
<li>
|
|
Comment out the <tt>smtp</tt> line in <tt>/etc/inetd.conf</tt> .</li>
|
|
|
|
<li>
|
|
In /<tt>etc/init.d/exim</tt> comment out the line <tt>exit 0</tt> near
|
|
the beginning, just after the line <tt>#usually this is disabled and exim
|
|
runs from /etc/inetd.conf</tt>. This causes exim to run as a daemon after
|
|
you call <tt>/etc/init.d/exim start</tt>. Letting exim run as a daemon
|
|
means that you have to call <tt>/etc/init.d/exim restart</tt> after every
|
|
change to <tt>exim.conf</tt>.</li>
|
|
</ul>
|
|
Letting exim run as a daemon means that it consumes some cycles and some
|
|
memory all the time. But as a bonus, exim's <tt>RETRY CONFIGURATION</tt>
|
|
now works properly as well, which it never did when running under <tt>inetd</tt>.
|
|
<h4>
|
|
7.4 Junkbuster</h4>
|
|
Junkbuster is an http proxy server which you can configure to keep out
|
|
ads and other unwanted stuff. It works very well. In a Debian system it
|
|
listens to port 5865, in other systems to port 8000. This is set in the
|
|
file
|
|
<tt>/etc/junkbuster/config</tt>. By default, junkbuster listens to
|
|
<i>all</i>
|
|
interfaces (in other words, to the whole world). However, you can set in
|
|
the config file
|
|
<p><tt> listen-address
|
|
192.168.1.1:5865</tt>
|
|
<p>and now only machines on our own network can connect to it (including
|
|
the gateway machine that junkbuster runs on, <b>heaven</b> in this example,
|
|
provided <tt>heaven</tt> is entered in the Netscape 'Preferences/Advanced/Proxies'
|
|
menu, not <tt>localhost</tt>).
|
|
<h4>
|
|
7.5 Other (non-<tt>inetd</tt>) services</h4>
|
|
The above examples are <i>only</i> examples. If your system runs other
|
|
services outside <tt>inetd</tt>, check their documentation for ways to
|
|
make them private. For instance, it appears that<i> sendmail</i> can be
|
|
made to listen only to the local network by means of
|
|
<p><tt> 0 DaemonPortOptions=Addr=192.168.1.1</tt>
|
|
<p>in the <tt>sendmail.cf</tt> file. I did not try this.
|
|
<h4>
|
|
7.6 Remaining problem cases, like <tt>lpd</tt></h4>
|
|
<tt>lpd</tt> remains a problem. It cannot be made to listen to the internal
|
|
network only. Basically, it should be replaced by something safe. <a href="#fortress1">Sander
|
|
Plomp</a> recommends replacing it by <b><tt><a href="http://pdq.sourceforge.net/">pdq</a></tt></b>.
|
|
I've been too lazy to do this yet, but it certainly needs attention in
|
|
the near future.
|
|
<p>Other problem cases may remain: servers which you need in your own network
|
|
but which cannot be made private, and for which private alternatives do
|
|
not exist. I have this problem with <tt>cannaserver</tt>, a system for
|
|
inputting Japanese characters from the keyboard. Such services must be
|
|
screened from the outside world by means of a packet-filtering firewall.
|
|
See section 10 of this article.
|
|
<h3>
|
|
8. Masking the <tt>inetd</tt> services through <tt>xinetd</tt></h3>
|
|
By now the list of visible services on the system, according to the Secure
|
|
Design scan, has become:
|
|
<ul>
|
|
<li>
|
|
telnet</li>
|
|
|
|
<li>
|
|
pop3</li>
|
|
|
|
<li>
|
|
lpd (the print system)</li>
|
|
</ul>
|
|
Much fewer than there used to be, but still far too much. Telnet and pop3
|
|
are started by inetd/tcpd and thus are secured by <tt>hosts.allow</tt>
|
|
and <tt>hosts.deny</tt>, but I'm not sure that this protection is 100%
|
|
cracker-proof. <tt>lpd</tt> remains totally 'open', as far as I can guess,
|
|
unsecured. It cannot, I think, be started from inetd.
|
|
<h4>
|
|
8.1 Replacing <tt>inetd</tt></h4>
|
|
Security for a home network really requires replacing <tt>inetd</tt> by
|
|
something which can distinguish between requests for service from the <i>local
|
|
network</i> and from the <i>outside</i>. Plomp recommends <tt>tcpserver</tt>;
|
|
I tried
|
|
<tt>xinetd</tt>. First kill
|
|
<tt>inetd</tt>, then install <tt>xinetd.
|
|
</tt><i>Important:</i>
|
|
The Debian script <tt>/etc/init.d/xinetd</tt> not only starts the <tt>xinetd</tt>
|
|
daemon by itself, but also the portmapper. We do not need/want the portmapper,
|
|
which is used for RPC calls and NFS, which we do not use. So anything related
|
|
to the portmapper in <tt>/etc/init.d/xinetd</tt> must be commented out
|
|
(# at the beginning of the line).
|
|
<p>One way to configure xinetd for telnet and pop3 is to put in <tt>/etc/xinetd.conf</tt>:
|
|
<p><tt>defaults</tt>
|
|
<br><tt> {</tt>
|
|
<br><tt> instances = 10</tt>
|
|
<br><tt> log_type = SYSLOG daemon</tt>
|
|
<br><tt> log_on_success += DURATION HOST
|
|
USERID</tt>
|
|
<br><tt> log_on_failure += HOST</tt>
|
|
<br><tt> interface = 192.168.1.1</tt>
|
|
<br><tt> }</tt>
|
|
<p><tt>service telnet</tt>
|
|
<br><tt> {</tt>
|
|
<br><tt> socket_type = stream</tt>
|
|
<br><tt> wait = no</tt>
|
|
<br><tt> user = root</tt>
|
|
<br><tt> server = /usr/sbin/in.telnetd</tt>
|
|
<br><tt> }</tt>
|
|
<p><tt>service pop-3</tt>
|
|
<br><tt> {</tt>
|
|
<br><tt> socket_type = stream</tt>
|
|
<br><tt> wait = no</tt>
|
|
<br><tt> user = root</tt>
|
|
<br><tt> server = /usr/sbin/in.qpopper</tt>
|
|
<br><tt> }</tt>
|
|
<p>So apart from a general 'defaults' section which specifies the interface,
|
|
there is a separate section for each service that you want to run. Although
|
|
the format is completely different, the <i>data</i> for the various sections
|
|
can be found in your existing <tt>inetd.conf</tt>. See also <tt>man xinetd.conf</tt>.
|
|
<p>I started <tt>xinetd</tt> and verified that is is now possible to telnet
|
|
to <b>heaven</b> both from
|
|
<b>heaven</b> itself and from <b>earth</b>.
|
|
However, Secure Design no longer reports that my system has open telnet
|
|
and pop3 ports! Success! <i>NOTE</i>: from my own machine, <tt>telnet heaven</tt>
|
|
succeeds, but <tt>telnet localhost</tt> does not. <tt>xinetd</tt> can only
|
|
bind to one interface; in this case 192.168.1.1, not at the same time to
|
|
<tt>localhost</tt>,
|
|
which is the loopback interface (127.0.0.1).
|
|
<p>By now, all other services in <tt>/etc/inetd.conf</tt> have been commented
|
|
out. Therefore <tt>inetd</tt> no longer does anything and we can get rid
|
|
of it in the boot-up scripts. In Debian, it goes like this:
|
|
<blockquote><tt>update-rc.d -f /etc/init.d/inetd remove</tt></blockquote>
|
|
Its place is taken by <tt>xinetd</tt>:
|
|
<blockquote><tt>update-rc.d xinetd defaults</tt></blockquote>
|
|
OK; another step towards security successfully taken.
|
|
<p>The output of <tt>netstat -pan --inet</tt> is now something like:
|
|
<p><tt><font size=-1>heaven:~# netstat -pan --inet</font></tt>
|
|
<br><tt><font size=-1>Active Internet connections (servers and established)</font></tt>
|
|
<br><tt><font size=-1>Proto Local Address
|
|
Foreign Address State PID/Program name</font></tt>
|
|
<br><tt><font size=-1>tcp 127.0.0.1:25
|
|
0.0.0.0:* LISTEN 11391/exim</font></tt>
|
|
<br><tt><font size=-1>tcp 192.168.1.1:25
|
|
0.0.0.0:* LISTEN 11391/exim</font></tt>
|
|
<br><tt><font size=-1>tcp 192.168.1.1:139
|
|
0.0.0.0:* LISTEN 10761/smbd</font></tt>
|
|
<br><tt><font size=-1>tcp 192.168.1.1:5865 0.0.0.0:*
|
|
LISTEN 1670/junkbuster</font></tt>
|
|
<br><tt><font size=-1>tcp 192.168.1.1:110
|
|
0.0.0.0:* LISTEN 161/xinetd</font></tt>
|
|
<br><tt><font size=-1>tcp 192.168.1.1:23
|
|
0.0.0.0:* LISTEN 161/xinetd</font></tt>
|
|
<br><tt><font size=-1>tcp 0.0.0.0:515
|
|
0.0.0.0:* LISTEN 148/lpd
|
|
MAIN</font></tt>
|
|
<br><tt><font size=-1>udp 192.168.1.1:138
|
|
0.0.0.0:*
|
|
10759/nmbd</font></tt>
|
|
<br><tt><font size=-1>udp 192.168.1.1:137
|
|
0.0.0.0:*
|
|
10759/nmbd</font></tt>
|
|
<br><tt><font size=-1>udp 0.0.0.0:138
|
|
0.0.0.0:*
|
|
10759/nmbd</font></tt>
|
|
<br><tt><font size=-1>udp 0.0.0.0:137
|
|
0.0.0.0:*
|
|
10759/nmbd</font></tt>
|
|
<br><tt><font size=-1>raw 0.0.0.0:1
|
|
0.0.0.0:* 7
|
|
-</font></tt>
|
|
<br><tt><font size=-1>raw 0.0.0.0:6
|
|
0.0.0.0:* 7
|
|
-</font></tt>
|
|
<p>Almost all services now listen to a local interface. The print system
|
|
is the exception: it listens to address 0.0.0.0 (i.e., everywhere) on port
|
|
515. Sure enough, if the system is scanned now, only port 515 is reported
|
|
as 'open'. In fact some Windows-oriented scan services will report your
|
|
system as totally 'closed', because they do not scan port 515.
|
|
<h3>
|
|
9. What about IP Masquerading?</h3>
|
|
For ages I have used IP Masquerading, to give the Windows box in my home
|
|
access to the Internet. Or so I thought. When recently, in the course of
|
|
my investigations into system safety, I switched off Masquerading, the
|
|
Windows box could use the Internet as before.
|
|
<p>What happened? Simply that <b>earth</b>, the Windows machine, only does
|
|
three Internet-related things:
|
|
<ol>
|
|
<li>
|
|
e-mail, which does not require <b>earth</b> to connect to the Internet,
|
|
only to the smtp and pop3 servers running on <b>heaven</b>;</li>
|
|
|
|
<li>
|
|
Web browsing; for this, <b>earth</b> connects to junkbuster on <b>heaven</b>,
|
|
again not directly to the Internet;</li>
|
|
|
|
<li>
|
|
fetching the outside mail from the ISP; for this, <b>earth</b>'s user telnets
|
|
to <b>heaven</b> and runs fetchmail from there.</li>
|
|
</ol>
|
|
So, ever since I installed junkbuster about six months ago, <b>earth</b>
|
|
has never approached the Internet directly, and Masquerading is now superfluous.
|
|
I had not realized this. Inadvertently I had created a 'proxying firewall'.
|
|
This means that Masquerading can - and must - now simply be switched off.
|
|
This has several advantages:
|
|
<ul>
|
|
<li>
|
|
Simplicity: ipchains (see the next section) no longer has a FORWARD chain,
|
|
so we don't have to worry about it. We do not need to set up DNS on <b>earth</b>
|
|
(entering nameserver addresses).</li>
|
|
|
|
<li>
|
|
Security: if ever some Trojan becomes established on <b>earth</b>, it will
|
|
not be able to contact its evil accomplices through the Internet.</li>
|
|
</ul>
|
|
The only 'downside' is that <b>earth</b> is now restricted to e-mail and
|
|
http only. No ping and telnet to the outside world, no ftp, Real Audio,
|
|
chat, etc. But for the moment mail and http is all that's required. If
|
|
other services become necessary on <b>earth</b>, I suppose I shall have
|
|
to install proxies for them on <b>heaven</b>.
|
|
<p>To switch IP masquerading and forwarding off, in Debian, you do
|
|
<ul>
|
|
<li>
|
|
change the first line in <tt>/etc/network/options</tt> so it says <tt>ip_forward=no</tt></li>
|
|
|
|
<li>
|
|
disable forwarding in the kernel by means of <tt>echo 0 > /proc/sys/net/ipv4/ip_forward</tt></li>
|
|
|
|
<li>
|
|
remove any special commands for Masquerading, like <tt>ipchains -A forward
|
|
-s 192.168.1.0/24 -j MASQ</tt> from your startup scripts, ip-up script,
|
|
or wherever you had them.</li>
|
|
</ul>
|
|
|
|
<h3>
|
|
10. Closing the last doors</h3>
|
|
Let's recapitulate: by <i>eliminating</i> services, <i>reconfiguring</i>
|
|
other services so they don't listen to the gateway interface, by <i>wrapping</i>
|
|
others inside xinetd, and by turning off Masquerading, we have created
|
|
a system which is already quite secure
|
|
<i>without a firewall</i>. Now it
|
|
is time to add the final touch: we build a packet-filtering firewall around
|
|
the system using ipchains. This should be the last step, not the first.
|
|
<p>One often reads the advice to configure ipchains in such a way that
|
|
'everything is blocked by default', and then to make exceptions for the
|
|
things that you want to allow. Theoretically this may be the right thing,
|
|
but in practice it leads to much frustration. If everything is blocked,
|
|
your system will basically not work. You are more or less groping in the
|
|
dark when it comes to deciding what you have to allow. So I allow everything
|
|
by default, and then add restrictions one by one. If the system breaks
|
|
(e.g. no ping, or no Web page viewing) the last restriction has been too
|
|
drastic, and must be undone. Setting the default policy of a chain to DENY
|
|
or REJECT can then (again) be the last step, not the first.
|
|
<p>I started by taking down the firewall (<tt>ipchains -F</tt>) and then
|
|
running a simple firewall script with one rule:
|
|
<p><tt>#!/bin/sh</tt>
|
|
<br><tt># simple firewall</tt>
|
|
<p><tt>ipchains -F input</tt>
|
|
<br><tt>ipchains -P input ACCEPT</tt>
|
|
<br><tt>ipchains -A input -i ppp0 -p TCP --syn -j DENY -l</tt>
|
|
<p>This blocks SYN packets coming from the outside interface, enhancing
|
|
the privacy of the system very considerably. Nobody from the outside can
|
|
start a connection; outside scan services report that the site is completely
|
|
closed (some now even call it 'stealthed' or 'invisible'). But we can add
|
|
more restrictions. That is, we can use <i>more general </i>DENY/REJECT
|
|
rules, and <i>more specific</i> ACCEPT rules.
|
|
<p>Before you add restrictions, it is useful to do some experiments. You
|
|
can make ipchains-type rules which let packets through while logging them
|
|
(<tt>-j ACCEPT -l</tt>). So even if (like me) you do not really
|
|
<i>know</i>
|
|
which packets to block, you can see what is going on 'normally' by keeping
|
|
a window open with <tt>tail -f /var/log/syslog</tt> in it. Then afterwards
|
|
you can make rules to block packets which are not 'normal'. I strongly
|
|
advise you to do your <i>own</i> experiments, and to make rules based on
|
|
your <i>own</i> understanding.
|
|
<p>After a few such experiments,<i> my</i> firewall script in <tt>/etc/ppp/ip-up.d</tt>
|
|
looks as follows. This assumes you have no nameserver running, but have
|
|
the addresses of TWO nameservers provided by your ISP in <tt>/etc/resolv/conf</tt>.
|
|
Mind the important <i>backquotes</i> (<tt>`</tt>)! They may disappear if
|
|
you cut-and-paste from this page.
|
|
<p><tt><font size=-1>#!/bin/sh</font></tt>
|
|
<br><tt><font size=-1># A slightly more complicated firewall</font></tt>
|
|
<p><tt><font size=-1># Find external name server addresses</font></tt>
|
|
<br><tt><font size=-1>ns="`grep nameserver /etc/resolv.conf | awk '{print
|
|
$2}'`"</font></tt>
|
|
<br><tt><font size=-1>nameserver1="`echo $ns | sed -e 's/ .*//'`"</font></tt>
|
|
<br><tt><font size=-1>nameserver2="`echo $ns | sed -e 's/.* //'`"</font></tt>
|
|
<p><tt><font size=-1># Set up INPUT rules</font></tt>
|
|
<br><tt><font size=-1>ipchains -F input</font></tt>
|
|
<br><tt><font size=-1>ipchains -P input ACCEPT</font></tt>
|
|
<p><tt><font size=-1># Block outside input from reserved address ranges</font></tt>
|
|
<br><tt><font size=-1>ipchains -A input -i ppp0 -s 10.0.0.0/8
|
|
-j DENY</font></tt>
|
|
<br><tt><font size=-1>ipchains -A input -i ppp0 -s 172.16.0.0/12
|
|
-j DENY</font></tt>
|
|
<br><tt><font size=-1>ipchains -A input -i ppp0 -s 192.168.0.0/16
|
|
-j DENY</font></tt>
|
|
<p><tt><font size=-1># Block TCP connections from the outside</font></tt>
|
|
<br><tt><font size=-1>ipchains -A input -i ppp0 -p TCP --syn -j DENY -l</font></tt>
|
|
<p><tt><font size=-1># Block all UDP except nameserver replies</font></tt>
|
|
<br><tt><font size=-1>ipchains -A input -i ppp0 -p UDP -s $nameserver1
|
|
53 -j ACCEPT</font></tt>
|
|
<br><tt><font size=-1>ipchains -A input -i ppp0 -p UDP -s $nameserver2
|
|
53 -j ACCEPT</font></tt>
|
|
<br><tt><font size=-1>ipchains -A input -i ppp0 -p UDP -j DENY -l</font></tt>
|
|
<p><tt><font size=-1># Allow (for now) but log all ICMP</font></tt>
|
|
<br><tt><font size=-1>ipchains -A input -i ppp0 -p ICMP -j ACCEPT -l</font></tt>
|
|
<p><tt><font size=-1># From local net, allow only packets to us and broadcasts</font></tt>
|
|
<br><tt><font size=-1># Forwarding is off, other packets won't go anywhere,
|
|
but</font></tt>
|
|
<br><tt><font size=-1># now we can log them to detect illegal activity
|
|
on our net</font></tt>
|
|
<br><tt><font size=-1>ipchains -A input -i eth0 -d 192.168.1.1
|
|
-j ACCEPT</font></tt>
|
|
<br><tt><font size=-1>ipchains -A input -i eth0 -d 192.168.1.255 -j ACCEPT</font></tt>
|
|
<br><tt><font size=-1>ipchains -A input -i eth0 -j REJECT -l</font></tt>
|
|
<p><tt><font size=-1># Set up OUTPUT rules</font></tt>
|
|
<br><tt><font size=-1>ipchains -F output</font></tt>
|
|
<br><tt><font size=-1>ipchains -P output ACCEPT</font></tt>
|
|
<p><tt><font size=-1># Don't send packets out to reserved address ranges</font></tt>
|
|
<br><tt><font size=-1>ipchains -A output -i ppp0 -d 10.0.0.0/8
|
|
-j REJECT</font></tt>
|
|
<br><tt><font size=-1>ipchains -A output -i ppp0 -d 172.16.0.0/12
|
|
-j REJECT</font></tt>
|
|
<br><tt><font size=-1>ipchains -A output -i ppp0 -d 192.168.0.0/16
|
|
-j REJECT</font></tt>
|
|
<p><tt><font size=-1># Block all UDP except nameserver requests</font></tt>
|
|
<br><tt><font size=-1>ipchains -A output -i ppp0 -p UDP -d $nameserver1
|
|
53 -j ACCEPT</font></tt>
|
|
<br><tt><font size=-1>ipchains -A output -i ppp0 -p UDP -d $nameserver2
|
|
53 -j ACCEPT</font></tt>
|
|
<br><tt><font size=-1>ipchains -A output -i ppp0 -p UDP -j REJECT -l</font></tt>
|
|
<p><tt><font size=-1># Allow (for now) ICMP to the outside, but log</font></tt>
|
|
<br><tt><font size=-1>ipchains -A output -i ppp0 -p ICMP -j ACCEPT -l</font></tt>
|
|
<p><tt><font size=-1># We do not have FORWARD rules; forwarding is off</font></tt>
|
|
<p>Such a firewall (which you should adapt to your personal tastes and
|
|
needs) will provide an extra 'shell' around the system. But basically,
|
|
the security of your system should not <i>depend</i> on the firewall; if
|
|
only because firewalls are complicated things, and it is far too easy to
|
|
make mistakes with them. Many other things can be done first to ensure
|
|
the privacy of your network.
|
|
<h3>
|
|
11. References and further reading</h3>
|
|
|
|
<ol>
|
|
<li>
|
|
<a NAME="fortress1"></a><i><a href="http://rootprompt.org/article.php3?article=903">Amateur
|
|
Fortress Building in Linux, part 1</a></i>, by Sander Plomp (rootprompt.org)</li>
|
|
|
|
<li>
|
|
<a NAME="fortress2"></a><i><a href="http://rootprompt.org/article.php3?article=931">Amateur
|
|
Fortress Building in Linux, part 2</a></i>, by Sander Plomp (rootprompt.org)</li>
|
|
|
|
<li>
|
|
<a NAME="rwls"></a><i><a href="http://www.realworldlinuxsecurity.com">Real
|
|
World Linux Security</a></i>, by Bob Toxen (Prentice-Hall, 2001).</li>
|
|
|
|
<li>
|
|
<i><a href="http://logi.cc/linux/reject_or_deny.html">What is the difference
|
|
between REJECT and DENY?</a></i> (Linux@home)</li>
|
|
|
|
<li>
|
|
<i><a href="http://logi.cc/linux/ipchains-log-format.html">Ipchains log
|
|
format</a></i> (Linux@home). For understanding what you see while running
|
|
<tt>tail
|
|
-f /var/log/syslog</tt>.</li>
|
|
|
|
<li>
|
|
<i><a href="http://www.isi.edu/in-notes/iana/assignments/icmp-parameters">ICMP
|
|
Type numbers</a></i> (IANA)</li>
|
|
|
|
<li>
|
|
<a NAME="jwexim"></a><i><a href="../issue43/stumpel.html">Setting
|
|
Up Mail for a Home Network Using Exim</a></i> (Linux Gazette, July 1999)</li>
|
|
|
|
<li>
|
|
<a NAME="jwsmtp"></a><i><a href="../issue45/stumpel.html">Experiments
|
|
with SMTP</a></i> (Linux Gazette, September 1999)</li>
|
|
</ol>
|
|
|
|
|
|
|
|
|
|
<!-- *** BEGIN copyright *** -->
|
|
<P> <hr> <!-- P -->
|
|
<H5 ALIGN=center>
|
|
|
|
Copyright © 2001, Jan Stumpel.<BR>
|
|
Copying license <A HREF="../copying.html">http://www.linuxgazette.com/copying.html</A><BR>
|
|
Published in Issue 65 of <i>Linux Gazette</i>, April 2001</H5>
|
|
<!-- *** END copyright *** -->
|
|
|
|
<!--startcut ==========================================================-->
|
|
<HR><P>
|
|
<CENTER>
|
|
<!-- *** BEGIN navbar *** -->
|
|
<IMG ALT="" SRC="../gx/navbar/left.jpg" WIDTH="14" HEIGHT="45" BORDER="0" ALIGN="bottom"><A HREF="steffler.html"><IMG ALT="[ Prev ]" SRC="../gx/navbar/prev.jpg" WIDTH="16" HEIGHT="45" BORDER="0" ALIGN="bottom"></A><A HREF="index.html"><IMG ALT="[ Table of Contents ]" SRC="../gx/navbar/toc.jpg" WIDTH="220" HEIGHT="45" BORDER="0" ALIGN="bottom" ></A><A HREF="../index.html"><IMG ALT="[ Front Page ]" SRC="../gx/navbar/frontpage.jpg" WIDTH="137" HEIGHT="45" BORDER="0" ALIGN="bottom"></A><A HREF="http://www.linuxgazette.com/cgi-bin/talkback/all.py?site=LG&article=http://www.linuxgazette.com/issue65/stumpel.html"><IMG ALT="[ Talkback ]" SRC="../gx/navbar/talkback.jpg" WIDTH="121" HEIGHT="45" BORDER="0" ALIGN="bottom" ></A><A HREF="../faq/index.html"><IMG ALT="[ FAQ ]" SRC="./../gx/navbar/faq.jpg"WIDTH="62" HEIGHT="45" BORDER="0" ALIGN="bottom"></A><A HREF="sunil.html"><IMG ALT="[ Next ]" SRC="../gx/navbar/next.jpg" WIDTH="15" HEIGHT="45" BORDER="0" ALIGN="bottom" ></A><IMG ALT="" SRC="../gx/navbar/right.jpg" WIDTH="15" HEIGHT="45" ALIGN="bottom">
|
|
<!-- *** END navbar *** -->
|
|
</CENTER>
|
|
</BODY></HTML>
|
|
<!--endcut ============================================================-->
|