Chapter 9 Mixed Mode With Proxies

Typically, you use SunScreen in a mixed-mode configuration to provide the advantages of stealth to the subnet it partitions (which is not visible outside of the network and can be added to a network without changing IP addresses) without the additional cost of a second Screen.

It is not necessary to configure the Screen in a mixed-mode for you to use proxies; you can also use proxies on a Screen in routing mode.

Network Example

For the network example, shows the London segment of the network. Looking at the diagram, a single Screen, lon-screen1, is configured to run in a mixed mode to provide a stealth firewall and to provide an interface with an IP address that provides user authentication using proxies. The hosts protected by SunScreen have illegal IP addresses that gives them web access to the Internet. Screen lon-screen1 acts as an HTTP proxy and performs NAT for these hosts as well.

Use care when designing the security policy for the routing interface to ensure that the advantage of stealth is not negated by the exposed qfe2 interface. For example, an open policy on the routing interface can expose the Screen to be compromised, and can affect the stealth operation as well.

Figure 9-1 London Segment of the Sample Company Network

General Mixed-Mode Configuration

The following parameters are used to implement this example:

• Two interfaces are set up in stealth mode

• Two interfaces are set up in routing mode

  ---

  Note -

  The routing and stealth interfaces must be on different subnets, and separated by an external router.

  ---

• User authentication is provided for telnet access from the Internet to the internal network (lon-host1, and so forth)

• Anonymous FTP access is provided using the FTP proxy to lon-host2 (ftp-server)

• Rules are added to only ALLOW SMTP access to mail-server

• Rules are added to only ALLOW authenticated telnet and FTP to the qfe2 interface of lon-screen1

• The HTTP proxy is used to provide web access to the Internet

  All proxies are accessed through the transmission control protocol (TCP), and therefore can only run on systems configured in routing mode.

Mixed-Mode Limitation

Because NAT has a single state table only, NAT cannot be used to translate the IP addresses of the internal network in this mixed-mode configuration. You can, however, use NAT on the routing interfaces and on the stealth interfaces on a mixed-mode Screen provided that the packets only pass through the Screen once.

NAT is not required because the proxies that provide the telnet/ FTP/HTTP connections between the Internet and the internal network use the IP address of the Screen and not the illegal IP address of the host, only the Screen needs to be able to resolve the hosts IP address.

For example, the mail-server can have its address translated when packets pass to the Internet as the packets only pass through the stealth interfaces once. This is true of any host on the private part of the network (192.168.3.0 in this example) or on the 192.156.4.0 network.

Using DYNAMIC NAT

The following steps outline how DYNAMIC NAT is used to translate the source IP addresses of hosts on the network (10.0.3.0 in this example) to a legal address (192.168.3.100 in this example).

1. Add rules to ALLOW hosts on the 10.0.3.0 network free access to the Internet.

2. Add rules to only ALLOW SMTP access to mail-server.

3. Add rules to only ALLOW authenticated telnet and FTP to the qfe2 interface of lon-screen1.

   ---

   Note -

   The routing and stealth interfaces must be on different subnets, and separated by an external router.

   ---

Detailed Mixed-Mode Configuration

1. Configure the interfaces qfe2 and qfe3 with the correct IP addresses.

2. Confirm that the Screen can contact the addresses of both the internal router and the internal hosts.

   ---

   Tip -

   Ensure that the correct routing and netmasks are used.

   ---

3. Follow the procedure for remotely installing a Screen using Administration Station lon-host4, as described previously in the Hong-Kong example.

   ---

   Note -

   Check the "routing mode" box when installing the firewall software even though this Screen has both stealth- and routing-mode interfaces.

   ---

4. After rebooting the Screen, start a browser on the Administration Station and log into the Screen.

   See the SunScreen Installation Guide for information regarding which browsers are supported for SunScreen.

5. Define the following Address objects, as shown in the following table:

   Table 9-1 Address Objects

   Name	Type	Details
   external-router	HOST	192.168.3.1
   168.3-private	RANGE	192.168.3.2 to 192.168.3.254
   mail-server	HOST	192.168.3.10
   168.4-net	RANGE	192.168.4.1 to 192.168.4.254
   10.0.3-net	RANGE	10.0.3.1 to 10.0.3.254
   ftp-server	HOST	10.0.3.3
   qfe3_grp	GROUP	Include {10.0.3-net} exclude {}
   qfe2_grp	GROUP	Include {*} exclude {10.0.3-net}
   qfe1_grp	GROUP	Include {168.3-private 168.4-net 10.0.3-net} exclude {}
   Internet	GROUP	Include {*} exclude {qfe1_grp}
   qfe0_grp	GROUP	Include {Internet} exclude {}

   ---

   Note -

   The address groups (for example, qfe1_grp) must contain all the IP addresses that can be reached from that interface.

   ---

6. Verify that the interfaces qfe2 and qfe3 were defined by the installation procedure.

   They must have the interface groups qfe2_grp and qfe3_grp assigned to them, respectively.

7. Add INTERFACE objects for qfe0 and qfe1 using the address groups qfe0_grp and qfe1_grp.

   These interfaces must be defined as TYPE: STEALTH.

8. Edit the Screen object ensuring that the STEALTH SUBNET/NETMASK are defined (129.168.3.0 and 255.255.255.0 in this example).

9. Install an open, or test, policy.

10. Save and activate the policy.

11. Verify that the configuration works by using ping to the mail-server from an external host.

12. Verify that this host can ping the Screen's external routing interface qfe2.

Using Proxies For User Authentication

Typically, you set up a mixed-mode Screen to employ a stealth firewall with an IP address for user authentication (there is no security advantage in having stealth interfaces protecting routing interfaces on the same firewall over a straight-forward routing firewall, if you ALLOW access to the routing interfaces). The mixed-mode configuration gives the DMZ stealth protection and enables user authentication.

In the London segment of the sample company network, as shown in Figure 9-1, telnet access is required to the hosts on the 10.0.3.0 network from unspecified hosts on the Internet. To give access to your trusted users only, use user authentication.

Also required is anonymous FTP access to the FTP server running on host lon-host3 so you can upload files, which is also provided by proxies. No other access to the firewall or the Intranet is permitted.

Setting Up Telnet User Authentication

This example shows six user names that need access to the 10.0.3.0 network: William, Henry, Beatrice, Eugenie, Peter, and Zara.

1. Define each of your users as an Authenticated User, as shown in the following figure:

   Figure 9-2 Authenticated User Definition

   
   

2. Define each of your users as a Proxy User, as shown in Figure 9-3.

   That is, define only those users who are qualified to use the proxy for authentication.

   Figure 9-3 Proxy User Definition

   
   

3. Create a rule to ALLOW proxy access that references either a single Proxy User, or, more usually, a GROUP of Proxy Users, as shown in the following figure.

   Figure 9-4 Proxy User Name Used in the Rule

   
   

4. Define a Proxy User GROUP with all the your users.

5. Add a rule to ALLOW telnet with Proxy AUTHENTICATION, as shown in the following figure.

   Figure 9-5 ALLOW telnet Rule

   
   

6. Save and activate the configuration.

Setting Up anonymous FTP Using the FTP Proxy

Another requirement is to ALLOW anonymous FTP to the server lon-host3 using the FTP Proxy. Because this is anonymous FTP, it is not necessary to create an Authenticated User. Use the predefined Proxy Users for ftp and anonymous for this purpose.

The advantage of using the FTP Proxy to ALLOW anonymous FTP access over a regular packet filter rule in this configuration is that the outside world does not need to know which system is the FTP server. Because the FTP connection is made from the firewall, only the firewall needs to know how to resolve the name ftp-server to an IP address. The firewall can use a simple alias in its hosts file and can be changed to another server without the need to tell your users. In this example, the FTP server lon-host3 has an illegal IP address, which is enabled because the firewall can contact it.

Using NAT with a conventional packet filtering rule requires you to add a DNS entry for this host.

1. Define a Proxy User Group that contains the users who can use FTP, as shown in the following figure.

   Figure 9-6 Proxy User Group Definition

   
   

2. Define a rule to ALLOW FTP access, as shown in the following figure.

   Figure 9-7 ALLOW FTP Access Rule Definition

   
   

3. Save and activate the policy.

Configuring the HTTP Proxy

Because the users behind the firewall have illegal IP addresses and NAT cannot be used in a mixed-mode configuration, the HTTP proxy can be used to provide Internet access for your internal users.

1. Add a rule to ALLOW Internet access, as shown in the following figure.

   Figure 9-8 Rule Definition: Initial Window

   
   

2. Save and activate the policy.

   The internal hosts must set the Proxy Address of their browsers to the internal IP address of the firewall (10.0.3.100 in this example).

Proxy Considerations

Ensure that the rules do not open a back door into the Intranet that bypasses the proxy rules. For example, a rule that enables telnet directly to a host.

Adding a rule that explicitly drops telnet/FTP after the proxy rules does this as shown in .

Figure 9-9 Add a Rule to Drop telnet or FTP After the Proxy Rules

Your user must telnet/ FTP to the firewall to be authenticated. The proxy connects the user to the target system (even though the rule has the destination address as the target host), as shown in the following figure.

Figure 9-10 Target System Proxy Connection

After configuring a proxy rule you may need to reboot or rule this script to start the proxy by typing:

# /etc/rc2.d/S79proxy start

You can verify that the proxies are running by typing:

# ps -ef

which gives results like those shown in the following table:

The common objects, authorized user, administrative user, and proxy user that appear in the administration GUI are automatically saved when they are edited or new objects are added. You do not need to save these objects. Changes made to them apply immediately and cannot be reversed; however, they do not take effect until a policy is activated. To install the new objects and to propagate these changes to secondary Screens, activate your system configuration.

The Save button is grayed out to show that it is inactive.

See the SunScreen 3.1 Reference Manual for more information regarding authentication.