| 리포트 | 기술문서 | 테크-블로그 | 원샷 갤러리 | 링크드인 | 스폰서 컨텐츠 | 네트워크/통신 뉴스 | 인터넷자료실 | 자유게시판    한국 ICT 기업 총람 |

제품 검색

|

통신 방송 통계

 
 
 
섹션 5G 4G LTE C-RAN/Fronthaul Gigabit Internet IPTV/UHD IoT SDN/NFV Wi-Fi Video Streaming KT SK Telecom LG U+ OTT Network Protocol CDN YouTube Data Center
 

2023

5G 특화망

포탈

Private 5G/이음 5G

 포탈홈

  넷매니아즈 5G 특화망 분석글 (128)   5G 특화망 4가지 구축모델   산업계 5G 응용   산업분야별 5G 특화망 활용사례  [5G 특화망 벤더Samsung | HFR | Nokia | more
 

해외

  국가별 사설5G 주파수 [국가별 구축현황] 일본 | 독일 | 미국 | 프랑스 | 영국  [사설5G 사업자] Verizon | AT&T | DT | Telefonica | AWS | Microsoft | NTT동일본 | NTT Com    
 

국내

  5G 특화망 뉴스 | 국내 5G 특화망 구축 현황 | 국내 5G 특화망사업자 현황 (19개사) | 국내 자가구축사례 일람 | 국내 특화망 실증사업사례 일람 | 5G 특화망 정책
 
 

[5G 특화망 구축 사례] 한국식품산업클러스터 | 반월시화산단 삼성서울병원 | 롯데월드 | 한국수력원자력 | 해군본부 | 한국전력공사 | more  [이통사] KT

 
 
스폰서채널 |

 HFR의 5G 특화망 솔루션 (my5G)  Updated   | HFR 5G 특화망 뉴스HFR my5G 자료

  스폰서채널 서비스란?
Network Core Infrastructure Security - Best Practices
March 02, 2010 | By Cisco
코멘트 (0)
7
Thank you for visiting Netmanias! Please leave your comment if you have a question or suggestion.
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
View All (861)
4G (2) 4G Evolution (1) 5G (49) 5G 특화망 (10) 5g (1) 802.11 (1) 802.1X (1) ALTO (1) ANDSF (1) AT&T (2) Acceleration (1) Adobe HDS (3) Akamai (6) Amazon (3) Apple HLS (4) Authentication (1) BRAS (2) BT (1) Backbone (4) Backhaul (12) BitTorrent (1) Broadcasting (3) C-RAN (13) C-RAN/Fronthaul (12) CCN (4) CDN (52) CDNi (1) COLT (1) CORD (1) CPRI (2) Cache Control (1) Caching (5) Carrier Cloud (2) Carrier Ethernet (9) Channel Zapping (4) China Mobile (1) China Telecom (1) Cloud (10) Cloudfront (1) DASH (2) DCA (1) DHCP (3) DNS (1) DSA (1) Data Center (7) Dynamic Web Acceleration (1) EDGE (1) EPC (5) Edge (1) Energy (1) Ericsson (5) Ethernet (8) FEO (2) Fairness (1) Fronthaul (5) GiGAtopia (1) Gigabit Internet (2) Global CDN (1) Google (5) HLS (1) HTTP (1) HTTP Adaptive Streaming (18) HTTP Progressive Download (3) HTTP Streaming (1) HetNet (1) Hot-Lining (1) Hotspot 2.0 (2) Huawei (3) ICN (4) IP (1) IP Allocation (1) IP Routing (8) IPTV (15) Intel (1) Internet (1) Interoperability (2) IoST (1) IoT (14) KT (22) LG U+ (3) LTE (70) LTE MAC (1) LTE-A (2) Licensed CDN (1) M2M (3) MEC (5) MPLS (25) MVNO (1) Market (4) Metro Ethernet (7) Microsoft (2) Migration (1) Mobile (4) Mobile Backhaul (1) Mobile Broadcasting (1) Mobile CDN (2) Mobile IP (1) Mobile IPTV (3) Mobile Video (1) Mobile Web Perormance (1) Mobility (1) Multi-Screen (7) Multicast (7) NFC (1) NFV (2) NTT Docomo (2) Netflix (6) Network Protocol (31) Network Recovery (3) OAM (6) OTT (31) Ofcom (1) Offloading (2) OpenFlow (1) Operator CDN (14) Orange (1) P2P (4) PCC (1) Page Speed (1) Private 5G (13) Programmable (1) Protocol (7) Pseudowire (1) QoS (5) Router (1) SCAN (1) SD-WAN (1) SDN (15) SDN/NFV (15) SK Telecom (22) SON (1) SaMOG (1) Samsung (2) Security (6) Service Overlay (1) Silverlight (4) Small Cell (3) Smart Cell (1) Smart Grid (2) Smart Network (2) Supper Cell (1) Telefonica (1) Telstra (1) Terms (1) Traffic (2) Traffic Engineering (1) Transcoding (3) Transparent Cache (2) Transparent Caching (14) VLAN (2) VPLS (2) VPN (9) VRF (2) Vendor Product (2) Verizon (2) Video Optimization (4) Video Pacing (1) Video Streaming (14) Virtual Private Cloud (1) Virtualization (3) White Box (1) Wholesale CDN (4) Wi-Fi (13) WiBro(WiMAX) (4) Wireless Operator (5) YouTube (4) eMBMS (4) eNB (1) 망이용대가 (1) 망중립성 (1) 스마트 노드 (1) 이음 5G (3)

 

 

     
         
     

 

     
     

넷매니아즈 회원 가입 하기

2023년 6월 현재 넷매니아즈 회원은 55,000+분입니다.

 

넷매니아즈 회원 가입을 하시면,

► 넷매니아즈 신규 컨텐츠 발행 소식 등의 정보를

   이메일 뉴스레터로 발송해드립니다.

► 넷매니아즈의 모든 컨텐츠를 pdf 파일로 다운로드

   받으실 수 있습니다. 

     
     

 

     
         
     

 

 

비밀번호 확인
코멘트 작성시 등록하신 비밀번호를 입력하여주세요.
비밀번호