|
|
| Previous | Table of Contents | Next |
When a connection is received and this rule is applied, the IP address of the remote machine will be used to match this rule. If the pattern to match consists entirely of digits and decimals, matching is performed against the IP address; otherwise, it is performed against the hostname.
If the rule specifies a host- or domain name, as in the following rule
netacl-in.ftpd: permit-hosts *.istar.net -exec /usr/etc/in.ftpd
then the remote system’s name is used to validate against the rule, not the IP address. To prevent any vulnerability from DNS spoofing, it is highly recommended that the configuration rules be bound to IP addresses. When matching, asterisk wildcards are supported with syntax similar to the shell’s, matching as many characters as possible.
When the application attempts to resolve an IP address to domain name and the reverse lookup fails, the hostname is set to “unknown.” Otherwise the real hostname of the remote system is returned. When the Domain Name resolution is performed by the firewall, a check is made to ensure that the IP address for the DNS name returned by the reverse lookup is the same.
This setup prevents DNS spoofing. If a hostname for this IP address cannot be located in the DNS system, the hostname is set to “unknown” and a warning is logged. This permits rules to operate on hosts that didn’t have valid DNS mappings. This means that it is possible to allow any host in the Internet to pass through your firewall, or access certain services (or both) as long as reverse DNS, or IN-ADDR.ARPA addressing is properly configured.
netacl is a network access control program; it provides a degree of access control for various TCP-based services available on the server. For example, you may want to have Telnet access to the firewall for authorized users. The netacl program and the appropriate rules enable you to create this setup. The same capabilities are possible for any of the available services, including ftp and rlogin.
The netacl program is started through inetd; after inetd performs some checks, netacl allows or denies the request for service from the remote user/system. When configuring the inetd.conf file for netacl, it is important to know that netacl accepts only one argument: the name of the service to be started. Any other arguments that are intended for the service do not go in the inetd.conf file. Consider this example:
ftp stream tcp nowait root /usr/local/etc/netacl ftpd
In this situation, when a connection request is accepted by inetd for an ftp service, the netacl program is started with an argument of ftpd. Before the ftpd daemon is started, the request is validated using the rules found in the netperm-table. The rule name for netacl consists of the keyword netacl-followed by the name of the service. For example, if the named service is ftpd, the rule name consists of netacl-ftpd, as in the following:
netacl-ftpd: permit-hosts 204.191.3.147 -exec /usr/libexec/ftpd -A -l
When you examine these two lines—the first from inetd.conf and the second from netperm-table—you can see that the command-line arguments and other information required for the daemon is found in netperm-table.
As with all the TIS Toolkit components, arguments and descriptive keywords are permitted in the authentication clause. As seen in the preceding command output, only the host 204.191.3.147 is permitted access on the firewall to run the ftpd command. It does, however, mean that FTP requests can be sent through the firewall. Table 6.2 lists various keywords that are understood by the netacl program.
| Service | Keyword | Description |
|---|---|---|
| netacl | permit-hosts IP Address or hostname | Specifies a permission rule to allow the named hosts. This is a list of IP addresses or hostnames. |
| deny-hosts IP Address or hostname | Specifies a permission rule to deny the named hosts. This is a list of IP addresses or hostnames. The denial of service is logged via syslogd. | |
| -exec executable [args] | Specifies a program to invoke to handle the service. This option must be the final option in the rule. An -exec option must be present in every rule. | |
| -user userid | userid is the numeric UID or the name from a login in /etc/passwd that the program should use when it is started. | |
| -chroot rootdir | Specifies a directory to which netacl should chroot(2) prior to invoking the service program. This requires that the service program be present, and the path name for the executable be relative to the new root. | |
Acceptance or rejection of the service is logged by the syslog facility. The messages printed in the syslog files resemble those shown here:
Oct 4 00:56:12 pc netacl[339]: deny host=stargazer.unilabs.org/204.191.3.147 service=ftpd Oct 4 01:00:20 pc netacl[354]: permit host=stargazer.unilabs.org/204.191.3.147 service=ftpd execute=/usr/libexec/ftpd
The first line in the log report indicates that the host stargazer.unilabs.org was denied access to the ftp service through the netacl program. The second line of output indicates that the ftp request was accepted and allowed. Notice that the logging information only specifies the service that was originated, and from where it originated. It does not show who the user connected to. The sample netacl rules that follow illustrate the use of some of the parameters and clauses for netacl.
netacl-in.telnetd: permit-hosts 198.53.64.*-exec /usr/etc/in.telnetd netacl-in.ftpd: permit-hosts unknown -exec /bin/cat /usr/local/etc/noftp.txt netacl-in.ftpd: permit-hosts 204.191.3.* -exec /usr/etc/in.ftpd netacl-in.ftpd: permit-hosts * -chroot /home/ftp -exec /bin/ftpd -f
In this example, netacl is configured to permit telnet only for hosts in a particular subnet. Netacl is configured to accept all FTP connections from systems that do not have a valid DNS name (“unknown”) and to invoke cat to display a file when a connection is made. This provides an easy and flexible means of politely informing someone that they are not permitted to use a service. Hosts in the specified subnet are connected to the real FTP server in /usr/etc/in.ftpd but all connections from other networks are connected to a version of the FTP server that is already chrooted to the FTP area, effectively making all FTP activity “captive.”
| Previous | Table of Contents | Next |