Re: CBAC : Firewall ACL bypass

I agree with your logic! I do!

me = not sure.

A couple of links on the order of operations ... maybe this is not related
to FW access but when NAT is in play only. I am not sure ...

https://supportforums.cisco.com/docs/DOC-1570;jsessionid=9744E170C73CD19A3B70
8F4404A8607D.node0

Furthermore the config guide mentions that if you have a inbound access list
that this list must be an extended access list and must have deny statements
for those protocols / traffic being inspected. If the state table comes
first, then why do you need the deny statements when using an inbound list?

Again ... it is no worry to me. I like CBAC and have used it much in the
past when I was on the road a lot ... (several years ago I must say ...)
;-)

Appreciate you and your efforts Piotr!

Andrew

.
On Tue, Jan 19, 2010 at 10:50 AM, Piotr Matusiak <piotr_at_ccie1.com> wrote:

> ALL,
>
> Let's assume for a moment that an inbound ACL on outside interface is
> checked first and if it fails then CBAC's state table is checked. If this
is
> true, what's the value of ACL bypass? The main reason Cisco implemented ACL
> bypass feature was to avoid double ACL checking and performance
improvement.
>
> When ACL bypass is used, CBAC's state table is checked first and if there
> is a match it simply allows returning packets in. Hence, there are no
> dynamic ACEs showed anymore in "sh ip access-list" command.
>
> For traffic originated from the outside, CBAC's state table has no entry so
> this packet must be checked against inbound ACL to be passed or denied.
>
>
> I hope we're on the same page here - not talking about different things :)
>
> Cheers,
>
> --
> Piotr Matusiak
> CCIE #19860 (R&S, Security)
> Technical Instructor
> website: www.MicronicsTraining.com
>
> If you can't explain it simply, you don't understand it well enough -
> Albert Einstein
>
>
> 2010/1/19 ALL From_NJ <all.from.nj_at_gmail.com>
>
>> Interesting ...
>>
>>
>> Now I have to check some links. ;-)
>>
>> Piotr, not sure the state table is consulted first ... maybe this is newer
>> behavior.
>>
>> The way i remembered this was that if it was permitted via an inbound
>> access
>> list, it was not checked via CBAC ... it was simply allowed in since the
>> inbound access list said so. This was needed for internal mail and web
>> servers.
>>
>> If it was denied via an inbound access list, it would then have a second
>> check via CBAC to see if it was permitted via CBAC. In this way the
>> access
>> list came first.
>>
>> Now you no longer need the access list, this is good. However ... I
>> believe
>> the order of operations are still the same.
>>
>> Humm ... not that it matters too much to me (as long as it works) ... but
>> now I am more curious.
>>
>> When searching for order of operations, there are many links that still
>> show
>> an inbound ACL comes before NAT and then of course before CBAC.
>>
>> Any thoughts? Appreciate your teaching me!
>>
>> Andrew
>>
>>
>> On Tue, Jan 19, 2010 at 9:56 AM, Divin Mathew John <divinjohn_at_gmail.com
>> >wrote:
>>
>> > ACL Bypass normally occurs in the direction opposite to the INSPECT.!
>> >
>> >
>> > On Tue, Jan 19, 2010 at 8:21 PM, Piotr Matusiak <piotr_at_ccie1.com>
>> wrote:
>> >
>> >> Actually, the state table is checked before an ACL:
>> >>
>> >> ACL bypassing subjects the packet to one search the inspection session
>> >> search during its processing path through the router. When a packet is
>> >> subjected to a single inspection session search before the ACL checks,
>> the
>> >> packet is matched against the list of session identifiers that already
>> >> exist
>> >> on the interface. (Session identifiers keep track of the source and
>> >> destination IP addresses and ports of the packets and on which
>> interface
>> >> the
>> >> packet arrived.)
>> >>
>> >>
>> >>
>>
http://www.cisco.com/en/US/docs/ios/12_3t/12_3t4/feature/guide/gt_aclby.html#
>> >> wp1046054<
>>
http://www.cisco.com/en/US/docs/ios/12_3t/12_3t4/feature/guide/gt_aclby.html#
wp1046054
>> >
>>
>> >>
>> >> HTH,
>> >> --
>> >> Piotr Matusiak
>> >> CCIE #19860 (R&S, Security)
>> >> Technical Instructor
>> >> website: www.MicronicsTraining.com
>> >>
>> >> If you can't explain it simply, you don't understand it well enough -
>> >> Albert Einstein
>> >>
>> >>
>> >> 2010/1/19 ALL From_NJ <all.from.nj_at_gmail.com>
>> >>
>> >> > Just to add a little here ...
>> >> >
>> >> > As I recall, an inbound ACL will be checked before the state table
>> and
>> >> thus
>> >> > no existing connection is required. This is why you would add an ACL
>> >> when
>> >> > a
>> >> > FW is configured on the router.
>> >> >
>> >> > The order of operations in important for incoming packets ... ACLs
>> can
>> >> get
>> >> > you out of ... and into trouble.
>> >> >
>> >> > Andrew Lee Lissitz
>> >> >
>> >> >
>> >> > On Tue, Jan 19, 2010 at 8:24 AM, Piotr Matusiak <piotr_at_ccie1.com>
>> >> wrote:
>> >> >
>> >> > > Hi,
>> >> > >
>> >> > > Old version of CBAC (prior 12.3(4)T) automatically added ACEs to
>> the
>> >> > > inbound
>> >> > > ACL to permit returning traffic. Now it was changes to only check
>> CBAC
>> >> > > state
>> >> > > table in order to allow that traffic back.
>> >> > >
>> >> > > If you have Web server in inside (trusted) network and you try to
>> get
>> >> > there
>> >> > > from the outside (untrusted), you'll need an ACL on untrusted
>> >> interface
>> >> > (in
>> >> > > inbound direction) as the traffic is originated from the outside.
>> This
>> >> is
>> >> > > normal behavior and has nothing to CBAC deployment.
>> >> > >
>> >> > > HTH,
>> >> > > --
>> >> > > Piotr Matusiak
>> >> > > CCIE #19860 (R&S, Security)
>> >> > > Technical Instructor
>> >> > > website: www.MicronicsTraining.com
>> >> > >
>> >> > > If you can't explain it simply, you don't understand it well
>> enough
>> >> -
>> >> > > Albert Einstein
>> >> > >
>> >> > >
>> >> > > 2010/1/19 Ajay mehra <ajaymehra01_at_gmail.com>
>> >> > >
>> >> > > > Hi Guys,
>> >> > > >
>> >> > > > I could not understand why do we bypass the ACLs when CBAC is
>> >> enabled.
>> >> > If
>> >> > > > we
>> >> > > > have a http server inside trusted network that has client on
>> >> outside
>> >> > in
>> >> > > > that case we permit http connection explicitly in ACL on outside
>> >> > > interface,
>> >> > > > inspection can be enabled inbound on trusted or outbound on
>> >> untrusted
>> >> > > > interface. If firewall acl bypass feature is enabled (default )
>> then
>> >> > > these
>> >> > > > ACLs will not be checked. From the configs and testing point of
>> >> view I
>> >> > > > know
>> >> > > > these ACLs are checked.
>> >> > > >
>> >> > > > Are these ACLs which are dynamically created when CBAC inspection
>> is
>> >> > > > enabled
>> >> > > > and different from manually defined acls ?
>> >> > > >
>> >> > > > Thanks,
>> >> > > > Ajay
>> >> > > >
>> >> > > >
>> >> > > > Blogs and organic groups at http://www.ccie.net
>> >> > > >
>> >> > > >
>> >> _______________________________________________________________________
>> >> > > > Subscription information may be found at:
>> >> > > > http://www.groupstudy.com/list/CCIELab.html
>> >> > >
>> >> > >
>> >> > > Blogs and organic groups at http://www.ccie.net
>> >> > >
>> >> > >
>> >> _______________________________________________________________________
>> >> > > Subscription information may be found at:
>> >> > > http://www.groupstudy.com/list/CCIELab.html
>> >> > >
>> >> > >
>> >> > >
>> >> > >
>> >> > >
>> >> > >
>> >> > >
>> >> > >
>> >> >
>> >> >
>> >> > --
>> >> > Andrew Lee Lissitz
>> >> > all.from.nj_at_gmail.com
>> >> >
>> >> >
>> >> > Blogs and organic groups at http://www.ccie.net
>> >> >
>> >> >
>> _______________________________________________________________________
>> >> > Subscription information may be found at:
>> >> > http://www.groupstudy.com/list/CCIELab.html
>> >>
>> >>
>> >> Blogs and organic groups at http://www.ccie.net
>> >>
>> >> _______________________________________________________________________
>> >> Subscription information may be found at:
>> >> http://www.groupstudy.com/list/CCIELab.html
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >
>> >
>> > --
>> >
>> > Sent from Bangalore, KA, India
>> >
>>
>>
>>
>> --
>> Andrew Lee Lissitz
>> all.from.nj_at_gmail.com
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>>
>>
>>
>>
>>
>>
>>
>>
>

--
Andrew Lee Lissitz
all.from.nj_at_gmail.com
Blogs and organic groups at http://www.ccie.net