screend(8)screend(8)NAMEscreend - Internet (IP) gateway screening daemon
SYNOPSIS
/usr/sbin/screend [-d] [-c] [-l] [-f configfile] [-L logfile] [-s] [-r]
OPTIONS
Prints large amounts of debugging information. This is not meant for
normal use. Checks the syntax of the configuration file but does not
actually process any packets. Turns on logging for all packets (nor‐
mally, packets are logged only if requested in the configuration file).
Specifies the configuration file. If not specified, the default,
/etc/screend.conf, is used. Specifies that logging records should be
appended to the given file. There is no default logging file. This may
be specified simultaneously with -s, in which case each logging record
is stored by both means. Specifies that logging records should be
logged using syslogd(8). Specifies that logging records should include
the rule number of the configuration file rule responsible for the
action logged. This is useful for debugging configuration file prob‐
lems. See the section in this reference page on RULE NUMBERS.
DESCRIPTION
The screend daemon is used in conjunction with the gateway screen
facility to decide which IP packets should be forwarded when the system
is acting as an IP gateway. Only the super-user may run this program.
Before using screend, build a new kernel by using the doconfig command.
Choose the GWSCREEN option in addition to any other options you want.
Then, reboot the system. For information on rebuilding the kernel see
the System Administration manual and doconfig(8).
When screend is started, it reads the configuration file specified
(configfile) and then processes packets according to the instructions
in that file.
The kernel screening facility must be enabled using screenmode(8)
before screend has any effect. (When screening is disabled, packets are
forwarded by the kernel according to its usual procedures.)
It is possible to run more than one copy of screend at a time, although
it is not recommended. You might do this, however, when the configura‐
tion file is changed. Because the configuration file is read only at
program startup, you must restart screend when the file is changed. To
avoid any service interruption, you should start a new instance of
screend before killing the old one.
You can modify the size of the kernel screen cache and packet backlog
queue length, by using either dxkerneltuner or the sysconfig command.
The attribute names are screen_cachedepth, screen_cachewidth, and
screen_maxpend, respectively. See sys_attrs_net(5) for more informa‐
tion.
You can also view the amount of memory that the gwscreen subsystem uses
by using the vmstat -M command (the type is GWSCREEN).
CONFIGURATION FILE
This is an informal guide to the grammar of the screend configuration
file. It is intended for readers who are familiar with the basic con‐
cepts of the IP protocol family, including the distinction between the
terms “network” and “subnet.”
Lexical structure: Can either be C-style comments, delimited by /* and
*/ or csh-style comments begun with a number sign (#) and terminated by
the end of a line. Comments do not nest. Significant in reserved
words (all are lower-case). This is actually a benefit, because if a
host name happens to conflict with a reserved word, you can use the
host name in upper-case. Must begin with a letter but may contain dig‐
its, minus signs (-), dots ( . ), and underscores (_ ). The same is
true of network, subnet, and netmask names. Hosts can also be identi‐
fied by their IP address, in dotted quad notation (for example,
“128.45.40.15”). May be in decimal or in hex (0x0 notation). Octal
notation is not allowed. Decimal notation is the preferred method.
Specified as they are found in /etc/protocols. These can also be given
as numbers. For TCP or UDP, specified as they are in /etc/services.
These can also be given as numbers (host byte order). Must be chosen
from the following list, or given as numbers:
echo echoreply sourcequench
redirect unreachable timeexceeded
parameterproblem timestamp timestampreply
informationrequest informationreply
addressmaskrequest addressmaskreply
All white space is the same (including newlines).
General syntax rules:
The configuration file consists of specifications terminated by semi‐
colons.
There are three kinds of specifications: There should only be one of
these (the last one is the one that counts); it specifies what action
to take if no action specification matches a packet. Specifies the
subnet mask used for a given network. Specifies a class of packets and
the action to take when such a packet is received.
Specifications can appear in any order, but the evaluation order of
action specifications is the order in which they appear in the file.
In BNF, this is:
<configuration-file> ::= \ { <specification> | <configuration-file>
<specification> } <specification> ::= \ { <default-action> | <subnet-
spec> | <action-spec> }
The syntax for a default-action specification is:
<default-action> ::= default {accept | reject} [notify] [log];
Note that default accept notify; is not legal. If not specified, the
default-action is reject.
The syntax for subnet mask specifications is:
<subnet-spec> ::= for <network> netmask is <maskval>;
The <network> is either a network name or a dotted-quad address, such
as “36.0.0.0”. The number “36” is not a reasonable value. The <maskval>
is either a name (treated as a hostname) or a dotted-quad address, such
as “255.255.255.0” (bits are on for the network and subnet fields.)
The syntax for action specifications is:
<action-spec> ::= \ from <object> to <object> {accept | reject}
[notify] [log];
Such a specification says that packets flowing this way between this
pair of objects (defined below) should either be accepted or rejected.
If notify is specified, when a packet is rejected an ICMP error message
is returned to the source. If log is specified, this packet and its
disposition are logged.
Conceptually, for each packet the action specifications are searched in
the order they appear in the configuration file, until one matches. The
specified action is then performed. If no specification matches, the
default action is performed.
To simplify the configuration file, the following syntax may be used to
indicate that the same action should be performed on packets flowing in
either direction between the specified pair of objects:
<action-spec> ::= \ between <object> and <object> {accept | reject}
[notify] [log] ;
Note that this has the same effect as specifying the two unidirectional
rules, with the forward direction listed first.
An object is a specification of the source or destination of a packet.
The syntax for object specifications is somewhat complex, since certain
fields are optional:
<object> ::= { <address-spec> | <port-spec> | \ <address-spec> <port-
spec> }
If the <address-spec> is not given, any host will match. If the <port-
spec> is not given, any protocol and port will match.
<address-spec> ::= { <net-spec> | <subnet-spec> | <host-spec> | any }
<net-spec> ::= { net <name-or-addr> | net-not <name-or-addr> } <subnet-
spec> ::= \ { subnet <name-or-addr> | subnet-not <name-or-addr> }
<host-spec> ::= { host <name-or-addr> | host-not <name-or-addr> }
The -not convention means that the object specification matches if the
specified field does not have the specified value. In the following
example, packets not from nic.ddn.mil are dropped.
from host-not nic.ddn.mil to host any reject;
The “subnet” and “subnet-not” forms match against the entire address
under the subnet mask (for example, if the netmask for net 36 is
“255.255.0.0”, then “subnet 36.8.0.0” matches a packet address of
36.8.0.1).
<name-or-addr> ::= { <name> | <dotted-quad> | any }
<port-spec> ::= { proto <proto-name-or-number> \
| icmp type <type-name-or-number> \
| icmp type-not <type-name-or-number> \
| tcp port <port-name-or-number> \
| tcp port-not <port-name-or-number> \
| udp port <port-name-or-number> \
| udp port-not <port-name-or-number> }
<proto-name-or-number> ::= { <name> | <number> } <type-name-or-number>
::= { <name> | <number> | any | infotype } <port-name-or-number> ::= \
{ <name> | <number> | any | reserved | xserver }
“Reserved” ports are those reserved by 4.2BSD Unix for privileged pro‐
cesses. “Xserver” ports are those used by X11 window system servers.
“Infotype” ICMP packets are those that are purely informational: echo,
timestamp, information, and addressmask requests, and the corresponding
replies.
RULE NUMBERS
If the -r option is given, log records contain a notation of the rule
number responsible for the action being logged. A rule is a “from ...
to ...” specification in the configuration file; rules are numbered in
order starting with zero. Note that “between ... and ...” specifica‐
tions expand to two “from ... to ... ” rules, each numbered individu‐
ally. The default action, whether explicitly stated or not, is not num‐
bered; it is referred to distinctively in the log.
DIAGNOSTICS
During argument processing and configuration file parsing, various
diagnostics may be issued. During normal operation, only serious inter‐
nal inconsistencies result in diagnostics. (See the RESTRICTIONS sec‐
tion about warning messages in some borderline cases.) Except in debug
mode (-d), most diagnostics are logged using syslogd(8).
Once an hour, a statistics report is made using syslogd(8) that shows
the number of packets processed since the program was started, the hit
rate of an internal cache buffer, and the number of packets dropped
because they arrived too rapidly.
RESTRICTIONS
IP gateways are allowed to fragment IP datagrams if they are too large
to be forwarded in one piece. Only the first fragment of a datagram
carries enough information to make certain kinds of accept/reject deci‐
sions. The screend daemon can only handle fragments if it sees the
first fragment of a datagram before it sees any subsequent fragments.
Also, only a limited rate of fragmented packet arrival can be accommo‐
dated by the program (fragmentation is, in general, a bad idea).
Finally, if more than one instance of screend is running, most likely
this will result in significant loss of fragments.
The current implementation does not forward packets that contain IP
header options. This is because several of these options can be used to
subvert checks based on the IP header destination address.
If a host name given in an object specification has more than one IP
address associated with it, screend does not understand that all these
addresses should be checked. Only the first (primary) address of the
host is used. This may lead to erroneous operation in some cases (pos‐
sibly including a security hole), so a warning is printed if the con‐
figuration file contains such names. (Note that you probably will not
see this warning if screend is started using the init program.)
EXAMPLES
The following is an example of the syntax; it is not intended to be
used in an actual installation:
# Example configuration file default reject;
for 36.0.0.0 netmask is 255.255.0.0;
from subnet 36.8.0.0 to net milnet reject notify; from host nic.ddn.mil
to host any accept; from host any to net arpanet tcp port telnet
accept; from host any to host any icmp type redirect reject log; from
host any to subnet 36.10.0.0 tcp port-not reserved reject;
FILES
Default configuration file
SEE ALSO
Commands: vmstat(1), dxkerneltuner(8), screenmode(8), screenstat(8),
sysconfig(8)
Functions: screen(2)
System Attributes: sys_attrs_net(5)screend(8)