NETPERM-TABLE(5)

NAME
netperm-table - configuration file for Firewall Toolkit proxies and utilities

DESCRIPTION
The network permissions table (netperm-table) contains configuration information for the Firewall Toolkit. The proxies and other applications read their configuration information from this table. The rules in the table include two types of information: generic proxy rules and application-specific rules.

The permissions/configuration file is organized into rules, one rule per `logical' line of text (`logical' line is single line of text with possible continualtion lines, which are specified by escaping trailing LF with `\'. The first part of each rule is the name of the application that rule applies to, followed by a colon. Multiple applications can be targeted by a single rule, by separating the names with commas, or wildcarding them with an asterisk. When an application extracts its configuration information, it only extracts the rules that apply to it, preserving the order in which they appeared in the file. For example, if the application smtpd read its configuration rules, the following would all match:

# sample rules for smtpd
smtpd, smtpfwdd:  userid 4
smtpd, smtpfwdd:  directory /mail/inspool
smtpd:         timeout \
 3600

Comments can be inserted in the configuration file by starting the line with '#' as the first character.

Once an application has matched a rule, the rule is tokenized into whitespace-delimited strings for later application specific use. Typically, the application retrieves matching rules based on the first word in the rule; the remaining words serve as parameters to that clause. Special modifiers are recognized for each clause, if it begins with a permit- or deny- the rule is internally flagged as granting or revoking permission for that clause. I.e., if an application retrieves all of its configuration clauses for "hosts", the following will be returned:

netacl-in.ftpd: permit-hosts 192.33.112.117 -exec /usr/etc/in.ftpd
netacl-in.ftpd: permit-hosts 198.137.240.101 -exec /usr/etc/in.ftpd
netacl-in.ftpd: deny-hosts unknown
netacl-in.ftpd: deny-hosts *

Some application may read more than one application name tag, applying specific policies when needed. A common example is squid-gw, which allows policies to be defined depending on multiple conditions:

squid-gw:	permit-hosts 10.0.0.* -class int
squid-gw-int:   block -force javascript

NETPERM-TABLE SYNTAX

  Precedence
Applications and proxies read the tables from the top of the table to the bottom. They use the first rule that applies for a particular attribute. If there are multiple rules in the table that could apply for an attribute, the application uses the first one it finds. For example, a netperm-table contains the following rule:

    smtpd:  userid  uucp

and later in the file contains the rule:

    smtpd: 	userid 	mail

When smtpd parses the netperm-table, it will use the first rule it finds, and run as the user uucp.

  Format
Each line in the netperm-table contains a separate configuration rule in the format:

keyword: attribute valuelist

where:

    keyword
        indicates the application to which the rule on that line applies. The wildcard (*) indicates the rule is valid for all applications and proxies. Comma separated lists of multiple keywords indicates the rules apply to the proxies or applications listed. The keyword usually matches the name of the service in the /etc/rc.local file.

    attribute
        is a configuration parameter for that application or proxy.

    valuelist
        is the value for the specific configuration parameter. Some attributes allow multiple values.

A rule must fit on a single line. The length of a line varies by operating system, but is generally around 1,024 bytes. There is no provision for continuing lines.

Whitespace and tabs are both valid separators.

  Macros
Much like cpp(1) or m4(1), macros can be defined that will later be expanded in context. Macro names must start with a letter, and may contain letters, digits and underscores. Macros are not expanded inside quotes. Macro processing is designed to be compatible with global object definitions which may be used in system-wide configuration, say, controlling OpenBSD's pf and other. Plese note that macro expands exactly as it was defined, thus, if there is a configuration line where a group of parameters must be embraced with brackets, you should place it around the macro call.

MYNETWORK = 192.168.1.0/255.255.255.0
ftp-gw:	TRUSTEDSERVERS="10.1.1.2 10.1.1.5"
ftp-gw:	permit-hosts $MYNETWORK -dest { $TRUSTEDSERVERS }

As seen on the example above, macro definitions may exist in global namespace or may be keyword-bound.

  Includes
"include" statement followed by filename requests other netperm-table file to be included into rules processing. Example:

include /usr/local/etc/netperm-squid-gw.txt

Failure when reading an included file is treated as fatal error.

  Comments
A hash mark (#) at the beginning of a line indicates a comment. Applications ignore any text between the # and the end of the line.

CONVENTIONS

Much of the usage of the netperm-table is application specific, but where possible, several conventions are enforced. When a host name or host IP address is given to match against, matching is performed based on whether the pattern to match against is all digits and decimal points, or whether it contains other characters. If the pattern to match against is entirely digits and decimals, matching is performed against the IP address, otherwise it is performed against the hostname. Generally, to prevent being vulnerable to DNS spoofing, one should use configuration rules based on IP addresses. When matching, asterisk wildcards are supported, with syntax similar to the shell's, matching as many characters as possible. When resolving IP addresses to DNS names, if the reverse lookup fails, the host name is set to "unknown." When resolution is performed, a check is made to ensure that the IP address for the DNS name returned by the reverse lookup is the same. If it is not, the host name is set to "unknown" and a warning is logged. This permits rules to specifically operate on hosts that didn't have valid DNS mappings. Thus:

192.33.*   will match against IP address
*.tis.com  will match against host name
unknown    will match against hosts not in the DNS

Note that sites using NIS or other resolver systems where the gethostbyaddr library routine returns a non-fully-qualified domain name will have problems generating a matching rule using their domain name. In this case, the numeric IP address should be used. In general, using IP addresses will provide better security, by removing the threat of DNS spoofing attacks. When IP-based address pattern is specified, it is possible to use generic netmask-based network definitions, like:

10.0.0.0/255.255.255.0	will match C class network 10.0.0

Other common configuration parameters (besides hostnames described above), being covered by specific proxy manuals, may include:

integers
    - as decimal values,

strings
    - tokenized in generic way, so if a string includes whitespace it should be embraced with quotation marks,

lists
    - any application with parameter that uses "values list" should employ { item [item..] } format, using space as separator. Individual values may be negated (excluded from list) with "!" prefix.

user and group ids
    - as numeric values or system-provided names,

tcp/ip ports
    - as numeric values or service names,

DSCPs
    - (diffserv codepoints) - ToS/QoS byte in decimal, octal (0 prefix) or hexadecimal (0x prefix) format, or symbolic reference to diffserv-codepoint line, like:

    ftp-gw: permit-hosts 192.168.1.* -serverdata-dscp throughput
    ftp-gw: diffserv-codepoint throughput 0x08

content-types
    - in type/subtype format, wildcards may apply,

content inspection servers
    - at the moment only Milter protocol is supported, and milter specification looks like unix:/path-to-unix-socket or inet:port@host.

DIAGNOSTICS

Syslog error messages are generated by malformed lines, including lines that are missing the application name or colon, lines that are missing any clause following the colon, lines that have too many tokens, or a memory allocation error.

FILES
/usr/local/etc/netperm-table

CAVEATS

The location of netperm-table is compiled into the components of the firewall toolkit. Its location may change, depending on compile time options.

Applications in the toolkit that attempt to open netperm-table and fail will exit with a warning in syslog.

FILES

/usr/local/etc/netperm-table
    The network permissions file contains configuration information for the Firewall Toolkit

BUGS
Report bugs to ark@eltex.net or fwtk-users@buoy.com. Include a complete example, explaining what you expected to happen and what actually happened. Be sure to indicate the type of system (operating system, hardware, etc.) you are using, as well as the version of the netperm-table.

SEE ALSO
authmgr(8), authsrv (8), ftp-gw(8), plug-gw(8), rlogin-gw(8), smtpd(8), smtpfwdd(8), tn-gw(8), x-gw(8), hostmatch(3), peername(3), ip2name(3), namatch(3), cfg_read(3), proxy_init(3), cfg_get(3)

HISTORY
netperm-table file format was introduced by TIS; macros and continuation lines are OpenFWTK extensions. Gauntlet netperm-table shares the same basic syntax, but the proxy control differs so it is not compatible.