Network Core Infrastructure Best Practices

1y ago

21 Views

1 Downloads

575.77 KB

89 Pages

Report/dmca

Download PDF

Transcription

Agenda Infrastructure Protection Overview Understanding Routers and Planes Infrastructure Protection from the Inside OutRouter Hardening: Traditional MethodsRouter Hardening: Protecting the CPUNetwork Hardening 2007 Cisco Systems, Inc. All rights reserved.2

Router CPUProtection“untrusted”ProtectionRouter Hardening: Protecting the CPUAttacks, junk We will look at best practices on preventing unwantedtraffic from reaching the CPU 2007 Cisco Systems, Inc. All rights reserved.4

Network Availability:Protect the Infrastructure Security is the heart of internetworking’s future; wehave moved from an Internet of implicit trust to anInternet of pervasive distrust No packet can be trusted; all packets must earn thattrust through a network device’s ability to inspect andenforce policyWhat does it mean for a packet to be trusted? Protecting the infrastructure is the most fundamentalsecurity requirement Infrastructure protection should be included in all highavailability designs A secure infrastructure forms the foundation forcontinuous business operations 2007 Cisco Systems, Inc. All rights reserved.11

It Is All About the PacketInternetOnce a packet gets intothe Internet, some device,somewhere has to do oneof two things: Deliver the packet Drop the packet 2007 Cisco Systems, Inc. All rights reserved.12

Understand the Threats InternalInadvertent human error (fat finger attack)Malicious insider ExternalWormsPacket floodsSecurity vulnerabilityIntrusionRoute hijackingService attacks (DNS, voice, video, etc.) 2007 Cisco Systems, Inc. All rights reserved.14

Understand the Threats InternalInadvertent human error (fat finger attack)Malicious insider ExternalWormsPacket floodsThese ThreatsWill Be OurMain FocusSecurity vulnerabilityIntrusionRoute hijackingService attacks (DNS, voice, video, etc.) 2007 Cisco Systems, Inc. All rights reserved.15

Taking a Measured ApproachThe Techniques We Will Be Discussing Are ExtremelyUseful, but Must Be Applied in an ArchitecturallySound, Situationally Appropriate, and OperationallyFeasible Manner Don’t try to do all of this at once—pick a techniquewith which you are comfortable and which you thinkwill benefit you the most Pilot your chosen technique in a controlled manner,in a designated portion of your network Take the lessons learned from the pilot and workthem into your general deployment plan andoperational guidelines It is not uncommon to take 9–12 months to deploy 2007 Cisco Systems, Inc. All rights reserved.16

Routers and Planes A network device typically handles traffic in severaldifferent forwarding planes There are nuances to the definition of these planesIETF RFC3654 defines two planes: control and forwardingITU X805 defines three planes: control, management,and end-userCisco defines three planes: control, management, and data 2007 Cisco Systems, Inc. All rights reserved.19

Routers and Planes Traffic to the control and management plane isalways destined to the device and is handled atprocess level ultimately:In hardware switched platforms, control/managementplane traffic is sent to the RP/MSFC and then sent tothe process level for processingIn software switched platforms, it is sent directly tothe process level for processing Traffic in the data plane is always destinedthrough the device and is:Implemented in hardware on high end platformsCEF switched (in the interrupt) in software switched platforms 2007 Cisco Systems, Inc. All rights reserved.20

Routers and PlanesSome Data Plane Traffic May Also Reachthe Control Plane Packets that are not routable reach the control plane sothat ICMP unreachable messages can be generated Packets that have IP options set are also handled bythe processor 2007 Cisco Systems, Inc. All rights reserved.21

ASIC Based Platform—Main ComponentsForwarding/FeatureASIC ClusterForwarded PacketsIngress PacketsAlso Called CPU Queue(s)and Punt Queue(s)Punted PacketsRaw Queue(s)ASICsSupportingCPU 2007 Cisco Systems, Inc. All rights reserved.ToFab to OtherLine CardsPackets Bound forthe LC CPU or RPReceive Path PacketsRouteProcessorCPU22

Data PlaneData PlaneForwarding/FeatureASIC ClusterForwarded PacketsIngress PacketsAll PacketsForwarded Throughthe PlatformPunted PacketsData PlaneASICsSupportingCPU 2007 Cisco Systems, Inc. All rights reserved.ToFab to OtherLine CardsReceive Path PacketsRouteProcessorCPU23

Control PlaneForwarding/FeatureASIC ClusterForwarded PacketsIngress PacketsToFab to OtherLine CardsControl PlaneARP, BGP, OSPF, andOther Protocols that Gluethe Network TogetherPunted PacketsControl PlaneASICsSupportingCPU 2007 Cisco Systems, Inc. All rights reserved.Most ControlPlane PacketsGo to the RPReceive Path PacketsRouteProcessorCPU24

Management PlaneForwarding/FeatureASIC ClusterForwarded PacketsIngress PacketsToFab to OtherLine CardsManagement PlaneTelnet, SSH, TFTP, SNMP,FTP, NTP, and OtherProtocols Used to Managethe DevicePunted PacketsManagement PlaneASICsSupportingCPU 2007 Cisco Systems, Inc. All rights reserved.All ManagementPlane TrafficGoes to the RPReceive Path PacketsRouteProcessorCPU25

Data Plane Feature PuntData PlaneForwarding/FeatureASIC ClusterForwarded PacketsIngress PacketsPackets that Cannot BeProcessed in theForwarding ASIC GetPunted to the ASICsSupporting CPU(e.g. IP Options) 2007 Cisco Systems, Inc. All rights reserved.Punted PacketsPunted Data PlanePacketsToFab to OtherLine CardsASICsSupportingCPUReceive Path PacketsRouteProcessorCPU26

Attack VectorsData PlaneForwarding/FeatureASIC ClusterForwarded PacketsIngress PacketsToFab to OtherLine CardsControl PlaneManagement PlaneSaturate theSupporting ASICCPUPunted PacketsSaturate the Raw“Punt” QueueASICsSupportingCPUPacketsBound forthe LC CPUor RPSaturate theInput Bufferson the RPReceive Path PacketsSaturatethe CPURouteProcessorCPUFabricInterconnect 2007 Cisco Systems, Inc. All rights reserved.27

Router Security Best Practices Many organizations publish guides to best practicesaround router security In addition to CCO resources, these .org/html.charters/opsec-charter.html Many of these best practices address threats that areoutside the scope of this session There is usually an incident or story behind why varioustechniques are deployed Therefore, we will review a sample of the key pointsand features 2007 Cisco Systems, Inc. All rights reserved.30

Router Hardening: Traditional Methods Disable any unused protocolsno service tcp-small-serversno cdp runno crypto isakmp enable VTY ACLs SNMP Community ACL SNMP views Disable SNMP RWUse SNMPv3 for RW if needed Prevent dead TCP sessionsfrom utilizing all VTY lines Edge QoS enforcement Use secret passwordService password encryption isreversible and is only meant toprevent shoulder surfing Run AAADon’t forget Authorizationand Accounting Disable extraneousinterface featuresno ip directed-broadcastno ip proxy-arpno ip redirectsservice tcp-keepalives-in 2007 Cisco Systems, Inc. All rights reserved.31

Router Hardening: Traditional Methods Source address validation(RFC2827/BCP38,RFC3704/BCP84)ip verify unicast source reachablevia {any rx}cable source-verify [dhcp]ip verify source [port-security] Disable source-routingno ip source-route Prefix-list filtering oneBGP peers BGP dampening MD5 on BGP and IGP Hardware-dependent issuesControl ICMPunreachable generationip icmp rate-limit unreachableip icmp rate-limitunreachable DFinterface null0no ip unreachablesEnsure CPU cyclesfor managementscheduler allocateSelective Packet Discard (SPD) BGP maximum-prefix 2007 Cisco Systems, Inc. All rights reserved.32

Router CPUAttacks, junkProtection“untrusted”ProtectionThe New World: Router Hardening Central policy enforcement, prior to process level Granular protection schemes On high-end platforms, hardware implementations 2007 Cisco Systems, Inc. All rights reserved.36

Receive ACL Command Introduced in:12000: 12.0(21)S2/12.0(22)S7500: 12.0(24)S10720: 12.0(31)S10K-PRE2: 12.3(7)XI1Router(config)# ip receive access-list [number] Standard, extended, or compiled ACL As with other ACL types, show access-listprovide ACE hit counts Log keyword can be used for more detail 2007 Cisco Systems, Inc. All rights reserved.38

Receive ACLs (rACLs) Receive ACLs filter traffic destined to the RP viareceive adjacencies (generally control andmanagement plane only) rACLs explicitly permit or deny traffic destinedto the RP rACLs do not affect the data plane Traffic is filtering on the ingress line card (LC), prior toroute processor (RP) processing rACLs enforce security policy by filtering who/what canaccess the router 2007 Cisco Systems, Inc. All rights reserved.39

Receive Adjacencies CEF entries for traffic destined to router, not through itReal interface(s)Loopback interface(s)c12008#sh ip cefPrefixNext 255.255.255.255/32 receiveInterfaceSerial6/0Serial6/0 Packets with next hop receive are sent to the RP forprocessing 2007 Cisco Systems, Inc. All rights reserved.40

Receive ACL Traffic FlowRouter(config)# [no] ip receive access-list num 12000i/fGRPLine CardNote: The rACL Is NeverExamined for Transit TrafficLine ts to the RouterPackets Through the Router 2007 Cisco Systems, Inc. All rights reserved.41

rACLs and Fragments Fragments can be denied via an rACL Denies fragments and classify fragment by protocol:access-list 110 deny tcp any any fragmentsaccess-list 110 deny udp any any fragmentsaccess-list 110 deny icmp any any fragments 2007 Cisco Systems, Inc. All rights reserved.42

Using Classification ACL to build rACL Iterative Deployment Develop list of required protocols Develop address requirements Determine interface on routerDoes the protocol access 1 interface?Many interfaces?Loopback or real? Deployment is an iterative processStart with relatively “open” lists tighten as needed 2007 Cisco Systems, Inc. All rights reserved.43

rACL: Iterative Deployment Step 1: Identify protocols/ports used in the network witha classification ACLPermit any any for various protocols/portsGet an understanding of what protocols communicatewith the routerPermit any any log at the end can be used to identify anymissed protocolsThis should be done slowly to ensure no protocols are missed Step 2: Review identified packets, begin to filter accessto the GRP/PRPUsing list developed in step 1, permit only those protocolsDeny any any at the end basic protection 2007 Cisco Systems, Inc. All rights reserved.44

rACL: Iterative Deployment Step 3: Restrict a macro range of source addressesOnly permit your CIDR block in the source fieldeBGP peers are the exception: they may fall outsideCIDR block Step 4: Narrow the rACL permit statements: authorizedsource addressesIncreasingly limit the source addresses to known sources:management stations, NTP peers, AAA server, etc. 2007 Cisco Systems, Inc. All rights reserved.45

rACL: Iterative Deployment Step 5: Limit the destination addresses on the rACLFilter what interfaces are accessible to specific protocolsDoes the protocol access loopbacks only? Real interfaces? Rinse, repeatRemember, start slow and openGradually improve security over timeIf you try and start very secure, you are increasing your chanceof dropping legitimate traffic 2007 Cisco Systems, Inc. All rights reserved.46

rACL: Sample Entriesip receive access-list 110 Fragmentsaccess-list 110 deny any any fragments OSPFaccess-list 110 permit ospf host ospf neighbour host 224.0.0.5! DR multicast address, if neededaccess-list 110 permit ospf host ospf neighbour host 224.0.0.6access-list 110 permit ospf host ospf neighbour host local ip BGPaccess-list 110 permit tcp host bgp peer host loopback eq bgp EIGRPaccess-list 110 permit eigrp host eigrp neighbour host 224.0.0.10access-list 110 permit eigrp host eigrp neighbour host local ip 2007 Cisco Systems, Inc. All rights reserved.47

rACL: Sample Entries SSH/Telnetaccess-list 110 permit tcp management addresses host loopback eq 22access-list 110 permit tcp management addresses host loopback eq telnet SNMPaccess-list 110 permit udp host NMS stations host loopback eq snmp Traceroute (router originated)!Each hop returns a ttl exceeded (type 11, code 3)destination returns an ICMP port unreachable (typeaccess-list 110 permit icmp any routers interfacesaccess-list 110 permit icmp any routers interfacesmessage and the final3, code 0)ttl-exceededport-unreachable Deny Anyaccess-list 110 deny ip any any 2007 Cisco Systems, Inc. All rights reserved.48

Router CPUProtection“untrusted”rACLrACLs: SummaryAttacks, junk Contain the attack: compartmentalizeProtect the RP Widely deployed and highly effectiveIf you have platforms that support rACLs, start planninga deploymentMany ISPs use rACLs in conjunction with CoPP (next topic) 2007 Cisco Systems, Inc. All rights reserved.49

Control Plane Policing (CoPP) rACLs are great butLimited platform availabilityLimited granularity—permit/deny only Need to protect all platformsTo achieve protection today, need to apply ACL toall interfacesSome platform implementation specifics Some packets need to be permitted but atlimited rateThink ping :-) 2007 Cisco Systems, Inc. All rights reserved.51

Control Plane Policing (CoPP) CoPP uses the Modular QoS CLI (MQC) for QoS policydefinition Consistent approach on all boxes Dedicated control-plane “interface”Single point of application Highly flexible: permit, deny, rate limit Extensible protectionChanges to MQC (e.g. ACL keywords) areapplicable to CoPP 2007 Cisco Systems, Inc. All rights reserved.52

Control Plane Policing FeatureCONTROL PLANEManagementSNMP, TelnetICMPIPv6INPUTto theControl PlaneCONTROL PLANEPOLICING(Alleviating DoS Attack)RoutingUpdatesManagementSSH, SSLOUTPUTfrom theControl PlaneProcessorSwitchedPackets SILENT CKETBUFFERLocallySwitched PacketsINCOMINGPACKETSCEF/FIB LOOKUP 2007 Cisco Systems, Inc. All rights reserved.53

Control Plane Policing (CoPP) Command Introduced in:12000: 12.0(29)S (aggregate mode)12000: 12.0(30)S (distributed mode)6500/7600: 12.2(18)SXD110720: 12.0(32)SMost other platforms: 12.2(18)S/12.3(4)TRouter(config)# control-plane [slot slot-number]Router(config-cp)# service-policy input control-plane-policy Uses the Modular QoS CLI (MQC) syntax for QoS policy definition Dedicated control-plane “interface” for applying QoS policies—single point of application Unlike rACL, CoPP handles data plane punts as well ascontrol/management plane traffic 2007 Cisco Systems, Inc. All rights reserved.54

Deploying CoPP One option: attempt to mimic rACL behaviorCoPP is a superset of rACLApply rACL to a single class in CoPPSame limitations as with rACL: permit/deny only Recommendation: develop multiple classes ofcontrol plane trafficApply appropriate rate to each“Appropriate” will vary based on network, risk tolerance,and risk assessmentBe careful what you rate-limit Flexible class definition allows extension of modelFragments, TOS, ARP 2007 Cisco Systems, Inc. All rights reserved.55

Configuring CoPPFour Required Steps:1. Define ACLsClassify traffic2. Define class-mapsSetup class of traffic3. Define policy-mapAssign QoS policy action to class of traffic (police, drop)4. Apply CoPP policy to control plane “interface” 2007 Cisco Systems, Inc. All rights reserved.56

Step 1: Define ACLsGroup IP Traffic Types into Different Classes Pre-Undesirable—traffic that is deemed “bad” or“malicious” to be denied access to the RP Critical—traffic crucial to the operation of the network Important—traffic necessary for day-to-day operations Normal—traffic expected but not essential fornetwork operations Post-Undesirable—traffic that is deemed “bad” or“malicious” to be denied access to the RP Catch-All—all other IP traffic destined to the RP thathas not been identified Default—all remaining non-IP traffic destined to the RPthat has not been identified 2007 Cisco Systems, Inc. All rights reserved.57

Step 1: Define ACLsThe Router IP Address for Control/ManagementTraffic Is 10.1.1.1 Pre-Undesirable—ACL 120 Post-Undesirable—ACL 124 Critical—ACL 121 Catch All—ACL 125 Important—ACL 122 Default—no ACL required Normal—ACL 123! Pre-Undesirable – Traffic that should never touch the RPaccess-list 120 permit tcp any any fragmentsaccess-list 120 permit udp any any fragmentsaccess-list 120 permit icmp any any fragmentsaccess-list 120 permit ip any any fragmentsaccess-list 120 permit udp any any eq 1434 2007 Cisco Systems, Inc. All rights reserved.58

Step 1: Define ACLsThe Router IP Address for Control/ManagementTraffic Is 10.1.1.1 Pre-Undesirable—ACL 120 Post-Undesirable—ACL 124 Critical—ACL 121 Catch All—ACL 125 Important—ACL 122 Default—no ACL required Normal—ACL 123! CRITICAL -- Defined as routing protocolsaccess-list 121 permit tcp host 10.1.1.2 eq bgp host 10.1.1.1 gt 1024access-list 121 permit tcp host 10.1.1.2 gt 1024 host 10.1.1.1 eq bgpaccess-list 121 permit tcp host 10.1.1.3 eq bgp host 10.1.1.1 gt 1024access-list 121 permit tcp host 10.1.1.3 gt 1024 host 10.1.1.1 eq bgpaccess-list 121 permit ospf any any precedence internetaccess-list 121 permit ospf any any precedence networkaccess-list 121 permit pim any host 224.0.0.13 2007 Cisco Systems, Inc. All rights reserved.59

Step 1: Define ACLsThe Router IP Address for Control/ManagementTraffic Is 10.1.1.1 Pre-Undesirable—ACL 120 Post-Undesirable—ACL 124 Critical—ACL 121 Catch All—ACL 125 Important—ACL 122 Default—no ACL required Normal—ACL 123! IMPORTANT -- Defined as traffic required to manage the routeraccess-list 122 permit tcp 10.2.1.0 0.0.0.255 eq 22 host 10.1.1.1establishedaccess-list 122 permit tcp 10.2.1.0 0.0.0.255 host 10.1.1.1 eq 22access-list 122 permit tcp 10.2.1.0 0.0.0.255 host 10.1.1.1 eq telnetaccess-list 122 permit udp host 10.2.2.1 eq tftp host 10.1.1.1access-list 122 permit udp host 10.2.2.2 host 10.1.1.1 eq snmpaccess-list 122 permit udp host 10.2.2.3 host 10.1.1.1 eq ntp 2007 Cisco Systems, Inc. All rights reserved.60

Step 1: Define ACLsThe Router IP Address for Control/ManagementTraffic Is 10.1.1.1 Pre-Undesirable—ACL 120 Post-Undesirable—ACL 124 Critical—ACL 121 Catch All—ACL 125 Important—ACL 122 Default—no ACL required Normal—ACL 123! NORMAL -- Defined as other traffic destined to the router to trackand limitaccess-list 123 permit icmp any any ttl-exceededaccess-list 123 permit icmp any any port-unreachableaccess-list 123 permit icmp any any echo-replyaccess-list 123 permit icmp any any echoaccess-list 123 permit icmp any any packet-too-big 2007 Cisco Systems, Inc. All rights reserved.61

Step 1: Define ACLsThe Router IP Address for Control/ManagementTraffic Is 10.1.1.1 Pre-Undesirable—ACL 120 Post-Undesirable—ACL 124 Critical—ACL 121 Catch All—ACL 125 Important—ACL 122 Default—no ACL required Normal—ACL 123! Post-Undesirable – Traffic that should never touch the RPaccess-list 124 permit tcp any host 10.1.1.1 eq 22access-list 124 permit tcp any host 10.1.1.1 eq telnetaccess-list 124 permit tcp any host 10.1.1.1 eq bgpaccess-list 124 permit udp any eq tftp host 10.1.1.1access-list 124 permit udp any host 10.1.1.1 eq snmpaccess-list 124 permit udp any host 10.1.1.1 eq ntp 2007 Cisco Systems, Inc. All rights reserved.62

Step 2: Define Class-Maps Create class-maps to complete thetraffic-classification processUse the access-lists defined on the previous slidesto specify which IP packets belong in which classes Class-maps permit multiple match criteria,and nested class-mapsmatch-any requires that packets meet only one“match” criteria to be considered “in the class”match-all requires that packets meet all of the“match” criteria to be considered “in the class” A “match-all” classification scheme with a simple,single-match criteria will satisfy initial deployments Traffic destined to the “undesirable” class shouldfollow a “match-any” classification scheme 2007 Cisco Systems, Inc. All rights reserved.64

Step 2: Define Class-Maps! Define a class for each “type” of traffic and associate the! appropriate ACLclass-map match-any CoPP-pre-undesirablematch access-group 120class-map match-any CoPP-criticalmatch access-group 121class-map match-any CoPP-importantmatch access-group 122class-map match-any CoPP-normalmatch access-group 123class-map match-any CoPP-post-undesirablematch access-group 124class-map match-any CoPP-catch-allmatch access-group 125 2007 Cisco Systems, Inc. All rights reserved.65

Step 3: Define Policy-Map Class-maps defined in Step 2 need to be “enforced” byusing a policy-map to specify appropriate servicepolicies for each traffic class For example:For undesirable traffic types, all actions are unconditionally“drop” regardless of rateFor critical, important, and normal traffic types, all actions are“transmit” to start outFor catch-all traffic, rate-limit the amount of traffic permittedabove a certain bpsNote: all traffic that fails to meet the matching criteria belongs tothe default traffic class, which is user configurable, but cannotbe deleted 2007 Cisco Systems, Inc. All rights reserved.66

Step 3: Define Policy-Map! Example “Baseline” service policy for each traffic classificationpolicy-map CoPPclass CoPP-pre-undesirablepolice 8000 1000 4470 conform-action drop exceed-action dropclass CoPP-criticalpolice 5000000 2500 4470 conform-action transmit exceed-action transmitclass CoPP-importantpolice 1000000 1000 4470 conform-action transmit exceed-action transmitclass CoPP-normalpolice 1000000 1000 4470 conform-action transmit exceed-action dropclass CoPP-post-undesirablepolice 8000 1000 4470 conform-action drop exceed-action dropclass CoPP-catch-allpolice 1000000 1000 4470 conform-action transmit exceed-action dropclass class-defaultpolice 8000 1000 4470 conform-action transmit exceed-action transmit 2007 Cisco Systems, Inc. All rights reserved.67

Step 4: Apply Policy to “Interface” Apply the policy-map created in Step 3 to the“control plane” The new global configuration CLI “control-plane”command is used to enter “control-planeconfiguration mode” Once in control-plane configuration mode, attach theservice policy to the control plane in the “input” directionInput—applies the specified service policy to packetsthat are entering the control plane 2007 Cisco Systems, Inc. All rights reserved.68

Step 4: Apply Policy to “Interface” CentralizedRouter(config)# control-planeRouter(config-cp)# service-policy [input output] policy-map-name DistributedRouter(config)#control-plane slot n Router(config-cp)#service-policy input policy-map-name ! Example! This applies the policy-map to the Control Plane control-planeservice-policy input CoPP 2007 Cisco Systems, Inc. All rights reserved.69

Monitoring CoPP “show access-list” displays hit counts on a per ACL entry(ACE) basisThe presence of hits indicates flows for that data type to the control plane asexpectedLarge numbers of packets or an unusually rapid rate increase in packetsprocessed may be suspicious and should be investigatedLack of packets may also indicate unusual behavior or that a rule may need tobe rewritten “show policy-map control-plane” is invaluable for reviewing andtuning site-specific policies and troubleshooting CoPPDisplays dynamic information about number of packets (and bytes) conformingor exceeding each policy definitionUseful for ensuring that appropriate traffic types and rates are reaching theroute processor Use SNMP queries to automate the process of reviewing servicepolicy transmit and drop ratesThe Cisco QoS MIB (CISCO-CLASS-BASED-QOS-MIB) provides the primarymechanisms for MQC-based policy monitoring via SNMP 2007 Cisco Systems, Inc. All rights reserved.70

Show Policy-Map CommandRouter#show policy-map control-plane inputControl PlaneService-policy input: CoPPClass-map: CoPP-critical (match-all)16 packets, 2138 bytes5 minute offered rate 0 bps, drop rate 0 bpsMatch: access-group 121police:cir 5000000 bps, bc 2500 bytesconformed 16 packets, 2138 bytes; actions:transmitexceeded 0 packets, 0 bytes; actions:transmitconformed 0 bps, exceed 0 bps Class-map: class-default (match-any)250 packets, 84250 bytes5 minute offered rate 0 bps, drop rate 0 bpsMatch: anypolice:cir 8000 bps, bc 1000 bytesconformed 41 packets, 5232 bytes; actions:transmitexceeded 0 packets, 0 bytes; actions:transmitconformed 0 bps, exceed 0 bpsRouter# 2007 Cisco Systems, Inc. All rights reserved.71

Router CPUProtection“untrusted”CoPPControl Plane PolicingAttacks, junk Superset of rACL: Start planning your migrations Provides a cross-platform methodology for protecting thecontrol planeConsistent “show” command and MIB support Granular: Permit, deny and rate-limit Platform specifics details: Centralized vs. distributed vs. hardware 2007 Cisco Systems, Inc. All rights reserved.72

Network Hardening In the context of denial of service if the packet makes itto the router its already too lateCoPP and rACL help dramatically, but they donot solve the problemThe unwanted packets must be dropped oningress into your network Three methods:Infrastructure ACLCore HidingRFC2547 (MPLS) VPN 2007 Cisco Systems, Inc. All rights reserved.75

Infrastructure ACLs Basic premise: filter traffic destined to your core routersDo your core routers really need to processall kinds of garbage? Develop list of required protocols that are sourced fromoutside your AS and access core routersExample: eBGP peering, GRE, IPSec, etc.Use classification ACL as required Identify core address block(s)This is the protected address spaceSummarization is critical simpler and shorter ACLsPoor summarization may make iACLs unwieldy 2007 Cisco Systems, Inc. All righ

Infrastructure Protection Overview Understanding Routers and Planes Infrastructure Protection from the Inside Out Router Hardening: Traditional Methods Router Hardening: Protecting the CPU Network Hardening