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 .
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:
Suppose we configure the following into the PIX:
access-list ping_acl permit icmp any anyThen (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
access-group ping_acl in interface dmz
access-group ping_acl in interface outside
access-group ping_acl in interface management
no access-group ping_acl in interface dmz
no access-group ping_acl in interface outside
no access-group ping_acl in interface management
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!
access-list aclname action protocol source_address port destination_address portwhere action is permit or deny.
|
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.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:
|
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 domainWe'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!)
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
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.
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 insideTo 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 insideIf 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 managementYou 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 insideSee 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 .
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 |
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-server community publicYou 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.
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
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 level 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.
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 enableThere are several documented internal PDM commands, all starting with pdm.
http 10.2.2.100 255.255.255.255 management
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 .