From: ccie2be (ccie2be@nyc.rr.com)
Date: Thu Dec 16 2004 - 12:40:05 GMT-3
David,
This link has the best info I could find on NBAR.
http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a0080087cd0.html#wp1031614
Notice in the "Restrictions" section, there is no restriction on what
commands (actions) you can use in the policy-map portion, but there is a
restriction regarding non-transit traffic - NBAR can only act upon transit
traffic.
But, while going through this document, I came upon something I didn't
understand. Maybe someone can help me out.
If you look at the "Supported Protocols" section, you'll see that many
protocols that NBAR can match on were introduced in IOS 12.1(5)T.
I have different versions of 12.2 on my 2500's but I don't have any of the
protocols introduced in IOS 12.1(5)T. Why is that?
Do I need to use a different feature set? I think I'm using IP Plus.
TIA, Tim
----- Original Message -----
From: "Martin, David (Contractor)" <David.Martin@eu.dodea.edu>
To: <swm@emanon.com>; "Martin, David (Contractor)"
<David.Martin@eu.dodea.edu>; "'Brian McGahan'"
<bmcgahan@internetworkexpert.com>; "'Lord, Chris'"
<chris.lord@lorien.co.uk>; "'Group Study'" <ccielab@groupstudy.com>;
"'marvin greenlee'" <marvin@ccbootcamp.com>
Sent: Thursday, December 16, 2004 10:17 AM
Subject: RE: NBAR for Security Filtering
> Thanks Scott,
> Yes my intend here is not to throttle but to drop. I too understand that
p2p
> needs to setup some sort of session before it can start sharing.
>
> I initially setup the default 'input' on the LAN and 'output' on the WAN,
as
> can be seen from the my first email. But now I may try input on the WAN
and
> see how this goes.
>
> ______________________________________________________
>
> Can anybody recommend set dscp 1 marking, then using a deny ACL to drop
dscp
> = 1 ?
> I had mixed success with this setup. Perhaps again this was a direction
> issue. ??
>
> ______________________________________________________
>
>
> -----Original Message-----
> From: Scott Morris [mailto:swm@emanon.com]
> Sent: Thursday, December 16, 2004 2:34 PM
> To: 'Martin, David (Contractor)'; 'Brian McGahan'; 'Lord, Chris'; 'Group
> Study'; 'marvin greenlee'
> Subject: RE: NBAR for Security Filtering
>
> If you want to drop it entirely (which it seems from your policing
command)
> then just use 'drop' in your policy instead.
>
> As for the input or output portion, you'll need to figure out where
traffic
> is coming from that you want to get rid of. If it's coming from within,
> then it'll be an output policy on your edge link. If it's coming from
> outside, it'll be an input policy.
>
> Most P2P stuff that I've looked at needs to establish some sort of session
> before sending information, so you may be able to just kill it one way and
> have the same effect. But with the different ports and sessions that open
> up, it can't hurt to kill it both ways!
>
> How's the CPU currently?
>
> Scott
>
> -----Original Message-----
> From: Martin, David (Contractor) [mailto:David.Martin@eu.dodea.edu]
> Sent: Thursday, December 16, 2004 7:23 AM
> To: 'Brian McGahan'; Lord, Chris; swm@emanon.com; Group Study; marvin
> greenlee
> Subject: RE: NBAR for Security Filtering
>
> Hi Brian,
>
> I need to drop p2p at my distribution layer which has a LAN, 6 E1's to the
> remotes and a 34MB circuit to the core.
>
> Should I use 'input' on the LAN and E1's and 'output' drop on the 34Meg ?
Or
> can I just put one drop statement on the 34meg ?
>
> Interface Fastethenet0/0
> Desc LAN
> service-policy input drop_p2p
> !
>
> interface Serial2/2
> Desc drop to remote site A
> service-policy input drop_p2p
> !
> Interface serial 6/0
> Desc 34MB to Core
> service-policy output drop_p2p
> !
> policy-map drop_p2p
> class p2p
> police 1000000 31250 31250 conform-action drop exceed-action drop
> violate-action drop !
> class-map match-any p2p
> match protocol fasttrack
> match protocol gnutella
> match protocol edonkey
> match protocol kazaa2
> match protocol napster
> !
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Brian McGahan
> Sent: Thursday, December 16, 2004 12:28 AM
> To: Lord, Chris; swm@emanon.com; Group Study; marvin greenlee
> Subject: RE: NBAR for Security Filtering
>
> Chris,
>
> Even without a version that supports unconditional packet discard
> you can still use policing to accomplish this. If both the conform and
> exceed actions are drop, the effect is the same as just using the "drop"
> keyword. For example:
>
> class-map SOMETHING
> match protocol SOMETHING
> !
> policy-map DROP_IT
> class SOMETHING
> police cir 8000 confrom-action drop exceed-action drop !
> Interface serial0
> Service-policy input DROP_IT
>
>
> HTH,
>
> Brian McGahan, CCIE #8593
> bmcgahan@internetworkexpert.com
>
> Internetwork Expert, Inc.
> http://www.InternetworkExpert.com
> Toll Free: 877-224-8987 x 705
> Outside US: 775-826-4344 x 705
> 24/7 Support: http://forum.internetworkexpert.com
> Live Chat: http://www.internetworkexpert.com/chat/
>
>
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> Of
> > Lord, Chris
> > Sent: Wednesday, December 15, 2004 1:38 PM
> > To: swm@emanon.com; Group Study; marvin greenlee
> > Subject: RE: NBAR for Security Filtering
> >
> > Many thanks for the replies. I had wondered about feature-set timing
> but
> > since the book makes several references to 12.3(4)T I'd just about
> ruled
> > that one out. Hadn't thought about performance issues though!
> >
> > Regards,
> >
> > Chris.
> >
> > -----Original Message-----
> > From: Scott Morris [mailto:swm@emanon.com]
> > Sent: 15 December 2004 18:54
> > To: Lord, Chris; 'Group Study'
> > Subject: RE: NBAR for Security Filtering
> >
> > When this book and the whitepapers were first written, 'drop' was
> likely
> > not
> > a valid entry for the policy.
> >
> > Plus there is some argument about which parts of code take more
> > processing power to execute (which nobody will likely have a true
> > answer that
> could
> > be
> > released publically anyway!).
> >
> > But mostly a timing thing.
> >
> > Scott
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> Of
> > Lord, Chris
> > Sent: Wednesday, December 15, 2004 1:48 PM
> > To: Group Study
> > Subject: NBAR for Security Filtering
> >
> > I was wondering whether anybody has read Deal's "Cisco Router Firewall
> > Security" book - section on using NBAR to filter attacks.
> >
> >
> >
> > The method prescribed is to craft a policy map on the inbound
> interface
> > using NBAR to detect dangerous traffic (e.g. Code Red urls), mark
> > matching packets with a dscp value and then use an acl on the outbound
> interface
> > to
> > detect the dscp value and deny the traffic.
> >
> >
> >
> > Why not just drop the packets in the first place using the inbound
> > policy-map instead of letting it traverse the router first??
> >
> >
> >
> > Any views out there on this??
> >
> >
> >
> > TIA
> >
> >
> >
> > Chris.
> >
> >
> >
> > **********************************************************************
> > The information contained in this email is confidential and is
> intended
> > for
> > the recipient only. If you have received it in error, please notify us
> > immediately by reply email and then delete it from your system. Please
> > do not copy it or use it for any purposes, or disclose its contents to
> any
> > other person or store or copy this information in any medium. The
> views
> > contained in this email are those of the author and not necessarily
> > those of Lorien plc.
> >
> > Thank you for your co-operation.
> > **********************************************************************
> >
> >
> _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> >
> _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Mon Jan 03 2005 - 10:31:27 GMT-3