Re: CBAC : Firewall ACL bypass

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
Blogs and organic groups at http://www.ccie.net