Understanding Inspection

[Trey Grun]

I've never seen it in black and white, but my interpretation of "inspection" of traffic through a firewall is the concept of flows being continuously examined for statefulness.  I suppose I need to define my understanding of statefulness as the maintenance of knowledge of tcp flows relative to sequence information.  Of course I'm not sure how inspection works for connectionless protocols like icmp or udp...

Anyway,  my understanding that 'inspection' should be non-impacting has been challenged by attempts to implement the default inspection policy on an ASA on two occasions.  On both occasions, implementation of the policy has stopped all HTTP traffic through the device, and the most recent application of the policy stopped pretty much all traffic.  I'd paste the default policy that was created here for review, but understandably I had to remove it from the device, but can assure you that both http and icmp were included in the policy.

If it helps, I tried to get some understanding by reviewing a couple other threads - like this one:

https://supportforums.cisco.com/message/3267055

There was another thread that outlined creating policies for specific http traffic, but I figure that's not really what we need since the problem is that the default inspection policy cuts down all traffic.

Am I wrong to expect that the default inspection should not stop all traffic for the protocol being inspected?

[Maykol Rojas]

Hi Trey,

Depending on the Inspection that you are talking about, I would like to say that the firewall has 3 main types of inspection.

Layer 3/4 inspection (Stateful packet inspection)

This is basically inspections done only on layer 3/4 (TCP,UDP,ICMP). This what it does is to maintain some information into an state table. In case of TCP (as you previoulsy mention) the ASA saves information such as, source, destination, sequence number, source port, destination port etc. The packet that comes back with the expected information (lets call it next packet) should match exactly what it says on the state table. In case of UDP and ICMP, if a session is established, the firewall would check on the flow and verify if the packets are similar to the ones exchanged on the session, if not, they will be dropped.

Protocol Inspection (The one you see on the policy map)

This type of inspection is the one that you configure with MPF. The ASA works based on the RFC of protocols, for example, if you enable the HTTP inspection, the ASA would analyze every packet that comes in and out on port 80, making sure that inside of the HTTP packet has all the fields and the correct fields based on the RFC. If he sees something abnormal (Another header injecting code on a stream of data) the ASA will start dropping the packets.

Note that if these inspecions are not in place, then the firewall will just inspect the packets at layer 3/4.

Layer 7 Inspection

This is the most powerful of all 3 and the most deep. This one will take a protocol and look into the payload for informatiion and even change the information on the payload as it is presented to the end user. This is also configured via MPF. For example, if you want to add security to your mail server and you dont want anyone to see your SMTP server banner at logging, the ASA can mask the reply and the end user will not be able to see what type of server you are using, this with the purpose of the end user to not look what version of OS and software is being used by the server, thus making him unable to look for vulnerabilities.

This is basically what inspection means on the big world of ASA firewalls, if you have any doubts, let me know.

Mike

[Trey Grun]

Maykol,

Thanks for the complete response, and I have to make sure:

Enabling a default global service policy which allows for the inspection of http *specifically* should ABSOLUTELY NOT disrupt or cause the firewall to drop non-acl filtered http packets.

Would that be an accurate statement?  Because there is no access control applied to the inside interface, and that was the key issue - basic web browsing - attempts to go to google.com for example - were getting dropped by the global service policy... even though it was the default, and "inspection http" was a part of it.

[Maykol Rojas]

Hi Trey,

It is not entirely accurate, If the sites that you are accessing are not RFC compliant the end user may experience slowness or even the site to do not come up at all.

Now as a personal Opinion, many websites and Web designers do implementations and changes to how http behaves, to give better performance, but not yet defined in an RFC, so the ASA will drop them. If it was only http that was being drop and DNS, ICMP and other tcp protocols were working fine, I would recommend to take it off.

Let me know if you have any more questions.

Mike

[Trey Grun]

So -

I'm going to assume the content filter is playing a role in messing with the http flow and causing the strange behavior since I can't really explain otherwise... but that raises another interesting question:

Why is it that with no default service policy applied and therefore no inspection going on, does http operate fine, but icmp is not allowed through at all?  I remember reading something about the stateless nature of icmp, but can't really remember what the details were...

[Maykol Rojas]

Hi,

Excellent question Trey, and I am glad that we are clearing this doubts up. If No inspection policy, is not that the packets are not being inspected, they are but not at the application layer (In this case the protocol itself) They are just being inspected at layer 3/4 (First type of inspection I reffered earlier).

This is the type of inspection that allow the return packets if a session was initiated from a higher security level.

ICMP is a totally different case. ICMP by default is not allowed across the ASA, so an inspection or an access list is needed to allow it.

Didnt you noticed that UDP 53 (DNS) was working without the inspection? It follows the same patter, they are being inspected at the transport layer only, allowing the firewall to track the sessions if permitted across the ASA and allowing the return traffic.

Mike