Transcription
icast 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 2005 Cisco Systems, Inc. All rights reserved.61
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 2005 Cisco Systems, Inc. All rights reserved.62
nmprACLstelnet,“untrusted”Router CPUReceive ACLsAttacks, junk Contain the attack: compartmentalizeProtect the RP! Widely deployed and highly effectiveIf you have platforms that support rACLs, start planning adeploymentrACL deployments can easily be migrated to control planepolicing (next topic) Limited platform support Lack of granularity 2005 Cisco Systems, Inc. All rights reserved.63
CONTROL PLANE POLICING(CoPP)SEC-2T019815 05 2004 c1 2004 Cisco Systems, Inc. All rights reserved.64
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 :-) 2005 Cisco Systems, Inc. All rights reserved.65
Control Plane Policing (CoPP) CoPP uses the Modular QoS CLI (MQC) for QoSpolicy definition 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 2005 Cisco Systems, Inc. All rights reserved.66
Control Plane Policing FeatureCONTROL PLANEManagementSNMP, TelnetCONTROL PLANEPOLICING(Alleviating DoS Attack)ICMPIPv6INPUTto theControl PlaneRoutingUpdatesManagementSSH, SSLOUTPUTfrom theControl PlaneProcessorSwitchedPackets SILENT CKETBUFFERLocallySwitched PacketsINCOMINGPACKETSCEF/FIB LOOKUP 2005 Cisco Systems, Inc. All rights reserved.67
Configuring CoPP CoPP policy is applied to the control-plane itselfRouter(config)# control-planeRouter(config-cp)# service-policy inputplane-policycontrol- Three required steps:Class-mapSetup class of trafficPolicy-mapDefine the actual QoS policy: rate limiting and actionsApply CoPP policy to control plane “interface” 2005 Cisco Systems, Inc. All rights reserved.68
Deploying CoPP Do you know what rate of TCP/179 traffic is normalor acceptable? rACL are relatively simple to deployI know that I need BGP/OSPF/etc., deny all else To get the most value from CoPP, detailed planningis requiredDepends on how you plan to deploy itbps vs. ppsin vs. out 2005 Cisco Systems, Inc. All rights reserved.69
Deploying CoPP One option: mimic rACL behaviorApply 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,risk assessment Flexible class definition allows extension of modelFragments, TOS, ARP 2005 Cisco Systems, Inc. All rights reserved.70
Step 1: Classification Identity traffic destined to routersSome is easy (BGP, OSPF, etc.)What else? NetFlow can be used to classify trafficNeed to export and review Classification ACL can be used to identify requiredprotocolsSeries of permit statements that provide insight intorequired protocolsInitially, many protocols can be permitted, only requiredones permitted in next step Regardless of method, unexpected results shouldbe carefully analyzed do not permit protocolsthat you can’t explain! 2005 Cisco Systems, Inc. All rights reserved.71
Step 2: Policy Creation Define classification policyGroup IP traffic types identified in step 1 into different classesCritical—traffic crucial to the operation of the networkImportant—traffic necessary for day-to-day operationsNormal—traffic expected but not essential for network operationsUndesirable—explicitly “bad” or “malicious” traffic to be denied access to the RPDefault—all remaining traffic destined to RP that has not been identified Create ACLs to define trafficUse ACLs with unique numbers to represent each class defined above Create class maps to collect access-listsAssociate the traffic separation ACLs developed above with class-maps with“descriptive” namesUse the simple “match access-group acl-number ” formatAdd the “match protocol” format as necessary (e.g. ARP)Use class-default to identify all unclassified packets 2005 Cisco Systems, Inc. All rights reserved.72
Step 2: Policy CreationPacket ClassificationThe Router IP Address for Control/Management Traffic Is 10.1.1.1 Critical—ACL 120 Important—ACL 121 Normal—A
Sites with Cisco documents and presentations on routing protocols (and I don't mean Cisco.com) Marked increase in presentations about routers, routing and Cisco IOS vulnerabilities at conferences like Blackhat, Defcon and Hivercon Router attack tools and training are being published Why mount high-traffic DDOS attacks when you can
