Category Archives: CCIE Security

ASA Access Control List Basics Part 1 of 2

CCIE Security, , , , , ,

In this post – we are going to create a quick ASA topology in GNS3 and have some fun with access lists basics.

Here is our topology – I will go ahead and configure OSPF everywhere so we have full reachability. I also placed X.X.X.X loopbacks on the devices that will be nice for testing purposes. I used 3.3.3.3 on the TestPC:

Screenshot 2015-03-28 08.46.12If you are wondering what those hubs are all about – I read somewhere that they are the least finicky when it comes to getting the ASA to speak to the devices on the network. I know direct connections and the Ethernet Switch in GNS3 are both buggy. I cannot wait for VIRL to feature the ASA in April 2015.

So we better start with a basic sanity check. Lets try and Telnet from the inside (R1) to the outside (R2). We expect this to work of course thanks to the inspection of TCP and UDP traffic by the ASA with its default rules in place:

R1#telnet 2.2.2.2
Trying 2.2.2.2 ... Open
User Access Verification
Password:
R2>

Well – that worked great – did the ASA inspect it? Let’s check:

ASA1# show conn detail
7 in use, 10 most used
...
TCP outside:2.2.2.2/23 inside:10.10.10.1/64631,
flags UIO, idle 57s, uptime 59s, timeout 1h0m, bytes 102
ASA1#

Yes indeed.

Now – let’s say we want R1 to be able to ping R2. This is not possible by default. Let’s punch a hole in the outside interface inbound so that ECHO-REPLY packets can make it for this specific ping.

access-list OUT_IN permit icmp host 192.168.1.1 host 10.10.10.1 echo-reply
access-group OUT_IN in interface outside

So I just did the ping on R1 (ping 192.168.1.1) and it worked perfectly, so that very specific access list did its job.

But wait a minute – didn’t we just break Telnet from the inside to the outside? That access list has an implicit deny all at the end…

I just tried a Telnet from R1 to R2 and it worked perfectly just as before. What gives?

Well – for those Reply packets for the Telnet from the inside, inspection happens first – then the ACL. So the traffic is indeed permitted in this case even with our outside access control list permitting the ping responses.

DO NOT CONFUSE ACCESS LISTS WITH INSPECTION. They are indeed two different things and it is very important to know each separately and how they operate – and then how they would react when combined.

Thanks for reading. We will take this topology and have even more fun with it in the next post.

 

Application Inspection on the ASA

CCIE Security, , ,

One of the key areas for the Cisco ASA is giving us great control when it comes to ensuring applications running across the device are not trying to do us harm. This is implemented, of course, with Application Inspection. This permits us to only examine the packet header, but also the contents of the packet right up to Layer 7.

hke03515

Another nice thing is the fact that the ASA is trained to deal with applications that require special handling. Examples would be the handling of data packets that embed IP addressing information in the data payload, or that open up secondary channels on dynamically assigned ports.

The list of applications supported is impressive and continues to grow. Here are just some:

  • HTTP
  • FTP
  • IM
  • H.323
  • TFTP
  • SIP
  • DNS

Application Inspection is enabled and tweaked through the use of the Modular Policy Framework (MPF). Remember, this follows the general structure of a traffic class to identify traffic (class-map), actions assigned with policies (policy-map), and then the service policies activated on interfaces (service-policy).

Remember, the ASA is setup for some Application Inspection right out of the box.  You can see this with the default class-map of inspection_default, the policy-map of global_policy, and the service-policy globally assigned.

Here is a look at these default structures. Note this shows you which specific protocols are being inspected by default on all interfaces:

class-map inspection_default
   match default-inspection-traffic
policy-map type inspect dns preset_dns_map
   parameters
       message-length maximum 512
policy-map global_policy
   class inspection_default
       inspect dns preset_dns_map
       inspect ftp
       inspect h323 h225 
       
       inspect h323 ras
       inspect ip-options
       inspect rsh
       inspect rtsp
       inspect esmtp
       inspect sqlnet
       inspect skinny
       inspect sunrpc
       inspect xdmcp
       inspect sip
       inspect netbios
       inspect tftp
service-policy global_policy global

At your fingertips is your own manipulation of Application Inspection on the ASA. In this example of HTTP inspection, we selectively inspect HTTP traffic to our Web server, spoof that our server is an Apache Server, reset connections with a long header length, and guard against DoS attacks:

access-list OUT_IN extended permit tcp any host 192.168.65.3 eq www
access-group OUT_IN in interface outside
access-list AHTTP permit tcp any host 192.168.65.3 eq www
class-map CHTTP
   match access-list AHTTP
policy-map type inspect http PDHTTP
   parameters
      spoof-server "Apache Server"
      match request header length gt 4096
      reset
policy-map POUTSIDE
   class CHTTP
      inspect http PDHTTP
      set connection conn-max 2 embryonic-conn-max 1
service-policy POUTSIDE interface outside