screend man page on OSF1

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

screend(8)							    screend(8)

NAME
       screend - 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)
[top]
                             _         _         _ 
                            | |       | |       | |     
                            | |       | |       | |     
                         __ | | __ __ | | __ __ | | __  
                         \ \| |/ / \ \| |/ / \ \| |/ /  
                          \ \ / /   \ \ / /   \ \ / /   
                           \   /     \   /     \   /    
                            \_/       \_/       \_/ 
More information is available in HTML format for server OSF1

List of man pages available for OSF1

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