From: Church, Chuck (cchurch@netcogov.com)
Date: Thu Dec 16 2004 - 10:58:50 GMT-3
David,
I agree with Scott. Block it via both input and output on each
interface. If after a while you see all the drops occurring on the
input policy and never getting to an output policy, you could probably
remove the output policies for sake of efficiency. Beyond that, check
out:
http://www.cisco.com/cgi-bin/tablebuild.pl/pdlm for adding additional
protocol support to NBAR. The bittorrent one is highly recommended! If
you're 12.3T, you pick up PDLM versioning, which I believe is nice when
you start dealing with different versions of these PDLMs.
Chuck Church
Lead Design Engineer
CCIE #8776, MCNE, MCSE
Netco Government Services - Design & Implementation Team
1210 N. Parker Rd.
Greenville, SC 29609
Home office: 864-335-9473
Cell: 703-819-3495
cchurch@netcogov.com
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4371A48D
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Scott Morris
Sent: Thursday, December 16, 2004 8:34 AM
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.
> **********************************************************************
>
>
This archive was generated by hypermail 2.1.4 : Mon Jan 03 2005 - 10:31:27 GMT-3