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.