2016-01-25 22:56:21 +00:00
|
|
|
<!doctype linuxdoc system>
|
2000-10-27 17:00:20 +00:00
|
|
|
<!-- 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>
|
|
|
|
[ 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">. ]
|
|
|
|
|
|
|
|
<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>
|
|
|
|
[ 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">. ]
|
|
|
|
|
|
|
|
<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>$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>$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>$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>$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 $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é Dumas (<url
|
|
|
|
url="mailto:m_a_dumas@hotmail.com"
|
|
|
|
name="m_a_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>
|