LDP
/
LDP
mirror of https://github.com/tLDP/LDP
0
1
Fork 0
Code Releases Activity
LDP/LDP/howto/linuxdoc/Domain.sgml

2266 lines
94 KiB
Plaintext
Raw Permalink Blame History

<!doctype linuxdoc system>
<!-- This is the DOMAIN setup mini-HOWTO, by Christopher Neufeld.
-->
<article>
<title>Setting Up Your New Domain Mini-HOWTO.
<author>by Christopher Neufeld (neufeld@linuxcare.com)
<date>version 0.12. 2000-10-27.
<abstract>
This document outlines the things you will probably have to do when
you want to set up a network of computers under your own domain. It
covers configuration of network parameters, network services, and
security settings.
</abstract>
<toc>
<sect>Notices
<sect1>Disclaimer
<p>
This is a preliminary document. I have glossed over many things
which could be given in much more detail, and have probably missed
important sections entirely. Any suggestions for additions,
deletions, or areas where I ought to provide more or less detail are
very welcome.
<sect1>Location
<p>
The most recent version of this document can be found at <url
url="http://caliban.physics.utoronto.ca/neufeld/Domain.HOWTO/">.
<sect1>Copyright
<p>
Copyright (c) by Christopher Neufeld. This document may be
distributed only subject to the terms and conditions set forth in the
LDP License at <url url="http://www.linuxdoc.org/COPYRIGHT.html"
name="this location">.
<sect>Introduction
<p>
This is a guide to setting up your own domain of Linux machines, or
mixed Linux and Windows machines, on an always-up connection with a
static IP and a named domain. It is not really intended for setups
which use dynamic IPs, or which are regularly disconnected from their
provider for long periods of time, though some basic hints for
operating such a setup are available in section <ref id="dynamic-ip"
name="Using A Dynamic IP">.
<p>
With the increasing availability of permanent connections and static
IPs, it's becoming easier for people and organizations to set up a
real domain, with the associated Internet presence. Proper planning at
the outset can reduce problems later.
<p>
Much of this document describes techniques for implementing
unobtrusive security on the newly exposed network. This deals with
protection from external attack, and from casual internal attack. It
does not claim to provide an extremely secure setup, but is usually
enough to discourage the less determined attacker.
<p>
This document is primarily directed at small organizations which have
an existing network of computers, possibly with a shared dialup line,
which are trying to move to a permanent, relatively high-speed
connection, either to improve data transfer with the outside world, or
to create a WWW or FTP site. The document is also directed at new
organizations which want to skip the early stage and start out with
higher speed networking and services under their own domain name.
<p>
Throughout this document, I will discuss the configuration of a newly
registered domain, <bf>example.com</bf>. Note that the name
example.com is reserved by the Internet Assigned Numbers Authority for
use in documentation, and so will never correspond to an actual
domain.
<p>
Much of the information in this document is available in other
places. I have tried to distill the material relevant to the creation
of a new domain. Where detail on a specific subject is lacking, you
may want to consult one of the more comprehensive documents.
<p>
This document will also assume a mixed OS environment. Specifically, I
will assume that some desktop machines are running some version of
Microsoft Windows, while servers and the private network gateway are
running Linux.
<sect>Planning Your Network Topology<label id="plannettop">
<p>
While there are arguments which can be made for many different network
layouts, the requirements of many organizations can be met by putting
the desktop machines and private servers on a private masqueraded
subnet, and the publicly accessible machines on valid external
IPs. The machines on valid external IPs will be referred to in this
document as ``exposed hosts''. This leads to the following (example)
topology:
<tscreen><verb>
+--------------+
| | +---------------+
| ISP-supplied |---------------| FTP server |
| router | | +---------------+
| | |
+--------------+ | +---------------+
|------| WWW server #1 |
| +---------------+
|
| +---------------+
|------| WWW server #2 |
| +---------------+
|
~
~
|
| +---------------+
|------| Private |
| Network |
| Gateway |
+---------------+
|
|
|
|
+------------+ | +-------------------+
| Desktop #1 |-------------------|------| Private server #1 |
+------------+ | +-------------------+
|
. -------------------|-------- .
. | .
. -------------------|-------- .
|
+------------+ | +-------------------+
| Desktop #N |-------------------|------| Private server #N |
+------------+ +-------------------+
</verb></tscreen>
<p>
In this example, the router provided by the ISP (Internet Service
Provider), FTP server, WWW servers, and the machine labelled ``private
network gateway'' all have externally visible IP numbers, while the
desktop and private server machines have IP numbers allocated from
<url url="http://www.ietf.org/rfc/rfc1918.txt" name="RFC 1918">,
reserved for private use. The IP numbers you choose for use within the
private network (everything below the private network gateway
machine) should be chosen to be unique, not only among the hosts under
your control, but should also not conflict with numbers assigned on
similar private subnets at other sites or partner companies with whom
you might, at some time, want to implement a virtual private network,
in order to reduce confusion and reconfiguration when the networks are
merged in that way. As outlined in the RFC, you can choose from any
class C network from 192.168.0.* to 192.168.255.*, or any class B
network from 172.16.*.* to 172.31.*.*, or the class A network
10.*.*.*. In the rest of this document I will assume that your private
network (if you've chosen to create one) is on the class C network
192.168.1.*, and your private network gateway machine is at IP number
10.1.1.9, one of the IP numbers provided to you by your provider (note
that this is not a valid external IP, I use it as an example only). I
will also assume that there is a machine, betty.example.com, at
10.1.1.10, which will handle both www and FTP services.
<p>
Take note of the number of external IP numbers which you need for your
own machines. You will need one IP number for each machine which lies
outside the private network gateway, plus one for the gateway
itself. This count does not include any IP numbers which may be taken
by routers, broadcast addresses, and so on. You should ask your
provider for a block of addresses large enough to mount the given
number of machines. For example, in my office network, of the 8 IP
numbers allocated from the ISP, three were not usable by my
computers, leaving enough IP numbers for four machines outside the
gateway, plus the gateway itself.
<p>
This network topology is not correct for everybody, but it is a
reasonable starting point for many configurations which don't have
special needs. The advantages of this configuration include:
<itemize>
<item>Easy expandability. If you suddenly double your number of
private nodes, you don't have to worry about getting a new IP block
from your provider and reconfiguring all of the interfaces on your
machines.
<item>Local network control. Adding a new workstation to your private
network requires no communication with your provider, unlike exposed
nodes, which need both forward and reverse DNS (domain name service)
mappings if they are to perform certain tasks (ssh and ftpd may
complain if they can't perform reverse and forward DNS on incoming
connections). A reverse DNS query is an attempt to obtain the host name
from the IP number.
<item>Centralized security. The private network gateway can enforce
security over the whole private network, filtering packets and logging
attacks, rather than having to install such measures on each desktop
and server on the private network. This can be enforced not only on
incoming packets, but also on outgoing packets, so that a
misconfigured desktop machine doesn't inadvertently broadcast data
to the outside world which ought to remain internal.
<item>Easy transplantability. Because the IP numbers within the
private network are yours for as long as you want them, you can move
the entire network to a new range of IP numbers without having to make
any changes to the network configuration on the private network. The
publicly exposed hosts still have to be reconfigured, of course.
<item>Transparent Internet access. The machines on your private
network can still use FTP, telnet, WWW, and other services with
minimal obstruction, assuming a Linux masquerading router. The users
may not even be aware that their machines are not on externally
visible IP numbers.
</itemize>
<p>
Some of the potential disadvantages of such a configuration are:
<itemize>
<item>Some services will not be available directly to the machines on
the internal network. NTP synchronization against an outside host,
certain obscure services which may not have masquerading rules in the
kernel, and .shosts authentication for logging in to external nodes
are all difficult or impossible, but simple workarounds are almost
always available.
<item>More network hardware costs. The private network gateway machine
needs two network cards, and you need at least two hubs / switches,
one on the visible network and one on the private network.
<item>Machines outside the private network cannot easily make direct
connections to machines within the private network. They may have to
open a session first on the private network gateway machine, then log
through to the internal host. It is possible to route packets
transparently through the firewall, but this is not recommended for
security reasons which will be discussed in a later section.
</itemize>
<p>
You should consider these points in planning your network topology,
and decide if a fully visible network is more appropriate for your
situation. In the rest of this document I will assume that you have
configured your network as shown above. If you have chosen to have a
fully visible network, some details will differ, and I will try to
point out such differences in this document.
<p>
As a special case, if you do not need any external servers, the
ISP-supplied router can be attached directly to your external
interface on the private network gateway machine, rather than with a
hub.
<sect>Obtaining Your Connection<label id="obtain-conn">
<p>
<sect1>Choosing Your Provider<label id="choose-provider">
<p>
As with anything, shop around. Determine which services are available
in your area, as well as the costs associated with those services. Not
all locations are wired to accept DSL, and some locations may not be
suitable for wireless connections due to constraints of the landscape,
architecture, or environment. Be prepared to provide the street
address of the location where your hookup will be installed, as DSL
speeds are strongly dependent on your distance from the switch, and
ask specifically about such details as bandwidth between your machine
and the provider, what has to be done to install the connection, and
what hardware is provided in the quoted monthly rate. Also, you should
have some idea of how many IP numbers you need for your own machines
(remember that not all IP numbers in the block you get from the
provider will be available for attaching your computers). Ask the
provider what their total bandwidth is out to the outside world, as
the quoted speed is only between your site and theirs. If the provider
has insufficient bandwidth to the outside, the customers will suffer
bottlenecks within the provider's network.
<p>
Once you have narrowed down a list of candidates, ask around, see if
anybody can provide you with recommendations for the services you're
considering. Ask them what sort of bandwidth they get to unloaded
sites. Also, if you intend to have fast connections between the new
domain and local ISP accounts from home, for telecommuting, or just
remote administration, it is essential that you do a
<em>traceroute</em> from your home ISP account to a host operating on
the service you're considering. This will tell you how many hops, and
how much latency you should expect, between home and the new
domain. Latencies much above 100 to 200 milliseconds can be difficult
to use for extended periods of time. The <em>traceroute</em> should be
run around the time of day that you expect to make use of the network
connection between home and the new domain.
<sect1>Preparing For Hardware Installation<label id="prepare-hw">
<p>
After you have chosen the provider and service type for the new
domain, ask about installation details. You may require service calls
from the telephone company as well as from the ISP in order to install
the service, and the technicians may need access to controlled areas
of your building, so inform the building engineer of the installation
requirements.
<p>
Before the ISP technician arrives, ask for the network parameters,
specifically the IP number, netmask, broadcast address, gateway
routing address, DNS server address, and also what cabling you need to
connect to the hardware delivered by the technician
(i.e. straight-through or crossover RJ45 cabling, etc.).
<p>
Have one machine available for testing, and put it close to where the
network connection hardware will be installed. If possible, configure
it before the service technician arrives, setting the IP number and
netmask, and have the appropriate cabling ready so that the
installation and testing can be done quickly.
<sect1>Testing The Connection<label id="test-conn">
<p>
With your test machine attached to the ISP's hardware, make sure that
you can ping sites beyond the ISP. If not, a <em>traceroute</em> to
the outside can help to show where the connection is failing. If
traceroute shows no successful hops it indicates that your test
machine's network configuration (default route, interface address, NIC
drivers, DNS, etc.) is incorrectly set. If it shows one hop, that could
mean that your router is not correctly configured to communicate with
the ISP. If it shows several hops before failing, the problem is
almost certainly in the ISP or in the outside world, and beyond your
immediate control.
<sect1>Using A Dynamic IP<label id="dynamic-ip">
<p>
The benefits of a corporate connection, with a static IP block and
various hosted services, comes with a cost. It can be more than ten
times as expensive as a high speed home connection on DSL or cable
modem. If the budget can't support a corporate connection, or if no
such connections are available in your area, you might want to try to
set up a domain on a dynamic IP. Instead of a range of IP numbers, you
typically get exactly one, which means that your private network
gateway machine will also have to host any incoming services from the
outside.
<p>
First, you might want to check the legality of it. Many companies'
user agreements explicitly forbid setting up externally-accessible
servers on personal accounts. They may enforce this with packet
filters blocking incoming connections on the http and FTP ports. You
should also be aware that the quoted connection speed for personal
accounts such as home DSL or cable modem are the downlink speeds, and
that the uplink speeds might be much slower. The uplink speed is what
is important for serving up FTP or web content.
<p>
If you have a dynamic IP, and you want to have incoming connections,
you will have to subscribe to a dynamic IP hosting service, such as
one of those listed at <url url="http://www.technopagan.org/dynamic/"
name="Dynamic DNS Providers">. These services typically work by running
software on your machine which passes your current IP number on to the
company's servers. When your current IP number arrives at the servers,
their DNS tables are updated to reflect the new value. You can either
get a domain name under their domain name, such as
``example.dynip.com'' or ``example.dynhost.com'', or you can register
your own domain and set the primary DNS authority to point to
the company providing this service (usually at a higher cost).
<p>
There is also a free hosting service, at <url
url="http://www.dhs.org/" name="Domain Host Services">. They seem
fairly new, and there are few details on their web site at the moment,
but you might find it worth a look.
<p>
If you have set up a dynamic IP, and subscribed to one of these
services, it will affect some of the decisions you make in section
<ref id="which-servs" name="Deciding Which Domain Services You Will
Host">. In particular, there is little point subscribing to a dynamic
IP hosting service if you do not plan to host at least one of web or
FTP services. You will have to set primary DNS authority to point to
the company you've chosen. You should not have a <em>named</em> daemon
answering requests from outside your private network. Other details,
such as handling of email, will depend on the specifics of the service
you've subscribed to, and can best be answered by the support staff of
that company.
<p>
One final note: if you want to have remote access to a machine with a
dynamic IP, but don't need it for hosting other services, the
inexpensive solution is to create a ``drop box'' on a publicly
accessible machine with a static IP, and have your dynamic IP host
send its IP number there, either in email or simply by writing it into
a file on a shell account. When you want to access your machine
remotely, first extract the current IP number from the drop box, then
use <em>slogin</em> to attach directly to that IP number. This is,
after all, really all that a dynamic IP hosting service does, they
just do it automatically over standard services, saving you some
steps.
<sect>Registering A Domain Name<label id="register">
<p>
In order for people in the outside world to locate your servers under
the domain name of your choice, whether for web, FTP, or email
delivery, you will have to register the domain name for insertion into
the relevant top level domain database.
<p>
Exercise some simple prudence in choosing your domain name. Certain
words or phrases may be forbidden on the grounds of community
standards, or may be offensive to visitors whose language or slang
differs from that of your region. Domain names can contain only the 26
letters of the Roman alphabet (without accents), the hyphen (though
not at the beginning or end of the name), and the 10 digits. Domain
names are not case-sensitive, and can be at least 26 characters long
(this limit is subject to change). Be careful not to register a name
which you can reasonably have been expected to know infringes on the
trademarks of an existing company, the courts are not kind to
cybersquatters. Some information on the circumstances under which your
poorly-chosen domain name might be stripped from your control are
available in this <url
url="http://www.icann.org/udrp/udrp-policy-24oct99.htm" name="Uniform
Domain Name Dispute Resolution Policy">.
<p>
There are many companies which register names in the ``.com'',
``.net'', and ``.org'' top level domains. For a current list, check
the <url url="http://www.icann.org/registrars/accredited-list.html"
name="list of accredited registrars">.
<p>
To register a name under a country top level domain, such as a
``.ca'', ``.de'', ``.uk'', etc., check with the appropriate authority,
which can be located in the <url url="http://www.iana.org/cctld.html"
name="Country Code Top-Level Domains database">.
<p>
Typically, you have to provide the registrar with contact information,
primary and secondary DNS IP numbers, a change request validation
scheme (you wouldn't want just anybody changing your domain for you),
and money in the form of an annual fee. If you're not comfortable with
the change request validation schemes offered by a registrar, let them
know that you're not willing to use the service until they address
your security concerns.
<sect>Deciding Which Domain Services You Will Host<label id="which-servs">
<p>
Most full-service ISPs will provide a variety of domain services for
their customers. This is largely because of the problems associated
with hosting these services under certain other, more popular desktop
and server operating systems. These services are much easier to
provide under Linux, and can be hosted on fairly inexpensive hardware,
so you should decide what services you want to take on for
yourself. Some of these services include:
<itemize>
<item>Primary DNS authority on your domain. See section <ref
id="serv-prim-dns" name="Primary DNS Authority">.
<item>Electronic mail. See section <ref
id="serv-email" name="Electronic Mail">.
<item>Web space hosting. See section <ref
id="serv-www" name="Web Space Hosting">.
<item>FTP space hosting. See section <ref
id="serv-ftp" name="FTP Site Hosting">.
<item>Packet filtering. See section <ref
id="serv-filtering" name="Packet Filtering">.
</itemize>
</p>
<p>
In each of these, you basically have to weigh convenience against
control. When your ISP performs one or more of these services, you can
usually be fairly sure that they have people with experience
maintaining the service, so you have less to learn, and less to worry
about. At the same time, you lose control over these services. Any
changes require that you go through the technical support of your ISP,
something which may sometimes be inconvenient or cause longer delays
than you would like. There's also a security issue involved, the ISP
is a much more tempting target to attackers than your own site. Since
an ISP's servers might host email and/or web space for the dozens of
companies which are their customers, an attacker who compromises one
of those servers gets a much higher return for his efforts than one
who attacks your personal servers, where only one company's data is
kept.
<sect1>Primary DNS Authority<label id="serv-prim-dns">
<p>
When a person somewhere in the outside world attempts to connect to a
machine in the new example.com domain, queries are sent between
various servers on the Internet, ultimately resulting in the IP number
of that machine being returned to the software of the person
attempting the connection. The details of this sequence are beyond the
scope of this document. Neglecting many details, when a request is
made for the machine fred.example.com, a centralized database is
consulted to determine what is the IP number of the machine which
holds primary DNS authority for the example.com domain. This IP number
is then queried for the IP number of the machine fred.example.com.
<p>
There must be a primary and a secondary DNS server for every domain
name. The names and IP numbers of these two servers are stored in a
centralized database whose entries are controlled by domain
registration authorities such as
<url url="http://www.networksolutions.com/" name="Network Solutions">.
<p>
If you elect to have primary DNS authority hosted by your ISP, these
two servers will probably both be machines controlled by the ISP. Any
time you want to add an externally visible machine to your network,
you will have to contact the ISP and ask them to put the new machine
in their database.
<p>
If you elect to hold primary DNS authority on your own host, you will
still use another machine as your secondary. Technically, you should
use one on a redundant Internet connection, but it is very common that
the secondary is held on one of your ISP's machines. If you want to
add an externally visible machine to your network, you will have to
update your own database, and then wait for the change to propagate
(something which takes, typically, a small number of hours). This
allows you to add barney.example.com without having to go through your
ISP.
<p>
It is a good idea to set up secondary DNS on a geographically distant
host, so that a single cable cut near your ISP doesn't take both your
primary and secondary DNS servers off line. The domain registrar you
used to register your domain name may provide secondary DNS service.
There is also a free service, <url url="http://www.granitecanyon.com/"
name="Granite Canyon">, available to anybody who asks.
<p>
Regardless of whether or not you choose to act as primary DNS
authority for your domain, see section <ref id="setup-nameres"
name="Setting Up Name Resolution"> for configuration help. You will
want some sort of name resolution system for your private network,
even if you delegate primary DNS authority to the ISP.
<sect1>Electronic Mail<label id="serv-email">
<p>
When you subscribe with your ISP, they will typically supply a number
of email boxes. You can elect to use this service exclusively, in
which case all incoming email is stored on the ISP's servers and your
users read their mail with POP3 clients which connect to the ISP's
servers. Alternately, you may decide to set up email on your own
machines. Once again, you should weigh the merits of the two
approaches, and choose the one which you prefer.
<p>
Things to remember if you use the ISP for all email:
<itemize>
<item>It may be easier to access the email from home, or from other
locations when you're on a business trip, depending on the security
which you use to protect your domain.
<item>Email is routinely stored on the ISP's servers, which may be a
problem if sensitive material is sent unencrypted.
<item>You have a limited number of email accounts, and may have to pay
if you exceed this limit.
<item>To create a new email address, you have to go through the ISP.
</itemize>
<p>
Things to remember if you provide your own email:
<itemize>
<item>Email is routinely stored on your own servers, with backup
storage on your ISP if your mail host goes down or its disk fills up.
<item>You have an essentially unlimited number of email accounts,
which you can create and delete yourself.
<item>You have to support the email clients used on your private
network, and possibly by people trying to read their email from home.
</itemize>
<p>
One possible approach is to host email yourself, but also use the
several email addresses provided by the ISP. People who need email
accessible from outside the private network can have an email address
in your domain which gets redirected to one of the ISP-supplied email
addresses. Others can have local email on the private network. This
requires a bit more coordination and configuration, but gives more
flexibility than either of the other approaches.
<p>
Should you choose to host email for your domain, see
section <ref id="setup-email" name="Setting Up Email For Your Domain"> for
configuration help.
<p>
If you decide not to host email for your domain, refer to section <ref
id="dns-no-email" name="DNS Configuration If You Are Not Hosting
Email"> for important notes on the name resolution configuration.
<sect1>Web Space Hosting<label id="serv-www">
<p>
Your ISP may allocate you a certain amount of space on their web
servers. You might decide to use that, or you might have a web hosting
machine which you put on your external network, in one of your
external IP numbers.
<p>
Points to remember if you choose to use the ISP's web space hosting:
<itemize>
<item>You have a certain disk space allocation which you should not
exceed. This will include not only web space contents, but also data
collected from people visiting the site.
<item>The bandwidth between your web server and the outside world will
almost certainly be higher than it would be if you hosted it on your
own hardware. In any case, it will not be slower.
<item>It may be difficult to install custom CGI scripts or commercial
packages on your web site.
<item>Your bandwidth between your network and your web server will
almost certainly be lower than it would be if you hosted it on your
own network.
</itemize>
<p>
Points to remember if you choose to host your own web space:
<itemize>
<item>You have much more control over the hosting machine. You can
tailor your security more precisely for your application.
<item>Potentially sensitive data, such as credit card numbers or
mailing addresses, remains on machines which you control.
<item>Your backup strategy is probably not as comprehensive as your
ISP's.
</itemize>
<p>
Notice that I do not mention anything about the ISP having more
powerful hardware, higher peak data rates, and so on. By the time these
things become important, you're talking about very high data rate
network connections, and, quite frankly, you had better be delegating
these decisions to a skilled consultant, not looking in a Linux
HOWTO.
<p>
Should you choose to host web space for your domain on your own
server(s), refer to other documents, such as the <url
url="ftp://metalab.unc.edu/pub/Linux/docs/HOWTO/WWW-HOWTO"
name="WWW-HOWTO">, for configuration help. I strongly recommend that
this service be run on a different machine from the private network
gateway machine, for security reasons.
<sect1>FTP Site Hosting<label id="serv-ftp">
<p>
Basically, the same arguments apply to FTP hosting as apply to WWW
hosting, with the exception that active content is not an issue for
FTP, and CGI scripts don't appear. Most of the recent ftpd exploits
have come from buffer overruns resulting from the creation of large
directory names in anonymously-writable upload directories, so if
your ISP allows uploads and is lax in keeping up with security updates
on the FTP daemon, you might be better off hosting this service
yourself.
<p>
Should you choose to host FTP for your domain on your own server(s),
make sure to get the latest version of your FTP daemon, and consult
the configuration instructions there. Once more, I strongly recommend
that this service be run on a different machine from the private
network gateway machine, for security reasons.
<p>
For <em>wu-ftpd</em>, I would recommend the following configuration options:
<itemize>
<item>--disable-upload - unless you need anonymous uploads
<item>--enable-anononly - encourage your local users to use
<em>scp</em> to transfer files between machines.
<item>--enable-paranoid - disable whatever features of the current
release might be considered questionable.
</itemize>
<sect1>Packet Filtering<label id="serv-filtering">
<p>
Some ISPs will put packet filters on their network, to protect the
users of the system from each other, or from external attackers. Cable
modem networks and similar broadcast networks have had embarrassing
problems when users of Windows 95 or 98 inadvertently set up disk
shares, exporting the full contents of their hard drives to anybody on
the network segment who cared to browse for active servers in the
neighbourhood. In some cases, the solution has been to tell the users
not to do that, but some providers have put filtering into the access
hardware to prevent people from exporting their data by accident.
<p>
Packet filtering is really something which you ought to do yourself.
It fits in easily into the kernel running on your private network
gateway machine and gives you a better idea of what's happening around
you. You often will find that you have to make small tweaks to the
firewall to optimize it during the initial setup, and this is much
easier to do in real time than through a technical support contact.
<p>
Should you choose to do packet filtering for your domain, see section
<ref id="setup-filtering" name="Setting Up Packet Filtering"> for
configuration help.
<sect>Configuring Your Hosted Services
<sect1>Setting up Name Resolution<label id="setup-nameres">
<p>
You will want some way for the computers on your network to refer to
one another by name, and also a way for people in the outside world to
refer to your exposed hosts by name. There are several ways to go
about doing this.
<sect2>DNS On Private Network, ISP Handles Domain<label id="dns-and-isp">
<p>
&lsqb; Note: if you have chosen not to implement a private network, go to
section
<ref id="fully-exposed-isp" name="Fully Exposed Network, Hosted By
ISP">. &rsqb;
<p>
In this configuration, you have delegated responsibility for the
primary DNS authority on your domain to the ISP. You still use DNS
within your private network when hosts there want to talk to one
another. You have given your ISP a list of the names and IP numbers of
all exposed hosts. If you want one externally visible machine, for
instance betty.example.com, to act both as web and FTP server, you
should ask the ISP to make CNAME entries for www.example.com and
ftp.example.com pointing to betty.example.com.
<p>
Set up DNS on your private network gateway machine. This can be done
securely, and makes upgrading easier, should you later decide to host
primary DNS authority for your domain.
<p>
I will assume that you have decided to host DNS from the machine
dns.example.com, which is on the private network gateway, and an alias
for fred.example.com at 192.168.1.1. Some small modifications have to
be made to this configuration if this is not the case. I will not
cover that in this HOWTO unless there is significant interest.
<p>
You will have to download and compile a recent
version of BIND, the Berkeley Internet Name Domain. It is available at
the <url url="http://www.isc.org/products/BIND/" name="BIND web
site">. Next, you have to configure the daemon.
Create the following file, <tt>/etc/named.conf</tt>:
<tscreen><code>
options {
directory "/var/named";
listen-on { 192.168.1.1 };
};
zone "." {
type hint;
file "root.hints";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "pz/127.0.0";
};
zone "1.168.192.in-addr.arpa" {
type master;
file "pz/1.168.192";
};
zone "example.com" {
type master;
notify no;
file "pz/example.com";
};
</code></tscreen>
Note that we are declaring ourselves the master for the example.com
domain. Meanwhile, our ISP is also declaring itself to be the master
for the same domain. This is not a problem, as long as you are careful
about the setup. All of the machines on the private network must use
dns.example.com to perform their name resolution. They must
<em>not</em> use the name resolvers of the ISP, as the ISP name server
believes itself to be authoritative over your entire domain, but it
doesn't know the IP numbers or names of any machines on your private
network. Similarly, hosts on exposed IP numbers in your domain
<em>must</em> use the ISP name server, not the private name server on
dns.example.com.
<p>
The various files under <tt>/var/named</tt> must now be
created.
<p>
The <tt>root.hints</tt> file is exactly as described in the
BIND documentation, or in the <url
url="ftp://metalab.unc.edu/pub/Linux/docs/HOWTO/DNS-HOWTO" name="DNS
HOWTO">. At the time of this writing, the following is a valid
root.hints file:
<tscreen><code>
H.ROOT-SERVERS.NET. 6d15h26m24s IN A 128.63.2.53
C.ROOT-SERVERS.NET. 6d15h26m24s IN A 192.33.4.12
G.ROOT-SERVERS.NET. 6d15h26m24s IN A 192.112.36.4
F.ROOT-SERVERS.NET. 6d15h26m24s IN A 192.5.5.241
B.ROOT-SERVERS.NET. 6d15h26m24s IN A 128.9.0.107
J.ROOT-SERVERS.NET. 6d15h26m24s IN A 198.41.0.10
K.ROOT-SERVERS.NET. 6d15h26m24s IN A 193.0.14.129
L.ROOT-SERVERS.NET. 6d15h26m24s IN A 198.32.64.12
M.ROOT-SERVERS.NET. 6d15h26m24s IN A 202.12.27.33
I.ROOT-SERVERS.NET. 6d15h26m24s IN A 192.36.148.17
E.ROOT-SERVERS.NET. 6d15h26m24s IN A 192.203.230.10
D.ROOT-SERVERS.NET. 6d15h26m24s IN A 128.8.10.90
A.ROOT-SERVERS.NET. 6d15h26m24s IN A 198.41.0.4
</code></tscreen>
<p>
The <tt>pz/127.0.0</tt> file is as follows:
<tscreen><code>
$TTL 86400
@ IN SOA example.com. root.example.com. (
1 ; Serial
8H ; Refresh
2H ; Retry
1W ; Expire
1D) ; Minimum TTL
NS dns.example.com.
1 PTR localhost.
</code></tscreen>
<p>
The <tt>pz/1.168.192</tt> file is as follows:
<tscreen><code>
$TTL 86400
@ IN SOA dns.example.com. root.dns.example.com. (
1 ; Serial
8H ; Refresh 8 hours
2H ; Retry 2 hours
1W ; Expire 1 week
1D ; Minimum 1 day
)
NS dns.example.com.
1 PTR fred.example.com.
PTR dns.example.com.
PTR mail.example.com.
2 PTR barney.example.com.
3 PTR wilma.example.com.
</code></tscreen>
and so on, where you create one PTR record for each machine with an
interface on the private network. In this example, fred.example.com is
on IP number 192.168.1.1, and is pointed to by the dns.example.com and
mail.example.com aliases. The machine barney.example.com is on IP
number 192.168.1.2, and so on.
<p>
The <tt>pz/example.com</tt> file is as follows:
<tscreen><code>
$TTL 86400
@ IN SOA example.com. root.dns.example.com. (
1 ; Serial
8H ; Refresh 8 hours
2H ; Retry 2 hours
1W ; Expire 1 week
1D ; Minimum 1 day
)
NS dns.example.com.
IN A 192.168.1.1
IN MX 10 mail.example.com.
IN MX 20 <ISP mail machine IP>.
localhost A 127.0.0.1
fred A 192.168.1.1
A 10.1.1.9
dns CNAME fred
mail CNAME fred
barney A 192.168.1.2
wilma A 192.168.1.3
betty A 10.1.1.10
www CNAME betty
ftp CNAME betty
</code></tscreen>
Note that we create entries for machines both within the private
network and on external IPs, since machines within the private network
will not query the ISP's name servers for a request on, say,
betty.example.com. We also provide both IP numbers for fred, the
private and external IP numbers.
<p>
One line in the ``options'' section of
<tt>/etc/named.conf</tt> bears discussion:
<tscreen><verb>
listen-on { 192.168.1.1 };
</verb></tscreen>
This will prevent your named daemon from answering DNS requests on the
outside interface (all requests from the outside must go through the
ISP's name resolver, not yours).
<sect2>Non-DNS Resolution On Private Network, ISP Handles Domain
<p>
&lsqb; Note: if you have chosen not to implement a private network, go to
section
<ref id="fully-exposed-isp" name="Fully Exposed Network, Hosted By
ISP">. &rsqb;
<p>
In this configuration, you have decided that your private network is
fairly small and unlikely to change often. You have decided not to use
the centralized database of a DNS server, and instead to maintain the
host resolution separately on each machine. All machines should use
the ISP's DNS server for their host name resolution for machines
beyond the private network gateway. For name resolution on the private
network, a hosts table has to be created. For Linux, this means
entering the names and IP numbers of all of the machines on the
private network into the <tt>/etc/hosts</tt> on each
machine. Any time a new machine is added, or a name or IP number is
changed, this file has to be updated on each Linux box.
<p>
As in section <ref id="dns-and-isp" name="DNS Resolution on Private
Network, ISP Handles Domain">, the list of host names on exposed IP
numbers must be sent to the ISP, and any aliases (such as for www and
ftp names) should be specified so that a CNAME entry can be created by
the ISP.
<sect2>You Are Primary DNS Authority For Domain
<p>
While you could set up <em>named</em> resolution on the exposed hosts, and
private database resolution for the private network, I will not cover
that case. If you're going to be running named for one service, you
ought really to do it for both, just to simplify the configuration. In
this section I will assume that the private network gateway machine is
handling name resolution both for the private network and for outside
requests.
<p>
At the time of this writing, under version 8.2.2 of the BIND package,
there is no way for a single <em>named</em> daemon to produce
different answers to requests, depending on which interface the
request arrives on. We want name resolution to act differently if the
query comes from the outside world, because IP numbers on the private
network shouldn't be sent out, but have to be available in answer to
requests from within the private network. There is some discussion of
a new ``views'' keyword which may be added to BIND to fill this need
at a later date, but until that happens, the solution is to run two
<em>named</em> daemons with different configurations.
<p>
First, set up the private network domain name server as described in
section <ref id="dns-and-isp" name="DNS Resolution on Private Network,
ISP Handles Domain">. This will be the name resolver visible
from within your private network.
<p>
Next, you have to set up DNS for your domain, as visible to hosts in
the outside world. First, check with your provider to see if they will
delegate reverse lookups of your IP numbers to them. While the
original DNS standard didn't account for the possibility of
controlling reverse DNS on subnets smaller than a class C network, a
workaround has been developed which works with all compliant DNS
clients, and has been outlined in
<url url="http://www.ietf.org/rfc/rfc2317.txt" name="RFC 2317">. If
your provider is willing to delegate control of reverse DNS on your IP
block, you will have to determine from them the exact name of the in-addr
pseudo-domain they have chosen to delegate to (the RFC does not offer
a convention they recommend for everyday use), and you will have to
register control for that pseudo-domain. I will assume that the
provider has delegated control to you, and the name of the
pseudo-domain is 8.1.1.10.in-addr.arpa. The provider would create
CNAME entries of the form
<tscreen><verb>
8.1.1.10.in-addr.arpa. 2H IN CNAME 8.8.1.1.10.in-addr.arpa.
9.1.1.10.in-addr.arpa. 2H IN CNAME 9.8.1.1.10.in-addr.arpa.
10.1.1.10.in-addr.arpa. 2H IN CNAME 10.8.1.1.10.in-addr.arpa.
etc.
</verb></tscreen>
in their zone file for the 1.1.10.in-addr.arpa domain. The
configuration of your 8.1.1.10.in-addr.arpa zone file is given later
in this section.
<p>
If your provider is willing to delegate control of the reverse DNS to
you, they will create CNAME entries in their reverse DNS zone table
for those IP numbers you control, pointing to the corresponding
records in your pseudo-domain, as shown above. If they are not willing
to delegate control to you, you will have to ask them to update their
reverse DNS entries any time you add, delete, or change the name of an
externally visible host in your domain. If the reverse DNS table is
not synchronized with your forward DNS entries, certain services may
generate warnings, or refuse to handle requests issued by machines
affected by the mismatch.
<p>
You now have to create a second <em>named</em> setup, this one to handle
requests issued by machines outside the private network gateway. This
setup lists only those hosts and IP numbers which are externally
visible, and responds only to requests on the outside interface of the
private network gateway machine.
<p>
First, create a second configuration file, for instance
<tt>/etc/named.ext.conf</tt> for requests from the external
interface. In our example, it might be as follows:
<tscreen><code>
options {
directory "/var/named";
listen-on { 10.1.1.9; };
};
zone "." {
type hint;
file "root.hints";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "pz/127.0.0";
};
zone "8.1.1.10.in-addr.arpa" {
type master;
file "ext/8.1.1.10";
};
zone "example.com" {
type master;
notify no;
file "ext/example.com";
};
</code></tscreen>
<p>
The <tt>root.hints</tt> and <tt>pz/127.0.0</tt>
files, both under <tt>/var/named</tt> are shared with the
other running daemon. The file <tt>ext/8.1.1.10</tt> is as
follows:
<tscreen><code>
$TTL 86400
@ IN SOA fred.example.com. root.fred.example.com. (
1 ; Serial
10800 ; Refresh 3 hours
3600 ; Retry 1 hour
3600000 ; Expire 1000 hours
86400 ) ; Minimum 24 hours
NS dns.example.com.
9 IN PTR fred.example.com.
PTR dns.example.com.
PTR mail.example.com.
10 IN PTR betty.example.com.
PTR www.example.com.
PTR ftp.example.com.
</code></tscreen>
<p>
The file <tt>ext/example.com</tt> contains the following:
<tscreen><code>
$TTL 86400
@ IN SOA example.com. root.fred.example.com. (
10021 ; Serial
8H ; Refresh 8 hours
2H ; Retry 2 hours
1W ; Expire 1 week
1D ; Minimum 1 day
)
NS fred.example.com.
IN A 10.1.1.9
IN MX 10 mail.example.com.
IN MX 20 <ISP Mail Machine>.
localhost A 127.0.0.1
fred A 10.1.1.9
betty A 10.1.1.10
dns CNAME fred
mail CNAME fred
www CNAME betty
ftp CNAME betty
</code></tscreen>
<p>
Start the two daemons on the private network gateway machine. Put the
following into your network daemon initialization scripts:
<tscreen><verb>
/usr/sbin/named -u dnsuser -g dnsgroup /etc/named.conf
/usr/sbin/named -u dnsuser -g dnsgroup /etc/named.ext.conf
</verb></tscreen>
I've assumed here that you have created the unprivileged user
``dnsuser, and the corresponding unprivileged group ``dnsgroup''. If a
bug in bind turns up, which allows an attacker to execute code from
within <em>named</em>, the attacker will find himself restricted to
those operations available to the unprivileged user. The
<tt>/var/named</tt> directory and the files within should not be
writable by ``dnsuser''.
<p>
The machines on the private network must have their name resolution
configured to ask dns.example.com (at IP 192.168.1.1 in our example),
while the externally visible machines can either query the network
gateway's outside interface (at IP 10.1.1.9 in our example), or the
ISP's DNS servers.
<sect2>Fully Exposed Network, Hosted By ISP<label id="fully-exposed-isp">
<p>
In this configuration, you have chosen to expose all of your
hosts. You have a real IP number for each machine in your domain, and
you've given your ISP the list of machine names and IP numbers. The
ISP has given you at least one IP number for their DNS host(s). Your
Linux boxes are now configured for name resolution in
/etc/resolv.conf:
<tscreen><code>
search example.com
nameserver <DNS host 1>
nameserver <DNS host 2>
</code></tscreen>
<p>
Windows boxes are configured with the same parameters, in the network
settings dialogues.
<sect2>Preparing DNS Before Moving Your Domain
<p>
If you decide to move your domain to a new IP number, either because
you have to change your ISP or because you've changed some details of
your service which require you to move to a new IP number from the
same ISP, you will have to make a few preparations ahead of the move.
<p>
You want to set things up so that the IP number fetched by a DNS
lookup somewhere in the outside world points properly to the original
IP number until you move, and then quickly points to the new IP number
after you move. Remote sites can have cached your IP number, and
subsequent queries may be answered locally from the cache, rather than
querying the appropriate servers. The effect of this might be that
people who had visited your site recently are unable to connect, while
new visitors have no problems, because only the new visitors are
getting valid uncached data. Complicating things further is the fact
that the root-level servers are only updated twice a day, so it's
difficult to time a change to the identities of your primary and
secondary DNS servers in the root servers.
<p>
The easiest way to make the transition is probably to duplicate the
entire site, or at least the publicly visible components of it, on the
new IP number, submit the changes, and then wait for the traffic to
shift completely to the new IP number. This is probably not very
practical, though.
<p>
What you should do first is to arrange with your new ISP (or your
current ISP if you've just changing IP numbers within a single ISP) to
host primary and secondary DNS during the transition. This should be
done at least a day before the move. Ask them to set the TTL on this
record to something appropriately small (for instance, five
minutes). The sample DNS files given earlier in this section all have
TTL values set to 86400 seconds (1 day). If your TTL is longer than
this, you will have to arrange the change that much more in advance of
the move. Ultimately, here's what you have to achieve. If your current
domain information TTL is, say, N hours, then the following have
to be finished more than N hours before the move:
<itemize>
<item>Your domain registration entry must show primary and secondary
DNS on the new ISP's machines in the root database. Allow at least a
day between the time you submit the change and the time the change
enters the database.
<item>The new primary and DNS servers should point to the original IP
numbers of your site, with a fairly small TTL.
</itemize>
Note that you cannot accelerate this process by reducing your current
domain TTL value, unless you've also done this at least N hours before
the move.
<p>
Now, you're ready for the move. Move your machines over to the new IP
numbers. Synchronize this with an update of the DNS records on your
ISP to point to the new numbers. Within five minutes (the small TTL
you set for the move), the traffic should have switched over to the
new site. You can now rearrange the DNS authority to your liking,
making yourself primary if that's how you want it, and putting the TTL
back up to a reasonably large value.
<sect1>DNS Configuration If You Are Not Hosting Email<label
id="dns-no-email">
<p>
The configurations described in section <ref id="setup-nameres"
name="Setting Up Name Resolution"> have MX records pointing to a
machine ``mail.example.com''. The MX record with the lowest priority
number following tells remote sites where to send email. Other MX
records with higher priority numbers are used as backup email
receivers. These backups will hold the mail for a certain period of
time if the primary email receiver is not able to accept the messages
for some reason. In the examples in that section, I have assumed that
fred.example.com, under its alias of mail.example.com, is handling
email for the domain. If you have chosen to let the ISP handle all of
your email hosting, you should change those MX records to point to the
appropriate ISP machines. Ask your ISP technical support
representative what host names you should use for the MX records in
the various files.
<sect1>Setting up Electronic Mail<label id="setup-email">
<p>
If you have chosen to do full electronic mail hosting for your domain,
you'll have to take special actions for email coming from hosts on the
private network, and for allowing transparent mail reading from
anywhere within the private network. Unless you're careful, messages
are likely to sit around for long times if they are waiting on one
host, and the intended recipient is logged on another machine. For
security reasons, I recommend that the incoming email not be
accessible from the externally visible hosts (this might help to
discourage a PHB who wants his desktop machine to be on a real IP,
then wonders why he gets brought down by a ping of death twice a
day). A transparent email sharing system on the private network fairly
straight-forward in sendmail. If anybody wants to provide
<em>tested</em> solutions for other mail handling daemons, I welcome
additions.
<sect2>A Solution Using "sendmail"
<p>
In order that email delivered to one host be visible on all machines,
the simplest solution is to export the mail spool directory with
read-write privileges over the entire private network. The private
network gateway machine will also act as mail collector and forwarder
for the entire private network, and so must have root write privileges
to the mail spool drive. The other clients may or may not squash root,
at your discretion. My general security philosophy is not to grant
privileges unless there is a clear reason for it, so I squash root on
the mail spool network drive for all hosts except the private network
gateway machine. This has the effect that root can only read his mail
from that machine, but this is not a particularly serious
handicap. Note that the mail spool drive can be a directory on the
private network gateway machine, exported via NFS, or it can be a
directory on one of the internal servers, exported to the entire
private network. If the mail spool drive is resident on the private
network gateway, there is no issue of squashing root for that
machine. If it is on another server, then note that email will be
undeliverable if that server, the gateway machine, or the network
connecting them, is down.
<p>
For Windows machines on your private network, you may either set up a
POP server on the mail spool host, or use samba to export the mail
spool to those machines. The Windows machines should be configured to
send and retrieve mail under a Linux username, such as
joeuser@example.com, so that the email address host name is the bare
domain name, not a machine name like barney.example.com. The outgoing
SMTP host should be set to the private network gateway machine, which
will be responsible for forwarding the mail and doing any address
rewriting.
<p>
Next, you should configure sendmail to forward email from the machines
on the private network, rewriting the addresses if necessary. Obtain
the latest sources to sendmail from the <url
url="http://www.sendmail.org/" name="sendmail.org WWW site">. Compile
the binaries, then go to the <tt>cf/domain</tt> subdirectory
within the sendmail source tree, and create the following new file:
<tt>example.com.m4</tt>
<tscreen><code>
divert(-1)
#
# Copyright (c) 1998 Sendmail, Inc. All rights reserved.
# Copyright (c) 1983 Eric P. Allman. All rights reserved.
# Copyright (c) 1988, 1993
# The Regents of the University of California. All rights reserved.
#
# By using this file, you agree to the terms and conditions set
# forth in the LICENSE file which can be found at the top level of
# the sendmail distribution.
#
#
#
# The following is a generic domain file. You should be able to
# use it anywhere. If you want to customize it, copy it to a file
# named with your domain and make the edits; then, copy the appropriate
# .mc files and change `DOMAIN(generic)' to reference your updated domain
# files.
#
divert(0)
define(`confFORWARD_PATH', `$z/.forward.$w+$h:$z/.forward+$h:$z/.forward.$w:$z/.forward')dnl
FEATURE(redirect)dnl
MASQUERADE_AS(example.com)dnl
FEATURE(masquerade_envelope)dnl
</code></tscreen>
<p>
This defines the domain ``example.com''. Next, you have to create the
<tt>sendmail.cf</tt> files which will be used on the mail
host (the private network gateway), and on the other Linux nodes on
the private network.
<p>
Create the following file in the sendmail source tree, under
<tt>cf/cf</tt>:
<tt>example.master.m4</tt>
<tscreen><code>
divert(-1)
#
# Copyright (c) 1998 Sendmail, Inc. All rights reserved.
# Copyright (c) 1983 Eric P. Allman. All rights reserved.
# Copyright (c) 1988, 1993
# The Regents of the University of California. All rights reserved.
#
# By using this file, you agree to the terms and conditions set
# forth in the LICENSE file which can be found at the top level of
# the sendmail distribution.
#
#
#
# This is the prototype file for a configuration that supports nothing
# but basic SMTP connections via TCP.
#
# You MUST change the `OSTYPE' macro to specify the operating system
# on which this will run; this will set the location of various
# support files for your operating system environment. You MAY
# create a domain file in ../domain and reference it by adding a
# `DOMAIN' macro after the `OSTYPE' macro. I recommend that you
# first copy this to another file name so that new sendmail releases
# will not trash your changes.
#
divert(0)dnl
OSTYPE(linux)dnl
DOMAIN(example.com)dnl
FEATURE(nouucp)
FEATURE(relay_entire_domain)
FEATURE(`virtusertable', `hash /etc/sendmail/virtusertable')dnl
FEATURE(`genericstable', `hash /etc/sendmail/genericstable')dnl
define(`confPRIVACY_FLAGS', ``noexpn,novrfy'')dnl
MAILER(local)
MAILER(smtp)
Cw fred.example.com
Cw example.com
</code></tscreen>
In this example we have disabled the ``expn'' and ``vrfy''
commands. An attacker could troll for aliases with ``expn'', trying
names like ``staff'', ``allstaff'', ``office'', and so on, until he
hits an alias which expands out several usernames for him. He can then
try the usernames against certain weak passwords in hopes of getting
in (assuming he can get a login prompt - the security settings
described in section <ref id="security" name="Securing Your Domain">
are set up so that no login prompt is available for off-site attackers).
<p>
The other file you should create will define the sendmail.cf for the
slave machines:
<tt>example.slave.m4</tt>
<tscreen><code>
divert(-1)
#
# Copyright (c) 1998 Sendmail, Inc. All rights reserved.
# Copyright (c) 1983 Eric P. Allman. All rights reserved.
# Copyright (c) 1988, 1993
# The Regents of the University of California. All rights reserved.
#
# By using this file, you agree to the terms and conditions set
# forth in the LICENSE file which can be found at the top level of
# the sendmail distribution.
#
#
#
# This the prototype for a "null client" -- that is, a client that
# does nothing except forward all mail to a mail hub. IT IS NOT
# USABLE AS IS!!!
#
# To use this, you MUST use the nullclient feature with the name of
# the mail hub as its argument. You MUST also define an `OSTYPE' to
# define the location of the queue directories and the like.
# In addition, you MAY select the nocanonify feature. This causes
# addresses to be sent unqualified via the SMTP connection; normally
# they are qualified with the masquerade name, which defaults to the
# name of the hub machine.
# Other than these, it should never contain any other lines.
#
divert(0)dnl
OSTYPE(linux)
FEATURE(nullclient, fred.$m)
Cm example.com
</code></tscreen>
<p>
You build the appropriate sendmail.cf files with the command:
<tscreen><verb>
make example.master.cf example.slave.cf
</verb></tscreen>
and then copy the files to the appropriate machines under the name
<tt>sendmail.cf</tt>.
<p>
This configuration puts most of the sendmail configuration files under
the <tt>/etc/sendmail/</tt> subdirectory. This configuration
causes <em>sendmail</em> to parse and use two special files,
<tt>virtusertable.db</tt> and
<tt>genericstable.db</tt>. To use these special files,
create their parent files. First,
<tt>virtusertable.src</tt>:
<tscreen><code>
John.Public@example.com jpublic
Jane.Doe@example.com jdoe@somemachine.somedomain
abuse@example.com root
Pointyhaired.Boss@example.com #phb#@hotmail.com
</code></tscreen>
This maps the email addresses on incoming email to new
destinations. Mail sent to John.Public@example.com is delivered
locally to the Linux account jpublic. Mail to Jane.Doe@example.com is
redirected to another email account, possibly in a different
domain. Mail to abuse@example.com is sent to root, and so on.
The other file is <tt>genericstable.src</tt>:
<tscreen><code>
jpublic John.Public@example.com
janedoe Jane.Doe@example.com
whgiii Pointyhaired.Boss@example.com
</code></tscreen>
This file renames the sender on outgoing email from locally-sourced
mail. While it clearly can't affect the return address for mail sent
directly from jdoe@somemachine.somedomain, it allows you to rewrite
the sender's email address from the internal usernames to whatever
email address convention you've chosen. Finally, create the following
<tt>Makefile</tt> in <tt>/etc/sendmail/</tt>:
<tscreen><code>
all : genericstable.db virtusertable.db
virtusertable.db : virtusertable.src
makemap hash virtusertable < virtusertable.src
genericstable.db : genericstable.src
makemap hash genericstable < genericstable.src
</code></tscreen>
Run <em>make</em> to create the hashed files which <em>sendmail</em>
can use, and remember to re-run <em>make</em> and restart
<em>sendmail</em> (or send it a SIGHUP) after any changes to either of
these ``.src'' files.
<sect2>Solutions Using Other Mail Transfer Agents
<p>
My experience is only with sendmail. If anybody would like to write
this section, please contact me. Otherwise, I may, at some later time,
try to provide details myself on such MTAs as <em>Postfix</em>,
<em>Exim</em>, or <em>smail</em>. I'd really rather somebody wrote
these sections who uses those programs.
<sect1>Setting up Web Space Hosting<label id="setup-www">
<p>
You should set up your externally visible web server on a machine
outside the private network, and not on the private network gateway
machine, for security reasons. If the web server needs access to
databases or other resources stored on the private network, the
situation becomes more complicated, both from a network and a security
standpoint. Such configurations are beyond the scope of this
document.
<p>
The details of setting up the server itself can be found in
the apache documentation, and in the <url
url="ftp://metalab.unc.edu/pub/Linux/docs/HOWTO/WWW-HOWTO" name="Linux
WWW HOWTO"> document.
<sect1>Setting up FTP Hosting<label id="setup-ftp">
<p>
Once again, your FTP host should be an externally visible machine, and
not the private network gateway machine. Follow the setup directions
which ship with your FTP daemon package. Be sure to download the most
recent version of the daemon, as there are security vulnerabilities in
some older versions of many daemons. If your FTP site does not require
anonymous users to upload files, be sure to disable that feature in
the daemon. I recommend that user (non-anonymous) FTP logins not be
permitted on the FTP host, that you require your regular users to use
scp, the secure shell remote copy command, for any file updating they
may have to do on the FTP host. This is to help build secure habits in
the users, and to protect against the ``hostile router'' problem
described in section <ref id="security" name="Securing Your Domain">.
<sect1>Setting up Packet Filtering<label id="setup-filtering">
<p>
This is discussed in detail in section <ref id="filtering"
name="Configuring Your Firewall">.
<sect>Securing Your Domain<label id="security">
<p>
This section deals with setting up security for your new domain. The
emphasis is on user-transparent features. If your security is too
obtrusive, and interferes strongly with the actions of the users, the
users will develop their own workarounds which may compromise the
entire domain. The best way to avoid this is to make the security as
transparent as possible, and to encourage users to come to you first
when they have difficulties which might be related to the security
measures of the site. A certain flexibility in attitude is
important. I know from personal experience that if the security policy
is too rigid, the users will simply set up their own network tunnels
through the firewall so they can log in from outside the domain. It's
better that remote login procedures, or whatever the users are trying
to do, be set up, inspected, and approved by you.
<p>
This section deals with securing your network against outside attack,
and against casual snooping from within. Securing your site against
determined attack from validated users within the private network is a
more difficult and involved task, and is beyond the scope of this
document.
<p>
One of the security considerations used in this section is protecting
against the ``hostile router''. The router provided by your ISP may be
a remotely configurable computer in its own right, with the
administrative password held by your provider. There have been
security problems in the past when the router's manufacturer override
password (the one used when your ISP forgets the password they
programmed in) has become known to system crackers. When possible, you
should design your security around the assumption that the router is
potentially hostile. That is, it could be using any IP number in your
public <em>or private</em> network blocks, it could be redirecting
traffic on outgoing packets to another site, and it could be recording
anything which goes through.
<sect1>Configuring Your Firewall<label id="filtering">
<p>
This section deals with configuring an <em>ipchains</em>-based
masquerading, forwarding, filtering router. You should probably read
the <url
url="ftp://metalab.unc.edu/pub/Linux/docs/HOWTO/IPCHAINS-HOWTO"
name="IPCHAINS-HOWTO"> document first, then look here for additional
hints. That HOWTO describes the steps necessary to compile a kernel
with masquerading support, and describes the use of the ipchains
binary in detail. You should enable firewalling on all machines with
exposed IP numbers.
<p>
Check your startup scripts to make sure that the sequence is as
follows on the private network gateway machine:
<enum>
<item>Outside Ethernet card is initialized.
<item>Firewall rules are run through ipchains.
<item>Forwarding is turned on.
<item>Network service daemons are started.
</enum>
So, as an example, on a Slackware-based system, the firewall
configuration should come between the execution of
<tt>rc.inet1</tt> and <tt>rc.inet2</tt>. Further,
if any problems arise during the firewall configuration steps, a
warning should be printed, and the external Ethernet card taken
off line before the network service daemons are run.
<p>
One common problem with ipchains-based firewalls is the tedium of
making sure that your rules are correctly set for packets arriving
from the loopback interface, or arriving from either of the internal
or external interfaces on the firewall machine. These locally-sourced
packets can be blocked by a firewall. All too often, this is fixed by
a sort of shotgun debugging approach, whereby the rules for the
firewall are tweaked until all applications seem to run properly on
the firewall host again. Unfortunately, this can sometimes result in a
firewall which has unintended holes. With ipchains it is possible to
write a firewall script which is easily debugged, and which avoids
many of the packet source problems. Here is a sample script,
<tt>/sbin/firewall.sh</tt>:
<tscreen><code>
#! /bin/sh
#
# New firewalling script using IP chains. Creates a filtering router
# with network masquerading.
#
# define a few variables
IPCHAINS=/sbin/ipchains
LOCALNET="192.168.1.0/24" # the private network
ETHINSIDE="192.168.1.1" # fred.example.com's private IP #
ETHOUTSIDE="10.1.1.9" # fred.example.com's public IP #
LOOPBACK="127.0.0.1/8"
ANYWHERE="0/0"
OUTSIDEIF=eth1 # fred.example.com's private interface
FORWARD_PROCENTRY=/proc/sys/net/ipv4/ip_forward
#
# These two commands will return error codes if the rules
# already exist (which happens if you run the firewall
# script more than once). We put the commands before "set -e"
# so that the script doesn't abort in that case.
$IPCHAINS -N outside
$IPCHAINS -N portmap
set -e # Abort immediately on error setting
# up the rules.
#
# Turn off forwarding and clear the tables
echo "0" > ${FORWARD_PROCENTRY}
$IPCHAINS -F forward
$IPCHAINS -F input
$IPCHAINS -F output
$IPCHAINS -F outside
$IPCHAINS -F portmap
#
# Masquerade packets from within our local network destined for the
# outside world. Don't masquerade packets which are local to local
$IPCHAINS -A forward -s $LOCALNET -d $LOCALNET -j ACCEPT
$IPCHAINS -A forward -s $ETHOUTSIDE -d $ANYWHERE -j ACCEPT
$IPCHAINS -A forward -s $LOCALNET -d $ANYWHERE -j MASQ
#
# Set the priority flags. Minimum delay connections for www, telnet,
# ftp, and ssh (outgoing packets only).
$IPCHAINS -A output -p tcp -d $ANYWHERE www -t 0x01 0x10
$IPCHAINS -A output -p tcp -d $ANYWHERE telnet -t 0x01 0x10
$IPCHAINS -A output -p tcp -d $ANYWHERE ftp -t 0x01 0x10
$IPCHAINS -A output -p tcp -d $ANYWHERE ssh -t 0x01 0x10
#
# Anything from our local class C is to be accepted, as are
# packets from the loopback and fred's external IP.
$IPCHAINS -A input -s $LOCALNET -j ACCEPT
$IPCHAINS -A input -s $LOOPBACK -j ACCEPT
$IPCHAINS -A input -s $ETHOUTSIDE -j ACCEPT
# We'll create a set of rules for packets coming from the big, bad
# outside world, and then bind all external interfaces to it. This
# rule will be called "outside"
#
# We also create a "portmap" chain. The sockets used by daemons
# registered with the RPC portmapper are not fixed, and so it is
# a bit difficult to set up filter rules for them. The portmap
# chain is configured in a separate script.
#
# Send packets from any outside interface to the "outside"
# rules chain. This includes the $OUTSIDEIF interface and any
# ppp interfaces we create for dialout (or dialin).
$IPCHAINS -A input -i ${OUTSIDEIF} -j outside
$IPCHAINS -A input -i ppp+ -j outside
##################################################
#
# Set up the "outside" rules chain #
#
##################################################
#
# Nobody from the outside should claim to be coming from our localnet
# or loopback
$IPCHAINS -A outside -s $LOCALNET -j DENY
$IPCHAINS -A outside -s $LOOPBACK -j DENY
#
# No packets routed to our local net should come in from outside
# because the outside isn't supposed to know about our private
# IP numbers.
$IPCHAINS -A outside -d $LOCALNET -j DENY
#
# Block incoming connections on the X port. Block 6000 to 6010.
$IPCHAINS -l -A outside -p TCP -s $ANYWHERE -d $ANYWHERE 6000:6010 -j DENY
#
# Block NFS ports 111 and 2049
$IPCHAINS -l -A outside -p TCP -s $ANYWHERE -d $ANYWHERE 111 -j DENY
$IPCHAINS -l -A outside -p TCP -s $ANYWHERE -d $ANYWHERE 2049 -j DENY
$IPCHAINS -l -A outside -p UDP -s $ANYWHERE -d $ANYWHERE 111 -j DENY
$IPCHAINS -l -A outside -p UDP -s $ANYWHERE -d $ANYWHERE 2049 -j DENY
#
# Block XDM packets from outside, port 177 UDP
$IPCHAINS -l -A outside -p UDP -s $ANYWHERE -d $ANYWHERE 177 -j DENY
#
# Block the YP/NIS port 653
$IPCHAINS -l -A outside -p TCP -s $ANYWHERE -d $ANYWHERE 653 -j DENY
#
# Don't bother logging accesses on TCP port 80, the www port.
$IPCHAINS -A outside -p TCP -s $ANYWHERE -d $ANYWHERE 80 -j DENY
#
# Accept FTP data and control connections.
$IPCHAINS -A outside -p TCP -s $ANYWHERE 20:21 -d $ANYWHERE 1024: -j ACCEPT
#
# Accept ssh packets
$IPCHAINS -A outside -p TCP -s $ANYWHERE -d $ANYWHERE ssh -j ACCEPT
#
# Accept DNS packets from outside
$IPCHAINS -A outside -p TCP -s $ANYWHERE -d $ANYWHERE 53 -j ACCEPT
$IPCHAINS -A outside -p UDP -s $ANYWHERE -d $ANYWHERE 53 -j ACCEPT
#
# Accept SMTP from the world
$IPCHAINS -A outside -p TCP -s $ANYWHERE -d $ANYWHERE 25 -j ACCEPT
#
# Accept NTP packets
$IPCHAINS -A outside -p UDP -s $ANYWHERE -d $ANYWHERE 123 -j ACCEPT
#
# Accept no tap ident packets, we don't use them
$IPCHAINS -A outside -p TCP -s $ANYWHERE -d $ANYWHERE 113 -j DENY
#
# Turn off and log all other packets incoming, TCP or UDP, on privileged ports
$IPCHAINS -l -A outside -p TCP -s $ANYWHERE -d $ANYWHERE :1023 -y -j DENY
$IPCHAINS -l -A outside -p UDP -s $ANYWHERE -d $ANYWHERE :1023 -j DENY
#
# Check against the portmapper ruleset
$IPCHAINS -A outside -j portmap
##############################################
#
# End of "outside" rules chain #
#
##############################################
#
# Block outgoing rwho packets
$IPCHAINS -A output -p UDP -i $OUTSIDEIF -s $ANYWHERE 513 -d $ANYWHERE -j DENY
#
# Prevent netbios packets from leaving
$IPCHAINS -A output -p UDP -i $OUTSIDEIF -s $ANYWHERE 137 -d $ANYWHERE -j DENY
#
# Turn on forwarding
echo "1" > ${FORWARD_PROCENTRY}
</code></tscreen>
Notice that the firewall can be used not only to block incoming
packets, but also outgoing packets which might leak information about
your private network, such as rwho and netbios packets.
<p>
As noted earlier, the portmapper rules are a bit different, because
the portmap daemons register themselves with the portmapper and are
told which ports to listen on. The ports used by a particular daemon
may change as you change the RPC services used, or change their order
of startup. The following script,
<tt>/sbin/firewall.portmap.sh</tt> generates rule sets for the
portmapped daemons:
<tscreen><code>
#! /bin/sh
#
ANYWHERE=0/0
IPCHAINS=/sbin/ipchains
$IPCHAINS -F portmap
# Rules for preventing access to portmapped services by people on the outside
#
/usr/bin/rpcinfo -p | tail +2 | \
{ while read program vers proto port remainder
do
prot=`echo $proto | tr "a-z" "A-Z"`
$IPCHAINS -l -A portmap -p $prot -s $ANYWHERE -d $ANYWHERE $port -j DENY || exit 1
done
}
</code></tscreen>
We didn't have to worry about whether packets coming in were
legitimate packets from the private network, the portmap chain is only
checked when the packets come in from the outside.
<p>
This firewall configuration logs most suspicious packets through
klogd with the kern.info logging priority. It will log normal
connection attempts, as well as all known ``stealth'' probes.
<p>
Now, we put these all together. We'd like to make sure that there
isn't a small window of vulnerability while the system is starting up,
so you should configure your startup sequence as follows:
<tscreen><code>
#! /bin/sh
#
# Get the network started, securely
#
#
/etc/rc.d/rc.inet1 # Configure the network interfaces
# and set up routing.
/sbin/firewall.sh || { echo "Firewall configuration failed"
/sbin/ifconfig eth1 down }
/sbin/ipchains -I outside 1 -j DENY # Deny all incoming packets
/etc/rc.d/rc.inet2 # Start the network daemons
sleep 5 # Let them stabilize
# Secure the portmapped services
/sbin/firewall.portmap.sh || { echo "Portmap firewall configuration failed"
/sbin/ifconfig eth1 down }
/sbin/ipchains -D outside 1 # Allow incoming packets
</code></tscreen>
This assumes that eth1 is the interface on the externally visible IP
number. If any of the ipchains rule sets fail to install, a warning is
issued and that interface is taken off line. The ``outside'' chain is set
to deny all packets before the network service daemons are started,
because the firewalling rules are not yet in place for the portmapped
services. Once the portmapped services are firewalled, the ``outside''
chain is restored to its proper behaviour.
<sect1>Configuring OpenSSH or SSH1<label id="config-ssh">
<p>
At the time of this writing, OpenSSH, like SSH1, now offers a
configuration setting which allows you to insert <em>scp</em>,
<em>ssh</em>, and <em>slogin</em> as binaries named <em>rcp</em>,
<em>rsh</em>, and <em>rlogin</em>, with transparent fall-through in
the ssh client programs to the original <em>rsh</em>, <em>rcp</em>, or
<em>rlogin</em> when the remote site isn't running
<em>sshd</em>. Making an invocation of <em>rsh</em> run, instead, the
<em>ssh</em> client program is, in my opinion, important for keeping
the security easy to use and out of the way of the users. Everybody's
scripts, <em>rdist</em> configurations, and so on will continue to
work without modification if the remote site is running <em>sshd</em>,
but data will be sent encrypted, with strong host authentication. The
converse will not always be true. Specifically, if the remote machine
is not running <em>sshd</em>, the <em>rsh</em> program will echo a
diagnostic to the screen warning that the connection is
unencrypted. This message breaks <em>rdist</em>, and possibly other
programs. The message cannot be suppressed with command line or
compile time switches. For <em>rdist</em>, one solution is to invoke
the program with <tt>-p /usr/lib/rsh/rsh</tt>.
<p>
Obtain ssh1 from the <url url="http://www.ssh.org/" name="ssh web
site">, or OpenSSH from the <url url="http://www.openssh.org/"
name="OpenSSH web site">, and compile it to replace the unencrypted
r-programs (<em>rsh</em>, <em>rlogin</em>, and <em>rcp</em>). First,
copy those three files to <tt>/usr/lib/rsh/</tt>, then configure the
ssh package with:
<tscreen><verb>
./configure --with-rsh=/usr/lib/rsh/rsh --program-transform-name='s/^s/r/' --prefix=/usr
</verb></tscreen>
Install the binaries, and configure according to the directions. On
the private network gateway machine, make sure that the sshd
configuration has the following entries defined:
<tscreen><verb>
ListenAddress 192.168.1.1 # fred's internal IP
IgnoreRhosts no
X11Forwarding yes
X11DisplayOffset 10
RhostsAuthentication no
RhostsRSAAuthentication yes
RSAAuthentication yes
PasswordAuthentication yes
</verb></tscreen>
You will have to do further configuration of other entries in the
<tt>/etc/sshd_config</tt> file, but try not to change these
fields. Once you have all of the entries in the file set to your
satisfaction, copy this entire file into a new file,
<tt>/etc/sshd_config.ext</tt>, for the external
network. Change two fields in the new file: the ``ListenAddress'' should
be changed to the private network gateway's external IP number
(10.1.1.9 in our fred.example.com case), and ``PasswordAuthentication''
should be set to ``no'' in <tt>/etc/sshd_config.ext</tt>. In
your network services startup script, start sshd twice, once with
<tscreen><verb>
/usr/sbin/sshd
</verb></tscreen>
and once with
<tscreen><verb>
/usr/sbin/sshd -f /etc/sshd_config.ext
</verb></tscreen>
This will create two running sshd daemons. The one operating on the
internal interface will allow logins with passwords, but the external
interface will require an RSA key validation before anybody can log
on.
<p>
Next, turn off incoming telnet and shell services in the inetd
configuration file (note that the firewall configuration listed in
section <ref id="filtering" name="Configuring Your Firewall"> already
prevents access from outside, but it's best to defend in depth, don't
rely on everything working correctly).
<p>
People who want to be able to log in from home, or from out of town,
will need an RSA key. Make sure they know how to do this, so they
don't spend their energies trying to figure out another way to do it,
like running a telnetd on an unprivileged port on your firewall
machine.
<p>
An RSA key is generated by the command:
<tscreen><verb>
ssh-keygen -b 1024 -f new_rsa_key
</verb></tscreen>
You will be prompted for a pass phrase. This should <em>not</em> be
blank. A person with access to the file
<tt>new_rsa_key</tt>, and knowledge of the pass phrase, has
everything necessary to pass an RSA authentication challenge. The
pass phrase can be an ``unguessable'' password, or a long sentence, but
make it something non-trivial. The file <tt>new_rsa_key</tt>
can be copied to a floppy disk, or onto a laptop, and, along with the
pass phrase, can be used to log into accounts which are set to grant
access to that particular RSA key.
<p>
To configure an account to allow access by a particular RSA key,
simply create a <tt>&dollar;HOME/.ssh/</tt> directory for that user
on the private network gateway machine (i.e. the machine which will be
receiving the login attempt), and copy the file
<tt>new_rsa_key.pub</tt> which was created by the
"ssh-keygen" command into the file
<tt>&dollar;HOME/.ssh/authorized_keys</tt>. See the section
``AUTHORIZED_KEYS FILE FORMAT'' in the sshd man page for details on
other options you can add to the key, such as requiring the login to
come from a certain IP or host name, or authorizing the key only to
permit the remote invocation of certain commands (for instance, an RSA
key which commands a backup to take place, or commands a status report
to be emailed somewhere off site).
<p>
Only one thing remains to make the RSA key mechanism as gentle as
possible to the users. If a user is forced to enter the pass phrase
more than once or twice in a session, they are likely to become bored
and take security matters into their own hands. Under Linux, arrange
their login shell to be invoked under <em>ssh-agent</em>. For
instance, if the company laptop used on business trips runs
<em>xdm</em>, and drops users into an X session, go into the
<tt>/var/X11R6/lib/xdm/Xsession_0</tt> file and change the lines which
invoke the startup, which are probably of the form:
<tscreen><verb>
exec "$startup"
</verb></tscreen>
into lines of the form:
<tscreen><verb>
exec ssh-agent "$startup"
</verb></tscreen>
In my xdm setup, there are three such lines which should be altered in
that one file. Now, when the user logs onto the laptop, he enters the
command
<tscreen><verb>
ssh-add new_rsa_key
</verb></tscreen>
at any prompt, enters the pass phrase when prompted, and all windows
will have pass phrase-free access to the account on the private network
gateway until the user logs off his X session on the laptop.
<p>
Run sshd on all of the machines on your private network, as well as on
any exposed hosts. For machines other than the private network gateway
machine, the ListenAddress entry in
<tt>/etc/sshd_config</tt> can be set to ``0.0.0.0''. You
should set up the host keys with the command:
<tscreen><verb>
ssh-keygen -b 1024 -f /etc/ssh_host_key -N ""
</verb></tscreen>
then run <em>make-ssh-known-hosts</em> and distribute the
<tt>/etc/ssh_known_hosts</tt> file among all of the machines
on the private and public networks.
<p>
Disable incoming telnet and the unencrypted r-services. Don't delete
the <em>telnet</em> binary, it's useful for things other than simple
telnet sessions on port 23. You should allow password authentication
on the private network, and disable it on the exposed machines,
requiring an RSA key to log onto the exposed hosts.
<p>
It is convenient for the users if the hosts on the private network are
mentioned in each other's <tt>/etc/hosts.equiv</tt>
files. The sshd daemons will respect those, and allow people to rlogin
and rsh between machines without passwords or pass phrases. On every
connection, the machines will be verifying each other's identities
with host-level RSA keys.
<p>
One difficulty arises when a user logged onto a machine on the private
network wants to log onto a box on an exposed IP number. You can't use
<tt>/etc/hosts.equiv</tt> or <tt>&dollar;HOME/.shosts</tt> to allow
password-less validation, because the user is coming from a machine
whose IP number cannot be determined - it will appear to be coming
from the masquerading firewall machine, but the host keys won't
match. There are two solutions to this. First, if you insist on using
the <tt>/etc/hosts.equiv</tt> or <tt>&dollar;HOME/.shosts</tt>
methods, the user will have to log onto the private network gateway
machine (fred.example.com in our example here), and then log through
to the exposed machine from there. The other technique is to use RSA
key authentication, that always works regardless of what games are
going on with IP numbers and host name lookups.
<sect1>Configuring X
<p>
In the user's continuing quest to prove that he values convenience
over security, it has become common for people to put
<tscreen><verb>
xhost +
</verb></tscreen>
commands right into their X initialization scripts. This grants X
server access to everybody in the world. Now the random outsider can
change your root window graphic to something embarrassing while your
boss is showing his mother around your office. Alternately, this
outsider can quietly monitor every keystroke you issue, and dump the
contents of your screen to his desktop. Needless to say, this doesn't
bode well for passwords used to log into other sites, or for sensitive
documents being edited on screen. The xhost protocol itself is
inherently limited, as it is not possible to grant permissions to use
the screen on a user basis, only on a machine basis.
<p>
Enter <em>xauth</em> authentication. If you have <em>xdm</em> you
probably already are running <em>xauth</em> authentication, but
<em>xhost</em> still works, and might still be what people are using
to run X processes between machines. Once again, the goal is to make
the security easy enough to use that the users aren't tempted to run
the <em>xhost</em> command anymore.
<p>
The sshd setup described in section <ref id="config-ssh"
name="Configuring SSH1">, with the ``X11Forwarding'' flag set, is
actually simpler to use than the <em>xhost</em> technique. Once you
have logged into your terminal, you can simply rlogin to a remote
machine, and run <em>netscape</em>, <em>xv</em>, or whatever you like,
without having to set the &dollar;DISPLAY variable name or allow
explicit permissions. During <em>ssh</em> login, it configures the
system in a way transparent to the end user, and even encrypts all of
your X packets before they go over the network.
<p>
If you are unable to use the sshd X11 forwarding for some reason, you
should use <em>xauth</em> when you want to authorize other machines to have
access to your X server. Document this for the users, or create
specialized shell scripts to help them out. The relevant command to
authorize a particular login, ``jpublic'', on machine ``barney'' to have
access to your X server is:
<tscreen><verb>
/usr/X11/bin/xauth extract - $DISPLAY | rsh -l jpublic barney /usr/X11/bin/xauth merge -
</verb></tscreen>
This sequence is not necessary to authorize X connections from
machines which share a common NFS-mounted home directory. The xauth
key will be immediately available to that user on all machines which
mount the same home directory.
<p>
I'd be tempted to delete <em>xhost</em> from your machines entirely. If it
causes problems with any programs, you will at least know that those
programs had poorly-designed security. It's simple enough to build a
shell script as a drop-in replacement for <em>xhost</em> which uses the
<em>xauth</em> sequence listed above.
<p>
Note that if <em>rsh</em> is not the encrypting ssh program, the xauth
key is sent plaintext. Anybody who holds the plaintext of the key can
access your server, so you do not gain much security if you don't use
ssh for these transactions. Note, also, that if the users' home
directories are exported via NFS (the Network File System), the xauth
key is available in plaintext to anybody able to snoop those NFS
packets, regardless of whether you're running ssh on your systems.
<sect1>Configuring Disk Sharing
<p>
With email coming to a central machine, the read/send from any host
setup described here is very convenient, but some care has to be taken
to protect against trivial snooping by bored local users. NFS without
AUTH_DES implemented is inherently insecure. NFS relies on the client
machine to authenticate access, there is no password verification on
the server to make sure that the client should be permitted to access
the private files of a particular user. A Windows box can be
configured to read NFS-exported volumes as any numeric uid, completely
bypassing UNIX file permissions. Consequently, NFS exports should
only be made to machines which are always Linux (or UNIX) boxes under
your direct control, and never ones which can be dual-booted into
Windows. If you want to export the mail spool directory, or any other
directory, to machines which can sometimes be used as Windows boxes,
export them with samba, setting the authentication mode to
``security=USER''. Connecting the machines on your network with a
switch rather than a hub will also help, as it leaves very little of
interest for sniffers on Windows machines. Ultimately, though, it's
very difficult to secure any disk sharing over the network at the time
of this writing.
<p>
Why bother, if you can't really secure the network disks? Mostly it's
an issue of credible defense. If you leave a sheet of paper on your
desk with confidential information, and somebody in the office reads
it, he can argue that he didn't realize what the paper was, his
natural curiosity just got the better of him when he saw it sitting on
the desk. If the sheet of paper were in a filing cabinet or desk
drawer, it's an entirely different story. The purpose of taking some
basic network security measures internally is to ensure that nobody
``accidentally'' compromises security.
<sect>Acknowledgements
<p>
This document was written as internal documentation for the DYNACAN
project, as part of the project's continuing development under the
control of the Ministry of Human Resources Development Canada.
<p>
This document has benefited considerably from the suggestions of
<itemize>
<item>Rod Smith (<url url="mailto:rodsmith@rodsbooks.com"
name="rodsmith@rodsbooks.com">), who suggested I provide details on
registering a domain name and on setting up with a dynamic IP, and
pointed me at the various dynamic IP hosting services and at Granite
Canyon.
<item>Greg Leblanc (<url url="gleblanc@my-deja.com"
name="gleblanc@my-deja.com">) for useful suggestions on improving
the clarity of the document.
<item>Sami Yousif (<url url="mailto:syousif@iname.com"
name="syousif@iname.com">).
<item>Marc-Andr&eacute; Dumas (<url
url="mailto:m&lowbar;a&lowbar;dumas@hotmail.com"
name="m&lowbar;a&lowbar;dumas@hotmail.com">), who suggested the
section on moving your domain to a new IP number.
<item>Osamu Aoki (<url url="mailto:aoki@pacbell.net"
name="aoki@pacbell.net">).
<item>Joao Ribeiro <(url url="mailto:sena@decoy.ath.cx"
name="sena@decoy.ath.cx">).
</itemize>
<sect>Glossary of Terms
<p>
This is a list of the meanings of some of the words and acronyms used
in this document.
<descrip>
<tag/CGI Script/ A Common Gateway Interface Script. This is a program
which is run on demand to generate the content of a web page. If a web
page has to do more than simply feed an unchanging text and graphics
display to the viewer, you will probably need some sort of dynamic
content generation program such as a CGI Script. Examples include
discussion boards, feedback forms, e-commerce shopping carts, and
more.
<tag/<label id="glossary-dhcp">DHCP/ Dynamic Host Configuration
Protocol. A standard, defined in RFC 1531, for computers on a TCP/IP
network to request from a central server information such as the IP
number they should be using, the netmask, the gateway, etc. Rather
than an administrator entering this information into the machine
configuration, the machine simply requests it from the server as it is
preparing to attach to the network.
<tag/<label id="glossary-dns">DNS/ Domain Name Service. A standard for
translating domain names into <ref id="glossary-ip-num" name="IP
Number">s, or vice versa, by looking up data in centralized databases.
<tag/DSL/ Digital Subscriber Line. A relatively high speed network
connection, usually delivered through specialized telephone wiring.
<tag/<label id="glossary-dyn-ip">Dynamic IP Number/ An <ref
id="glossary-ip-num" name="IP Number"> which is assigned periodically
or on a per-session basis. No guarantee is made that the number will
remain constant. A dynamic IP number might change only when your
network connection hangs up and reconnects, or it might change
periodically under <ref id="glossary-dhcp" name="DHCP">
negotiation. Certain session-based services such as <em>telnet</em>
and <em>ssh</em> will stop working if the IP number of either end of
the connection is changed during the session.
<tag/Forward DNS Query/ A <ref id="glossary-dns" name="DNS"> query
which converts a domain name into an <ref id="glossary-ip-num" name="IP
Number">.
<tag/<label id="glossary-ftp">FTP/ The File Transfer Protocol. A
standard system for sending files between machines over the Internet.
<tag/ftpd/ The daemon responsible for providing <ref id="glossary-ftp"
name="FTP"> services on a host. It responds to queries initiated by a
remote client.
<tag/Internet Service Provider/ See <ref id="glossary-isp" name="ISP">.
<tag/IP/ See <ref id="glossary-ip-num" name="IP Number">.
<tag/<label id="glossary-ip-num">IP Number/ The ``address'' of a
certain network interface. Under the current addressing standard,
called ipv4, this number consists of four 8-bit values, generally
written as base-10 numbers separated by dots. Communication between
computers on the Internet is based on packets of information sent
between IP numbers.
<tag/<label id="glossary-isp">ISP/ Internet Service Provider. The
company which provides your network connectivity, including connection
hardware, service hosting, and leasing out the IP numbers under their
control.
<tag/Masquerading/ A form of filtering in which packets from one
machine to the outside world have their headers rewritten so that they
appear to come from an intermediate machine. That intermediate machine
then passes responses back to the originating machine. The net effect
is that an entire network of machines can appear to use a single IP
number, that of the masquerading host, for the purpose of outgoing
connections.
<tag/named/ The name server daemon. This is the daemon which answers
<ref id="glossary-dns" name="DNS"> queries, and is distributed as part
of the BIND package.
<tag/Network Time Protocol/ See <ref id="glossary-ntp" name="NTP">.
<tag/<label id="glossary-ntp">NTP/ Network Time Protocol. A standard
for synchronizing your system clock with the ``true time'', defined as
the average of many high-accuracy clocks around the world.
<tag/OS/ Operating system. Linux, Windows, FreeBSD, BeOS, HP-UX, etc.
<tag/PHB/ <url
url="http://www.unitedmedia.com/comics/dilbert/about/html/boss.html" name="Pointy-Haired Boss">. A creation of Scott Adams, of Dilbert
fame.
<tag/Provider/ See <ref id="glossary-isp" name="ISP">.
<tag/Reverse DNS Query/ A <ref id="glossary-dns" name="DNS"> query
which converts a <ref id="glossary-ip-num" name="IP
Number"> into a domain name.
<tag/Router/ A specialized hardware device which implements rules for
where to send packets based on their <ref id="glossary-ip-num"
name="IP Number">s, and which bridges between your Ethernet hardware
and whatever communications medium connects you to your <ref
id="glossary-isp" name="ISP">.
<tag/ssh/ The secure shell. A cryptographically strong replacement for
<em>rlogin</em>, <em>telnet</em>, <em>ftp</em>, and other programs.
Protects against ``spoofing'', man in the middle attacks, and packet
sniffing.
<tag/Static IP Number/ An <ref id="glossary-ip-num" name="IP Number">
which has been assigned or leased to you permanently. Barring
revocation of the agreement which granted you this number, that IP
number will always be available for your use, and no other machine on
the Internet is allowed to use that number. Contrast this with <ref
id="glossary-dyn-ip" name="Dynamic IP Number">s.
</descrip>
</article>
View Git Blame Copy Permalink