Sometimes the easiest way to transfer information from one system to another is to actually transfer the relevant files. The File Transfer Protocol (FTP) is one of several protocols that make this possible. The Gauntlet Firewall includes a proxy that allows secure file transfer between the outside network and the inside network.
This chapter explains the concepts behind the FTP proxy and how it works, how to configure it, and how to use FTP services. One section discusses considerations for running anonymous FTP servers. The chapter consists of the following sections:
The FTP proxy is an application-level proxy that provides configurable access control, authentication, and logging mechanisms.
The FTP proxy, which runs on the firewall, passes FTP requests through the firewall, using rules you supply. You can configure the FTP proxy to allow file transfer activity based on:
source IP address
source hostname
destination IP address
destination hostname
FTP commands (for example, STOR and RETR)
Using these options, you can configure your firewall to allow specific hosts on outside networks to transfer files to and from inside hosts. Employees working at specific customer sites can access files on their workstations. Similarly, you can configure your firewall to permit users on the inside network to copy files (using the FTP daemon RETR command) from hosts on the outside network, but not place files (using the FTP daemon STOR command) on these outside hosts.
The FTP proxy allows administrators to require users to authenticate before transferring files. The FTP proxy logs all successful and unsuccessful file transfer attempts, and the number of bytes transferred.
The FTP proxy's access controls allow you to have more control over the files entering and leaving your system than you would by using the standard IRIX FTP daemon. The logging capabilities are also more extensive.
The firewall runs the network access control daemon (netacl) as a daemon listening for requests on the standard FTP port (TCP port 21). Whenever the daemon receives an FTP request on this port, the netacl daemon checks its configuration information and determines whether the initiating host has permission to use FTP. If the host has permission, the netacl daemon starts the standard FTP server (ftpd) or the FTP proxy (ftp-gw). If the host does not have permission, the daemon displays an error message.
The default trusted service group and rules allow all inside hosts to initiate FTP sessions and transfer files without authenticating. The inside host passes FTP requests to the firewall, which starts the netacl daemon. The netacl daemon checks its permissions, and determines that the inside host can use FTP. The netacl daemon starts ftp-gw. The proxy logs the transaction and passes the request to the outside host. ftp-gw remains active until either side terminates the connection. The default untrusted service group and rules also allow outside hosts to initiate FTP sessions. They must, however, authenticate before accessing inside hosts.
The default configuration does not allow either inside or outside hosts to FTP directly to the firewall itself. If you configure your Gauntlet Firewall to allow FTP to the firewall, hosts connect to the firewall with an FTP request. The firewall starts the netacl daemon. The netacl daemon checks its permissions, and determines that outside hosts can use FTP to the firewall itself. The netacl daemon starts the standard FTP daemon (in a chrooted environment).
This configuration using netacl allows a fair amount of flexibility in configuring FTP services. Users inside the perimeter can continue to interact with outside hosts, generally without authentication. Users outside the perimeter can interact with inside hosts, generally with authentication.
To access the FTP proxy configuration:
Configuring the Gauntlet Firewall for FTP services involves planning, configuring the FTP proxy to enforce company security policy, enabling the proxy, and creating user accounts for users who will need to authenticate.
When planning FTP proxy settings, determine policies for:
Requiring authentication.
Allowing specific FTP commands (for example, RETR and STOR).
Permitting or denying specific sources and destinations.
Configure the FTP proxy to enforce company security policies.
To configure FTP proxy settings, you can provide optional information about time-out values and other configuration settings for the FTP proxy. Refer to the online help for specific information about the available settings. Refer to Chapter 30, “Managing Content Scanning,” for information on configuring the content scanning features for the FTP proxy.
To enable the FTP proxy service:
In the FTP configuration tab, click Enabled.
Add the FTP configuration to the service groups you want to use the FTP proxy.
Before exiting the Gauntlet Firewall Manager, Save and Apply your changes.
The firewall enables the FTP proxy.
Use the authentication management system to create authentication user entries for any users who must authenticate when using FTP services. See Chapter 6, “Users and User Groups,” for more information.
The idea behind the FTP proxy is that most users working on the trusted networks behind the firewall will not see a change in their daily FTP activities. The default configuration allows users on trusted networks to FTP to untrusted networks without authenticating. Users on the trusted networks do not need to change their FTP procedures.
If you have configured any FTP activities to require authentication, users will need to follow different procedures to use FTP.
FTP to the firewall itself.
Authenticate to the proxy.
Connect to the desired FTP server.
Continue as before.
A common security policy for the FTP proxy is to authenticate all requests from untrusted networks to or through the firewall. The example below shows a sample FTP session from an untrusted network to a trusted network, using S/Key authentication at the firewall:
blaze.clientsite.com-27: ftp fire-out.yoyodyne.com Connected to fire-out.yoyodyne.com 220-Proxy first requires authentication 220 fire-out.yoyodyne.com FTP proxy (Version 4.0a) ready. Name (fire-out.yoyodyne.com:clancy): clancy 331 Skey Challenge: s/key 653 fi19289 Password: password does not display 230 User authenticated to proxy ftp> user clancy@dimension 331- (-----GATEWAY CONNECTED TO dimension----) 331- (220 dimension FTP server ready.) 331 Password required for clancy. Password: ######### 230 User clancy logged in. ftp> |
In this example, Clancy, working at a client site (blaze.clientsite.com), needs FTP access to a system behind the firewall (dimension.yoyodyne.com). He first FTPs to the outside address of the firewall for Yoyodyne (fire-out.yoyodyne.com). The FTP proxy on fire-out prompts him to authenticate. Clancy provides his authentication user ID (clancy). When the proxy prompts, he enters the response to the authentication challenge, which does not display. The proxy authenticates clancy.
Clancy indicates the host he needs to access and his user name for that host (clancy@dimension). The FTP proxy connects Clancy to dimension and prompts him for his password on dimension. Clancy enters his password for dimension. The FTP server on dimension verifies Clancy's user name and password, and logs him in. Clancy can now transfer files.
The FTP proxy can require you to authenticate twice. Some GUI FTP tools for Microsoft Windows and the Macintosh require you to specify the user name and password in a dialog box. These tools assume that once you supply this information, you are connected. The FTP proxy displays the challenge and response information for authentication in FTP comments.
Some Microsoft Windows and Macintosh FTP tools do not display FTP comments. Unless the user sees the comment, they will have a really difficult time trying to guess the current challenge. You can still use these FTP tools with S/Key authentication, by combining the authentication and FTP host information.
To authenticate using some GUI tools:
For the hostname, supply the name of the firewall.
For the user name, supply the firewall authentication user name, the FTP host user name, and the name of the FTP host in this form:
authentication-username@ftp-host-username@ftp-host
For the password, supply the authentication response and FTP host password:
authentication-response@ftp-host-password
You may need to TELNET to the firewall to see what the next challenge is.
The example below shows the information a user enters in their FTP tool when going from an untrusted network to a trusted network, using S/Key authentication for the firewall:
host: fire-out.yoyodyne.com username: clancy@clancy@dimension password: elk elba iris odd skim lee@######### |
Because you cannot tell what the next challenge will be when using an authentication system that uses random challenges (such as the AssureNet Pathways SecureNet Key), you may not be able to use these instructions with some GUI FTP tools.
By its very nature, an anonymous FTP server requires easy access by the public. If you place the anonymous FTP server behind the firewall, you are allowing an additional type of access within your security perimeter. If you place the FTP server on the firewall itself, you are allowing additional access to your firewall.
Gauntlet for IRIX allows you to run the standard IRIX FTP server (ftpd) in an isolated (chrooted) environment as an anonymous FTP server (but you give up the ability to allow authenticated users from untrusted networks to use ftp-gw to access trusted networks).
The best solution is generally to place your anonymous FTP server on a system outside the perimeter. Follow good security practices for this system:
Turn off all other services.
Create the minimum number of user accounts.
Use strong authentication.
Patch the operating system and applications.
Use checksums to watch for file changes.
Back up frequently.