Thanks Piotr With regards Kings
On Fri, Mar 23, 2012 at 3:08 AM, Piotr Kaluzny <[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]>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]>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]] >>> *Sent:* 22 March 2012 13:31 >>> *To:* Piotr Kaluzny >>> >>> *Cc:* Eugene Pefti; [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]> >>> 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]> >>> 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]> >>> >> 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]] >>> >>> Sent: 22 March 2012 11:43 >>> >>> To: Kingsley Charles >>> >>> Cc: Eugene Pefti; [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]> 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]> >>> >>> 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]> >>> >>> Date: Thu, 22 Mar 2012 12:59:24 +0530 >>> >>> To: <[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 >>> >>> Are you a CCNP or CCIE and looking for a job? Check out >>> >>> www.PlatinumPlacement.com >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> 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 >>> >>> >>> >>> >>> >> >>> >> >>> >> >>> >> _______________________________________________ >>> >> 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 >>> > >>> > >>> > >>> > -- >>> > 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 >
_______________________________________________ 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
