screend(8)screend(8)Namescreend - Internet (IP) gateway screening daemon
Syntax
/usr/etc/screend [ -d ] [ -c ] [ -l ] [ -f configfile ] [ -L logfile ]
[ -s ] [ -r ]
Description
The 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 you must add the following line to your system configura‐
tion file:
pseudo-device gwscreen
After editing the system configuration file you must rebuild the ker‐
nel, and reboot the system. For information on rebuilding the kernel
see the Guide to Configuration File Maintenance and the reference page.
When 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 before has any
effect. (When screening is disabled, packets are forwarded by the ker‐
nel according to its usual procedures.)
It is possible to run more than one copy of at a time, although it is
not recommended. You might do this, however, when the configuration
file is changed. Because the configuration file is read only at pro‐
gram startup, you must restart when the file is changed. To avoid any
service interruption, you should start a new instance of before killing
the old one.
Options-d Prints large amounts of debugging information. This is not meant
for normal use.
-c Checks the syntax of the configuration file but does not actually
process any packets.
-l Turns on logging for all packets (normally, packets are logged
only if requested in the configuration file).
-f configfile
Specifies the configuration file. If not specified, the default,
is used.
-L logfile
Specifies that logging records should be appended to the given
file. There is no default logging file. This may be specified
simultaneously with in which case each logging record is stored by
both means.
-s Specifies that logging records should be logged using
-r 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 problems. See the
section in this reference page on Rule Numbers.
Configuration File
This is an informal guide to the grammar of the configuration file. It
is intended for readers who are familiar with the basic concepts of the
IP protocol family, including the distinction between the terms ``net‐
work'' and ``subnet.''
Lexical structure:
Comments
Can either be C-style comments, delimited by /* and */ or
csh-style comments begun with a number sign (#) and ter‐
minated by the end of a line. Comments do not nest.
Case 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.
Host names
Must begin with a letter but may contain digits, minus
signs (-), dots ( . ), and underscores (_ ). The same is
true of network, subnet, and netmask names. Hosts can
also be identified by their IP address, in dotted quad
notation (for example, ``128.45.40.15'').
Numbers
May be in decimal or in hex (0x0 notation). Octal nota‐
tion is not allowed. Decimal notation is the preferred
method.
Protocol names
Specified as they are found in These can also be given as
numbers.
Port names
For TCP or UDP, specified as they are in These can also
be given as numbers (host byte order).
ICMP type codes
Must be chosen from the following list, or given as num‐
bers:
echo echoreply sourcequench redi‐
rect unreachable timeexceeded parameter‐
problem timestamp timestampreply information‐
request informationreply addressmaskrequest address‐
maskreply
White space
All white space is the same (including newlines).
General syntax rules:
The configuration file consists of specifications terminated by
semicolons.
There are three kinds of specifications:
default-action specification
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.
subnet mask specifications
Specifies the subnet mask used for a given network.
action specifications
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 is not legal. If not specified, the default-action is
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.
<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 is specified, when a packet is rejected an ICMP error message is
returned to the source. If is specified, this packet and its disposi‐
tion 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 convention means that the object specification matches if the spec‐
ified field does not have the specified value. In the following exam‐
ple, 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
processes. ``Xserver'' ports are those used by X11 window system
servers. ``Infotype'' ICMP packets are those that are purely informa‐
tional: echo, timestamp, information, and addressmask requests, and the
corresponding replies.
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 daemon can only handle fragments if it sees the first frag‐
ment of a datagram before it sees any subsequent fragments. Also, only
a limited rate of fragmented packet arrival can be accommodated by the
program (fragmentation is, in general, a bad idea). Finally, if more
than one instance of is running, most likely this will result in sig‐
nificant 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, 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 is only started in
Examples
This 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;
Rule Numbers
If the option is given, log records contain a notation of the rule num‐
ber 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
numbered; 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
internal inconsistencies result in diagnostics. (See the Restrictions
section about warning messages in some borderline cases.) Except in
debug mode ( most diagnostics are logged using
Once an hour, a statistics report is made using 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.
Files
default configuration file
See Alsoscreen(2), screenmode(8), screenstat(8)screend(8)