Options

netacl accepts one parameter: the name of the service it is to provide. This service name is appended to the string “netacl-” to generate the name by which rules are read from the netperm-table configuration file. If invoked with no parameters, the service is assumed to be the program name, just in case an administrator needs to replace the executable of some daemon with a copy of netacl. For example, if netacl is invoked using the following command, it will retrieve all the configuration rules for netacl-in.telnetd:

netacl in.telnetd

The following configuration rules are recognized:

hosts [options]

The hosts rule specifies a host permission rule. Host permission rules are in the form:

netacl-in.telnet permit-hosts host1 host2 -options
netacl-in.telnet deny-hosts host1 host2 -options

Following the permit-hosts or deny-hosts clause is a list of host names or IP-addresses that can contain wildcards. Host names are searched in order until the first option (starting with a “-”) is encountered, at which point, if there is a match for that rule, it will be accepted. If the rule is a deny-hosts rule, the program will log the denial of the service and exit. If the rule is a permit-hosts rule, the options will be processed and executed in order. If no rule is explicitly permitting or denying a service, the service is denied. Options include:

•  -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 is used to invoke the program.

•  -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 pathname for the executable be relative to the new root.

Examples

In this example, the \ line wraps have been added to fit lines on the page. \-escapes are not permitted in netperm-table—they are here only as part of the example.

netacl-in.telnetd: permit-hosts 192.33.112.* -exec /usr/etc/in.telnetd
netacl-in.ftpd: permit-hosts unknown -exec /bin/cat  /usr/local/
etc/noftp.txt
netacl-in.ftpd: permit-hosts 192.33.112.* -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. ftpd is configured to accept all 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 he or she is not permitted to use a service. Hosts in the specified subnet are connected to the real FTP server in /usr/etc/in.ftpd. 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.”

Installation

To install netacl, place the executable in a system area, then modify /etc/inetd.conf as desired, replacing entries for the servers that will be controlled via netacl. For example, the FTP service might be configured as follows (syntax may differ slightly depending on O/S version):

ftp stream tcp nowait root /usr/local/etc/netacl in.ftpd

After inetd.conf has been modified, restart or reload inetd. Verify installation by attempting a connection and monitoring the system logs.

plug-gw—Generic TCP Plug-board Proxy

Synopsis

plug-gw portnumber/name (invoked from inetd)

Description

plug-gw provides pass-through TCP services with logging and access control for generic connection-oriented applications such as NNTP. When plug-gw is invoked from inetd, it reads its configuration and checks to see if the system that has just connected is permitted to use the proxy. If not, it shuts down and logs the connection. If the peer is permitted to use the proxy, plug-gw determines (based on its configuration) what host to connect to on the “other side.”

---

Note:  The service port plug-gw is servicing must be specified on the command line.

---

Options

plug-gw reads its configuration rules and permissions information from the firewall configuration table netperm-table, and retrieves all rules specified for “plug-gw.” The following configuration rules are recognized:

timeout seconds

The timeout rule specifies a timeout value to wait until an inactive connection is disconnected. If no timeout is specified, the default is to remain connected until one side or the other closes its connection.

port portid hostpattern [options]

The port option specifies a connection rule. When a connection is made, a match is searched for on the port-id and calling host. The port-id may be either a numeric value (such as 119) or a value from /etc/services (such as “nntp”). If the calling port matches, then the host-pattern is checked for a match, following the standard address matching rules employed by the firewall. If the rule matches, the connection will be made based on the remaining options in the rule, all of which begin with “-.” Sub-options include:

•  -plug-to host. Specifies the name or address of the host to connect to. This option is mandatory.

•  -privport. Indicates that a reserved port number should be used when connecting. Reserved port numbers must be specified for protocols such as rlogin, which rely on them for “security.”

•  -portportid. Specifies a different port. The default port is the same as the port used by the incoming connection.

Installation

To install plug-gw place the executable in a system area, then modify inetd.conf to install plug-gw for whatever services will be plug-boarded. Reinitialize inetd and test by connecting to the port.

plug-gw was designed to permit “tunneling” NNTP traffic through firewalls, but it can be used for a variety of purposes such as permitting remote access to a single service on a single host. Typically, when configured for NNTP traffic, the user’s software is configured so that internal NNTP connections to the outside news server connect to the firewall and are automatically plug-boarded to the external NNTP server, and vice versa. The USENET news software must then be configured so that both the internal and external NNTP servers believe they are exchanging news with the firewall machine.