Posts from ‘PIX/ASA Firewall’
INE is proud to announce the upcoming release of our new CCIE Security Advanced Technologies Class and CCIE Security 5-Day Bootcamp. The 5-Day Bootcamp will be available in streaming and download format starting this weekend, followed shortly by the Advanced Technologies class. Both of these video series are included with the All Access Pass subscriptions, or can be purchased as standalone downloads. Samples of both classes are available below.
For Part 2 of this series, click here.
The following questions will be added to the Core Knowledge Simulation engine. Answers will be provided in the comments section.
Implement Identity Management
Refer to the diagram. The software running on the PC performs what role? Continue Reading
After returning from vacation, Bob (the optimistic firewall technician) decided that he wanted to take some time and get a little bit more familiar with firewall configuration. He was able to get permission to use some spare equipment for practice.
It was a dark, cold night in late December, and Bob, (the optimistic firewall technician), had a single ASA to deploy before going home for the holidays. The requirements for the firewall were simple. Bob read them slowly as follows:
- R1 should be able to ping the server “Radio.INE.com” by name.
- PC should be able to ping the server “Radio.INE.com” by name.
Bob also read the background information to see if this was something he could finish before leaving the office. Bob read the following:
Modular Policy Framework (MPF) configuration defines set of rules for applying firewall features, such as traffic inspection, QoS etc. to the traffic transiting the firewall. MPF has many similarities to MQC (Modular QoS CLI) syntax found in Cisco IOS, but there are some major differences in the flow of operations, even though many commands look the same. The following post assumes basic understanding of ASA firewall and its configuration. It covers the basic logic of the MPF, but does not go over all firewall features in depth.
as promised before, we posted the initial update to our Security Workbook VOL1 matching new new CCIE Security v3.0 blueprint. It covers the “ASA Firewall” section of the lab exam blueprint and contains 50 technology focused mini-scenarios. All customers with active subscription to the existing version of IEWB-SC VOL1 should see the new material under their members site accounts. The new content has been rewritten from scratch, with the task wording changed along with breakdowns, comments and explanatins added. You will see the mini-labs presented in “challenging” format, matching our new philosophy for the updated line of CCIE products. Of course, there are new scenarios covering the updated CCIE Security lab blueprint. If you are wondering why we jumped from version 3.2 to v5.0, there are few good reasons. Firstly, it symbolizes the unified design philosophy of our RS and SC products as the most recent version of RS products is v5.0. Secondly, you should remember how they jumped to IPv6 from IPv4. We thought that’s a good idea too. And last, but not least – Cisco did the same trick to their line of unified communication products!
Finally, Here is the list of topics covered in this update. The highlighted topics correspond to the completely new scenarios added to the section. Notice however, that all other tasks have been completely updated as well! Happy studying!
What in the world is a bogon? It is a source address that should not appear in an IP packet on an interface that faces the public Internet. A very famous example of a bogon address would be the Private IP address space, as defined in RFC 1918. This address space is as follows:
What would be another example of a bogon address? How about the “link-local” addresses that a system will use to communicate on the local link in the event of DHCP failure. This address space is 169.254.0.0/16.
So bogons consist of special use addresses and any other portions of the address space that has not been allocated for public use. This list of addresses is not static, and does change over time. These addresses are excellent entries in your filters (access control lists) for interfaces that face the Internet.
What is a convenient place to learn of the bogon addresses you should be most concerned with as a CCIE candidate? Well, it is none other than an RFC. It is RFC 3330. It is an excellent RFC that summarizes many of the other RFCs detailing special use address space. You can find RFC 3330 here:
As I am sure you have already seen from the blog on setting up the security device as a Layer 2 device, there are many interesting changes that occur on a PIX or ASA when configured for transparent operations. This blog highlights the major changes and guidelines that you should keep in mind when you opt for this special mode of operation.
- Number of interfaces – perhaps on of the biggest things you will want to keep in mind is the fact that you are going to be limited on the number of traffic forwarding interfaces you can use when in Layer 2 mode. When you switch to transparent mode, you are limited to the use of two traffic forwarding interfaces. On some ASA models, you may also use your dedicated management interface, but of course, the use of this port is limited for management traffic. Remember also, when in multiple context mode, you cannot share interfaces between contexts like you can when in routed mode.
- IP addressing – here is another major difference of course. In Layer 2 mode, you will assign a single IP address to the device in Global Configuration mode. This address is for remote management purposes and is required before the device will forward traffic. Once the address is assigned, all interfaces start “listening” on this address to ensure the device is responsive to its administrator. This global IP addressed assigned to the device must be in the same subnet that the forwarding interfaces are participating in. Remember, the transparent firewall is not adding a new network (subnet) to your topology.
- Default gateway – for traffic sourced from the security device itself, you can configure a default gateway on the transparent device. You can do this with the route 0 0 command.
- IPv6 support - the transparent firewall does not support IPv6.
- Non-IP traffic – you can pass non-IP traffic through the Layer 2 Mode device. Note that this is not possible on a security appliance in its default Layer 3 mode.
- More unsupported features – the Layer 2 mode device does not support – Quality of Service (QoS) or Network Address Translation (NAT).
- Multicast – the transparent mode device does not offer multicast support, but you can configure Access Control Lists (ACLs) in order to pass multicast traffic through the device.
- Inspection – with the Layer 2 mode device you can inspect traffic at Layer 2 and above. With the classic routed mode configuration, you can only inspect at Layer 3 and above.
- VPN support – the transparent mode device does support a site to site VPN configuration, but only for its management traffic.
This blog will examine the basic setup of the transparent firewall feature available with the PIX and the ASA. This blog was based on the PIX-525 running 7.2(4) code with a Restricted license in GNS3. Here is the topology that was used:
Remember, that a transparent firewall resides WITHIN a subnet and is easy to implement in an existing network where re-addressing to introduce a firewall might be difficult. This configuration is sometimes known as a “stealth” firewall or a “bump on the wire”. Thanks to the fact that the firewall lives within the subnet, instead of between it, the device has the ability to filter traffic between hosts within the subnet. Note that the traditional Layer 3 firewall can only filter traffic moving between subnets. This should remind you of the difference between a VLAN Access Control List versus a Router-based Access Control List.
Well, with the introductions out of the way, let’s do what we love best, let’s get to the command line.
The first thing I will do is configure and verify the transparent firewall feature and then name our PIX:
pixfirewall> en Password: pixfirewall# conf t pixfirewall(config)# firewall transparent pixfirewall(config)# show firewall Firewall mode: Transparent pixfirewall(config)# hostname LAYER2FIREWALL LAYER2FIREWALL(config)#
Excellent, now that the firewall is in transparent mode, let’s take care of the inside and outside interfaces. When in transparent mode, you are limited to the use of two interfaces for passing traffic. Notice how the interfaces are not configured with IP addresses.
LAYER2FIREWALL(config)# int e1 LAYER2FIREWALL(config-if)# nameif inside INFO: Security level for "inside" set to 100 by default. LAYER2FIREWALL(config-if)# no shut LAYER2FIREWALL(config-if)# exit LAYER2FIREWALL(config)# int e0 LAYER2FIREWALL(config-if)# nameif outside INFO: Security level for "outside" set to 0 by default. LAYER2FIREWALL(config-if)# no shut LAYER2FIREWALL(config-if)# sh int ip brief Interface IP-Address OK? Method Status Protocol Ethernet0 unassigned YES unset up up Ethernet1 unassigned YES unset up up Ethernet2 unassigned YES unset administratively down up Ethernet3 unassigned YES unset administratively down up Ethernet4 unassigned YES unset administratively down up
I am sure this output looks a little strange for those of you that have not played with this feature. Just as unusual is the fact that all of the interfaces facing this device are addressed in the 10.0.0.0/24 subnet.
A requirement of the transparent firewall is that it must have an IP address assigned in global configuration mode for management access. Notice for verification we can see that our traffic forwarding interfaces are now “listening” on that IP address:
LAYER2FIREWALL(config)# ip address 10.0.0.22 255.255.255.0 LAYER2FIREWALL(config)# sh int ip brief Interface IP-Address OK? Method Status Protocol Ethernet0 10.0.0.22 YES unset up up Ethernet1 10.0.0.22 YES unset up up Ethernet2 unassigned YES unset administratively down up Ethernet3 unassigned YES unset administratively down up Ethernet4 unassigned YES unset administratively down up
Let us now test the “out of the box” functionality of the security device. I will initiate a Telnet session from the Inside interface to a device located on the Outside interface. This communication should be permitted due to the Adaptive Security Algorithm and the default security levels on our interfaces. Notice how we can easily verify the connection of the appliance.
R1#telnet 10.0.0.10 Trying 10.0.0.10 ... Open User Access Verification Password: R0> LAYER2FIREWALL(config)# show conn 1 in use, 1 most used TCP outside 10.0.0.10:23 inside 10.0.0.1:25501, idle 0:00:03, bytes 102, flags UIO
Let’s now permit Telnet connections from our management workstation (played by R2) and ensure we have connectivity to the PIX.
LAYER2FIREWALL(config)# telnet 10.0.0.20 255.255.255.255 Inside
R2#telnet 10.0.0.22 Trying 10.0.0.22 ... Open User Access Verification Password: Type help or '?' for a list of available commands. LAYER2FIREWALL>
Well, I am sure I will blog more on this Layer 2 firewall at a later point, but I sure do thank you for stopping by to read this initial post.
Thanks to Anisha with Cisco Systems for this idea. We were in Brian McGahan’s CCIE Security 5 Day Bootcamp, and she realized it would be nice to have a Quick Ref of his troubleshooting/verification commands. There is a bazillion shows and debugs it seems, but you only need a subset to be successful in the lab. Here is the first part of the “cheat sheet”. The rest will follow in the respective categories in the blog. Please let me know via comment if you see errors or have additions. I added to Brian’s classroom commands with some of my own. I also took a few from the Cisco Press ASA All-In-One Guide. It is an excellent text for your Kindle!
show aaa-server protocol PROTOCOL_NAME
Access Control Lists
show run | include ACCESS_LIST_NAME
show run object-group
show run time-range
show conn state STATE_TYPE detail
show int ip brief
show run interface INTERFACE_NAME
Connections and Translations
show conn detail
show local-host all
clear local-host all (clears all connections)
show run | begin policy-map
show run global
show run nat
debug fo rxip
debug fo txip
deug ospf event
show ospf database
show ospf interface
show ospf neighbor
show ospf PROCESS_ID
show ospf virtual-links
show igmp interface
show pim interface
show pim neighbor
debug crypto ca messages
debug crypto ca transactions
show crypto ca certificates
show crypto ca crls
show crypto key mypubkey rsa
Quality of Service
show priority-queue statistics
show run class-map
show run policy-map
show service-policy global
show service-policy interface INTERFACE_NAME
show service-policy priority
show service-policy shape
show crypto key mypubkey rsa
show ntp status
show snmp-server statistics
show ssh sessions
debug crypto ipsec
debug crypto isakmp
show crypto ipsec sa
show crypto isakmp sa detail
debug menu wbvpn
debug ssl cipher
show vpn-sessiondb summary
show vpn-sessiondb webvpn