Cisco PIX Firewalls: Access Lists and

Management
Peter J. Welcher and Grant Moerschel
Introduction
This month we continue a series of articles on the PIX. Our first article, which covers PIX basics, can
be found at http://www.netcraftsmen.net/welcher/papers/pix01.html . The present article takes a look
at access lists for the PIX, and finishes with some coverage of how to manage the PIX.
The online reference materials for configuring Cisco PIX Firewall Version 6.1 are at the URL
http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_61/index.htm . Please look there for
the details we had to omit in this article. 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 Do I Need Access Lists For?
When we set up paired nat and global commands, as in the last article, the PIX does NAT or PAT
address translation. It also does stateful inspection, whereby outbound (or higher- to lower- security
connections) can be established. Connections cannot be established in the inbound (or low- to high-
security) direction.
Access lists provide for exceptions to this.
One consequence of all this that usually baffles people is that PING from low-security to high-security
interfaces doesn't work without ACL's. We need to apply some simple access lists to fully test
connectivity through the PIX.
Here's our lab diagram again, this time with a full set of addresses:
Cisco PIX Firewalls: Access Lists and Management http://www.netcraftsmen.net/welcher/papers/pix02.html
1 of 8 1/2/03 9:57 AM
Suppose we configure the following into the PIX:
access-list ping_acl permit icmp any any
access-group ping_acl in interface dmz
access-group ping_acl in interface outside
access-group ping_acl in interface management
Then (with the previous configuration in the PIX as well) we should be able to ping through the PIX,
for example from the inside net to NMS, web server, FTP server, Internet router inside interface, and
some general Internet site. And also PING between the other possible combinations of two of these.
(Well, you probably can't PING from a random Internet set back into your net.) This can be a good
temporary test to ensure routing and NAT are configured correctly. You then would remove the ACL
from the interfaces with
no access-group ping_acl in interface dmz
no access-group ping_acl in interface outside
no access-group ping_acl in interface management
Troubleshooting
At this point, it might be appropriate to mention other aspects of troubleshooting your basic PIX
configuration. See
http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_61/config/bafwcfg.htm#xtocid25 .
(We see no point to creating our own version of clear, brief material already available to you.)
Cisco PIX Firewalls: Access Lists and Management http://www.netcraftsmen.net/welcher/papers/pix02.html
2 of 8 1/2/03 9:57 AM
One good suggestion is that you get the basics working and connected and PING tested. Then put in
static commands and access lists and confirm you can reach the static hosts. We are big fans of building
up configurations in incremental steps and testing at each stage. Then you have some idea which
commands might have broken things!
ACL Syntax
We've assumed you might already be able to und erstand ACL syntax, since it is so much like Cisco
IOS syntax. In general, you configure:
access-list aclname action protocol source_address port
destination_address port
where action is permit or deny.
ACL Examples
In our lab "real world" example, we might build access lists as follows. The first might be an access list
named from-outside-coming-in to permit outside traffic inbound.

access-list from-outside-coming-in
permit icmp any any time-exceeded
permit ICMP network diagnostic messages (TTL
exceeded)
access-list from-outside-coming-in
permit icmp any any unreachable
permit ICMP network diagnostic messages
(unreachables, allows for Path MTU Discovery)
access-list from-outside-coming-in
permit tcp any host EXTERNALSMTPHOST
eq smtp
permit SMTP traffic from anywhere to the SMTP mail
host (if we have one)
access-list from-outside-coming-in
permit tcp any host
EXTERNALWWWHOSTNAME eq www
permit port 80 traffic from anywhere to the Web server
access-list from-outside-coming-in
permit tcp any host
EXTERNALWWWHOSTNAME eq 443
permit port 443 traffic from anywhere to the Web
server, assuming our Web server is also responding on
port 443
access-list from-outside-coming-in
deny ip any any
Denies all other traffic. Note that replies to traffic that
originated from the inside will be allowed in. This is
implicit at the end of an ACL anyway, but we made it
explicit for clarity.
access-group from-outside-coming-in
in interface outside
Bind the ACL to an interface. The access list will be
applied to traffic inbound to the outside interface (we
used the keyword "in").
Packets on the specified interface (outside) going in the specified direction (inbound) are matched
against the ACL, working from the top down. When the packet matches, permit means it is allowed
through. Deny means the packet is discarded. In this case, PIX Firewall discards the packet and
generates the following syslog message:
%PIX-4-106019: IP packet from source_addr to destination_addr, protocol
protocol received from interface interface_name deny by access-group
acl_ID.
Cisco PIX Firewalls: Access Lists and Management http://www.netcraftsmen.net/welcher/papers/pix02.html
3 of 8 1/2/03 9:57 AM
Question for the reader: what statement(s) are missing from the above ACL? There is at least one
more form of traffic we need to allow in!
We might also use an ACL to permit some connectivity between the management net and the inside
net. We've called this ACL from-managementzone-coming-in .

access-list from-managementzone-coming-in permit tcp
10.2.2.0 255.255.255.0 10.1.1.0 255.255.255.0 eq
telnet
Permit telnet traffic from the
10.2.2.0 management net to the
10.1.1.0 inside net.
access-list from-managementzone-coming-in permit udp
10.2.2.0 255.255.255.0 10.1.1.0 255.255.255.0 eq
snmp
Permit snmp traffic from the
10.2.2.0 management net to the
10.1.1.0 inside net.
access-list from-managementzone-coming-in permit
icmp any any
Permit all ICMP traffic from any
net attached to the management
interface to any other net.
access-list from-managementzone-coming-in deny ip
any any
Deny all other traffic originating
from the management net side
going towards the PIX.
access-group from-managementzone-coming-in in
interface management
Bind the ACL to an interface.
This latter may seem a little contrived. Grant likes to have some sort of ACL on every interface for
consistency. Because of that, you do need to define what traffic can go through. It is a lower to higher
security situation so the ACL is needed anyway. One might view this as not so much a trust issue as
one of explicit control and flow.
Note that SNMP is stateful (default: 2 minutes; TCP default 60 minutes). So replies can come back
from the WWW and FTP servers to the NMS.
Access lists are not normally needed on the inside interface because it is a higher security interface than
all other interfaces and is by default trusted. An ACL named from-insidezone-coming-in might be
used to keep our inside users from doing outbound FTP.

access-list from-insidezone-coming-in deny ip
any any ftp
Denies FTP from the inside network going
toward the PIX.
access-list from-insidezone-coming-in permit
icmp any any
Permits ICMP from the inside to
anywhere.
access-list from-insidezone-coming-in permit
ip any any
Permits all other IP traffic from the inside
to anywhere
access-list from-insidezone-coming-in deny ip
any any
Denies all other traffic. Implicit but added
for clarity.
access-group from-insidezone-coming-in in
interface inside
Bind the ACL to an interface.
And an ACL named from-dmz-coming-in allows DMZ hosts to initiate very selective connections to
higher security level interfaces, if there is a corresponding static statement. If we create static
statements for internal DNS, Oracle, and NTP servers, then for each server ("DMZHOST") in the
DMZ, we might configure something like the following:
Cisco PIX Firewalls: Access Lists and Management http://www.netcraftsmen.net/welcher/papers/pix02.html
4 of 8 1/2/03 9:57 AM

access-list from-dmz-coming-in permit udp host
DMZHOST host INTERNALDNSHOST eq domain
This entry allows DNS lookups from the
dmz host to an internal DNS server.
access-list from-dmz-coming-in permit tcp host
DMZHOST host INTERNALORACLEHOST eq 1521
This entry allows SQLnet connections
from the dmz host to an internal Oracle
server.
access-list from-dmz-coming-in permit udp host
DMZHOST host INTERNALNTPHOST eq ntp
This entry allows NTP connections from
the dmz host to an internal NTP server.
access-group from-dmz-coming-in in interface
dmz
Bind the ACL to an interface.
In our example lab picture, this might result in something like:
access-list from-dmz-coming-in permit udp host 10.3.3.22 host DNSHOST eq
domain
access-list from-dmz-coming-in permit tcp host 10.3.3.22 host ORACLEHOST
eq 1521
access-list from-dmz-coming-in permit udp host 10.3.3.22 host NTPHOST eq
ntp
access-list from-dmz-coming-in permit udp host 10.3.3.30 host DNSHOST eq
domain
access-list from-dmz-coming-in permit udp host 10.3.3.30 host NTPHOST eq
ntp
access-group from-dmz-coming-in in interface dmz
We've left names for the internal DNS, Oracle, and NTP servers, since the addresses aren't visible in
our diagram above. This assumes the Web server need to access the Oracle server via SQL, and that
the FTP server does not. It implies that we trust our web server with SQL access to a selected internal
Oracle server. The internal Oracle server might be in a high-security segment, perhaps firewalled from
the rest of the inside so that if it is somehow compromised, the hacker still would not have access to
anything else. (As if losing your database isn't bad enough!)
The long names for the ACL's get a bit clumsy, but we find them useful for keeping track of the
purpose of the ACL and the direction in which it is intended to be applied.
Telnet Access
It seems appropriate to finish out the balance of this article with some tips on managing the PIX.
If you wish to allow telnet to the PIX, you need to configure which hosts are allowed in. To allow a
single host to telnet in via the inside interface:
telnet 10.1.1.100 255.255.255.255 inside
To allow any station on subnet 10.1.1.0 /24 to telnet in via the inside interface:
telnet 10.1.1.0 255.255.255.0 inside
If you have a host on the management segment that is allowed to telnet to the PIX, you might also
want:
telnet 10.2.2.100 255.255.255.255 management
Cisco PIX Firewalls: Access Lists and Management http://www.netcraftsmen.net/welcher/papers/pix02.html
5 of 8 1/2/03 9:57 AM
You do need to consider the security of using telnet. Telnet compromises your passwords and the data
of your entire session by sending it in clear over the network. So you might wish to use Secure Shell
(SSH) instead which encrypts the passwords and the data. In order to use SSH, you need to have a
DES (free) or 3DES (at cost) license activation key and execute a few commands as follows:

hostname Killroy
Assigns a hostname to your PIX
domain-name
yourcorp.com
This entry sets the domain name for the PIX and is necessary for the
subsequent commands.
ca generate rsa key
1024
Causes the PIX to generate an RSA public and private key pair with a
modulus (complexity)
size ranging from 512 to 2048 bits.
ca save all
Causes the PIX to save CA related information in a more secure persistant
data file in flash memory.
Once you have generated and saved the keys, you can specify which SSH hosts will be connecting to
the PIX through a specified interface. The configuration is very similar to Telnet configuration:
ssh 10.1.1.100 255.255.255.255 inside
See the documentation for how to obtain an SSH client:
http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_61/cmd_ref/s.htm#xtocid19 .
Syslog on PIX
The PIX provides Cisco IOS-like syslog logging capabilities, although the Configuration Guide
certainly doesn't say very much about this. (Look for the logging command in the Command
Reference.) This includes the ability to repackage console/syslog messages and send them as SNMP
traps to a management station. (We do not recommend this, the volume of traffic can be considerable.)
The syntax is mildly different from Cisco IOS on a couple of the commands. The recommendation is
that you do not enable console logging.
A sample configuration:

no logging console
disable logging to the console
logging buffered info
set to log to buffer at severity level "info" (all but
debug messages)
logging timestamp
add timestamps to log messages
logging host management 10.2.2.100
send messages to syslog on the NMS at
10.2.2.100 on interface "management"
logging trap info
send all but debug messages to the NMS and any
other syslog receivers
logging monitor error
display the more severe messages (levels 0-3) to
any terminal monitoring sessions
After configuring this, you could use show logging to examine your settings and see messages stored
in the buffer. Telnet users of course type terminal monitor to see copies of syslog messages.
Cisco PIX Firewalls: Access Lists and Management http://www.netcraftsmen.net/welcher/papers/pix02.html
6 of 8 1/2/03 9:57 AM
The logging standby command causes logging of messages from an inactive failover PIX. This
doubles your message volume, but does insure synchronization of messages should failover occur.
SNMP
For security, all SNMP to the PIX is read-only. The commands are a very limited subset of what's in
Cisco router IOS software (which is arguably a Good Thing). Sample configlet:
snmp-server community public
snmp-server contact John Doe, XYZ Corp Network Admin, 543-123-4567
snmp-server location Corporate Building 1234
snmp-server host management 10.2.2.100
no snmp-server enable traps
You can put traps or poll at the end of the snmp-server host line, if the NMS is only allowed to be sent
traps, or to allow the NMS to conduct polling of the PIX but not be sent traps.
The Reference manual says the no snmp-server enable traps command disables sending traps by
syslog. (We think this is the best choice here.) If you do send syslog messages as SNMP traps, use the
logging history l evel command to specify which severity levels get sent.
See the Command Guide for some idea of good SNMP MIB variables to monitor to help you manage
your PIX. You can track failover status, memory, connection statistics, and system buffer usage via
SNMP.
PDM
In our opening article on the PIX, we mentioned PDM. Cisco PIX Device Manager (PDM) is a
browser-based tool that lets you set up, configure, and monitor your PIX Firewall via a graphical user
interface (GUI). The point is, you don't need to deal with the PIX command line, so PDM can be a
really good way to get started with your first PIX. PDM works with browsers on Windows NT, 95,
2000, or Solaris. When you enable PDM on the PIX, access is limited to specified client systems within
the inside network and is password protected. PDM runs HTTP over SSL for additional security.
The PDM FAQ can be found at http://www.cisco.com/warp/customer/110/41.shtml .This page seems
to suggest the product might have once been PFM (PIX Firewall Manager).
PDM can be downloaded from http://www.cisco.com/cgi-bin/tablebuild.pl/pix . Follow the directions
at http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_60/pdm_in/upgrade.htm to upgrade
PDM. You do need an activation key allowing you to run DES or 3DES, which PDM uses for SSL.
See also http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_60/pdm_in/install.htm .
Sample configuration to support PDM, once you've loaded PDM into flash:
http server enable
http 10.2.2.100 255.255.255.255 management
There are several documented internal PDM commands, all starting with pdm.
Conclusion
Cisco PIX Firewalls: Access Lists and Management http://www.netcraftsmen.net/welcher/papers/pix02.html
7 of 8 1/2/03 9:57 AM
We hope this article has helped make you feel a little more comfortable with the PIX. If you have a
PIX, we hope it has given you some useful ideas on how to tweak your configuration.
Dr. Peter J. Welcher (CCIE #1773, CCSI #94014) is a Senior Consultant with Chesapeake
NetCraftsmen. NetCraftsmen is a high-end consulting firm and Cisco Premier Partner dedicated to
quality consulting and knowledge transfer. NetCraftsmen has nine CCIE's, with expertise including
large network high-availability routing/switching and design, VoIP, QoS, MPLS, network
management, security, IP multicast, and other areas. See http://www.netcraftsmen.net for more
information about NetCraftsmen. Pete's links start at http://www.netcraftsmen.net/welcher . New
articles will be posted under the Articles link. Questions, suggestions for articles, etc. can be sent to
pjw@netcraftsmen.net .
Grant P. Moerschel (CCNP #CSCO10108676) works for NovatoSystems.com LLC, an Internet
security and network architecture consultancy and developers of FlackJacket security. NovatoSystems
specializes in creating multi-layered secure networks based on the Cisco SAFE blueprint. FlackJacket,
the premiere product offering of NovatoSystems, uses best-of-breed security components and
advanced reporting systems to provide your organization with greater peace of mind regarding data
protection. See http://www.flackjacket.net for more information. Questions, suggestions for articles,
etc. can be sent to gm@flackjacket.net .
4/6/2002
Copyright (C) 2002, Peter J. Welcher

Cisco PIX Firewalls: Access Lists and Management http://www.netcraftsmen.net/welcher/papers/pix02.html
8 of 8 1/2/03 9:57 AM