screend - Internet (IP) gateway screening daemon
/usr/sbin/screend [-d] [-c] [-l] [-f configfile] [-L logfile]
[-s] [-r]
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 (normally, 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 problems. See the
section in this reference page on RULE NUMBERS.
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 configuration 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 information.
You can also view the amount of memory that the gwscreen
subsystem uses by using the vmstat -M command (the type is
GWSCREEN).
This is an informal guide to the grammar of the screend
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 "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 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"). 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 semicolons.
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> | \ <addressspec>
<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> | <hostspec>
| 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> } <typename-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 informational: echo, timestamp,
information, and addressmask requests, and the corresponding
replies.
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 ..." specifications
expand to two "from ... to ... " rules, each numbered
individually. The default action, whether explicitly
stated or not, is not numbered; it is referred to distinctively
in the log.
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
(-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.
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 decisions. 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 accommodated 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 (possibly
including a security hole), so a warning is printed if the
configuration file contains such names. (Note that you
probably will not see this warning if screend is started
using the init program.)
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;
Default configuration file
Commands: vmstat(1), dxkerneltuner(8), screenmode(8),
screenstat(8), sysconfig(8)
Functions: screen(2)
System Attributes: sys_attrs_net(5)
screend(8)
[ Back ] |
