From: Dmitry Volkov (dmitry.volkov@rogers.com)
Date: Mon Jan 26 2004 - 16:19:52 GMT-3
Rich,
I asked about NBAR and policing.
I believe this order of operations fits better in this situation:
http://www.cisco.com/en/US/tech/tk543/tk757/technologies_tech_note09186a0080
160fc1.shtml
Inbound
4. Input marking (class-based marking or Committed Access Rate (CAR))
5. Input policing (through a class-based policer or CAR)
I don't see why it can't happen on the same incoming interface ?
despite that
http://www.cisco.com/en/US/products/hw/routers/ps359/products_tech_note09186
a00800fc176.shtml#methodc
refers to the same QOS order of operations
Thanks,
Dmitry
> -----Original Message-----
> From: rich doty [mailto:rich_doty@hotmail.com]
> Sent: Monday, January 26, 2004 12:20 PM
> To: MMullen@nettechgroup.com; dmitry.volkov@rogers.com;
> ccielab@groupstudy.com
> Cc: security@groupstudy.com
> Subject: RE: NBAR with class based policing
>
>
> All comes back to the order IOS processes packets on interfaces.
> http://www.cisco.com/warp/public/556/5.html
>
> INSIDE-to-OUTSIDE
>
> If IPSec then check input access list
>
> decryption - for CET (Cisco Encryption Technology) or IPSec
>
> check input access list
>
> check input rate limits
>
> input accounting
>
> policy routing
>
> routing
>
> redirect to web cache
>
> NAT inside to outside (local to global translation)
>
> crypto (check map and mark for encryption)
>
> check output access list
>
> inspect (Context-based Access Control (CBAC))
>
> TCP intercept
>
> encryption
>
>
> OUTSIDE-TO-INSIDE
>
> If IPSec then check input access list
>
> decryption - for CET or IPSec
>
> check input access list
>
> check input rate limits
>
> input accounting
>
> NAT outside to inside (global to local translation)
>
> policy routing
>
> routing
>
> redirect to web cache
>
> crypto (check map and mark for encryption)
>
> check output access list
>
> inspect CBAC
>
> TCP intercept
>
> encryption
>
>
>
>
> >From: "Matt Mullen" <MMullen@nettechgroup.com>
> >Reply-To: "Matt Mullen" <MMullen@nettechgroup.com>
> >To: "Dmitry Volkov" <dmitry.volkov@rogers.com>,
> <ccielab@groupstudy.com>
> >CC: <security@groupstudy.com>
> >Subject: RE: NBAR with class based policing
> >Date: Thu, 22 Jan 2004 16:25:31 -0500
> >MIME-Version: 1.0
> >Received: from mc5-f27.hotmail.com ([65.54.252.34]) by
> mc5-s15.hotmail.com
> >with Microsoft SMTPSVC(5.0.2195.6824); Thu, 22 Jan 2004
> 13:54:32 -0800
> >Received: from groupstudy.com ([66.220.63.9]) by
> mc5-f27.hotmail.com with
> >Microsoft SMTPSVC(5.0.2195.6824); Thu, 22 Jan 2004 13:54:32 -0800
> >Received: from groupstudy.com (localhost [127.0.0.1])by
> groupstudy.com
> >(8.12.10/8.12.10) with ESMTP id i0MLPaxu020425GroupStudy
> Mailer; Thu, 22
> >Jan 2004 21:25:36 GMT
> >Received: (from listserver@localhost)by groupstudy.com
> >(8.12.10/8.12.8/Submit) id i0MLPZXl020424GroupStudy
> Submission Server; Thu,
> >22 Jan 2004 21:25:35 GMT
> >Received: from mail.nettechgroup.com (mail.nettechgroup.com
> >[66.114.207.33]) by groupstudy.com (8.12.10/8.12.10) with ESMTP id
> >i0MLPVxu020350; Thu, 22 Jan 2004 21:25:31 GMT
> >X-Message-Info: gUeNUVfFqHBVCg1mEzRjZB9SOYlq7qTE1hzqMgTdGqo=
> >content-class: urn:content-classes:message
> >Message-ID:
> <C444AB8E85181B4F8CADF2220A0B533C8506A3@mail.nettechgroup.com>
> >Thread-Topic: NBAR with class based policing
> >Thread-Index: AcPhIakRLpwmfIOuToyfNnRhEQXQUQACi3jg
> >X-MIME-Autoconverted: from quoted-printable to 8bit by
> groupstudy.com id
> >i0MLPVxu020350
> >X-ASK-Info: Whitelist match
> >Precedence: bulk
> >Return-Path: nobody@groupstudy.com
> >X-OriginalArrivalTime: 22 Jan 2004 21:54:32.0747 (UTC)
> >FILETIME=[5170D7B0:01C3E132]
> >
> >Hi Dmitry,
> >
> >I think what the document is saying and what you are missing in your
> >config is that you need an outbound ACL on your internal interface to
> >check for the DSCP value and drop if present. You can't check the
> >packet for the DSCP on the outside because the ACL would get
> processed
> >first, so the DSCP would get marked after the ACL has already been
> >processed. Here's my NBAR config:
> >
> >class-map match-any HTTP-HACKS
> > match protocol http url "*default.ida*"
> > match protocol http url "*x.ida*"
> > match protocol http url "*.ida*"
> > match protocol http url "*cmd.exe*"
> > match protocol http url "*root.exe*"
> >!
> >!
> >policy-map MARK-INBOUND-HTTP-HACKS
> > class HTTP-HACKS
> > set dscp 1
> >
> >interface Serial0/0
> > description Internet
> > service-policy input MARK-INBOUND-HTTP-HACKS
> >
> >interface Ethernet0/0
> > description Inside LAN
> > ip access-group DROP-HTTP-HACKS out
> > ip nbar protocol-discovery
> >
> >ip access-list extended DROP-HTTP-HACKS
> > deny ip any any dscp 1 log
> > permit icmp any any
> > permit ip any any
> >
> >You can test this config by downloading the Code Red scanner from
> >Digital eEye Security and running it against a web server behind your
> >router.
> >
> >Hope this helps,
> >Matt
> >
> >
> >-----Original Message-----
> >From: Dmitry Volkov [mailto:dmitry.volkov@rogers.com]
> >Sent: Thursday, January 22, 2004 2:35 PM
> >To: ccielab@groupstudy.com
> >Cc: security@groupstudy.com
> >Subject: NBAR with class based policing
> >
> >
> >Hi,
> >
> >If I want to use NBAR with class based policing against stuff like
> >codered - Is it enough to have ?:
> >
> >Router(config)#class-map match-any http-hacks
> Router(config-cmap)#match
> >protocol http url "*default.ida*" Router(config-cmap)#match protocol
> >http url "*cmd.exe*" Router(config-cmap)#match protocol http url
> >"*root.exe*" Router(config)#policy-map drop-inbound-http-hacks
> >Router(config-pmap)#class http-hacks
> Router(config-pmap)#police 1000000
> >31250 31250 conform-action drop exceed-action drop
> violate-action drop
> >Router(config)#interface serial 0/0
> Router(config)#Description OUTSIDE
> >INTERFACE Router(config-if)#service-policy input
> drop-inbound-http-hacks
> >
> >Example here
> >http://www.cisco.com/en/US/products/hw/routers/ps359/products
_tech_note0
>9186
>a00800fc176.shtml#methodc
>looks strange: Description of steps 1)-5) contradicts with config they
>place... They talk about 2 policies : inbound on outside interface for
>classification of traffic and outbound for policing: "Note that you must
>apply a separate policy to the outbound interface. You cannot apply a
>single policy that both marks the "Code Red" packets and drops them"
>
>but config depicts inbound policing on outside interface, why do I need
>to mark them when I just want to drop...
>
>Is config above correct ??
>
>Thank You
>Dmitry
This archive was generated by hypermail 2.1.4 : Mon Feb 02 2004 - 09:07:50 GMT-3