Cisco PIX Firewall Basics

Cisco PIX Firewall Basics

Introduction

The online reference materials for configuring Cisco PIX Firewall Version 6.1 can be found at: http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_61/index.htm . I recommend you look there for the details we had to omit in this article. It is always a good idea to check the Release Notes, especially for open caveats (bugs) that may affect an advanced PIX implementation.

Another good source of information about the Cisco PIX is the Cisco CSPFA course. This is a security-certification track course. See http://www.cisco.com/pcgi-bin/front.x/wwtraining/CELC/index.cgi?action=CourseDesc&COURSE_ID=1628 .

What Does a PIX Do?

The PIX is a firewall appliance based on a hardened, specially built operating system, PIX OS, minimizing possible OS-specific security holes. The PIX has received ICSA Firewall and IPsec certification as well as Common Criteria EAL4 evaluation status.

PIX firewalls provide a wide range of security and networking services including:

  • Network Address Translation (NAT) or Port Address Translation (PAT)
  • content filtering (Java/ActiveX)
  • URL filtering
  • IPsec VPN
  • support for leading X.509 PKI solutions
  • DHCP client/server
  • PPPoE support
  • advanced security services for multimedia applications and protocols including Voice over IP (VoIP), H.323, SIP, Skinny and Microsoft NetMeeting
  • AAA (RADIUS/TACACS+) integration

PIX can be graphically managed using the integrated Web-based management interface known as the PIX Device Manager (PDM) or by the Cisco Secure Policy Manager 2.3f and 3.0f (not to be confused with CSPM 2.3.3i which is for intrusion detection system management).  The PDM is a PIX-specific device configuration and management tool whereas CSPM is generally used as part of a larger security management infrastructure and allows one to correlate organizational security policies with a PIX configuration. Management interfaces include command-line interface (CLI), telnet, Secure Shell (SSH 1.5), console port, SNMP, and syslog.

Cisco PIX Models

Cisco PIX
Model
Rated
Throughput
Concurrent
Connections
Description
PIX 535 1 Gbps +Up to 95 Mbps 3DES VPN, 2000 IPsec tunnels 500,000 Some models include stateful high-availability capabilities, as well as integrated hardware acceleration for VPN. Modular chassis, up to 10 10/100 Fast Ethernet interfaces or 9 Gigabit Ethernet interfaces.
PIX 525 360 Mbps +Up to 70 Mbps 3DES VPN, 2000 IPsec tunnels 280,000 Some models include stateful high-availability capabilities, as well as integrated hardware acceleration for VPN. Modular chassis, up to 8 10/100 Fast Ethernet interfaces or 3 Gigabit Ethernet interfaces.
PIX 515E 188 Mbps + 125,000 Some models include stateful high-availability capabilities and integrate support for 2,000 IPsec tunnels. Modular chassis, up to six 10/100 Fast Ethernet interfaces.
PIX 506E 20 Mbps +,
16 Mbps 3DES VPN
Compact desktop chassis, two auto-sensing 10Base-T interfaces.
PIX 501 10 Mbps +,
3 Mbps 3DES VPN
Compact plug-n-play security appliance,  integrated 4-port Fast Ethernet (10/100) switch and one 10Base-T interface.

See http://www.cisco.com/warp/customer/cc/pd/fw/sqfw500/ for information about the PIX product line in general, or for more details or the latest models added to this product line.

PIX Terminology and Background Information

The following diagram shows a multi-port PIX connected to various networks. We will use this diagram as we build up a PIX configuration in this and any subsequent PIX articles.

PIX terminology: we generally refer to the user segment as the Inside subnet. The interface connected to the Internet router is the outside subnet. As shown, we probably have DMZ (De-Militarized Zone) subnet, the subnet where we quarantine all servers that are accessible from the outside. We might also have a separate management subnet and a subnet tying to a redundant PIX for failover (if supported/licensed).

The PIX Command-Line Interface (CLI) is somewhat like the Cisco IOS interface, but different. Use colon (“:”) for comments (which, as usual, are not retained).  Newer PIX OS uses ACL’s, replacing the former conduits (which were arguably more confusing to experienced Cisco router administrators).

PIX interfaces are normally shutdown until the administrator activates them.

PIX interfaces have an associated security level. Two interfaces at same level can’t send packets to each other. We’ll shortly see that you set levels with nameif command. Connections and traffic are normally permitted from higher to lower security level interfaces, although you do have to put in some basic configuration to allow traffic to flow. Connections the other way (from low to high security) are disallowed unless the configuration explicitly permits them.

You actually do not have to put any ACL if going from a higher security level to a lower. Everything will be allowed. Best practice is to put an ACL on all interfaces even if the ACL permits everything to flow using “ip any any”.  An ACL put inbound (PIX only does inbound ACLs) to the inside interface can control traffic destined going outbound. If an admin wants to only have www and dns traffic outbound he would allow only tcp on 80 and udp on 53 then everything else like real audio would be denied as it goes out.)

To let traffic flow from a high security level to a lower level, use the nat and global commands. For the opposite direction, from lower to higher, use the static and access-list commands. We suggest using nat and global when going from any non-outside interface to the outside interface (Internet usually unless the PIX is used as a border between business units) which is a little different than the first sentence above.  We also suggest using statics from any non-outside interface to any other non-outside interface (like inside to management or ethernet3 to ethernet4, below.)

The PIX normally uses stateful NAT connections and stateful security, referred to as the Adaptive Security Algorithm (ASA). The PIX does not pass multicast traffic. (Can you say “DVMRP tunnel”?)

Cisco and we recommend you do not dynamic routing to or through the PIX. The PIX does support RIP, but the authors both loathe RIP. And static routing is more secure, cannot be as easily fooled.

PIX Configuration

We’ll start off with good housekeeping. Enter configuration mode with “config t”. You’ll want to assign a hostname / prompt name so you can tell which device you’re on. You’ll also want to set up passwords.

Command Command Explanation
enable password myEnableSecret encrypted Set the enable password (displays encrypted). Displays in encrypted form, with the word “encrypted” at the end. Note that when entering the command leave off  “encrypted” keyword or the PIX will assume that the string you are putting in is the encryption of the actual password.
passwd myLoginSecret encrypted Set the user mode password, the first password challenge when using Telnet.  Note that when executing the command leave off the “encrypted” keyword or the PIX will assume that the string you are putting in is the encryption of the actual password.
hostname UNIT1 Set the name of the host. It is best to make this name innocuous so that it does not give away the type of device this is.

The PIX does allow you to set up a hosts table as a management convenience. Because there is no connection to DNS or /etc/hosts on UNIX servers, use of this command is a mixed blessing. It makes configurations much more readable but introduces another level of administration. Not only do you have to add and delete IP addresses to your configuration as you do now. But with this command, you also need to ensure that the host names match existing names.

Command Command Explanation
name 10.3.3.22 DMZWEBSERVER Map address to name
name 10.1.1.82 INTERNALDNSHOST
name 10.1.1.79 INTERNALORACLEHOST
name 10.1.1.71 INTERNALNTPHOST
name 1.1.1.5 EXTERNALSMTPHOST
name 1.1.1.22 EXTERNALWWWHOSTNAME

To start adjusting the default PIX configuration, one usually names the interfaces and assigns them security levels. (0 = least trusted; 100 = most trusted). We then specify the speed for each interface, carefully leaving off the default shutdown keyword at the end to activate (enable) the interface. We do this for each interface we’re going to use. We have one extra unused interface which we shutdown.

We also need to assign IP addresses to the interfaces that will be carrying IP traffic. One trick you can use on a shutdown interface is to assign it the loopback address, 127.0.0.1. This prevents accidental forwarding of traffic through that interface.

Command Command Explanation
nameif ethernet0 outside security0 Define the name of ethernet 0 and security level.
nameif ethernet1 inside security100
nameif ethernet2 management security90
nameif ethernet3 dmz security30
nameif ethernet4 pix_failover security40 We’ve connected ethernet4 to another failover-capable PIX. The name reflects this.
nameif ethernet5 not_in_use security20 Not currently in use.
interface ethernet0 100full Identify network interface speed and duplex. Activate the interface.
interface ethernet1 100full
interface ethernet2 100full
interface ethernet3 100full
interface ethernet4 100full Identify network interface speed and duplex. Note that this interface must be set to 100 and full duplex for proper operation of failover, which may be explained in another article.
interface ethernet5 100full shutdown Note that this interface is shutdown.
ip address outside 1.1.1.1 255.255.255.0 Assign IP address and subnet mask for the interface
ip address inside 10.1.1.1 255.255.255.0
ip address management 10.2.2.1 255.255.255.0
ip address dmz 10.3.3.1 255.255.255.0
ip address pix_failover 10.4.4.1 255.255.255.0

After the PIX has been addressed, we need to think about what it is to do with the addresses of other devices. Do we wish to use Network Address Translation (NAT)? Network Address Translation (NAT) lets your network have any IP addressing scheme and the firewall protects these addresses from visibility on the external network. If we have global Internet addressing and do not wish to re-address our computers, we can assign NAT ID 0 within the PIX to disable NAT. Let’s assume for our sample configuration that we do wish to perform NAT. (Looking at the above diagram, we have to do NAT, network 10.0.0.0  /8 is a private address range.

We generally put a global command on each lower security interface we want our internal users to have access to, although statics can be preferable for internal-internal access (see below). The main decision (other than addressing design) is whether to use one or multiple NAT ID’s. Using unique NAT ID’s limits access to specific interfaces. Using one NAT ID is simpler and assumes the PIX will sort out which nat command (below) pairs up with which global command on which interface.

We put nat commands on the higher security interfaces, allowing users to start connections to lower security level interfaces with global commands on them. The NAT ID ties the inside addresses in the nat command to the pool of addresses in one or more global commands with the same NAT ID.

Port Address Translation is where all inside addresses appear as one outside address, with shifted ports. PAT has some restrictions, for example it cannot support H.323 or caching nameserver use, so you may want to use it to augment a range of global addresses rather than using it as your sole global address.

Let’s see what that looks like:

global (outside) 1 1.1.1.51-1.1.1.100 netmask 255.255.255.0 Defines the routable addresses to be used for outbound connections. This pool defines 1.1.1.51 through .100 as being available on a first come first served basis. As connections are torn down the addresses become available again for use. These addresses are used before the PAT address specified below is used. The number “1” is the NAT ID for this pool.
global (outside) 1 1.1.1.50 netmask 255.255.255.0 Defines the port address translation (PAT) address to be used by outbound connections after all one-to-one translation address (defined above) are exhausted. This continues NAT ID (pool) 1.
nat (inside) 0 access-list 101 A “NAT 0” means no NAT-ing is happening. This entry is used for the IPsec connection defined in the configuration. The nat command with access list lets you exempt traffic that is matched by the access-list command statements from the NAT services. Access list 101 (not shown) specifies IPsec traffic. This row may confuse users and if we are not going to touch IPsec now, I would leave it out. We’ll cover IPsec on the PIX in a future article.
nat (inside) 1 10.1.1.0 255.255.255.0 0 0 This command connects the global pool 1 to the networks allowed to tap into that pool. Subnet 10.1.1.0 on the inside interface will be allowed to use global pool 1 for its outbound connections.The nat command lets you enable or disable address translation for one or more internal addresses. The nat command will disable nat for an inside network if that net is not explicitly defined to use the pool. Address translation means that when a host starts an outbound connection, the IP addresses in the internal network are translated into global addresses.
nat (management) 1 10.2.2.0 255.255.255.0 0 0 Subnet 10.2.2.0 on the management interface will be allowed to use global pool 1 for its outbound connections.

Note that if acl 101 is undefined, no IPsec traffic will match and no traffic will go through the IPsec tunnel. All traffic would then be subjected to NAT.

If you’ve used NAT before, you’ll recognize that servers on the inside that need to be connected to from the outside will need static mappings. The static command creates a permanent mapping (called a static translation slot or “xlate”) between a local IP address and a global IP address. Use the static and access-list commands when you are accessing an interface of a higher security level from an interface of a lower security level. When NAT exists between two interfaces the command takes the form of “static (high,low) low high” . Without address translation, the format of the static command becomes different: “static (high,low) high high“.

static (dmz,outside) 1.1.1.22 10.3.3.22 netmask 255.255.255.255 0 0 You need to specify the IP address users on the lower security interface’s network will use to access the server on the higher security level interface’s network. In this case, we make a DMZ web server at 10.3.3.22 accessible as outside address 1.1.1.22.
static (inside,management) 10.1.1.13 10.1.1.13 netmask 255.255.255.255 0 0 This static command allows traffic from inside interface (address 10.1.1.13) to management subnet, or vice versa if an appropriate ACL exists for traffic coming from the lower security interface. There is no NAT change to the address.

We also need some static routing, so the PIX knows which subnets are out which interface. Like Cisco routers, the PIX does know how to route to connected subnets, so you only have to specify subnets or address ranges behind other routers. You can only have one default route for the PIX Firewall.

route outside 0.0.0.0 0.0.0.0 1.1.1.254 1 Specifies a default route out the outside interface to a router at 1.1.1.254 which is 1 hop away.
route management 10.117.220.0 255.255.255.0 10.2.2.254 Specifies a route to the 10.117.220.0 network via the management interface with the next hop address set to 10.2.2.254 (assuming 10.117.220.0 is behind a router on the management subnet).


TIP: If you use statics you will also be able to go from higher to lower without having to use nat and global.  Example: suppose management station 10.2.2.2 (NMS) needs to talk to serv1 at 10.1.1.15 on the inside. Configure:

static (inside,management) 10.1.1.15 10.1.1.15 netmask 255.255.255.255
access-list from-management-coming-in permit tcp host 10.2.2.2 host 10.1.1.15 eq 8888
access-group from-management-coming-in in interface management

Because the static exists, 10.1.1.15 can also inititate connections to 10.2.2.2 but cannot talk to 10.2.2.50 (NMS2) because no method of translation exists.

Another example:

static (inside,management) 10.1.1.0 10.1.1.0 netmask 255.255.255.0

This allows each network to address the other. The inside can then talk to everything on the management net and reply packets are let back through by virtue of stateful inspection but an ACL must exist for the management net to initiate anything to the inside.

There are some other variations one can do, but statics are more clear and you can predict behaviour because no timeouts for the connections exist and you still retain ultimate control via the ACL.