Email Tom
Tom's Website
Email Brian
Brian's Website
|
Email Tom Tom's Website |
|
Email Brian Brian's Website |
Go to the Table Of Contents
Did you read the Preface? Thanks!
The DMZ (or Demilitarized Zone) is, in networking parlance, the part of a network that lies in the area outside of or parallel to a private internal network, yet is still within the network's "sphere of influence." Usually, this is a subnet separate from the main internal subnet, although it can also be on distinct routable IP addresses as well. This is not to say that these machines are unprotected. They are frequently secured using many of the same programs and procedures as the firewall protecting the network.
Sometimes these servers are just additional daemons running on the same system serving as a firewall. While this is efficient in terms of asset conservation (fewer computers doing the same amount of work makes bean counters happy), every service provided becomes a potential point of compromise for the "bad guys." For this reason, these services are usually relegated to one or more separate machines, and fenced off from the internal network by a separate firewall device.
The services discussed in this chapter are all generally recognized as "public," in that they are commonly configured to provide some degree of public access (in addition to internal users). In the sections that follow, we take a look at DNS, the name resolution service that provides one of the primary chains linking the Internet's disparate parts. Then we'll touch on e-mail service, and the types of programs that work in concert to send and receive messages. File Transfer Protocol is bundled with OpenLinux in the form of wuftp, the FTP server from Washington University. And if you've got a hankering to run your very own Web server, Apache is the dominant product of choice for over 60 percent of all sites hosted world-wide. Finally, we'll take a glance at setting up and configuring a news server.
Note
Both e-mail and Web services are common (and complex) enough that after a brief introduction for each, we'll hand the coverage off to separate chapters. Sendmail is addressed in Chapter 25, and the Apache Web Server is detailed in Chapter 26.
When providing services to the outside world, it's important that they be found at the same place all the time, that is, at a static IP address. To use an analogy, suppose that you have pizza ordered to the same address every night. But on any given night you might be found in a different apartment. You won't get your pizza very often!
Additionally, even if you do have a fixed address on the Internet, your service agreement with your upstream provider may disallow some or all server types. Be sure you understand what the limitations of your connection are, so that you don't find yourself summarily disconnected one day. Now let's look at DNS.
Hubris Alert
"Understanding DNS" is just a section title, and a goal. Observe that this is NOT a statement of the actual accomplishment on our part, though we tried mightily. On more than one occasion, we've watched better minds than ours crumble before the complexity of DNS configuration. That said, it really isn't that bad. Just be persistent, and make sure to take lots of baby steps. Big changes break DNS in weird and mysterious ways.
DNS is an acronym for Domain Name System (not Dynamic Name Service, as some people mistakenly believe). DNS provides the definition or map for the hierarchy of all computers connected to the Internet. The DNS structure was first introduced in the early 1980s for ARPANET (the Advanced Research Projects Agency Network, a development of the US Department of Defense), the predecessor of the Internet. Today, almost every machine that participates in a network - large or small - knows how to find its neighbors using the principles of DNS.
More Info
Name resolution in the early days of ARPANET was often handled using hosts files that had to be updated, and distributed, every time a machine was added to the network. Over time, the number of hosts made maintaining these files increasingly difficult, hence the advent of the DNS distributed hierarchical database.
Let's presume you have five physical machines connected to a local network, with one machine serving as an Internet gateway. Consider the setup shown in Table 24-1, (which includes two additional virtual machines, courtesy of VMware at http://www.vmware.com):
Table 24-1
A Home Network
| Machine Name | IP Address | Purpose of Machine |
grendel.orbdesigns.com |
192.168.0.1 |
Router, gateway, Web server, mail server. |
pavillion.orbdesigns.com |
192.168.0.2 |
Workstation #1. |
grinch.orbdesigns.com |
192.168.0.7 |
Workstation #2. |
fleet.orbdesigns.com |
192.168.0.3 |
Laptop #1. |
gryphon.orbdesigns.com |
192.168.0.9 |
Laptop #2. |
gwydion.orbdesigns.com |
192.168.0.5 |
Virtual eDesktop test server running on Grinch. |
mordred.orbdesigns.com |
192.168.0.10 |
Virtual eDesktop test client running on Grinch. |
For inter-machine communications, these hosts need to be able to find each other. While computers are quite content using just IP numbers, humans prefer a slightly more personal approach, so we give each machine a host name. A host name is a lot easier to remember than an IP number, especially when you work with a large network like the Internet. Unfortunately, these names are meaningless to the computer. To satisfy all parties involved, we have to create associations between the names we use, and the numeric addresses that computers recognize.
There are two approaches to providing the required correlation between host names and IP addresses. The first is the hosts file. Most Linux distributions place this file in /etc/hosts. The equivalent file in a Windows environment is called either lmhosts, or lmhosts.sam. The following listing is the /etc/hosts for our home network:
# /etc/hosts last modified 8/13/2000 bpb
#
# Always keep a localhost entry here, some programs need it.
127.0.0.1 localhost.localdomain localhost
# Define machines on the local net: format is IP FQDN Nickname(s)
192.168.0.1 grendel.orbdesigns.com grendel
192.168.0.2 pavillion.orbdesigns.com pavillion
192.168.0.3 fleet.orbdesigns.com fleet
192.168.0.7 grinch.orbdesigns.com grinch
192.168.0.9 gryphon.orbdesigns.com gryphon
# Define external machines if necessary (fast access for ssh & others)
# Define temporary local machines (including VMs).
192.168.0.5 gwydion.orbdesigns.com gwydion
192.168.0.10 mordred.orbdesigns.com mordred
A couple of terms need defining. FQDN stands for Fully Qualified Domain Name. While it's not strictly necessary that our internal machines have these, they make administration much easier as the network grows, and all networks do grow. Nicknames are handy for addressing the computers without having to type the FQDN each time.
Every Linux installation should at least have the localhost definition in place. For small networks, it's not difficult to create a hosts file and replicate it on every computer that's a member of the network. At some point in time, however, this approach is going to become unwieldy due to the number of machines involved, or because the appointed administrator lacks the time to keep up with required changes (understandably so - most people tasked with administering a small business network usually wear at least two other hats within the organization).
Running your own DNS server may be the answer you're looking for. Address-to-host translation can be managed from one central location. In addition to name resolution services, DNS underlies e-mail delivery protocols and Web site URLs. As previously noted, DNS is the glue that binds the Internet, pun intended. What pun? Ah, BIND is the name of the software suite that provides name services to the vast majority of Internet-connected computers.
BIND is the acronym for Berkeley Internet Name Domain, written at UC Berkeley under a DARPA [CT1]grant. After a number of transitions, BIND is now in the care of the Internet Software Consortium (http://www.isc.org). BIND 8.2.2p5 (that's version 8.2.2, patch level 5) is the most recent version 8 release, and is the default DNS server software bundled with eDesktop.
Warning
An exploit for named (including the version shipped in all current versions of OpenLinux) has been discovered. Upgrade to bind-8.2.2p7-1. See the details at Caldera's security updates page (http://www.caldera.com/support/security). The advisory is dated 11/10/2000.
In addition, Bind 9 (Fall 2000) is out and provides some new cutting edge abilities. However, the ISC group (http://www.isc.org/products/BIND/bind9.html) recommends the new version only for early adopters and those users who need to experiment with the latest features, such as IPv6 and DNSSEC.
The daemon that provides DNS service is called named. In Chapter 21, we showed you how to disable it. We'll reverse this process shortly. But first we have a decision to make, and some files to create. The decision is what kind of services we want to provide. There are several different types of name server:
Our choice is to build a primary master name server for orbdesigns.com, to be used for internal access only. That is, the server is located inside the firewall, and is unavailable to computers from the Internet. The main configuration file is /etc/named.conf:
// /etc/named.conf for gwydion.orbdesigns.com bpb 10/27/2000
// Options section for the named daemon:
// Set the directory where zone files are found
// and the default port, to provide guidance for a
// nameserver behind the firewall.
options {
directory "/var/named";
query-source port 53;
};
// root servers file
zone "." {
type hint;
file "root.hints";
};
// reverse lookup for local machine
zone "0.0.127.IN-ADDR.ARPA" {
type master;
file "localhost.rev";
};
// reverse lookup for the local zone
zone "0.168.192.in.addr.arpa" {
type master;
file "db.192.168.0";
};
// (private) master zone for orbdesigns.com
zone "orbdesigns.com" {
type master;
file "orbdesigns.com.zone";
};
Comments in named.conf are on separate lines, and begin with two forward slashes. The directory /var/named is where the rest of the required files (specified in each of the zone definitions) will be located. (This varies from distribution to distribution, but the premise is the same).
The root servers are at the foundation of the Internet - their addresses are downloaded and stored in /var/named/root.hints. When a host name can't be resolved at the local nameserver, a query is sent to one of the root servers to begin the process of name resolution. The other three zone files provide the named daemon with the information it needs concerning local host names and IP addresses. All other requests get kicked up to the root servers for external attention. As for the actual contents of the zone files, you'll need to customize this example to match your own data.
Hint
Comments can also be delimited using two semi-colons, but only in the named.conf file. You can also use, according to the man page, C style comments (/* comment */) and hash signs (# comment).
The next listing is a current /var/named/root.hints:
; <<>> DiG 8.2 <<>> @a.root-servers.net . ns
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 13
;; QUERY SECTION:
;; ., type = NS, class = IN
;; ANSWER SECTION:
. 6D IN NS A.ROOT-SERVERS.NET.
. 6D IN NS H.ROOT-SERVERS.NET.
. 6D IN NS C.ROOT-SERVERS.NET.
. 6D IN NS G.ROOT-SERVERS.NET.
. 6D IN NS F.ROOT-SERVERS.NET.
. 6D IN NS B.ROOT-SERVERS.NET.
. 6D IN NS J.ROOT-SERVERS.NET.
. 6D IN NS K.ROOT-SERVERS.NET.
. 6D IN NS L.ROOT-SERVERS.NET.
. 6D IN NS M.ROOT-SERVERS.NET.
. 6D IN NS I.ROOT-SERVERS.NET.
. 6D IN NS E.ROOT-SERVERS.NET.
. 6D IN NS D.ROOT-SERVERS.NET.
;; ADDITIONAL SECTION:
A.ROOT-SERVERS.NET. 5w6d16h IN A 198.41.0.4
H.ROOT-SERVERS.NET. 5w6d16h IN A 128.63.2.53
C.ROOT-SERVERS.NET. 5w6d16h IN A 192.33.4.12
G.ROOT-SERVERS.NET. 5w6d16h IN A 192.112.36.4
F.ROOT-SERVERS.NET. 5w6d16h IN A 192.5.5.241
B.ROOT-SERVERS.NET. 5w6d16h IN A 128.9.0.107
J.ROOT-SERVERS.NET. 5w6d16h IN A 198.41.0.10
K.ROOT-SERVERS.NET. 5w6d16h IN A 193.0.14.129
L.ROOT-SERVERS.NET. 5w6d16h IN A 198.32.64.12
M.ROOT-SERVERS.NET. 5w6d16h IN A 202.12.27.33
I.ROOT-SERVERS.NET. 5w6d16h IN A 192.36.148.17
E.ROOT-SERVERS.NET. 5w6d16h IN A 192.203.230.10
D.ROOT-SERVERS.NET. 5w6d16h IN A 128.8.10.90
;; Total query time: 96 msec
;; FROM: gwydion.orbdesigns.com to SERVER: a.root-servers.net 198.41.0.4
;; WHEN: Sat Oct 28 13:44:53 2000
;; MSG SIZE sent: 17 rcvd: 436
You can download the most recent listing of the root servers using the following procedure:
[root@gwydion named]# dig @a.root-servers.net . ns > root.hints.new
[root@gwydion named]# chmod 444 root.hints.new
[root@gwydion named]# mv root.hints root.hints.old
[root@gwydion named]# mv root.hints.new root.hints
[root@gwydion named]# /etc/rc.d/init.d/named start
new pid is nnnnn
The first line requests a copy of the latest canonical name server information from one of root servers. Next, make the new file read-only for all users, rename the old root.hints file, and rename the new file to root.hints. Finally, if DNS is already in operation, use the /etc/rc.d/init.d/named script to restart the daemon. Restarting the daemon forces named to re-load the new root.hints and existing zone files.
Oft-Forgotten Usage
All the domain name references in zone files are terminated with an explicit period. This is a result of the structure of the Internet, which starts with the root ".", followed by a number of Top Level Domains (TLDs, for example: edu, com, net, and others). Names are used with the most distant information first, as in machinename.subdomain.domain.tld, but for full specification in name server use, the terminating period fully qualifies the name, all the way to the root, thus: "grinch.orbdesigns.com." Leaving this terminating period off is the single most common mistake while writing and modifying zone files.
At the risk of sounding repetitious, you cannot use the example zone files that follow exactly. Adapt the names and addresses to match your local network setup. Now let's have a look at the local reverse lookup zone file, /var/named/localhost.rev:
;
; localhost reverse db file bpb 10/27/2000
;
$TTL 3600 ; set time to live when queried
@ IN SOA gwydion.orbdesigns.com. hostmaster.orbdesigns.com.
(
0010273 ; Serial number, increment with each change
3600 ; Refresh every hour
900 ; Retry every 15 minutes
3600000 ; Expire 1000 hours
3600 ) ; Minimum 1 hour
IN NS gwydion.orbdesigns.com.
1 IN PTR localhost.
The SOA record (Start Of Authority) record in localhost.rev designates the zone the computer is a member of. Given is the full hostname, and e-mail address of the responsible person (traditionally "hostmaster," which is aliased to a real person by e-mail software). A selection of zone configuration data is listed, with some fairly standard values given (all numbers listed are in seconds). Then the NS (name server) is specified (the hostname of the computer running the name server). The final resource record in this zone file is a PTR (Pointer Record), which in this case is an address-to-name mapping.
Hint
All zone files begin with a SOA record. This record indicates that the name server referenced is the best source of information for the data (host names and their respective IP's) within this zone.
Huh? What address? There's only a 1 at the beginning of the line! That's right. This is the reverse zone for 127.0.0.1, and the zone is called out in /etc/named.conf as "0.0.127.IN.ADDR.ARPA," which is DNS-speak for the reverse zone for subnet 127.0.0.n. The possibilities for n are listed as pointer records in the zone file. So all told, 127.0.0.1 resolves to the name localhost, according to this data. This usage is clarified in the next zone file, /var/named/ db.192.168.0:
;
; 192.168.0 reverse lookup db bpb 10/27/2000
;
$TTL 3600
@ IN SOA gwydion.orbdesigns.com. hostmaster.orbdesigns.com.
(
0010275 ; Serial number, increment with each change
3600 ; Refresh every hour
900 ; Retry every 15 minutes
3600000 ; Expire 1000 hours 5w6d16h
3600 ) ; Minimum 1 hour
IN NS gwydion.orbdesigns.com.
0 IN PTR network.orbdesigns.com.
1 IN PTR grendel.orbdesigns.com.
2 IN PTR pavillion.orbdesigns.com.
3 IN PTR fleet.orbdesigns.com.
7 IN PTR grinch.orbdesigns.com.
9 IN PTR gryphon.orbdesigns.com.
; Some temporary vm definitions
5 IN PTR gwydion.orbdesigns.com.
10 IN PTR mordred.orbdesigns.com.
While many of the features are the same, in the PTR section each computer is defined by its IP address, along with the overall network (which is 192.168.0.0). Next, the local orbdesigns.com.zone file needs to be written.
;
; orbdesigns.com forward zone db bpb 10/27/2000
;
$TTL 3600
@ IN SOA gwydion.orbdesigns.com. hostmaster.orbdesigns.com.
(
1 ; Serial number, increment with each change
3600 ; Refresh every hour
900 ; Retry every 15 minutes
3600000 ; Expire 1000 hours
3600 ) ; Minimum 1 hour
IN NS gwydion.orbdesigns.com.
IN A 192.168.0.5
localhost IN A 127.0.0.1
grendel IN A 192.168.0.1
pavillion IN A 192.168.0.2
fleet IN A 192.168.0.3
grinch IN A 192.168.0.7
gryphon IN A 192.168.0.9
gwydion IN A 192.168.0.5
mordred IN A 192.168.0.10
Here, instead of PTR records that associate addresses with names, we have A records, which are the name-to-address mappings.
Now we need to place the final piece in the DNS configuration puzzle. The name resolver utility has to be pointed at your freshly minted name server. Make a backup copy, then edit the file /etc/resolv.conf to point at your local domain and name server.
# /etc/resolv.conf 10/27/2000 bpb
#
# Set search domain to local (as opposed to ISP)
search orbdesigns.com
# Set nameserver to localhost
nameserver 127.0.0.1
Note
Note that Linux always uses resolv.conf, whether you're running a local service, or accessing remote name servers. Oncenamedis running, remote clients can access your running DNS server. To test and use it on your local machine, you need to tell the local resolver to look locally for DNS.
With all of these configuration files in place, it's time to start up the named daemon, and see that everything works.
Under the assumption that DNS is not running, start named, then examine the system log (/var/log/messages, or on some other distributions, /var/log/syslog) for details of the startup. Many problems in configuration can be easily detected by examining this log file:
[root@gwydion named]# /etc/rc.d/init.d/named start
Starting BIND DNS server: named.
[root@gwydion named]# tail -11 /var/log/messages
Oct 28 15:33:44 gwydion named[1277]: starting. named 8.2.2-P5 Thu Feb 17
16:11:19 MST 2000 ^[email protected]:/usr/src/OpenLinux/BUILD/bind-
8.2.2p5/src/bin/named
Oct 28 15:33:44 gwydion named[1277]: hint zone "" (IN) loaded (serial 0)
Oct 28 15:33:44 gwydion named[1277]: master zone "0.0.127.IN-ADDR.ARPA" (IN)
loaded (serial 10273)
Oct 28 15:33:44 gwydion named[1277]: master zone "0.168.192.in.addr.arpa" (IN)
loaded (serial 10275)
Oct 28 15:33:44 gwydion named[1277]: master zone "orbdesigns.com" (IN) loaded
(serial 1)
Oct 28 15:33:44 gwydion named[1277]: listening on [127.0.0.1].53 (lo)
Oct 28 15:33:44 gwydion named[1277]: listening on [192.168.0.5].53 (eth0)
Oct 28 15:33:44 gwydion named[1277]: Forwarding source address is [0.0.0.0].53
Oct 28 15:33:45 gwydion named[1278]: group = 19
Oct 28 15:33:45 gwydion named[1278]: user = bind
Oct 28 15:33:45 gwydion named[1278]: Ready to answer queries.
We've added a little formatting to the multi-line entries to make the messages log output more readable. Depending on the number of zones in your configuration, you may need to look at more than the last 11 lines of the messages file. First the named daemon starts up. Then the various zone files are loaded, one per line. The next two lines enumerate the interface/port combinations where named listens for requests. The request forwarding IP is given (set to zeros because we didn't define a forward). Finally, the group and user are logged, then named logs that it is up and ready.
Let's test our DNS server using nslookup (a utility to query Internet name servers interactively). First check the localhost forward and reverse lookups.
[root@gwydion named]# nslookup Default Server: localhost Address: 127.0.0.1 > localhost Server: localhost Address: 127.0.0.1 Name: localhost.orbdesigns.com Address: 127.0.0.1 > 127.0.0.1 Server: localhost Address: 127.0.0.1 Name: localhost Address: 127.0.0.1
If either query fails, there is a configuration error, likely in /var/named/localhost.rev. Now test a few of the other hosts on the local network.
> grendel
Server: localhost
Address: 127.0.0.1
Name: grendel.orbdesigns.com
Address: 192.168.0.1
> grinch
Server: localhost
Address: 127.0.0.1
Name: grinch.orbdesigns.com
Address: 192.168.0.7
These resolve correctly. Now to see how the DNS server handles external requests, we'll check a pair of frequently visited sites:
> syroidmanor.com
Server: localhost
Address: 127.0.0.1
Name: syroidmanor.com
Address: 142.165.206.61
> caldera.com
Server: localhost
Address: 127.0.0.1
Name: caldera.com
Address: 216.250.128.241
> syroidmanor.com
Server: localhost
Address: 127.0.0.1
Non-authoritative answer:
Name: syroidmanor.com
Address: 142.165.206.61
> exit
First we query for syroidmanor.com, then caldera.com. Finally, we re-query for syroidmanor.com. This repeated request returns a different message, "Non-authoritative answer:" followed by the name and IP address. This is because the response from the first query is cached locally and is not coming from an authoritative source (namely, the actual name server for syroidmanor.com, which is located by starting a query with the root servers). Type exit at the prompt to leave nslookup.
Now that everything is tested and running as designed, use COAS to enable the DNS server to start up at boot time. From the KDE taskbar menu, choose K --> Settings --> COAS --> System --> Daemons. In the System Services dialog box, check the box next to "Internet domain name server (named)," then select OK to accept the change and close the dialog box.
We ran into two distinct problems working with named. First, it's important to remember to restart the daemon after making changes to /etc/named.conf or any of the zone files. This can be accomplished by typing /etc/rc.d/init.d/named restart at the command prompt. Forgetting to do this is guaranteed to lead to long sessions of hair tearing.
The second "gotcha" we ran into is that a firewall configuration can get in the way of named operating correctly. In our case, we were configuring the host Gwydion, which is behind the firewall (running on the machine named Grendel). If the firewall contains rules restricting which name servers can be queried, then the root server requests can fail. We added the following IP Chains rules to the firewall for our testing (your needs might be different, depending on how your system is configured):
ipchains -A output -i $EXTERNAL_INTERFACE -p udp \
-s $IPADDR $UNPRIVPORTS -d $ANYWHERE 53 -j ACCEPT
ipchains -A input -i $EXTERNAL_INTERFACE -p udp \
-s $ANYWHERE 53 -d $IPADDR $UNPRIVPORTS -j ACCEPT
ipchains -A output -i $EXTERNAL_INTERFACE -p tcp \
-s $IPADDR $UNPRIVPORTS -d $ANYWHERE 53 -j ACCEPT
ipchains -A input -i $EXTERNAL_INTERFACE -p tcp ! -y \
-s $ANYWHERE 53 -d $IPADDR $UNPRIVPORTS -j ACCEPT
More DNS Resources
OpenLinux resources include a section on the Domain Name System in the Network Administrator's Guide, from the System Documentation menu (select the "Open Book" icon on the KDE taskbar). Manual pages that are helpful include named, named.conf, resolver(3), and resolver(5).
Online sources that we find to be most helpful include the ever-present Linux Documentation Project, with the DNS-HOWTO at http://www.linuxdoc.org/HOWTO/DNS-HOWTO.html. Also, we referenced Aaron Hughs' Bind.com site, explicitly http://www.bind.com/bind.html and the DNS Resources Directory at http://www.dns.net/dnsrd/.
If you intend to do any work at all with DNS, then you owe it to yourself to get a copy of DNS and BIND, Fourth Edition, by Paul Albitz & Cricket Liu (O'Reilly and Associates). There is no better DNS reference, period.
While the Web has taken the world by storm, creating an entirely new layer to the global economy in just a few short years, it can be argued that e-mail has had an even greater impact in the way we communicate on a daily basis. It's relatively immediate, without being too direct (as a phone call from someone every half hour would be). E-mail has become a mainstay of the business world; it's also used to keep in touch with friends and family, to document, and to facilitate any variety of tasks. But how does e-mail work?
There are three "agents" or mechanisms used to transport e-mail messages between computers: Mail User Agents (MUA) such as Outlook, Netscape Messenger, and Pine are at the client end of the spectrum; Mail Delivery Agents (MDA) like procmail, provide mail distribution to user accounts on a host machine; and Mail Transport Agents (MTA) like Sendmail, Exim, or Postfix, are the servers that transfer mail between mail servers across an organization or the Internet, making use of the facilities provided by DNS servers.
In addition, there are mail services that implement different mail retrieval protocols, such as POP3 (Post Office Protocol, version 3) and IMAP (Internet Message Access Protocol). These are the services that many MUAs connect with to retrieve or read e-mail from a specific account.
While most MTAs are superficially very similar, Sendmail was the first, and is nearly ubiquitous. There are estimates that 80 percent of the world's e-mail is moved about by Sendmail. This popularity is offset by a well-deserved reputation for complex configurations.
The main qualifications you'll need before running an MTA is a registered domain name, a static IP address, and some form of DNS service (either local or through an Internet provider). If your access to the Internet is accompanied by an account that provides a reliable e-mail service or your connection is dynamic rather than continuous (that is, dial-up versus cable modem or DSL), then running your own mail server can be more trouble than the convenience provided.
For further indoctrination into the mysteries of Sendmail, we direct your attention to Chapter 26. Now let's take a gander at FTP services.
There are a variety of FTP servers in the world. All of them provide a certain minimum level of compatibility and functionality. Beyond that, there are functional differences in the feature sets, configuration, innate security, and licensing that set them apart. Many Linux distributions, including OpenLinux, incorporate the FTP server from Washington University, wu-ftp.
In Chapter 21, we shut down FTP, along with nearly every other external service that runs by default on OpenLinux eDesktop. Now, for testing purposes, we'll re-enable the default configuration and test it, then discuss which files need to be edited to provide a secure configuration that meets your requirements.
Warning
A security note: In June and July 2000, vulnerabilities were discovered in wu-ftp, the FTP server package that is included with many Linux distributions, including OpenLinux. The updated RPM available at ftp.caldera.com:/pub/eDesktop/updates/current/RPMS (wu-ftpd-2.5.0-7.i386.rpm) has patches applied that address this exploit.
First, uncomment the relevant line (shown here) in /etc/inetd.conf:
[root@gwydion bilbrey]# vi /etc/inetd.conf
* * *
ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd -l -a
* * *
[root@gwydion bilbrey]# /etc/rc.d/init.d/inet stop
Stopping INET services: inetd.
[root@gwydion bilbrey]# /etc/rc.d/init.d/inet start
Starting INET services: inetd.
Next, use the correct system script found in /etc/rc.d/init.d to stop and restart the inetd server to load the modified configuration file. Now we can test anonymous access from another machine:
[syroid@mordred syroid]$ ftp -i gwydion
Connected to gwydion.orbdesigns.com.
220 gwydion.orbdesigns.com FTP server (Version wu-2.6.1(2) Sun Oct 29 16:37:43 PST 2000) ready.
Name (gwydion:syroid): anonymous
331 Guest login ok, send your complete e-mail address as password.
Password: [email protected]
230 Guest login ok, access restrictions apply.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls
200 PORT command successful.
150 Opening ASCII mode data connection for /bin/ls.
total 4
d--x--x--x 2 root root 1024 Oct 16 16:15 bin
d--x--x--x 2 root root 1024 Oct 16 16:15 etc
drwxr-xr-x 2 root root 1024 Feb 17 2000 lib
dr-xr-sr-x 2 root ftp 1024 Feb 17 2000 pub
226 Transfer complete.
ftp>
Note that anonymous FTP results in access to what's referred to as a chrooted jail (representing a changed root directory, restricting system access) - the top level for anonymous access is actually the /home/ftp directory. Polite anonymous access requests that the user enter a valid e-mail address for the password.
Now that we know that FTP is working, let's have a look at the configuration files that secure, affect, and record its operations. These are as follows:
tcpd), which permits access restrictions using the next two files.tcpd functions by intercepting a connection attempt for a monitored service. When tcpd receives a call for FTP service, it first looks in hosts.allow to see if the specific service/host combination is explicitly allowed. If it isn't, then the daemon checks hosts.deny to see if the connection is explicitly disallowed. If neither, then the default behavior is to allow the connection. Therefore, configure hosts.deny to reject all connections, and then setup hosts.allow to permit specified uses.
[root@gwydion /etc]# cat hosts.deny
#
# hosts.deny This file describes the names of the hosts which are
# *not* allowed to use the local INET services, as decided
# by the '/usr/sbin/tcpd' server.
#
# The portmap line is redundant, but it is left to remind you that
# the new secure portmap uses hosts.deny and hosts.allow. In particular
# you should know that NFS uses portmap!
# swat:ALL EXCEPT 127.0.0.1
# *** previous line commented out bpb 08/17/2000
# Desired default configuration - Deny everything to all hosts.
ALL:ALL
[root@gwydion /etc]# cat hosts.allow
#
# hosts.allow This file describes the names of the hosts which are
# allowed to use the local INET services, as decided
# by the '/usr/sbin/tcpd' server.
#
# Added 8/17/2000 bpb
swat : 127.0.0.1
# FTP access for local net only bpb 20001027
ftpd : 192.168.0.0/24
Hint
Used properly, hosts.allow and hosts.deny create a relatively secure environment to provide access to selected services. For more information, typeman hosts.allowfrom the command line. There is a certain amount of startup time overhead associated with using TCP Wrappers - it is for this reason that services with frequent transient connections (like Sendmail and Apache) are usually not run out of theinetdserver, nor secured with TCP Wrappers.
Then next listing is of /etc/ftpusers. As we noted above, this file records user accounts that are not permitted to login via FTP. Add additional users to the list to prevent them from logging in.
[root@gwydion /etc]# cat ftpusers
root
bin
daemon
adm
lp
sync
shutdown
halt
mail
news
uucp
operator
games
nobody
The main configuration file for wu-ftp is /etc/ftpaccess. We've added comments to the following listing to explain each option in this modified file from the eDesktop installation. The much larger set of available options is found in the ftpaccess manual page.
# /etc/ftpaccess modified for Caldera eDesktop
# bpb 20001027
# The class option can be used to restrict access, for instance
# class actual real *.orbdesigns.com
class all real,guest,anonymous *
# email address of ftp archive administrator
email [email protected]
# after N failures, FTP connection is terminated, and logged to syslog
loginfails 5
# define the readme files used at login and when
# changing directories, shown if present
readme README* login
readme README* cwd=*
# define the message files used at login and when
# changing directories, shown if present
message /welcome.msg login
message .message cwd=*
# define which capabilities are available for specified
# session types, conversions setup /etc/ftpconversions
compress yes all
tar yes all
chmod no guest,anonymous
delete no guest,anonymous
overwrite no guest,anonymous
rename no guest,anonymous
# setup logging for specified transactions by session type
log transfers anonymous,real inbound,outbound
# tells FTP server to keep alert for a pending system shutdown
shutdown /etc/shutmsg
# strictly check the type/style of password for anonymous users,
# then warn and let them login anyway, may also be none or trivial
passwd-check rfc822 warn
The final configuration file of note is /etc/ftpconversions, listed here. It relates file types (determined by extension) to the corresponding program used to act on the file.
:.Z: : :/bin/compress -d -c %s:T_REG|T_ASCII:O_UNCOMPRESS:UNCOMPRESS
: : :.Z:/bin/compress -c %s:T_REG:O_COMPRESS:COMPRESS
:.gz: : :/bin/gzip -cd %s:T_REG|T_ASCII:O_UNCOMPRESS:GUNZIP
: : :.gz:/bin/gzip -9 -c %s:T_REG:O_COMPRESS:GZIP
: : :.tar:/bin/tar -c -f - %s:T_REG|T_DIR:O_TAR:TAR
: : :.tar.Z:/bin/tar -c -Z -f - %s:T_REG|T_DIR:O_COMPRESS|O_TAR:TAR+COMPRESS
: : :.tar.gz:/bin/tar -c -z -f - %s:T_REG|T_DIR:O_COMPRESS|O_TAR:TAR+GZIP
: : :.crc:/bin/cksum %s:T_REG::CKSUM
: : :.md5:/bin/md5sum %s:T_REG::MD5SUM
This enables a user to request a file in a different format than the original, and have FTP dynamically convert it before passing it to the client. For example, if the requested file is called toms_shopping_list, and the remote user requests toms_shopping_list.tar.gz, then the FTP server first archives, then gzips the file immediately prior to transmission. This approach affords significant bandwidth advantages, at the cost of server CPU cycles.
Several server information utilities are included with wu-ftp. They include the following:
FTP servers are like air - they're everywhere. It's a simple and convenient way to provide remote access to files that you want to make available to either specific users or the general public. FTP servers have distinct drawbacks, though.
It seems like there's a new exploit against an FTP version every week. Each type of service also has its disadvantages. The maintainers of wu-ftp do not recommend anonymous access. Real account connections are dangerous because the user passwords are passed across the network as clear text, which creates a risk independent of your trust in the users and their full system access. Finally, guest accounts have a lower risk than either of the other types, but exact a maintenance cost from the administrator. Correctly configured and rigorously maintained, FTP can be relatively safe only on systems that aren't on an internal network and don't have resources (hosts or password files) that you wouldn't want compromised.
In the place of FTP, you can use a Web server (for example, Apache) for file distribution just as easily. We prefer installing either SSH or OpenSSH (see Chapter 22), either of which provides secure (encrypted) file transfer between machines. There's no provision for anonymous access, but then we don't allow untrustworthy individuals in the first place.
FTP resources
More FTP Resources
In OpenLinux, there are manual pages for ftpd (yes, the manpage name is different than the executable), ftpaccess, ftpconversions, ftpcount, ftpwho, ftpshut, and ftprestart. Additionally there is advice for securing an FTP installation in the Linux Administrator's Security Guide, found in the System Documentation menu.
The home of wu-ftp on the Internet is found at http://www.wu-ftpd.org/. An excellent third-party site is the WU-FTPD Resource Center, at http://www.landfield.com/wu-ftpd/.
The World Wide Web has almost overnight introduced a paradigm shift in the way people think about the flow of information in their lives. The Internet, or "Web," in and of itself is nothing more than millions of computers connected together to form a global network. And while this global network is a technological marvel in its own right, what has really brought the Web to the forefront of everyone's attention is the http protocol.
Loosely defined, a protocol is an agreed upon bi- or multi-lateral form of behavior. The http protocol allows a client (typically using a browser) connected to a network, to communicate with a server (running a program that responds to http requests for http) connected to the same network, and share information. That information can consist of "Web pages" (written in HTML, SHTML, XML, etc.), files, multimedia, graphics, or dynamic content generated by one of a dozen scripting languages.
One of the fastest rising stars in the Web server arena is Apache - and for good reason. The product is stable, flexible, extensible, and runs on a diverse range of platforms. Apache is also Open Source, which means it's available online (yes, the same "online" Apache played such a significant role in creating) for the cost of a download.
Chapter 26 contains all the details you'll need to install, configure, and maintain a basic Apache installation.
The USENET is a collection of computers connected by a variety of networks (one of which is the Internet) that collectively exchange uniquely identified articles posted to a diverse range of different newsgroups. Newsgroups are organized by interest or topic, and are identified by a top-level category (comp for computers, alt for alternate interest groups, rec for recreational and hobby groups, and so on) and further subdivided into specific focus groups through a hierarchical naming system. For example, the newsgroup comp.os.unix.aix would target people who shared an interest in the AIX operating system. Newsgroups (which can be private or public) are hosted on a news server. The news server is responsible for updating and managing posts made to locally hosted newsgroups, and (optionally) synchronizing a local cache of newsgroups available from one or more remote news servers (called a "newsfeed"). USENET is barely controlled anarchy, wildly diverse, marvelously informative, and on occasion, terribly offensive.
The following quote was culled from a very useful newsgroup site (http://www.cs.indiana.edu/docproject/zen/zen-1.0_6.html):
"Some people wish that Usenet were a democracy. Many people pretend that it is. Both groups are sadly deluded."
You can join this phenomenon by using a news client to one of an estimated 30,000+ public newsgroups, or, if you really want to immerse yourself in the process, by running your own news server. OpenLinux distributions come bundled with the "standard" among news server programs - InterNetNews (INN); it is present on your system only if you selected the All Packages installation. This program is the gatekeeper for incoming and outgoing newsfeeds, monitoring the default TCP port (119) for connection requests, and in the case of private newsgroups, authenticating users.
Warning
Before you consider hosting a news server, check with your ISP. While some providers will tolerate customers running a mail or FTP server (providing they stay within imposed bandwidth limitations), most will immediately terminate service if they find a news server running on the end of your connection.
The downside is that INN is a real bear to learn, understand, and configure. We understand that once things are running, INN is relatively easy to maintain, other than the ever-increasing disk space and CPU cycles that an active news server demands. Since most small companies and every home user we know has access to a full-on news server as a part of their provider's access package, we'll pass on looking at the complexities of INN's configuration.
For those of you interested in learning more about INN, here are several readily available resources. First, have a look at the user documentation that comes with the product. It can be found on your hard drive under /usr/doc/inn-2.2.2/, if the package is already installed. The Internet Software Consortium currently maintains INN; the ICS page for the suite is found at http://www.isc.org/products/INN/. Finally, there's the Usenet RKT (Rapid Knowledge Transfer) site for running news servers, with loads of help for both neophytes and professional administrators, at http://www.mibsoftware.com/userkt/forprov.htm. Finally, if you prefer a paper-bound reference, we recommend Spencer & Lawrence's Managing Usenet (O'Reilly & Associates).
So what alternate news servers are available and a bit easier to use? Off we go to Freshmeat (http://www.freshmeat.net/), the canonical source for Linux applications. In the menu at the upper right, select the link appindex. Then choose Daemons, followed by NNTP (Network News Transport Protocol). The resulting page is a list of the current crop of news server software. Among the current 13 items listed (following INN) we find Leafnode. This simple-to-use suite of programs has a good reputation, so we'll work with it.
Note
If you want to create and serve your own personal news groups, then Leafnode is not the answer (at least yet). Aside from working with INN, we know that people have had reasonable success working with DNews, which is commercial software. Also there's a package called SN (Small News) that apparently serves the purpose, but for a local host only. That's fine, if all your remote users actually login to read their newsgroups.
With an online presence at http://www.leafnode.org/, Leafnode is a small, capable package for low traffic, low use sites, and ideal for the SOHO (Small Office Home Office) and small business setting. The description from the home page is at least as succinct as we are:
"Leafnode is a USENET software package designed for small sites running any flavour of Unix, with a few tens of readers and only a slow link to the net. It was originally written by Arnt Gulbrandsen and is currently being maintained by Cornelius Krasel..."
From the Leafnode site, download the source package (6/2001: currently at version 1.9.19), unpack it in the /usr/local/src directory, then read the README and INSTALL files. What follows are a few annotated excerpts from the INSTALL file, which provides ample guidance from how to compile the program through connecting to a remote newsreader.
Compilation is standard - it follows the well-trodden path of ./configure, make and make install. Once the install is complete, edit the configuration file. We found that we needed to copy the sample /etc/leafnode/config.example to /etc/leafnode/config, then edit the new file:
## This is the NNTP server leafnode fetches its news from.
## You need read and post access to it. Mandatory.
server = news.at_your.isp
## Unread discussion threads will be deleted after this many days if
## you don't define special expire times. Mandatory.
expire = 20
##
## All the following parameters are optional
##
## I have free access to my news server. If you don't have, comment out
## the following two lines and change them accordingly.
# username = username
# password = secret_password
* * *
The top portion of /etc/leafnode/config, shown previously, contains all the critical entries that need editing. You must set the name of your upstream news server (usually provided by your ISP). If you don't have a news server available from your provider, there's a list of free news servers at http://www.newsservers.net/. If your news connection requires authentication, then you'll need to edit the username and password sections here. Note that this stores your password in a clear text file. In the /etc/leafnode directory, run the following commands to add a bit of security against wandering eyes:
[root@gwydion leafnode]# chown news.news *
[root@gwydion leafnode]# chmod 640 *
[root@gwydion leafnode]# ls -al
total 10
-rw-r----- 1 news news 4462 Oct 30 21:00 config
-rw-r----- 1 news news 4471 Oct 30 20:52 config.example
* * *
This sets the ownership (user and group) of the configuration files to news, and sets the files to read/write for owner, read for group, and no permission for other users, as shown in the file listing. Not a perfect solution, but far better than the previously world-readable file.
Next, edit /etc/inetd.conf to create a startup line for leafnode. There is already an nntp line in the default file, so change it as follows:
nntp stream tcp nowait news /usr/sbin/tcpd /usr/local/sbin/leafnode
This line starts leafnode operating under the auspices of tcpd, the TCP Wrappers security program. The port number that's monitored is 119 by default, as configured in /etc/services. Note that the program runs as the account news, rather than root. That's a nice touch, since news doesn't have much authority on the system.
Before starting the daemon, secure your news server by making the appropriate entries in /etc/hosts.allow and /etc/hosts.deny. At the risk of being oppressively repetitive, our general procedure is to have a single line in hosts.deny, ALL:ALL, which rejects all connections that are not explicitly allowed. Then add the following lines (or something similar, set up for your environment) to hosts.allow:
# Leafnode access for local net only bpb 20001030
leafnode : 192.168.0. localhost
The 192.168.0. (observe the trailing dot) matches any address on our test network. It matches NO outside address. The localhost permission is a good idea; otherwise you wouldn't be able to read from your own news server locally.
Once that's done, restart the inetd server by typing killall -HUP inetd. Once that's done, run fetchnews to retrieve the list of active newsgroups from your upstream server:
[root@gwydion leafnode]# /usr/local/sbin/fetchnews
Leafnode is a fairly well behaved "houseguest" under Linux. It only downloads feeds for newsgroups that you or your users are subscribed to and actively reading. That translates into fairly low disk space usage, unless you and/or your users are news junkies. If a newsgroup that was previously active lies inactive for a week, it is removed from the list of groups that are retrieved.
As noted previously, fetchnews is the program that handles the upstream news server end of the trade. In addition to retrieval, it also sends posted messages out. If you have a persistent Internet connection, then run fetchnews as a cron job, as shown here. The second line in the cron file for the news user runs fetchmail every 15 minutes:
[root@gwydion leafnode]# crontab -u news -e
0 4 * * * /usr/local/sbin/texpire
0,15,30,45 * * * * /usr/local/sbin/fetchnews
If your connection is via a dialup line, then instead run the command from within the /etc/ppp/ip-up script. Articles are expired from the news groups using the texpire utility. This should be run from cron (also shown in the crontab listing above); daily at 4 am is a good time. Now everything is up and running. Let's test it by checking in using Netscape Messenger from another machine on the network, as shown in Figure 24-1.
Figure 24-1
Netscape Messenger connected to a Leafnode news server, both in OpenLinux.
OK, so we cheated just a bit - what's shown in the illustration is the end result. What a user actually does is select newsgroups for reading. Each one is then loaded, with a single marker message placed in the group by Leafnode. Then wait for fetchmail to run next (or run it manually). Finally, reconnect to the server with the news reader client and up pops the news!
When installed, Leafnode adds several manual pages to the OpenLinux set: leafnode, fetchnews, texpire, and pcre. That last is a reference file for a set of functions that we haven't talked about called Perl-Compatible Regular Expressions. These are used by Leafnode to provide a rudimentary filtering capability. See the entry "filterfile" in the leafnode manpage for more details.
In this chapter, we covered some of the common services that are typically available on public servers. This doesn't prevent them from being used and useful for intranet applications as well - which is precisely how they've been presented in this chapter. When providing services on Internet accessible servers, you have a responsibility to protect your machine. Not only for your sake, or for your users or your company either: Badly secured Linux (and other *nix variants) have been implicated in the DDoS (Distributed Denial of Service) attacks that appeared in the last year of the millennium. OK, enough lectures for the time being. In this chapter, we covered the following points:
httpd is the daemon that provides Web server capabilities for OpenLinux. The Web server software bundled with OpenLinux, Apache, is perhaps the single best-known Open Source software success story on the planet. Everything you need to know about getting a Web server up and running (configuration, compiling from source, testing, and maintenance) can be found in Chapter 26.Go to the Table Of Contents