screend man page on Ultrix

Man page or keyword search:  
man Server   3690 pages
apropos Keyword Search (all sections)
Output format
Ultrix logo
[printable version]

screend(8)							    screend(8)

Name
       screend - 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 Also
       screen(2), screenmode(8), screenstat(8)

								    screend(8)
[top]

List of man pages available for Ultrix

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net