unixdev.net


Switch to SpeakEasy.net DSL

The Modular Manual Browser

Home Page
Manual: (OSF1-V5.1-alpha)
Page:
Section:
Apropos / Subsearch:
optional field



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

  -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	pro-
      cess 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,
      /etc/screend.conf, 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 -s, in which	case each logging record is stored by both means.

  -s  Specifies	that logging records should be logged using syslogd(8).

  -r  Specifies	that logging records should include the	rule number of the
      configuration file rule responsible for the action logged. This is use-
      ful for debugging	configuration file problems.  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 you must	add the	following line to your system confi-
  guration 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
  System Administration	and the	doconfig(8) reference page.

  When screend is started, it reads the	configuration file specified (config-
  file)	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 attri-
  bute 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).

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 concepts of the
  IP protocol family, including	the distinction	between	the terms "network"
  and "subnet."

  Lexical structure:

  Comments
      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 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 notation is not
      allowed.	Decimal	notation is the	preferred method.

  Protocol names
      Specified	as they	are found in /etc/protocols. These can also be given
      as numbers.

  Port names
      For TCP or UDP, specified	as they	are in /etc/services. 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
      parameterproblem	 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 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 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 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 speci-
  fied 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 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 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 ..." 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

  During argument processing and configuration file parsing, various diagnos-
  tics may be issued.  During normal operation,	only serious internal incon-
  sistencies result in diagnostics. (See the RESTRICTIONS section about	warn-
  ing 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 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 (fragmenta-
  tion 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 warn-
  ing 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

  /etc/screend.conf
      Default configuration file


SEE ALSO

  Commands: vmstat(1), dxkerneltuner(8), screenmode(8),	screenstat(8), sys-
  config(8)

  Functions: screen(2)

  System Attributes: sys_attrs_net(5)