Meet the ASA
Finally the time has come for us to talk about a dedicated firewall device. The ASA has been around for a long time, although it has often been called the PIX firewall.
There are a number of different hardware models of the ASA, however the all behave pretty much exactly the same, with the exception of the 5505. The 5505 has an inbuilt switch model and uses VLANs rather than physical interfaces for its IP addressing and configuration. However all the same principles apply. The 5510 up to the 5585 gradually move up in terms of capacity but for all intents and purposes can be treated the same, there also exists the Firewall Services Module which is a blade which can be plugged in to a compatible switch.
I won’t go into all the features which the ASA supports, but it has all the features you would expect from an enterprise firewall.
The basics
The ASA uses the concepts of security levels which are assigned to interfaces. The security level is a number between 0 and 100 and correlates to the trust you would place in that network. By default, an interface labelled ‘inside’ will have the security level 100 while an interface labelled ‘outside’ will have the security level 0. By default (and this is very important) if a packet is coming from a higher security level interface than it is destined for (eg, going from inside to outside) that traffic will be permitted even with no matching access-list. However the inverse of this is also true, any traffic going from a lower security to a higher security interface will be blocked. We also need to remember, that just like an IOS router, there is an implicit deny at the end of every access list, so if there are no matching permit statements that traffic will be dropped.
Let’s get into the fun stuff, we’re going to remove our central router and replace it with an ASA. We’re going to playing with a 5520 running version 8.4(2) so if you’re using a 5505 at home then the commands will differ slightly, however the theory behind them remains the same.
ciscoasa(config)# hostname CentralFW
CentralFW(config)# int g2
CentralFW(config-if)# ip address 192.168.21.1 255.255.255.0
CentralFW(config-if)# nameif inside
INFO: Security level for "inside" set to 100 by default.
CentralFW(config-if)# no shut
CentralFW(config-if)# int g1
CentralFW(config-if)# ip address 172.16.31.1 255.255.255.0
CentralFW(config-if)# nameif dmz
INFO: Security level for "dmz" set to 0 by default.
CentralFW(config-if)# security-level 50
CentralFW(config-if)# no shut
CentralFW(config-if)# int g0
CentralFW(config-if)# ip address 45.45.45.1 255.255.255.0
CentralFW(config-if)# nameif outside
INFO: Security level for "outside" set to 0 by default.
CentralFW(config-if)# no shut
We can also configure the ASA to act as a DHCP server, so first let’s change the configuration of our internal device to receive their IP addresses automatically.
InternalRTR(config)#int f0/0
InternalRTR(config-if)#no ip address 192.168.21.20 255.255.255.0
InternalRTR(config-if)#ip address dhcp
CentralFW(config)# dhcpd address 192.168.21.10-192.168.21.50 inside
CentralFW(config)# dhcpd enable inside
If we go back to InternalRTR now and check it’s IP address:
InternalRTR#show ip int br
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 192.168.21.10 YES DHCP up up
We also need to define routing just like a router, so let’s define a static route to the internet:
CentralFW(config)# route outside 0.0.0.0 0.0.0.0 45.45.45.20
NAT
NAT is where things can get very confusing on the ASA. When Cisco released version 8.3 they completely rewrote the way NAT is configured on the firewall. Whilst you will be expected to know how to configure NAT on a pre 8.3 device, this blog will go over NAT configuration on the newer devices.
We want to set up NAT like we did earlier, so that when hosts on the inside access hosts on the outside, they are translated to the external interface of the firewall.
CentralFW(config)# object network InternalNet
CentralFW(config-network-object)# subnet 192.168.21.0 255.255.255.0
CentralFW(config-network-object)# nat (inside,outside) static interface
Let’s setup an SSH session from inside to outside again to verify it is working:
ExternalRTR#show users
Line User Host(s) Idle Location
* 2 vty 0 admin idle 00:00:00 45.45.45.1
Note: on a pre 8.3 ASA instead of defining the NAT as part of the object group – we would define it as line like this:
nat (inside,outside) 1 source dynamic InternalNet interface
Now we’re going to want to define some access-lists to lock down this traffic a bit better than it is currently.
CentralFW(config)# access-list inside_to_outside extended permit tcp object InternalNet any eq ssh log
CentralFW(config)# access-group inside_to_outside in interface inside
We need to be very clear with what we are permitting now, because now that we have defined an access-list for traffic entering the inside interface, all traffic that is not explicitly permitted will be dropped.
One of the great tools that comes with the ASA is the packet-tracer command which allows us to simulate traffic and see the processing steps the firewall would take as if it were a real packet. Lets try it for ssh traffic (which will be allowed) and http traffic (which will be dropped).
CentralFW# packet-tracer input inside tcp 192.168.21.10 5342 45.45.45.20 ssh detailed
Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 45.45.45.0 255.255.255.0 outside
Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group inside_to_outside in interface inside
access-list inside_to_outside extended permit tcp object InternalNet any eq ssh log
Additional Information:
Forward Flow based lookup yields rule:
in id=0xbc3236e0, priority=13, domain=permit, deny=false
hits=0, user_data=0xb9466b40, cs_id=0x0, use_real_addr, flags=0x0, protocol=6
src ip/id=192.168.21.0, mask=255.255.255.0, port=0
dst ip/id=0.0.0.0, mask=0.0.0.0, port=22, dscp=0x0
input_ifc=inside, output_ifc=any
Phase: 3
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0xbc2a6700, priority=0, domain=inspect-ip-options, deny=true
hits=12, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
input_ifc=inside, output_ifc=any
Phase: 4
Type: NAT
Subtype:
Result: ALLOW
Config:
object network InternalNet
nat (inside,outside) static interface
Additional Information:
Static translate 192.168.21.10/5342 to 45.45.45.1/5342
Forward Flow based lookup yields rule:
in id=0xbc3215e0, priority=6, domain=nat, deny=false
hits=2, user_data=0xbc3116c8, cs_id=0x0, use_real_addr, flags=0x0, protocol=0
src ip/id=192.168.21.0, mask=255.255.255.0, port=0
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
input_ifc=inside, output_ifc=outside
Phase: 5
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Reverse Flow based lookup yields rule:
in id=0xbc3055c8, priority=0, domain=inspect-ip-options, deny=true
hits=4, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
input_ifc=outside, output_ifc=any
Phase: 6
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 13, packet dispatched to next module
Module information for forward flow ...
snp_fp_tracer_drop
snp_fp_inspect_ip_options
snp_fp_tcp_normalizer
snp_fp_translate
snp_fp_adjacency
snp_fp_fragment
snp_ifc_stat
Module information for reverse flow ...
snp_fp_tracer_drop
snp_fp_inspect_ip_options
snp_fp_translate
snp_fp_tcp_normalizer
snp_fp_adjacency
snp_fp_fragment
snp_ifc_stat
Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: allow
This shows all the processing steps the firewall takes on traffic that is coming from 192.168.21.10 to 45.45.45.20 on ssh on the inside interface. Pay particular attention to Phase 2 and Phase 4, which show the ACL it is hitting, and the NAT rule. Now let’s try it for http:
CentralFW# packet-tracer input inside tcp 192.168.21.10 5342 45.45.45.20 http detailed
Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 45.45.45.0 255.255.255.0 outside
Phase: 2
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:
Forward Flow based lookup yields rule:
in id=0xbc323778, priority=11, domain=permit, deny=true
hits=0, user_data=0x5, cs_id=0x0, flags=0x0, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
input_ifc=inside, output_ifc=any
Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule
Here we see that the traffic is dropped in phase 2, because it is not specified in the ACL.
That’s a basic rundown on how to use an ASA, but of course there’s much more that can be done with them.
