|
|
| Previous | Table of Contents | Next |
It is fairly common to restrict the proxy from connecting to the firewall for FTP services, but occasionally you may need to upgrade software or change text files and messages. For this reason, you may need to enable FTP access. This can be done using the services of netacl. With netacl, you can restrict what machines can connect to the firewall to specific machines within the local network. Consider the sample configuration entries in the following command:
netacl-ftpd: permit-hosts 204.191.3.* -exec /usr/libexec/ftpd -A -l
This entry for netacl allows systems on the 204.191.3 network to connect to the FTP server through netacl. The entry also locks out all other systems, as you can see when one of them tries to access the FTP server:
ftp> open 198.53.166.62 2021 Connected to 198.53.166.62. 421 Service not available, remote server has closed connection ftp>
From this message it appears that there is no server listening on port 2,021, when in fact there is. netacl does not allow the request because the IP address where the request originated does not match the rule established previously.
If you’re not sure whether you will ever need access for FTP services to the firewall, the safest thing to do is to not allow this type of access except when absolutely necessary. This means that netacl can be set up in the netperm-table file, but commented out, thereby making it unavailable. Furthermore, the proxy must be configured to prevent connections to the firewall on the FTP port.
Two components are used for the successful delivery of mail through the firewall: smap and smapd. The smap agent is a client that implements a minimal version of SMTP. The smap program accepts messages from the network and writes them to disk for future delivery by smapd. smap is designed to run under chroot as a non-privileged process; this setup overcomes potential security risks from privileged mailers that can be accessed over a network.
The smapd daemon periodically scans the mail spool area maintained by smap and delivers any messages that have been gathered and stored. Mail is delivered by sendmail, and the spool file is deleted. If the mail cannot be delivered normally, smapd can be configured to store spooled files to an area for later examination.
These two applications can share configuration information in the netperm-table file if desired. Some of the operations are different, so different steps need to be taken when configuring the two applications.
The smap client runs whenever a connection request is received on the smtp port of the firewall. This is done by adding an entry for smtp to the /etc/inetd.conf file:
smtp stream tcp nowait root /usr/local/etc/smap smap
After /etc/inetd.conf has been updated, the inetd process must be restarted so that smap accepts connections. This can be checked by connecting manually to the smtp port:
pc# telnet pc 25 Trying 206.116.65.3… Connected to pc.unilabs.org. Escape character is ‘^]’. 220 pc.unilabs.org SMTP/smap Ready. helo 250 Charmed, Im sure. help 214-Commands 214-HELO MAIL RCPT DATA RSET 214 NOOP QUIT HELP VRFY EXPN quit 221 Closing connection Connection closed by foreign host. pc#
As you can see, smap implements a minimal SMTP implementation and spools the mail into the specified spool area. In the spool directory, it may be required that an etc directory with system specific configuration files be installed. A recommended setup is to build smap so that it is completely standalone—it does not depend on other libraries and will run without fail.
The smap client reads its configuration from the netperm-table file by looking for the lines beginning with smap. If the line applies to both smap and smapd, the two programs can be listed on the same line by separating them with a comma:
smap, smapd: userid 6
The rules for smap are listed in table 6.9.
| Rule | Description |
|---|---|
| userid name | Specifies the userid under which smap should run. The name can be either a name from the password database or a numeric userid. This userid should be the same as that under which smapd runs, and should have write permission to the spool directory. |
| directory pathname | Specifies the spool directory where smap should store incoming messages. A chroot system call is used to irrevocably make the specified directory the root file system for the remainder of the process. |
| maxbytes value | Specifies the maximum size of messages to gather, in bytes. If no value is set, message sizes are limited by the amount of disk space in the spool area. |
| maxrecip value | Specifies the maximum number of recipients allowed for any message. This option is only for administrators who are worried about the more esoteric denial of service attacks. |
| timeout value | Specifies a timeout, after which smap should exit if it has not collected a message. If no timeout value is specified, smap will never time out a connection. |
As you can see in table 6.9, some items are common between the smap and smapd applications. These similarities will be discussed later. For now, develop a configuration section for the smap application.
The userid, directory, and timeout values are self-explanatory. However, unlike the directory clauses for the other applications, the smap client also uses the directory to save incoming messages. Consequently, these form the basis of your configuration:
smap: userid 6 smap: directory /var/spool/smap smap: timeout 3600
The maxbytes value specifies the size of the largest e-mail message. If the message is larger than the maxbytes value, the message size is truncated. If maxbytes is not included in the configuration information, then the maximum message size is the size of the available space in the spool area. The final clause specifies the maximum number of recipients that can be attached to the mail message. This is not a commonly-used option. The completed entry for the netperm-table file looks like the following:
smap: userid 6 smap: directory /var/spool/smap smap: timeout 3600 smap: maxbytes 10000 smap: maxrecip 20
| Previous | Table of Contents | Next |