Introduction
This example configuration demonstrates how to secure a network with a combination of routers and a Cisco Secure PIX Firewall. There are three levels of defense (two routers and the PIX Firewall) and logging set up to a syslog server to aid in the identification of potential security attacks.
Note: This document does not cover issues such as password selection and other forms of security that are necessary to successfully protect your network from attack.
Prerequisites
Requirements
There are no specific requirements for this document.
Components Used
The information in this document is based on PIX Software version 5.3.1 and later.
Note: Commands used in other versions of PIX software vary slightly. Refer to the PIX documentation before you implement this configuration.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Conventions
Refer to the Cisco Technical Tips Conventions for more information on document conventions.
Configure
In this section, you are presented with the information to configure the features described in this document.
Note: Use the Command Lookup Tool (registered customers only) to obtain more information on the commands used in this section.
Network Diagram
This document uses this network setup.
Configurations
The first configuration is for the PIX Firewall because the router configurations must be understood in relation to the firewall.
If you have the output of a write terminal command from your Cisco device, you can use the Output Interpreter (registered customers only) tool to display potential issues and fixes.
This document uses these configurations:
-
PIX Firewall
-
RTRA
-
RTRB
PIX Firewall |
---|
|
RTRA |
---|
no service tcp small-servers |
If you have the output of a show running-configuration command from your Cisco device, you can use Output Interpreter (registered customers only) to display potential issues and fixes.
RTRB |
---|
logging trap debugging |
Verify
There is currently no verification procedure available for this configuration.
Troubleshoot
There is currently no specific troubleshooting information available for this configuration.
Concepts
The purpose of Firewalls is to prevent unauthorized entry into your network while allowing desired traffic at the same time. It is probably easiest to begin with an analysis of what the objective of a break-in might be, then consider how to make it difficult for a potential criminal to get into your network. Suppose, in the situation described in this document, that the criminal had a server in mind that contained secret information which would be of great value to your competitors. The IP address of this server, the criminal has learned, is 10.100.100.10.
Immediately, the criminal is faced with a serious problem: the IP address of the server is an address which cannot be reached over the Internet, as no organization attached to the Internet forwards packets to a network 10 destination address. This forces the criminal to either attempt to find out what address this translates to on the Internet (a smart system administrator would never let this address be translated onto the Internet), or break directly into your network in order to obtain a "base camp" from which to attack the server containing the sensitive data. Assume that the criminal cannot find any way to attack the server directly, and so starts to attack your network in order to attack the server from within your network.
The first obstacle the criminal faces is the first "demilitarized zone" (DMZ), which is in between RTRA and the PIX Firewall. The criminal can attempt to break into RTRA, but the router is configured to only accept connections from the workstation of the administrator, and to block packets that appear to be sourced from the DMZ itself. If the criminal could break into RTRA, he would only find himself in a position to attack the PIX Firewall itself - he would not be 'in' the network, and he still could not attack the host with the sensitive material directly.
The criminal could also attempt to break into the FTP/HTTP server, which is a possibility to be watched for. This host should be as secure as possible against any such attacks. If the criminal successfully broke into the FTP/HTTP server, he would still not be in a position to attack the host with the sensitive data directly, but he would be in a position to attack the PIX Firewall directly. In either case, the criminal's activities should be logged at some point in the process of getting this far, so the system administrator should be alerted to the presence of an intruder.
If the attacker did successfully break into the outer DMZ, he would find himself in a position to attack the PIX Firewall and little more, so the second, or inner, DMZ becomes the next goal. He can reach this goal with an attack on the PIX Firewall itself, or an attack on the RTRB, which is programmed to accept Telnet sessions only from the system administrator's workstation again. Once again, his attempts to break into the inner DMZ are logged by both the PIX Firewall and RTRB, so the system administrator should have some warning and be able to stop the attack before the attacker gets to the point where he can attack the sensitive server directly.
The attacker could also bypass the outer DMZ and attempt to break into the inner DMZ by attacking the mail host. This host is protected by the PIX Firewall, and should be protected through careful monitoring and configuration. This is the most vulnerable host in the entire firewall.
The concept is to provide several layers of defense rather than one "super strong" wall. The pieces should interlock together into one strong firewall structure which is flexible enough to permit the traffic you need to allow through, but also provides plenty of alarms and early warning systems.
Network Protocols Whose Use Is Not Recommended with a Firewall
Due to their inherently insecure natures, some network protocols are not appropriate for running across Firewalls from untrusted to trusted networks. Examples of such insecure protocols are:
-
NFS
-
rlogin
-
rsh
-
any RPC-based protocol
Recent revisions of the PIX have included support for RPC protocols. Cisco, however, strongly discourages use of this capability, as RPC is very insecure. This feature is meant to be used in only the most unusual of circumstances.
PIX 7.0 uses the inspect rpc command to handle RPC packets. The inspect sunrpc command enables or disables application inspection for the Sun RPC protocol. Sun RPC services can run on any port on the system. When a client attempts to access an RPC service on a server, it must find out which port that particular service runs on. In order do this, the client queries the portmapper process on the well-known port number 111. The client sends the RPC program number of the service, and gets back the port number. From this point on, the client program sends its RPC queries to that new port.