Transcript
Network Core Infrastructure Best Practices
Yusuf Bhaiji
Agenda
Infrastructure Protection Overview
Understanding Routers and Planes
Infrastructure Protection from the Inside OutRouter Hardening: Traditional MethodsRouter Hardening: Protecting the CPUNetwork Hardening
Router Hardening: Traditional Methods
We will look at best practices on securing the CPU
“untrusted”
Router CPU
Protection
Attacks, junk
Router Hardening: Protecting the CPU
We will look at best practices on preventing unwanted traffic from reaching the CPU
“untrusted”
Protection
Protection
Attacks, junk
Router CPU
The Old World: Network Edge
Core routers individually secured
Every router accessible from outside
“outside”
“outside”
Core
Network Hardening
“outside”
“outside”
Core
We will look at best practices on preventing unwanted traffic from reaching the core routers
Agenda
Infrastructure Protection Overview
Understanding Routers and Planes
Infrastructure Protection from the Inside OutRouter Hardening: Traditional MethodsRouter Hardening: Protecting the CPUNetwork Hardening
Infrastructure Protection Overview
LIG00843
Three Security Characteristics
Confidentiality
Integrity
Availability
The goal of security is to maintain these three characteristics
Three Security Characteristics
Primary goal of infrastructure security and this session is maintaining availability
Confidentiality
Integrity
Availability
Network Availability: Protect the Infrastructure
Security is the heart of internetworking’s future; we have moved from an Internet of implicit trust to an Internet of pervasive distrust
No packet can be trusted; all packets must earn that trust through a network device’s ability to inspect and enforce policyWhat does it mean for a packet to be trusted?
Protecting the infrastructure is the most fundamental security requirement
Infrastructure protection should be included in all high availability designs
A secure infrastructure forms the foundation for continuous business operations
It Is All About the Packet
Once a packet gets into the Internet, somedevice, somewherehas to do one of two things:
Internet
EndUser
Deliverthe packet
Dropthe packet
It Is All About the Packet
In the context of an attack, the questions are by whomand wherewill that packet be dropped
Internet
EndUser
Understand the Threats
InternalInadvertent human error (fat finger attack)Malicious insider
ExternalWormsPacket floodsSecurity vulnerabilityIntrusionRoute hijackingService attacks (DNS, voice, video, etc)
Understand the Threats
InternalInadvertent human error (fat finger attack)Malicious insider
ExternalWormsPacket floodsSecurity vulnerabilityIntrusionRoute hijackingService attacks (DNS, voice, video, etc)
These Threats Will Be Our Main Focus
Taking a Measured Approach
Don’t try to do all of this at oncepick a technique with which you are comfortable and which you think will 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 work them into your general deployment plan and operational guidelines
It is not uncommon to take 912 months to deploy
The Techniques We Will Be Discussing Are Extremely Useful, but Must Be Applied in an Architecturally Sound, Situationally Appropriate, and Operationally Feasible Manner
Agenda
Infrastructure Protection Overview
Understanding Routers and Planes
Infrastructure Protection from the Inside OutRouter Hardening: Traditional MethodsRouter Hardening: Protecting the CPUNetwork Hardening
Understanding Routers and Planes
LIG00843
Routers and Planes
A network device typically handles traffic in several different 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
Routers and Planes
Traffic to the control and management plane is always destined tothe device and is handled at process level ultimately:In hardware switched platforms, control/management plane traffic is sent to the RP/MSFC and then sent to the process level for processing In software switched platforms, it is sent directly to the process level for processing
Traffic in the data plane is always destined throughthe device and is:Implemented in hardware on high end platformsCEF switched (in the interrupt) in software switched platforms
Routers and Planes
Packets that are not routable reach the control plane so that ICMP unreachable messages can be generated
Packets that have IP options set are also handled by the processor
Some Data Plane Traffic May Also Reach the Control Plane
ASIC Based PlatformMain Components
Forwarding/Feature ASIC Cluster
ASICs Supporting CPU
Receive Path Packets
Route Processor CPU
Ingress Packets
Forwarded Packets
Punted Packets
Raw Queue(s)
Also Called CPU Queue(s) and Punt Queue(s)
Packets Bound for the LC CPU or RP
ToFab to OtherLine Cards
Data Plane
ToFab to OtherLine Cards
Forwarding/Feature ASIC Cluster
ASICs Supporting CPU
Receive Path Packets
Route Processor CPU
Ingress Packets
Forwarded Packets
Punted Packets
Data PlaneAll Packets Forwarded Throughthe Platform
Data Plane
Control Plane
Forwarding/Feature ASIC Cluster
ASICs Supporting CPU
Receive Path Packets
Route Processor CPU
Ingress Packets
Forwarded Packets
Punted Packets
MostControl Plane Packets Go to the RP
Control PlaneARP, BGP, OSPF, and Other Protocols that Glue the Network Together
Control Plane
ToFab to OtherLine Cards
Management Plane
Forwarding/Feature ASIC Cluster
ASICs Supporting CPU
Receive Path Packets
Route Processor CPU
Ingress Packets
Forwarded Packets
Punted Packets
AllManagement Plane Traffic Goes to the RP
Management PlaneTelnet, SSH, TFTP, SNMP, FTP, NTP, and Other Protocols Used to Manage the Device
Management Plane
ToFab to OtherLine Cards
Data Plane Feature Punt
Forwarding/Feature ASIC Cluster
ASICs Supporting CPU
Receive Path Packets
Route Processor CPU
Ingress Packets
Forwarded Packets
Punted Packets
Punted Data Plane Packets
Packets that Cannot Be Processed in the Forwarding ASIC Get Punted to the ASICs Supporting CPU(eg IP Options)
Data Plane
ToFab to OtherLine Cards
Attack Vectors
ToFab to OtherLine Cards
Forwarding/Feature ASIC Cluster
ASICs Supporting CPU
Receive Path Packets
Route Processor CPU
Ingress Packets
Forwarded Packets
Punted Packets
Saturate the Supporting ASIC CPU
Data Plane
Control Plane
Saturate the Raw “Punt” Queue
Packets Bound for the LC CPU or RP
Saturate the Input Buffers on the RP
Fabric Interconnect
Saturate the CPU
Management Plane
Agenda
Infrastructure Protection Overview
Understanding Routers and Planes
Infrastructure Protection from the Inside OutRouter Hardening: Traditional MethodsRouter Hardening: Protecting the CPUNetwork Hardening
Router Hardening:Traditional Methods
LIG00843
Router Security Best Practices
Many organizations publish guides to best practices around router security
In addition to CCO resources, these include:http://wwwfirstorg/resources/guides/http://wwwsansorg/resources/policies/http://wwwietforg/htmlcharters/opsec-charterhtml
Many of these best practices address threats that are outside the scope of this session
There is usually an incident or story behind why various techniques are deployed
Therefore, we will review a sample of the key points and features
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 sessions from utilizing all VTY linesservice tcp-keepalives-in
Edge QoS enforcement
Use secret passwordService password encryption is reversible and is only meant to prevent shoulder surfing
Run AAADon’t forget Authorization and Accounting
Disable extraneous interface featuresno ip directed-broadcastno ip proxy-arpno ip redirects
Router Hardening: Traditional Methods
Source address validation (RFC2827/BCP38, RFC3704/BCP84)ip verify unicast source reachable-via {any|rx}cable source-verify [dhcp]ipverifysource[port-security]
Disable source-routingno ip source-route
Prefix-list filtering on eBGP peers
BGP dampening
BGP maximum-prefix
MD5 on BGP and IGP
Hardware-dependent issuesControl ICMP unreachable generationip icmp rate-limit unreachableip icmp rate-limit unreachable DF interface null0no ip unreachablesEnsure CPU cycles for managementscheduler allocateSelective Packet Discard (SPD)
Agenda
Infrastructure Protection Overview
Understanding Routers and Planes
Infrastructure Protection from the Inside OutRouter Hardening: Traditional MethodsRouter Hardening: Protecting the CPUNetwork Hardening
Router Hardening:Protecting the CPU
LIG00843
The Old World: Router Hardening
Policy enforced at process level (VTY ACL, SNMP ACL, etc)
“untrusted”
Attacks, junk
Protection
Router CPU
The New World: Router Hardening
Protection
Central policy enforcement, prior to process level
Granular protection schemes
On high-end platforms, hardware implementations
“untrusted”
Attacks, junk
Protection
Router CPU
Router Hardening:Protecting the CPU Receive Access-Lists
LIG00843
Receive ACL Command
Introduced in:12000: 120(21)S2/120(22)S7500: 120(24)S 10720: 120(31)S 10K-PRE2: 123(7)XI1 Router(config)# ip receive access-list [number]
Standard, extended, or compiled ACL
As with other ACL types, show access-list provide ACE hit counts
Log keyword can be used for more detail
Receive ACLs (rACLs)
Receive ACLs filter traffic destined to the RP via receive adjacencies (generally control and management plane only)
rACLs explicitly permit or deny traffic destinedto the RP
rACLs do notaffect the data plane
Traffic is filtering on the ingress line card (LC), prior to route processor (RP) processing
rACLs enforce security policy by filtering who/what can access the router
Receive Adjacencies
CEF entries for traffic destined to router, not through itReal interface(s)Loopback interface(s)c12008#sh ip cefPrefix Next HopInterface0000/32 receive100101/32receive10110/24 10031 Serial6/010030/30 attachedSerial6/010030/32 receive10032/32 receive10033/32 receive224000/24 receive255255255255/32 receive
Packets with next hop receiveare sent to the RP for processing
Receive ACL Traffic Flow
Line Card
Line Card
Switch
12000
GRP
i/f
IN
OUT
i/f
IN
OUT
Router(config)# [no] ip receive access-list <num>
Packets to the Router
Packets Through the Router
Note: The rACL Is Never Examined for Transit Traffic
Receive-ACL
Receive-ACL
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
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
rACL: Iterative Deployment
Step 1: Identify protocols/ports used in the network with a classification ACLPermit any any for various protocols/portsGet an understanding of what protocols communicate with the routerPermit any any log at the end can be used to identify any missed protocolsThis should be done slowly to ensure no protocols are missed
Step 2: Review identified packets, begin to filter access to the GRP/PRPUsing list developed in step 1, permit only those protocolsDeny any any at the end basic protection
rACL: Iterative Deployment
Step 3: Restrict a macro range of source addresses Only permit your CIDR block in the source fieldeBGP peers are the exception: they may fall outside CIDR block
Step 4: Narrow the rACL permit statements: authorized source addressesIncreasingly limit the source addresses to known sources: management stations, NTP peers, AAA server, etc
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 chance of dropping legitimate traffic
rACL: Sample Entries
ip receive access-list 110
Fragmentsaccess-list 110 deny any any fragments
OSPFaccess-list 110 permit ospf host ospf_neighbour host 224005! DR multicast address, if neededaccess-list 110 permit ospf host ospf_neighbour host 224006access-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 2240010access-list 110 permit eigrp host eigrp_neighbour host local_ip
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) message and the final destination returns an ICMP port unreachable (type 3, code 0)access-list 110 permit icmp any routers_interfaces ttl-exceededaccess-list 110 permit icmp any routers_interfaces port-unreachable
Deny Anyaccess-list 110 deny ip any any
rACLs: Summary
Contain the attack: compartmentalizeProtect the RP
Widely deployed and highly effectiveIf you have platforms that support rACLs, start planning a deploymentMany ISPs use rACLs in conjunction with CoPP (next topic)
“untrusted”
Attacks, junk
Router CPU
rACL
Protection
Router Hardening:Protecting the CPU Control Plane Policing
LIG00843
Control Plane Policing (CoPP)
rACLs are great butLimited platform availability Limited granularitypermit/deny only
Need to protect all platformsTo achieve protection today, need to apply ACL to all interfacesSome platform implementation specifics
Some packets need to be permitted but atlimited rateThink ping :-)
Control Plane Policing (CoPP)
CoPP uses the Modular QoS CLI (MQC) for QoS policy definition
Consistent approach on all boxes
Dedicated control-plane “interface”Single point of application
Highly flexible: permit, deny, rate limit
Extensible protectionChanges to MQC (eg ACL keywords) are applicable to CoPP
Control Plane Policing Feature
INCOMINGPACKETS
CONTROL PLANEPOLICING(Alleviating DoS Attack)
SILENT MODE(Reconnaissance Prevention)
PACKETBUFFER
OUTPUT PACKET BUFFER
LocallySwitched Packets
CEF/FIB LOOKUP
ProcessorSwitched Packets
CONTROL PLANE
ManagementSNMP, Telnet
ICMP
IPv6
Routing
Updates
Management
SSH, SSL
…
OUTPUT from the Control Plane
INPUT to the Control Plane
Control Plane Policing (CoPP) Command
Introduced in:12000: 120(29)S (aggregate mode)12000: 120(30)S (distributed mode) 6500/7600: 122(18)SXD1 10720: 120(32)S Most other platforms: 122(18)S/123(4)T Router(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 policiessingle point of application
Unlike rACL, CoPP handles data plane punts as well as control/management plane traffic
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 of control 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
Configuring CoPP
1
Define ACLsClassify traffic
2
Define class-mapsSetup class of traffic
3
Define policy-map Assign QoS policy action to class of traffic (police, drop)
4
Apply CoPP policy to control plane “interface”
Four Required Steps:
Step 1: Define ACLs
Pre-Undesirabletraffic that is deemed “bad” or “malicious” to be denied access to the RP
Criticaltraffic crucial to the operation of the network
Importanttraffic necessary for day-to-day operations
Normaltraffic expected but not essential for network operations
Post-Undesirabletraffic that is deemed “bad” or “malicious” to be denied access to the RP
Catch-Allall other IP traffic destined to the RP that has not been identified
Defaultall remaining non-IP traffic destined to the RP that has not been identified
Group IP Traffic Types into Different Classes
Step 1: Define ACLs
Pre-UndesirableACL 120
CriticalACL 121
ImportantACL 122
NormalACL 123
Post-UndesirableACL 124
Catch AllACL 125
Defaultno ACL required
The Router IP Address for Control/Management Traffic Is 10111
! Pre-Undesirable Traffic that should never touch the RP
access-list 120 permit tcp any any fragments
access-list 120 permit udp any any fragments
access-list 120 permit icmp any any fragments
access-list 120 permit ip any any fragments
access-list 120 permit udp any any eq 1434
Step 1: Define ACLs
Pre-UndesirableACL 120
CriticalACL 121
ImportantACL 122
NormalACL 123
Post-UndesirableACL 124
Catch AllACL 125
Defaultno ACL required
The Router IP Address for Control/Management Traffic Is 10111
! CRITICAL --Defined as routing protocols access-list 121 permit tcp host 10112 eq bgp host 10111 gt 1024access-list 121 permit tcp host 10112 gt 1024 host 10111 eq bgpaccess-list 121 permit tcp host 10113 eq bgp host 10111 gt 1024access-list 121 permit tcp host 10113 gt 1024 host 10111 eq bgpaccess-list 121 permit ospf any any precedence internetaccess-list 121 permit ospf any any precedence networkaccess-list 121 permit pim any host 2240013
Step 1: Define ACLs
Pre-UndesirableACL 120
CriticalACL 121
ImportantACL 122
NormalACL 123
Post-UndesirableACL 124
Catch AllACL 125
Defaultno ACL required
The Router IP Address for Control/Management Traffic Is 10111
! IMPORTANT --Defined as traffic required to manage the router access-list 122 permit tcp 10210 000255 eq 22 host 10111 establishedaccess-list 122 permit tcp 10210 000255 host 10111 eq 22access-list 122 permit tcp 10210 000255 host 10111 eq telnetaccess-list 122 permit udp host 10221 eq tftp host 10111access-list 122 permit udp host 10222 host 10111 eq snmpaccess-list 122 permit udp host 10223 host 10111 eq ntp
Step 1: Define ACLs
Pre-UndesirableACL 120
CriticalACL 121
ImportantACL 122
NormalACL 123
Post-UndesirableACL 124
Catch AllACL 125
Defaultno ACL required
The Router IP Address for Control/Management Traffic Is 10111
! NORMAL --Defined as other traffic destined to the router to track and limit access-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
Step 1: Define ACLs
Pre-UndesirableACL 120
CriticalACL 121
ImportantACL 122
NormalACL 123
Post-UndesirableACL 124
Catch AllACL 125
Defaultno ACL required
The Router IP Address for Control/Management Traffic Is 10111
! Post-Undesirable Traffic that should never touch the RPaccess-list 124 permit tcp any host 10111 eq 22access-list 124 permit tcp any host 10111 eq telnetaccess-list 124 permit tcp any host 10111 eq bgpaccess-list 124 permit udp any eq tftp host 10111access-list 124 permit udp any host 10111 eq snmpaccess-list 124 permit udp any host 10111 eq ntp
Step 1: Define ACLs
Pre-UndesirableACL 120
CriticalACL 121
ImportantACL 122
NormalACL 123
Post-UndesirableACL 124
Catch AllACL 125
Defaultno ACL required
The Router IP Address for Control/Management Traffic Is 10111
! CATCH ALL --Defined as other IP traffic destined to the router access-list 125 permit ip any any
Step 2: Define Class-Maps
Create class-maps to complete the traffic-classification processUse the access-lists defined on the previous slides to specify which IP packets belong in which classes
Class-maps permit multiple match criteria, and nested class-mapsmatch-anyrequires 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 should follow a “match-any” classification scheme
Step 2: Define Class-Maps
! Define a class for each “type” of traffic and associate the
! appropriate ACL
class-map match-any CoPP-pre-undesirable
match access-group 120
class-map match-any CoPP-critical
match access-group 121
class-map match-any CoPP-important
match access-group 122
class-map match-any CoPP-normal
match access-group 123
class-map match-any CoPP-post-undesirable
match access-group 124
class-map match-any CoPP-catch-all
match access-group 125
Step 3: Define Policy-Map
Class-maps defined in Step 2 need to be “enforced” by using a policy-map to specify appropriate service policies 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 permitted above a certain bpsNote: all traffic that fails to meet the matching criteria belongs to the default traffic class, which is user configurable, but cannot be deleted
Step 3: Define Policy-Map
! Example “Baseline” service policy for each traffic classification
policy-map CoPP
class CoPP-pre-undesirable
police 8000 1000 4470 conform-action drop exceed-action drop
class CoPP-critical
police 5000000 2500 4470 conform-action transmit exceed-action transmit
class CoPP-important
police 1000000 1000 4470 conform-action transmit exceed-action transmit
class CoPP-normal
police 1000000 1000 4470 conform-action transmit exceed-action drop
class CoPP-post-undesirable
police 8000 1000 4470 conform-action drop exceed-action drop
class CoPP-catch-all
police 1000000 1000 4470 conform-action transmit exceed-action drop
class class-default
police 8000 1000 4470 conform-action transmit exceed-action transmit
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-plane configuration mode”
Once in control-plane configuration mode, attach the service policy to the control plane in the “input” directionInputapplies the specified service policy to packets that are entering the control plane
Step 4: Apply Policy to “Interface”
Centralized
Router(config)# control-plane
Router(config-cp)# service-policy [input | output] <policy-map-name>
Distributed
Router(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-plane
service-policy input CoPP
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 as expectedLarge numbers of packets or an unusually rapid rate increase in packets processed may be suspicious and should be investigatedLack of packets may also indicate unusual behavior or that a rule may need to be rewritten
“show policy-map control-plane” is invaluable for reviewing and tuning site-specific policies and troubleshooting CoPPDisplays dynamic information about number of packets (and bytes) conforming or exceeding each policy definitionUseful for ensuring that appropriate traffic types and rates are reaching the route processor
Use SNMP queries to automate the process of reviewing service-policy transmit and drop ratesThe Cisco QoS MIB (CISCO-CLASS-BASED-QOS-MIB) provides the primary mechanisms for MQC-based policy monitoring via SNMP
Show Policy-Map Command
Router#show policy-map control-plane input
Control Plane
Service-policy input: CoPP
Class-map: CoPP-critical(match-all)
16 packets, 2138 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: access-group 121
police:
cir 5000000 bps, bc 2500 bytes
conformed 16 packets, 2138 bytes; actions:
transmit
exceeded 0 packets, 0 bytes; actions:
transmit
conformed 0 bps, exceed 0 bps
…
Class-map: class-default(match-any)
250 packets, 84250 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
police:
cir 8000 bps, bc 1000 bytes
conformed 41 packets, 5232 bytes; actions:
transmit
exceeded 0 packets, 0 bytes; actions:
transmit
conformed 0 bps, exceed 0 bps
Router#
Control Plane Policing
Superset of rACL: Start planning your migrations
Provides a cross-platform methodology for protecting the control planeConsistent “show” command and MIB support
Granular: Permit, deny and rate-limit
Platform specifics details: Centralized vs distributed vs hardware
“untrusted”
Attacks, junk
Router CPU
CoPP
Protection
Agenda
Infrastructure Protection Overview
Understanding Routers and Planes
Infrastructure Protection from the Inside OutRouter Hardening: Traditional MethodsRouter Hardening: Protecting the CPUNetwork Hardening
Network Hardening
LIG00843
Network Hardening
In the context of denial of service if the packet makes it to the router its already too lateCoPP and rACL help dramatically, but they do not solve the problemThe unwanted packets must be dropped on ingress into your network
Three methods:Infrastructure ACLCore HidingRFC2547 (MPLS) VPN
Network Hardening:Infrastructure ACL
LIG00843
Infrastructure ACLs
Basic premise: filter traffic destined to your core routersDo your core routers really need to process all kinds of garbage?
Develop list of required protocols that are sourced from outside your AS and access core routersExample: eBGP peering, GRE, IPSec, etcUse 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
Infrastructure ACLs
Infrastructure ACL will permit only required protocols and deny allothers to infrastructure space
ACL should also provide anti-spoof filteringDeny your space from external sourcesDeny RFC1918 spaceDeny multicast sources addresses (224/4)RFC3330 defines special use IPv4 addressing
Infrastructure ACLs
Infrastructure ACL must permit transit trafficTraffic passing through routers must be allowed via permit IP any any
ACL is applied inbound on ingress interfaces
Fragments destined to the core can be filtered via fragments keyword
Infrastructure ACL in Action
SRC: 127001DST: Any
SRC: Valid
DST: Rx (Any R)
SRC: eBGP Peer
DST: CR1 eBGP
SRC: Valid
DST: External to AS (eg Customer)
ACL “in”
ACL “in”
ACL “in”
ACL “in”
PR1
PR2
R1
CR1
R4
R2
R3
R5
CR2
Iterative Deployment
Typically a very limited subset of protocols needs access to infrastructure equipment
Even fewer are sourced from outside your AS
Identify required protocols via classification ACL
Deploy and test your ACLs
Step 1: Classification
Traffic destined to the core must be classified
NetFlow can be used to classify trafficNeed to export and review
Classification ACL can be used to identify required protocolsSeries of permit statements that provide insight into required protocolsLog keyword can be used for additional detail; hits to ACL entry with log will increase CPU utilization: impact varies by platform
Regardless of method, unexpected results should be carefully analyzed do not permit protocols that you can’t explain
Step 2: Begin to Filter
Permit protocols identified in Step 1 to infrastructure address blocks
Deny all others to infrastructure address blocksWatch access control entry (ACE) countersLog keyword can help identify protocols that have been denied but are needed
Last line: permit ip any any permit transit traffic
The ACL now provides basic protection and can be used to ensure that the correct suite of protocols has been permitted
Steps 3 and 4: Restrict Source Addresses
Step 3:ACL is providing basic protectionRequired protocols permitted, all other deniedIdentify source addresses and permit only those sources for requires protocolsEg, external BGP peers, tunnel end points
Step 4:Increase security: deploy destination address filters to individual hosts if possible
Example: Simplistic Infrastructure ACL
! Deny our internal space as a source of external packets
access-list 101 deny ip our_CIDR_block any
! Deny src addresses of 0000 and 127/8
access-list 101 deny ip host 0000 any
access-list 101 deny ip 127000 0255255255 any
! Deny RFC1918 space from entering AS
access-list 101 deny ip 10000 0255255255 any
access-list 101 deny ip 1721600 0015255 any
access-list 101 deny ip 19216800 00255255 any
!Permit eBGP from outside out network
access-list 101 permit tcp host peerA host peerB eq 179
access-list 101 permit tcp host peerA eq 179 host peerB
! Deny all other access to infrastructure
access-list 101 deny ip any core_CIDR_block
! Permit all data plane traffic
access-list 101 permit ip any any
Infrastructure ACL Summary
Infrastructure ACLs are veryeffective at protecting the network if properly and universally deployed
Have been successfully used by many SPs for years
IP Address summarization critical to successful deployment
Infrastructure ACLs also have a few weaknessesHardware restrictions associated with deploying ACLs or the ACEs required in iACL may prevent deploymentOperational overhead in maintaining and deploying iACLCollisions with customer ACLs difficult to manage
Q and A
LIG00724
Interesting Links
iACL Deployment Guidehttp://wwwciscocom/warp/public/707/iaclhtml
rACL Deployment Guidehttp://wwwciscocom/warp/public/707/raclhtml
CoPP Deployment Guidehttp://wwwciscocom/en/US/products/ps6642/products_white_paper0900aecd804fa16ashtml
Cisco Network Foundation Protection (NFP)http://wwwciscocom/warp/public/732/Tech/security/infrastructure/
SP Security Archiveftp://ftp-engciscocom/cons/isp/security/
NANOGhttp://wwwnanogorg/previoushtmlhttp://wwwnanogorg/ispsecurityhtml