Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

screend(8) [ultrix man page]

screend(8)						      System Manager's Manual							screend(8)

       screend - Internet (IP) gateway screening daemon

       /usr/etc/screend [ -d ] [ -c ] [ -l ] [ -f configfile ] [ -L logfile ] [ -s ] [ -r ]

       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 configuration file:
       pseudo-device	  gwscreen
       After editing the system configuration file you must rebuild the kernel, 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

       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 program 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.

       -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 simul-
	    taneously 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 ``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.

	      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 net-
		     work,  subnet,  and  netmask  names.  Hosts can also be identified by their IP address, in dotted quad notation (for example,

		     May be in decimal or in hex (0x0 notation).  Octal notation 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 numbers:

		     echo		 echoreply	   sourcequench     redirect		unreachable	  timeexceeded	    parameterprob-
		     lem    timestamp	      timestampreply informationrequest  informationreply   addressmaskrequest	addressmaskreply

	      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 speci-
		     fication 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

       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 ``''.  The number ``36'' is not a reasonable value.
       <Maskval> is either a name (treated as a hostname) or a dotted-quad address, such as ``'' (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  flow-
       ing 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 specified field does not have the  specified  value.	In  the  following
       example, packets not from are dropped.
       from host-not 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
       ``'', then ``subnet'' matches a packet address of

       <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 informational: echo, timestamp, information, and addressmask requests, and
       the corresponding replies.

       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 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 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, 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 is only started in

       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 netmask is;

       from subnet to net milnet reject notify;
       from host 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 tcp port-not reserved reject;

Rule Numbers
       If the 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 ...'' speci-
       fications 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 inter-
       nal 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.

       default configuration file

See Also
       screen(2), screenmode(8), screenstat(8)

Man Page