xfwp man page on BSDOS

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



XFWP(1)							XFWP(1)

NAME
       xfwp - X firewall proxy

SYNOPSIS
       xfwp [option ...]

COMMAND LINE OPTIONS
       The command line options that can be specified are:

       -cdt num_secs
	       Used to override the default time-to-close (604800
	       seconds) for xfwp client data connections on which
	       there  is  no  activity	(connections over which X
	       protocol is already being relayed by xfwp)

       -clt num_secs
	       Used to override the default time-to-close  (86400
	       seconds) for  xfwp  client listen ports (ports on
	       xfwp to which X clients first connect when  trying
	       to reach an X server)

       -pdt num_secs
	       Used  to override the default time-to-close (3600
	       seconds) for Proxy Manager  connections	on  which
	       there is no activity

       -config file_name
	       Used  to specify the configuration the name of the
	       configuration file

       -pmport port_number
	       Used to override the default port  address  (4444)
	       for proxy manager connections

       -verify Used  to display the configuration file rule that
	       was actually matched for each service request

       -logfile file_name
	       Used to specify the name of  a  file  where  audit
	       information  should  be	logged. The format of a
	       logged entry is: time of day; event  code;  source
	       IP address; destination IP address; and configura-
	       tion rule number.  The event codes are: "0" for	a
	       successful  connection;	"1"  if a  connection is
	       denied because of a configuration rule; and "2" if
	       a connection is denied because of an authorization

X Version 11		Release 6.4				1

XFWP(1)							XFWP(1)

	       failure. If the event code is "1", and a configu-
	       ration file is used, the configuration rule number
	       is the line number of the configuration file where
	       the  match was made (see the section CONFIGURATION
	       FILE for more information).  If the event code  is
	       not  "1", or if no configuration file is used, the
	       configuration rule number is "-1".

       -loglevel {0,1}
	       Used to specify the amount of  audit  detail  that
	       should  be  logged.   If "0", all connections are
	       logged.	If "1", only unsuccessful connections are
	       logged.

       -max_pm_conns num_connections
	       Used  to specify the maximum number of Proxy Man-
	       ager connections.  The default is 10.

       -max_pm_conns num_connections
	       Used to specify the maximum  number  of	X  server
	       connections.  The default is 100.

DESCRIPTION
       The  X firewall proxy (xfwp) is an application layer gate-
       way proxy that may be run on a network  firewall host  to
       forward	X  traffic across the firewall. Used in conjunc-
       tion with the X server Security extension  and  authoriza-
       tion  checking, xfwp constitutes a safe, simple, and reli-
       able mechanism both to hide the	addresses  of  X  servers
       located on the Intranet and to enforce a server connection
       policy.	Xfwp cannot protect against mischief  originating
       on  the Intranet; however, when properly configured it can
       guarantee that only trusted clients originating on  autho-
       rized  external	Internet  hosts will  be allowed inbound
       access to local X servers.

       To use xfwp there must be an X proxy  manager  running  in
       the  local environment which has been configured at start-
       up to know the location of the xfwp.  [NOTE:  There may be
       more  than  one	xfwp  running in a local environment; see
       notes below on load  balancing  for  further  discussion.]
       Using  the  xfindproxy  utility (which relays its requests
       through the proxy manager) a user asks xfwp to allocate	a
       client  listen  port  for  a particular X server, which is
       internally associated with all future connection requests
       for  that  server.   This  client  listen  port address is
       returned by the proxy  manager  through	xfindproxy.   The
       xfwp  hostname  and port number is then passed out-of-band
       (i.e., via a Web browser) to some remote X  client,  which
       will subsequently connect to xfwp instead of to the target

X Version 11		Release 6.4				2

XFWP(1)							XFWP(1)

       X server.

       When an X client connection  request  appears  on  one  of
       xfwp's listen ports, xfwp connects to the X server associ-
       ated with this  listen  port  and  performs  authorization
       checks  against the server as well as against its own con-
       figurable access control list for requesting clients.   If
       these  checks  fail,  or if the requested server does not
       support the X Security Extension, the client connection is
       refused. Otherwise,  the	 connection is accepted and all
       ensuing data between client and server is relayed by  xfwp
       until the client terminates the connection or, in the case
       of an inactive client, until a configured  timeout  period
       is  exceeded.  Xfwp is designed to block while waiting for
       activity on its connections, thereby minimizing demand for
       system cycles.

       If  xfwp is  run without a configuration file and thus no
       sitepolicy is defined, if xfwp is using an X server  where
       xhost  + has been run to turn off host-based authorization
       checks, when a client tries to connect to  this	X  server
       via  xfwp, the X server will deny the connection.  If xfwp
       does not define	a  sitepolicy,	host-based  authorization
       must  be turned	on for clients to connect to an X server
       via the xfwp.

INTEROPERATION WITH IP PACKET-FILTERING ROUTERS
       The whole purpose of the xfwp is to provide reliable  con-
       trol  over  access to Intranet X servers by clients origi-
       nating outside the firewall.  At the  present  time,  such
       access  control is typically achieved by firewall configu-
       rations incorporating IP packet-filtering  routers.   Fre-
       quently, the  rules  for	 such	filters deny access to X
       server ports (range 6000 - 6xxx) for  all  Intranet  host
       machines.

       In  order  for  xfwp to do its job, restrictions on access
       for ports 6001 - 6xxx must be removed from  the	rule-base
       of  the	IP  packet-filtering  router.	[NOTE:	xfwp only
       assigns ports in the range beginning with 6001; access  to
       port  6000  on  all  Intranet  hosts  may  continue  to be
       denied.] This does not mean the Intranet firewall will be
       opened  for  indiscriminate  entry by X clients. Instead,
       xfwp supports a fully configurable rule-based access  con-
       trol  system,  similar  to  that of  the IP packet-filter
       router itself.  Xfwp  in effect	adds  another	level  of
       packet-filtering control	 which is fully configurable and
       applies specifically to X traffic.  See	section entitled
       CONFIGURATION FILE, below, for further details.

INSTALLATION, SETUP AND TROUBLESHOOTING
       Xfwp  is typically  run	as  a	background process on the

X Version 11		Release 6.4				3

XFWP(1)							XFWP(1)

       Intranet firewall host.	It can be launched using  any  of
       the command-line options described above.  As noted above,
       xfwp works only in conjunction with proxy manager and  the
       xfindproxy  utility.  It can also be configured to support
       a user-defined X server site security policy, in which the
       X server is required to indicate to xfwp whether or not it
       supports the particular policy.	Consult the X server  man
       pages  for  further information on these components.  Xfwp
       diagnostics can be turned on by compiling with the -DDEBUG
       switch.	Connection  status  can be recorded by using the
       -logfile and -loglevel command line options.

PERFORMANCE, LOAD BALANCING AND RESOURCE MANAGEMENT
       Xfwp manages four different kinds of  connections:   proxy
       manager	(PM)  data, X client listen, X client data, and X
       server.	The sysadmin employing xfwp must  understand  how
       the resources for each of these connection types are allo-
       cated and reclaimed by  xfwp  in order	to  optimize  the
       availability of xfwp service.

       Each  connection-type  has  a default number of allocation
       slots and a default timeout.   The  number  of  allocation
       slots  for PM connections and X server connections is con-
       figurable via command line options.   Connection timeouts
       are also configurable via command line options.	Each con-
       nection timeout represents the period the connection  will
       be  allowed  to remain open in the absence of any activity
       on that connection.  Whenever there is activity on a  con-
       nection, the  time-to-close  is automatically reset.  The
       default distribution of	total  process	connection  slots
       across the four connection types, as well as the choice of
       default timeouts for the connection types, is governed  by
       a number of assumptions embedded in the xfwp use model.

       The default number of PM connections is 10 and the default
       duration for PM connections is 3,600 seconds (1 hour)  for
       each connection after time of last activity.  At start-up,
       xfwp listens  for  PM  connection  requests  on	any  non-
       reserved port  (default	of  4444 if not specified on the
       xfwp command-line).  The PM normally connects to xfwp only
       when  a	call  is  made to the PM with xfindproxy.  There-
       after, the PM remains connected to xfwp, even  after  the
       messaging between them has been completed, for the default
       connection duration period.  In some cases this may result
       in  depletion  of  available  PM connection slots.  If the
       sysadmin expects connections to a single xfwp  from  many
       PM's,  xfwp  should be started using the -pdt command line
       option, with a timeout value reflecting the desired  dura-
       tion that inactive connections will be permitted to remain
       open.

       Xfwp client listeners are set up by a call  to  xfindproxy

X Version 11		Release 6.4				4

XFWP(1)							XFWP(1)

       and  continue  to  listen for X client connection requests
       for a default duration of 86,400 seconds (24  hours)  from
       the  point  of  last  activity.	After this time they are
       automatically closed and their fd's recovered  for  future
       allocation.   In addressing the question of how to choose
       some alternative timeout value which  will  guarantee  the
       availability of client listen ports, sysadmins should take
       into consideration the expected	delay  between	the  time
       when the listener was allocated (using xfindproxy) and the
       time when a client actually attempts to connect	to  xfwp,
       as  well the likelihood that client listeners will be re-
       used after the initial client data connection is closed.

       Each client connection is allocated a default lifetime  of
       604,800 seconds (7 * 24 hours) from the point when it last
       saw activity.  After this time it is automatically  closed
       and  its fd's  recovered	 for future allocation.	 Because
       server connections are not actually  established until	a
       connection  request  from a remote X client arrives at one
       of the xfwp's client listen ports, the client data timeout
       applies	both  to  client-xfwp  connections  as well as to
       xfwp-server  connections.   If  the  system  administrator
       expects	many  client  data  connections through xfwp, an
       overriding of the default timeout should be considered.

CONFIGURATION FILE
       The xfwp configuration  file  resides  on  the  xfwp  host
       machine	and  is used  to determine whether X client data
       connection requests will be permitted or denied. The path
       to the file is specified at start-up time.  If no configu-
       ration file is specified, all  X client	data  connection
       requests routed through xfwp will be by default permitted,
       assuming that other X server authorization checks are suc-
       cessful. If a configuration file is supplied but none of
       its entries matches the connection request then	the  con-
       nection is by default denied.

       If  a  line  in the configuration file begins with the '#'
       character or a new-line character, the line is ignored and
       the evaluator will skip the line.

       The  configuration  file supports two entirely independent
       authorization checks:  one  which  is  performed by  xfwp
       itself,	and a second which is the result of xfwp's query-
       ing the target X server. For the first of these, the con-
       figuration  file employs a syntax and semantic similar to
       that of IP packet-filtering routers.  It contains zero  or
       more source-destination rules of the following form:

       {permit	|  deny}  <src> <src  mask>  [<dest> <dest mask>
       [<operator> <service>]]

X Version 11		Release 6.4				5

XFWP(1)							XFWP(1)

       permit/deny the keywords ``permit'' or  ``deny'' indicate
		   whether   the  rule	will  enable  or  disable
		   access, respectively

       src	 the IP address against the host who originated
		   the	connection   request  will  be	matched,
		   expressed in IP format (x.x.x.x)

       src mask a subnet mask, also in IP format, for  further
		   qualifying  the  source mask.  Bits set in the
		   mask indicate bits of the incoming address  to
		   be ignored when comparing to the specified src

       dest	the IP address against which	the  destination
		   of  the  incoming connection request (i.e. the
		   host IP of the X server to which the incoming
		   client  is  attempting  to  connect) will  be
		   matched

       dest mask   a subnet mask, also in IP format, for  further
		   qualifying  the destination mask.  Bits set in
		   the mask  indicate  bits  of the  destination
		   address  to	be  ignored when comparing to the
		   specified dest

       operator always ``eq'' (if the  service	field  is  not
		   NULL)

       service	one	of  the following three strings:  ``pm'',
		   ``fp'', or ``cd'', corresponding to proxy man-
		   ager, xfindproxy, or client data, respectively

       For the second type of authorization check, the configura-
       tion  file  contains zero or more site policy rules of the
       following form:

       {require | disallow} sitepolicy <site_policy>

       require	specifies that the X server must be configured
		   with at  least  one of the corresponding site
		   policies, else it must refuse the  connection.

       disallow specifies  that	 the X server must not be con-
		   figured with any  of the  corresponding  site
		   policies,  else it must refuse the connection.

       sitepolicy  a required keyword

       <site_policy>
		   specifies the policy string. The  string  may
		   contain  any combination of alphanumeric char-
		   acters subject only to interpretation  by  the
		   target X server

X Version 11		Release 6.4				6

XFWP(1)							XFWP(1)

RULES FOR EVALUATING THE XFWP CONFIGURATION FILE ENTRIES
       For the first type of configurable authorization checking,
       access can be permitted or denied for each connection type
       based  upon  source  and, optionally, destination and ser-
       vice.  Each file entry must at a minimum specify the  key-
       word  ``permit'' or  ``deny''  and the two source fields.
       The destination and service fields can be used to  provide
       finer-grained access control if desired.

       The algorithm for rule-matching is as follows:

	    while (more entries to check)
	    {
	      if ((<originator IP> AND (NOT <src mask>)) == src)
		[if  ((<dest  X server IP> AND (NOT <dest mask>))
	  == dest)]
		  [if (service fields present and matching)]
		    do either permit or deny connection depending
	  on keyword
	      else
		continue
	    }
	    if (no rule matches)
	      deny connection

       If  a  permit  or deny rule does not specify a service and
       operation, then the rule applies to all	services.   If	a
       configuration  file  is specified and it contains at least
       one valid deny or permit rule, then a  host  that  is  not
       explicitly permitted will be denied a connection.

       Site  policy configuration checking constitutes a separate
       (and X server only) authorization check on  incoming  con-
       nection requests.  Any number of require or disallow rules
       may be specified, but all rules must be of the same  type;
       that  is,  a single rule file cannot have both ``require''
       and ``disallow'' keywords.  The algorithm for  this  check
       is as follows:

	    if	(X  server  recognizes	any  of the  site policy
	  strings)
	      if (keyword == require)
		permit connection
	      else
		deny connection
	    else
	      if (keyword == require)
		deny connection
	      else
		permit connection

       The site policy check is performed by  xfwp  only  if  the
       source-destination rules permit the connection.

X Version 11		Release 6.4				7

XFWP(1)							XFWP(1)

EXAMPLES
       # if and only if server supports one of these policies then authorize
       # connections, but still subject to applicable rule matches
       #
       require sitepolicy policy1
       require sitepolicy policy2
       #
       # deny pm connections originating on 8.7.6.5 [NOTE:  If pm service
       # is explicitly qualified, line must include destination fields as
       # shown.]
       #
       deny  8.7.6.5  0.0.0.0  0.0.0.0	255.255.255.255 eq  pm
       #
       # permit xfindproxy X server connects to anywhere [NOTE: If
       # fp service is explicitly qualified, line must include source fields
       # as shown.]
       #
       permit  0.0.0.0	255.255.255.255 0.0.0.0	 255.255.255.255  eq	fp
       #
       # permit all connection types originating from the 192.0.0.0
       # IP domain only
       #
       permit  192.0.0.0   0.255.255.255

       Care  should  be taken	that source-destination rules are
       written in the correct order, as the first  matching  rule
       will be applied. In addition to parser syntax checking, a
       special command-line switch (-verify) has been provided to
       assist the sysadmin in determining which rule was actually
       matched.

BUGS
       Xfwp should check server site policy and security  exten-
       sion before allocating a listen port.

SEE ALSO
       xfindproxy (1), Proxy Management Protocol spec V1.0, prox-
       ymngr(1), Xserver(1)

AUTHOR
       Reed Augliere, consulting to X Consortium, Inc.

X Version 11		Release 6.4				8

[top]
                             _         _         _ 
                            | |       | |       | |     
                            | |       | |       | |     
                         __ | | __ __ | | __ __ | | __  
                         \ \| |/ / \ \| |/ / \ \| |/ /  
                          \ \ / /   \ \ / /   \ \ / /   
                           \   /     \   /     \   /    
                            \_/       \_/       \_/ 
More information is available in HTML format for server BSDOS

List of man pages available for BSDOS

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