And the second bullet to this question is whether any HTTP matching and inspection is expected in the first place by the default class as per Kings config.
From: Joe Astorino [mailto:[email protected]] Sent: 22 March 2012 17:55 To: Piotr Kaluzny Cc: Eugene Pefti; [email protected] Subject: Re: [OSL | CCIE_Security] Application not inspected once deniede So if I am understanding you correctly, the end expected result in this situation is that HTTP flows to 10.20.30.40 are NOT inspected but HTTP flows to any other address ARE inspected? On Thu, Mar 22, 2012 at 5:38 PM, Piotr Kaluzny <[email protected]<mailto:[email protected]>> wrote: Guys, "Deny" ACL entry actually matches a class. Not like with MQC (earlier I mentioned MPF - sorry for that, I was thinking about MQC). Then when you apply an action for this class in the policy, instead of enabling the feature (what normally happens for "permit" entries) you actually disable it. For example you don't want to inspect TCP 21 between host A and B as FTP but you want to keep inspection for all other src/dst over TCP 21 . If you create a class-map for this traffic and apply no action in the policy, the class inspection_default kicks in (with "inspect ftp") because inspection was NOT actually performed in user-defined class. For the class with "deny" + inspect, again the flow matches the class AND inspection is applied (actually being turned off), which means that other classes with "inspect" for this flow will not be checked (including class inspection_default). Hopefully makes more sense now. Regards, -- Piotr Kaluzny CCIE #25665 (Security), CCSP, CCNP Sr. Support Engineer - IPexpert, Inc. URL: http://www.IPexpert.com On Thu, Mar 22, 2012 at 9:44 PM, Joe Astorino <[email protected]<mailto:[email protected]>> wrote: If both are doing action "inspect" that is the way I understood it yeah, but evidently I am missing something. Anxiously awaiting a response from somebody that knows what they are talking about more than I do haha On Thu, Mar 22, 2012 at 4:40 PM, Eugene Pefti <[email protected]<mailto:[email protected]>> wrote: Oh, Christ... In plain old English it should have said: If you match the traffic for HTTP inspection in your custom class than the ASA will not match the same HTTP traffic in the default class. Correct ? From: Joe Astorino [mailto:[email protected]<mailto:[email protected]>] Sent: 22 March 2012 13:31 To: Piotr Kaluzny Cc: Eugene Pefti; [email protected]<mailto:[email protected]> Subject: Re: [OSL | CCIE_Security] Application not inspected once deniede You guys have made me go doubt myself (hate when that happens!) haha...here is how I understood the technology to work, based on the following from the 8.0 configuration guide. I take this to mean that if the packet matched the FIRST class map you have there matching on the ACL and it ALSO matched the class default policy, but the "feature type" was the same (inspect) that the action taken would be solely based on the first match (deny the flow in this case). What am I missing? Feature Matching Guidelines Within a Policy Map See the following guidelines for how a packet matches class maps in a policy map: 1. A packet can match only one class map in the policy map for each feature type. 2. When the packet matches a class map for a feature type, the security appliance does not attempt to match it to any subsequent class maps for that feature type. 3. If the packet matches a subsequent class map for a different feature type, however, then the security appliance also applies the actions for the subsequent class map, if supported. See the "Incompatibility of Certain Feature Actions" section for more information about unsupported combinations. For example, if a packet matches a class map for connection limits, and also matches a class map for application inspection, then both class map actions are applied. If a packet matches a class map for HTTP inspection, but also matches another class map that includes HTTP inspection, then the second class map actions are not applied. On Thu, Mar 22, 2012 at 4:27 PM, Joe Astorino <[email protected]<mailto:[email protected]>> wrote: > This is probably a dumb question, but I don't care : ) I don't > understand the logic of this situation. Why should the traffic be > inspected if it is explicitly denied in the first class map? At first > glance, I would think it works as it should -- The traffic flow comes > in, it is denied for inspection in the first class-map. Why would it > pass through and be inspected by the class default? > > On Thu, Mar 22, 2012 at 4:05 PM, Piotr Kaluzny > <[email protected]<mailto:[email protected]>> wrote: >> Eugene, >> >> I don't believe "match not" is available in L3/4 class-map, at least it was >> not in older versions of code >> >> Regards, >> -- >> Piotr Kaluzny >> CCIE #25665 (Security), CCSP, CCNP >> Sr. Support Engineer - IPexpert, Inc. >> URL: http://www.IPexpert.com >> >> >> On Thu, Mar 22, 2012 at 7:48 PM, Eugene Pefti >> <[email protected]<mailto:[email protected]>> >> wrote: >>> >>> Wouldn't it be better to use "match not" statement in the first class-map >>> to pass it to the default inspection class ? >>> >>> >>> >>> From: Piotr Kaluzny [mailto:[email protected]<mailto:[email protected]>] >>> Sent: 22 March 2012 11:43 >>> To: Kingsley Charles >>> Cc: Eugene Pefti; >>> [email protected]<mailto:[email protected]> >>> Subject: Re: [OSL | CCIE_Security] Application not inspected once deniede >>> >>> >>> >>> It won't hit any other class, again it is a little bit different with >>> "deny" in ACL than in MPF. >>> >>> The logic here is that the "deny" ACL entry actually matches the class as >>> long as an action (like e.g. inspect) is configured for this class. The >>> action will not be performed, however - it turns the specified action off >>> for the flow - useful with "inspect" when you want to only allow passive or >>> active FTP, not both. >>> >>> Regards, >>> -- >>> Piotr Kaluzny >>> CCIE #25665 (Security), CCSP, CCNP >>> Sr. Support Engineer - IPexpert, Inc. >>> URL: http://www.IPexpert.com >>> >>> On Thu, Mar 22, 2012 at 7:04 PM, Kingsley Charles >>> <[email protected]<mailto:[email protected]>> wrote: >>> >>> The denied http traffic should have been inspected by the next default >>> class map which is not happening. >>> >>> With regards >>> Kings >>> >>> >>> >>> On Thu, Mar 22, 2012 at 1:52 PM, Eugene Pefti >>> <[email protected]<mailto:[email protected]>> >>> wrote: >>> >>> I fear I didn't understand your question, Kings. >>> >>> Isn't what you are doing with placing the custom web class-map in front of >>> the default inspection class map to have the ASA inspection match first on >>> the traffic to 10.20.30.40. >>> >>> Or your point why HTTP is not inspected in the first place if we use >>> "deny" ACE? I believe we "permit" in the ACE to define the traffic that will >>> be matched and "deny" to exclude it from matching >>> >>> >>> >>> Eugene >>> >>> >>> >>> From: Kingsley Charles >>> <[email protected]<mailto:[email protected]>> >>> Date: Thu, 22 Mar 2012 12:59:24 +0530 >>> To: >>> <[email protected]<mailto:[email protected]>> >>> Subject: [OSL | CCIE_Security] Application not inspected once deniede >>> >>> >>> >>> Hi all >>> >>> In ASA, once if we deny the flow for inspection, it never gets inspected >>> back in other policies. In the below configuration, http traffic to >>> 10.20.30.40 is not inspected by the class inspection_default. >>> >>> Any comments? >>> >>> >>> HTTP traffic to 10.20.30.40 not inspect under class inspection_default >>> >>> access-list web extended deny tcp any host 10.20.30.40 eq www >>> access-list web extended permit tcp any any eq www >>> >>> class-map web >>> match access-list web >>> >>> policy-map global_policy >>> class web >>> inspect http >>> class inspection_default >>> inspect dns preset_dns_map >>> inspect ftp >>> inspect h323 h225 >>> inspect h323 ras >>> inspect netbios >>> inspect rsh >>> inspect rtsp >>> inspect skinny >>> inspect esmtp >>> inspect sqlnet >>> inspect sunrpc >>> inspect tftp >>> inspect sip >>> inspect xdmcp >>> inspect http >>> >>> >>> >>> With regards >>> Kings >>> >>> _______________________________________________ For more information >>> regarding industry leading CCIE Lab training, please visit >>> www.ipexpert.com<http://www.ipexpert.com> >>> Are you a CCNP or CCIE and looking for a job? Check out >>> www.PlatinumPlacement.com<http://www.PlatinumPlacement.com> >>> >>> >>> >>> >>> _______________________________________________ >>> For more information regarding industry leading CCIE Lab training, please >>> visit www.ipexpert.com<http://www.ipexpert.com> >>> >>> Are you a CCNP or CCIE and looking for a job? Check out >>> www.PlatinumPlacement.com<http://www.PlatinumPlacement.com> >>> >>> >> >> >> >> _______________________________________________ >> For more information regarding industry leading CCIE Lab training, please >> visit www.ipexpert.com<http://www.ipexpert.com> >> >> Are you a CCNP or CCIE and looking for a job? Check out >> www.PlatinumPlacement.com<http://www.PlatinumPlacement.com> > > > > -- > Regards, > > Joe Astorino > CCIE #24347 > http://astorinonetworks.com > > "He not busy being born is busy dying" - Dylan -- Regards, Joe Astorino CCIE #24347 http://astorinonetworks.com "He not busy being born is busy dying" - Dylan -- Regards, Joe Astorino CCIE #24347 http://astorinonetworks.com "He not busy being born is busy dying" - Dylan -- Regards, Joe Astorino CCIE #24347 http://astorinonetworks.com "He not busy being born is busy dying" - Dylan
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com
