Many sites rely on groupware or other interconnected applications, such as accounting packages and database applications. Each of these services uses a proprietary protocol, which would require its own application-specific proxy. The Plug proxy might be an ideal candidate for many of these applications. However, administrators also want to control who can access the service (by user name), which the plug proxy cannot do. Administrators can use the circuit proxy instead to allow certain users to tunnel these proprietary applications through the firewall.
 | Caution: Allowing proprietary protocols through your firewall can potentially have serious consequences. Because the protocols are proprietary, the firewall and the proxy have no information on the data or requests the applications are sending. It is also unknown how safe the application itself is. Always perform a risk assessment before using the circuit proxy for proprietary protocols. |
This chapter discusses the concepts behind the circuit proxy and explains how it works and how to configure and use the circuit proxy. The chapter consists of these sections:
The circuit proxy is an authenticated TCP gateway that provides configurable access control and logging mechanisms. The proxy, which runs on the firewall, authenticates users and passes TCP-based application requests through the firewall, using rules you supply. It essentially tunnels information from a port on the firewall to a specific port on another system, after authenticating the user.
You can configure the circuit proxy to service:
This is not an exhaustive list. The circuit proxy is protocol neutral, so you can tunnel a variety of other TCP-based applications. Weigh the risks carefully for each application.
You can configure the circuit proxy to allow connections based on:
user name
source hostname
source IP address
source port
destination hostname
destination IP address
destination port
Using these options, you can configure your firewall to allow certain users to access a database server on a system outside the defense perimeter. Employees working outside the perimeter can access important services inside the perimeter.
The strong authentication features of the circuit proxy require users to authenticate before connecting. The circuit proxy also logs all successful and unsuccessful connection attempts, and the amount of data transferred.
These access controls allow you to have more control over the connections to and from your system than you have without a firewall. The logging capabilities are also more extensive.
The firewall runs the circuit proxy (ck-gw) as a daemon on a user-specified port (generally on a TCP port above 1024). The user initiates the connection using TELNET to the port where the circuit proxy is listening (which is a different port than the port on which the service runs). When the proxy receives a request on this port, it checks its configuration information and determines whether the initiating host has permission to initiate this type of connection. If the host has permission, the circuit proxy authenticates the user with the authentication server specified in the configuration information.
If the authentication is successful, the proxy uses its configuration information to create a menu listing the available services for this user. The user selects the service they want to start. The proxy then waits at the port specified for this service for a connection from the user's system.
The user then starts the client application, which connects to the firewall on the service's port. The proxy accepts the connection and displays a confirmation request in the user's original TELNET window. After the user confirms the request for the connection, the circuit proxy starts a child process to handle the service request. The child process creates a connection from the client to the application server on the other side of the defense perimeter. The proxy then passes requests back and forth between the application client and server. The child process of the circuit proxy remains active until either side terminates the connection. The original TELNET window also remains active until either side terminates the connection.
To access the circuit proxy configuration:
Configuring the Gauntlet Firewall involves planning, indicating which daemons the system will run, configuring the proxies to enforce your security policy, and enabling the proxy.
| Caution: Note again that allowing proprietary protocols through your firewall can potentially have serious consequences. Because the protocols are proprietary, the firewall and the proxy have no information on the data or requests the applications are sending. It is also unknown how safe the application itself is. Always perform a risk assessment before using the circuit proxy for proprietary protocols. |
Verify that the protocol is TCP-based by consulting your protocol documentation and trying it with the plug proxy.
Verify that the protocol uses one port for all server connections.
Verify that the protocol opens only one connection for communicating between the client application and server.
Determine which external hosts can use these services.
Determine which internal hosts can use these services.
To configure circuit proxy settings:
In the Circuit window, provide information about the port you are using.
Port
Enter the port number on which the circuit proxy runs.
Click Server Settings.
The Circuit Service Definition window displays.
Provide information about the services you are offering.
Service Name
Name of the available service. Used by the proxy to create the menu of available services.
Port
Port on the remote host to which the circuit proxy connects. Specify by port number.
Remote Host
Name of the remote host to which the circuit proxy connects. Specify an individual system. Use IP addresses or hostnames. This option is required if you are not using transparency.
Click Add to add this service to the list of available services.
Click OK to return to the Circuit window.
Click Add to create a new circuit proxy configuration set.
The Add Circuit Gateway Configuration window displays.
Provide information about your configuration.
Configuration Name
Name for the circuit proxy configuration set.
Description
Description for this circuit proxy configuration set.
Click OK.
To enable the circuit proxy service:
On the Circuit window, click Enabled.
Add the appropriate configuration set to the service groups that you want to use the this configuration set of the circuit proxy.
Before exiting the Gauntlet Firewall Manager, Save and Apply your changes.
The firewall enables the circuit proxy.
Users follow slightly different procedures to use their application through the circuit proxy:
Use TELNET to connect to the circuit proxy.
Authenticate to the circuit proxy, if required.
Select the desired service.
Start your client application.
Confirm the client application connection.
Use your application.
The example below shows a user working on the trusted network inside the defense perimeter. The company has a policy to authenticate the use of some outside services. He is accessing an Oracle database on a system outside the perimeter at a client site.
First, the user connects to the port on the firewall where the circuit proxy is running. He authenticates using S/Key password:
dimension-59: telnet fire-in ck-gw Trying 10.0.1.100... Connected to fire-in.yoyodyne.com Escape character is '^]'. Username: hikita Skey challenge: s/key 502 fi34762 SILK SCAR DES DON JOEY RUNT Login Accepted fire-in.yoyodyne.com ck-gw proxy (Version 4.1) ready: ck-gw-> |
In this example, Robert Hikita, working at a system (dimension) inside the perimeter needs to access an Oracle database on a system outside the perimeter. He follows these steps:
He first uses TELNET to connects to the port (ck-gw) on the firewall for Yoyodyne (fire-in.yoyodyne.com) on which the circuit proxy is running.
The circuit proxy prompts Robert for his authentication user ID, which he provides (hikita).
When the proxy responds with a challenge, Robert enters his S/Key response.
The proxy authenticates him using the appropriate authentication server and provides him with a circuit proxy prompt.
Robert uses the services command to view a menu of available services. He indicates he wants to connect to the Oracle service (c oracle).
ck-gw->services Valid services are: oracle finance reservations ck-gw-> oracle waiting for oracle client to be started (type 'q<return>' to abort)...
Robert then starts his client application. Because Yoyodyne is using transparency (the default configuration), he indicates that the database server is on the remote host (db.clientsite.com). If Yoyodyne was not using transparency, Robert would tell the client that the database server was the inside address of the firewall (fire-in.yoyodyne.com), allowing the firewall to connect to the database server on his behalf.
Robert returns to the original TELNET window in which he connected to the circuit proxy. He notes that the circuit proxy has received a request for service. He confirms the request. He leaves this TELNET window active while he works so that the circuit proxy remains active.
waiting for oracle client to be started (type 'q<return>' to abort). oracle client started okay to proceed (answer yes only if you started a oracle client)? y ck-gw-> The proxy connects to the remote application server, and begins passing information between the client and server
When Robert no longer needs to use the application, he closes the application and the original TELNET window.