*nix Documentation Project
·  Home
 +   man pages
·  Linux HOWTOs
·  FreeBSD Tips
·  *niX Forums

  man pages->Tru64 Unix man pages -> screend (8)              



NAME    [Toc]    [Back]

       screend - Internet (IP) gateway screening daemon

SYNOPSIS    [Toc]    [Back]

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

OPTIONS    [Toc]    [Back]

       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.

DESCRIPTION    [Toc]    [Back]

       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


       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,
       "").  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]

       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 "". 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
       "" (bits are on for the  network  and  subnet

       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

       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

       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  "",  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>  }  <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

RULE NUMBERS    [Toc]    [Back]

       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.

DIAGNOSTICS    [Toc]    [Back]

       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.

RESTRICTIONS    [Toc]    [Back]

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

EXAMPLES    [Toc]    [Back]

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

       from  subnet  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 tcp port-not reserved reject;

FILES    [Toc]    [Back]

       Default configuration file

SEE ALSO    [Toc]    [Back]

       Commands:   vmstat(1),   dxkerneltuner(8),  screenmode(8),
       screenstat(8), sysconfig(8)

       Functions: screen(2)

       System Attributes: sys_attrs_net(5)

[ Back ]
 Similar pages
Name OS Title
screenstat Tru64 Show gateway screening statistics
screenmode Tru64 Enable or disable gateway screening
screen Tru64 Gateway packet screening facility
gateway IRIX Internet Gateway administration tool
bootpgw Tru64 Internet BOOTP Protocol gateway
bootpd FreeBSD Internet Boot Protocol server/gateway
bootpgw FreeBSD Internet Boot Protocol server/gateway
gated Tru64 gateway routing daemon
ogated Tru64 The gateway routing daemon
gated IRIX gateway routing daemon
Copyright © 2004-2005 DeniX Solutions SRL
newsletter delivery service