Posts Tagged ‘firewall’

Aug
25

The first portion of INE’s new CCIE Security Advanced Technologies Class for the 3.0 blueprint is now available in both streaming and download formats.  Subscribers to the All Access Pass already have access to this new course, and can upgrade to the download version for $159.  Non-subscribers can purchase the standalone download for $299, or subscribe to the AAP for just $159 per month.  Customers who have access to previous versions of the CCIE Security ATC will get access to the new streaming version at no extra charge.

The current release of the class contains the first 18 hours of videos.  New videos will be posted incrementally over the next few weeks, to bring the final runtime somewhere between 40 and 60 hours.  Specifically the following topics are covered in this first portion of the release:
Continue Reading

Tags: , , , ,

Aug
09

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.
Continue Reading

Tags: , , , , ,

Jun
23

INE is proud to announce the upcoming release of the following new additions to our All Access Pass Video-on-Demand library:

  • CCNA Security - Implementing Cisco IOS Network Security (640-553 IINS)
  • CCNP Security - Securing Networks with Cisco Routers and Switches (642-637 SECURE v1.0)
  • CCNP Security - Deploying Cisco ASA Firewall Solutions (642-617 FIREWALL v1.0)
  • CCNP Security - Deploying Cisco ASA VPN Solutions (642-647 VPN v1.0)
  • CCNP Security - Implementing Cisco Intrusion Prevention System v7.0 (642-627 IPS v7.0)
  • CCIE Security Advanced Technologies Class for Blueprint v3.0
  • CCIE Service Provider Advanced Technologies Class for Blueprint v3.0

All of these classes will be delivered by me, Brian McGahan – 3 x CCIE #8593.  Release dates for the CCNA Security and CCNP Security videos will be early and late July 2011 respectively.  The CCIE Security Advanced Technologies Class will be running as a live online class from July 25th – July 29th 2011, with an estimated release date of August 5th 2011 for the videos.  The CCIE Service Provider Advanced Technologies Class will be running as a live online class from August 29th – September 2nd 2011, with an estimated release date of September 9th 2011.

Subscribers to the All Access Pass will have immediate access to the streaming videos as they become available, and can attend the live online sessions of CCIE Security ATC and CCIE Service Provider ATC at no additional charge.  Seating is limited for the live class sessions, so contact sales@ine.com as soon as possible if you are interested in attending.  Download versions of each of the classes will be available for purchase as a standalone product, or as a discounted upgrade for AAP subscribers.

We will also releasing a new CCNA course delivered by Brian Dennis – 5 x CCIE #2210, and both CCNA Voice & CCNP Voice courses delivered by Mark Snow – 2 x CCIE #14073.  More details about these releases will be available soon.

 

Tags: , , , , ,

Sep
25

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.

marvin_9-25[1]

  Continue Reading

Tags: , , ,

Apr
19

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.
Continue Reading

Tags: , , ,

Jan
10

I. Security Fundamentals

a. Why Needed?

i. A closed network allows no connection to a public network; although security is still an issue due to a majority of attacks coming from inside networks today

Continue Reading

Tags: , , , , ,

Sep
29

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.

Tags: , , , ,

Sep
28

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.

Tags: , , , ,

Sep
27

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!

PIX/ASA 7.2

AAA

debug radius
debug tacacs
show aaa-server protocol PROTOCOL_NAME
test aaa-server

Access Control Lists

show access-list
show run | include ACCESS_LIST_NAME
show run object-group
show run time-range

Application Inspection

show conn state STATE_TYPE detail
show service-policy

Configuring Interfaces

show firewall
show int
show int ip brief
show ip
show mode
show nameif
show run interface INTERFACE_NAME
show version

Connections and Translations

clear xlate
show conn
show conn detail
show local-host all
clear local-host all (clears all connections)
show log
show run | begin policy-map
show run global
show run nat
show xlate
test regex

Failover

debug fo rxip
debug fo txip
show failover
show ip

IP Routing

deug ospf event
debug rip
show ospf database
show ospf interface
show ospf neighbor
show ospf PROCESS_ID
show ospf virtual-links
show route

Multicast

show igmp interface
show mroute
show pim interface
show pim neighbor

PKI

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

Security Contexts

show admin-context
show context
show mode

System Management

show clock
show crypto key mypubkey rsa
show logging
show ntp status
show running-config
show snmp-server statistics
show ssh sessions
show startup-config

Transparent Firewall

debug arp-inspection
debug l2-indication
debug mac-address-table
show access-list
show arp-inspection
show conn
show firewall
show mac-address-table

VPNs

debug crypto ipsec
debug crypto isakmp
show crypto ipsec sa
show crypto isakmp sa detail
show route

WebVPN

debug menu wbvpn
debug ssl cipher
show vpn-sessiondb summary
show vpn-sessiondb webvpn

Tags: , , , ,

Sep
09

This post was created using GNS3 and follows what I thought was some of the most lab and real-world relevant content from the Cisco ASA documentation in the area of IP Routing:

 

http://www.cisco.com/en/US/docs/security/asa/asa72/configuration/guide/ip.html

 

Here is the topology used:

 The Topology

 

Initial Setup

First, we place the necessary IP configurations on the devices for our initial connectivity:

R0:
en
conf t
host R0
line con 0
exec-time 0 0
logg synch
!
int fa0/0
no shut
ip address 192.168.1.100 255.255.255.0
end
R1:
en
conf t
host R1
line con 0
exec-time 0 0
logg synch
int fa0/0
no shut
ip address 10.10.10.100 255.255.255.0
!
interface loopback 20
ip address 10.10.20.100 255.255.255.0
end
R2:
en
conf t
host R2
line con 0
exec-time 0 0
logg synch
int fa0/0
no shut
ip address 172.16.1.100 255.255.255.0
end
FW0:
en
conf t
host FW0
!
int e0
ip address 192.168.1.1 255.255.255.0
nameif outside
no shut
!
int e1
ip address 10.10.10.1 255.255.255.0
nameif inside
no shut
!
int e2
ip address 172.16.1.1 255.255.255.0
nameif DMZ
security-level 50
no shut
!
end

At this point, I will be sure to ping each connected router from the PIX to ensure IP connectivity. Remember, by default you can ping from the PIX and to the PIX, but you cannot ping through the PIX.

Static Routing

First, I will create a simple static route to the “remote” loopback network that I have created on R1. Notice that to create a static route we simply use the route command, followed by the interface name, then the network and mask, and finally the next hop. Notice how similar this is to the syntax for a static route on a router, although one major difference is the command does not begin with ip.

FW0:
conf t
route inside 10.10.20.0 255.255.255.0 10.10.10.100
end  

Verification of this static route can be accomplished with a show route and a ping of the remote destination address 10.10.20.100.

Default Static Routing

In order to configure a default static route, use the route command but with an all 0′s network prefix and mask. The PIX/ASA allow a shortcut of 0 and 0 to represent 0.0.0.0 and 0.0.0.0. Here I configure a default static route pointing to our outside router.

FW0:
conf t
route outside 0 0 192.168.1.100
end

Verification for this configuration is a quick show route. The PIX/ASA should now show a gateway of last resort and the static route should be marked as a candidate default.

Static Route Tracking

An issue with the static route we just configured is the fact that if the destination gateway of last resort is down, the route is not removed from the routing table. This issue can be circumvented with the static route tracking capability.

First, I use the Cisco IOS IP Service Level Agreements (SLAs) monitor feature to track the availability of the gateway. This is done with the following commands:

FW0:
conf t
sla monitor 1
type echo protocol ipIcmpEcho 192.168.1.100 interface outside
exit
sla monitor schedule 1 life forever start-time now
end

Notice these commands instruct the SLA monitor to ping the gateway starting now and to do this forever. I picked an SLA_ID of 1 to bind these commands together.

Next, I will associate a tracked static route with the SLA monitoring process using the following commands. Notice here that I have used a Track_ID of 20 and I have recreated our default static route so that it includes the Track_ID. Notice also here that the track command is tied to the SLA monitor with the SLA_ID of 1.

FW0:
conf t
track 20 rtr 1 reachability
route outside 0 0 192.168.1.100 track 20
end

A nifty verification at this point is to move to R0 (the gateway of last resort) and run debug ip icmp. You will find that this router is being pinged every minute by the firewall now as a reachability test.

Next, I create a backup default static route. This is simply another default static route entry that possesses a higher administrative distance than the original static default route:

FW0:
conf t
route outside 0 0 192.168.1.55 22

For verification, you can shut the interface on the default gateway and run a show route on the PIX/ASA to ensure the backup is installed.

Dynamic Routing – OSPF

Now it is time to tackle a dynamic routing protocol configuration. Here I configure an MD5 authenticated neighborship between R2 and FW0. Notice that the network command on the PIX/ASA requires a subnet mask as opposed to a wildcard mask.

R2:
conf t
router ospf 1
network 172.16.1.100 0.0.0.0 area 0
!
interface fastethernet 0/0
ip ospf authentication message-digest
ip ospf message-digest-key 1 md5 cisco
!
end
FW0:
conf t
router ospf 1
network 172.16.1.1 255.255.255.255 area 0
!
interface e2
ospf authentication message-digest
ospf message-digest-key 1 md5 cisco
!
end

For verification, simply run show ospf neighbor on FW0.

Dynamic Routing – RIP version 2

Next, we will run RIP version 2 on the PIX/ASA and advertise the DMZ subnet to the internal router R1. Here are the configurations:

R1:
conf t
router rip
version 2
no auto-summary
passive-interface default
network 10.0.0.0
no passive-interface fa0/0
end
FW0:
conf t
router rip
version 2
no auto-summary
network 172.16.0.0
network 10.0.0.0
end

 Verification for RIP in this example would include show ip route on R1 and debug rip on FW0.  

Conclusion

I certainly hope you have enjoyed this blog on IP routing with the PIX/ASA. While my goal was to hit the highlights, please keep in mind the fact that there are many features of the dynamic routing protocols that are available and not covered here. In fact, there are even some static routing features that were omitted in this discussion. Just remember that these features should be very easy to find in the documentation link when you are in the heat of battle.

Tags: , , , ,

Categories

CCIE Bloggers