The X Window System provides many features and functions that allow systems to share input and output devices. A user running the X Window System on one system can display the results of a graphical program on another system running an X Window client. This flexibility is also the source of a number of well-known security problems.
When you allow access to your display, you are essentially allowing access to your screen, mouse and keyboard. Most sites do not want to provide this sort of free access to their systems, but administrators recognize that these services can be useful. The X11 proxy included with the Gauntlet Firewall allows administrators to selectively allow X11 services through their firewall.
This chapter explores the concepts behind the X11 proxy and explains how it works, how to configure the proxy, and how to use X11 services through the firewall. The chapter consists of the following sections:
The X11 proxy is an application-level proxy that provides configurable access control. The proxy, which runs on the firewall, passes X11 display requests through the firewall, using rules you supply. You can configure the proxy to allow display requests based on the display name and user name.
Using these rules, you can configure your firewall to allow only certain systems on the inside network to display information from systems on an outside network. Employees working on the inside network can configure their system to display information from a program on a client's system on the outside network. Or, an employee working at a client site can display output from a program running on a system inside the company's firewall. Similarly, you can configure your firewall to permit only certain users to use the X11 proxy.
The X11 proxy also requires that users confirm each new request for a connection to their display. Because of the lack of strong authentication systems for X11, this reconfirmation provides an additional opportunity to confirm that you really want to accept the connection.
Because the X11 proxy works in conjunction with the TELNET and Rlogin proxies, you can still configure access based on the source or destination hostname or IP address. The strong authentication feature is also available. The TELNET and Rlogin proxies also log X requests and connections.
Unlike some of the other Gauntlet proxies, the firewall does not start the X11 proxy when it receives display requests. Instead, users must explicitly start the X11 proxy from either the TELNET or Rlogin proxy. The firewall logs and denies all requests for services from hosts other than the firewall on the standard X port (TCP port 6000).
A user connects to the firewall, which runs the TELNET proxy. After checking permissions and authenticating users, the TELNET proxy (tn-gw) displays a prompt for the user. At the prompt, the user indicates she or he wishes to allow X displays across the firewall. The TELNET proxy starts the X11 proxy (x-gw) on port 6010 or higher. The X11 proxy checks its configuration information and determines whether the initiating user has permission to use X11 services related to the desired display.
If the user has permission, the proxy creates a “virtual display” on the firewall for the requesting client. When the outside X client requests access to the user's display, the virtual display server passes a query window request to the X server on the display system. This X server displays the query window on the real display, prompting the user to confirm the request. After the user confirms the request, the real X server receives the display information from the virtual X server. The proxy remains active until either end closes the connection.
The default service groups do not include the X11 proxy. The firewall itself can run an X server because the X server runs on the standard X port (TCP port 6000) and the X11 proxy runs on other ports (TCP ports 6010 or higher).
To access the X11 proxy configuration:
Configuring the Gauntlet Firewall involves planning and configuring the proxy to enforce your security policy.
When planning X11 proxy settings:
Determine whether you wish to allow X11 display connections through the firewall.
Determine which users and which displays can issue and receive display requests.
Ensure that your settings for X11 services and TELNET and Rlogin are compatible.
Configure the X11 proxy to enforce your security policies:
Click the TELNET or Rlogin tab.
The window for the selected proxy displays.
Select the configuration set for which you wish to allow X11 services.
Click Modify.
The Modify window for the selected proxy displays.
Click Allow X11 Requests to indicate that you want to allow X11 requests for this configuration set.
Click OK.
To enable the X11 proxy service:
In the X11 window, click Enabled.
Add the X11 proxy configuration to the service groups that you want to use the X11 proxy.
Make sure you have added the TELNET or Rlogin configuration set to the same service group.
Before exiting the Gauntlet Firewall Manager, save and apply your changes.
The firewall enables the X11 proxy.
Use TELNET to connect to a system outside the perimeter and display an X11 client on your system inside the perimeter. See “Using X11 Services” for instructions.
Users need to follow slightly different procedures to use X11 services through a firewall. The minimal time needed for these additional steps outweighs the time and money to recover after someone hijacks your display. The procedure is the same from either side of the firewall.
To use X11 services:
Allow the appropriate interface of the firewall to access your display (remember, it is the firewall you permit to access your display, not the client)
TELNET or Rlogin to the firewall.
Authenticate to the proxy if necessary.
Start the X proxy.
TELNET or Rlogin to the desired host.
Inform the client of the host and display information that the proxy provides.
Start the X client application.
Confirm the display request on the real display.
The following example shows a user working on the inside network who needs to display information from a program running on a system on an outside network.The user starts the X11 proxy and establishes a TELNET connection with the outside host:
dimension-27: xhost +fire-in dimension-28: telnet fire-in Trying 204.255.154.100... Connected to fire-in.yoyodyne.com Escape character is '^]'. Fire-out.yoyodyne.com telnet proxy (Version 4.1) ready: tn-gw> x tn-gw> Display port is fire-in.yoyodyne.com:10 tn-gw> c blaze.clientsite.com Connecting to blaze.clientsite.com .... connected BSDI BSD/OS 2.1 Kernel #0: Wed Mar 27 20:22:33 MST 1996 login: crawhide Password: ######### Please wait...checking for disk quotas You have mail. blaze.clientsite.com-1: |
Cindy Rawhide, working at her system (dimension) on the inside network, needs to run an X program on a client system (blaze.clientsite.com) on an outside network, and display the results on her display. She performs these actions:
Cindy gives the firewall access to display.
She uses TELNETs to connect to the inside interface of the firewall for Yoyodyne (fire-in.yoyodyne.com).
The security policy for her site does not require authentication for inside requests, so the firewall connects her to the TELNET proxy.
Cindy indicates that she wants to start an X proxy.
The firewall displays an X status window on Cindy's display, showing the port.
Cindy uses TELNET to connect to the client system (blaze.clientsite.com).
The TELNET daemon on blaze prompts Cindy for her user name (crawhide) and password on blaze. The TELNET daemon on blaze verifies Cindy's user name and password, and logs her in.
Cindy provides the X display information to the client system (blaze) and starts the client application. She uses the hostname of the outside interface of the firewall and the port information that the X proxy provided when she started the X proxy:
blaze.clientsite.com-1: setenv DISPLAY fire-out.yoyodyne.com:10 blaze.clientsite.com-2: xclock & blaze.clientsite.com-3:
Cindy confirms the display request on her system.
Cindy views the results on her screen inside the firewall.
