|
|
| Previous | Table of Contents | Next |
For mail to be successfully and correctly routed through the firewall, MX records need to be published in the zone’s DNS files to identify where SMTP mail is to be sent. This is done by adding MX, or mail exchanger, records to the DNS providers for the network domain, or zone. The zone information shown here provides some information regarding how this is configured.
Server: nic.fonorola.net
Address: 198.53.64.7
unilabs.org nameserver = nic.fonorola.net
unilabs.org nameserver = fonsrv00.fonorola.com
unilabs.org preference = 10, mail exchanger = mail.fonorola.net
unilabs.org preference = 1, mail exchanger = pc2.unilabs.org
unilabs.org preference = 5, mail exchanger = nis.fonorola.net
unilabs.org
origin = nic.fonorola.net
mail addr = chrish.fonorola.net
serial = 95102902
refresh = 10800 (3 hours)
retry = 1800 (30 mins)
expire = 3600000 (41 days 16 hours)
minimum ttl = 86400 (1 day)
unilabs.org nameserver = nic.fonorola.net
unilabs.org nameserver = fonsrv00.fonorola.com
nic.fonorola.net internet address = 198.53.64.7
fonsrv00.fonorola.com internet address = 149.99.1.3
mail.fonorola.net internet address = 198.53.64.8
pc2.unilabs.org internet address = 198.53.166.62
nis.fonorola.net internet address = 198.53.64.14
>
This output is from the nslookup command. Despite how this looks, you are in fact looking for the lines that contain the description mail exchanger, which are
unilabs.org preference = 1, mail exchanger = pc2.unilabs.org unilabs.org preference = 5, mail exchanger = nis.fonorola.net unilabs.org preference = 10, mail exchanger = mail.fonorola.net
When mail for the domain unilabs.org is to be sent from a host, that host will first try to locate the unilabs.org domain itself. The rule determining which host will be contacted first is simple: the host that has the lowest preference value is the first to be contacted. In the sample setup you’ve watched develop throughout this chapter, the host pc2.unilabs.org, which is the firewall, will be contacted first to see if it can in fact accept the e-mail. A recommended setup is to give the firewall the lowest priority on the system, so that no other machines can be directly contacted by the outside world.
If the machine with the lowest preference value is not available, then the next system is contacted—in this case, nis.fonorola.net. If the mail is delivered to nis.fonorola.net, then the sendmail daemon on nis will now take responsibility for attempting to deliver it to the lowest preference value machine, pc2.unilabs.org. The same is true should the second mail system not be available and the mail server must then contact the third system. The behavior described here may not be what happens in all situations. For example, the system nis.fonorola.net could simply decide to attempt delivery itself and not use the next MX record. The operation of sendmail is controlled by the sendmail.cf file on the remote machine. Remember that when you make changes to your DNS, you must restart or reload the DNS so that the new information is integrated into the DNS.
The HTTP proxy, http-gw, does more than simply provide a mechanism for HTTP requests to be sent through the firewall. It also provides support for Gopher clients, so that Gopher, Gopher+, and FTP requests can originate from a Gopher client, and for HTPP, Gopher, Gopher+, and FTP requests to be passed through from a WWW client.
The HTTP proxy also supports “proxy aware” clients, and supports clients that are not designed to work with these daemons. Before examining how to enable these services, first examine the steps required to place the proxy into operation, and also look at the configuration rules for this proxy.
By default, an HTTP or Gopher server usually runs on TCP/IP ports 80 and 70, respectively. These will not be running on the firewall, so it is necessary to configure inetd to accept connections on these ports and start the proxy agent. This is done by adding the following line to the /etc/services file:
gopher 70/tcp httpd 80/tcp
With these lines added, inetd now knows on what ports to listen. inetd must then have the appropriate lines added to its configuration file, inetd.conf:
httpd stream tcp nowait root /usr/local/etc/http-gw http-gw gopher stream tcp nowait root /usr/local/etc/http-gw http-gw
With the inetd configuration file now updated, inetd must be restarted, or instructed to read its configuration file using the kill -1 command. When these steps are completed, the http-gw proxy is ready to configure.
http-gw reads its configuration rules and permissions information from the firewall configuration table netperm-table, retrieving all rules specified for “http-gw.” The “ftp-gw” rules are also retrieved and are evaluated when looking for host rules after all the http-gw rules have been applied. Table 6.11 lists configuration rules applicable to this proxy.
| Option | Description |
|---|---|
| userid user | Allows the system administrator to specify a numeric userid or the name of a password file entry. If this value is specified, http-gw will set its userid before providing service. Note that this option is included mostly for completeness; http-gw performs no local operations that are likely to introduce a security hole. |
| directory pathname | Specifies a directory to which http-gw will chroot prior to providing service. |
| timeout secondsvalue | Used as a dead-watch timer when the proxy is reading data from the Net. Defaults to 60 minutes. |
| default-gopher server | Defines a Gopher server to which requests can be handed off. |
| default-httpd server | Defines an HTTP server to which requests can be handed off if they came from a WWW client using the HTTP protocol. |
| ftp-proxy server | This defines an ftp-gw that should be used to access FTP servers. If not specified, the proxy will do the FTP transaction with the FTP server. The ftp-gw rules will be used if there are no relevant http-gw rules, so this is not a major problem. |
| Previous | Table of Contents | Next |