Router Security Configuration Guide phần 5 ppsx

The following example shows Central deleting the route to 14.2.10.0 network as it comes in from a RIP update from South.. Although the use of prefix list filters is not restricted to BGP

Central# config t

Enter configuration commands, one per line End with CNTL/Z

Central(config)# router ospf 1

Central(config-router)# distribute-list 55 out

Central(config-router)# end

Central#

The RIP distribute-list in command deletes routes from incoming RIP

updates Subsequently, all updates sent from that router will not advertise the deleted route The following example shows Central deleting the route to 14.2.10.0 network

as it comes in from a RIP update from South Therefore, since Central no longer has

a route to network 14.2.10.0, it will not advertise this network to other routers Thus, North and East will not see a route to 14.2.10.0

Central# config t

Enter configuration commands, one per line End with CNTL/Z

Central(config)# router rip

South# config t

Enter configuration commands, one per line End with CNTL/Z

South(config)# access-list 55 deny 14.2.10.0 0.0.0.255

South(config)# access-list 55 permit any

South(config)# router rip

South(config-router)# distribute-list 55 out

South(config-router)# end

South#

The examples above essentially accomplish the same task, that is, hosts from the 14.2.10.0 network are prevented from reaching the Internet However, the three different filters also have unusual side effects Using the first filter, hosts on the 14.2.10.0 network can communicate with hosts on the 14.1.0.0 network if the hosts

on the latter network use Central, instead of North, as their default gateway This is because, while Central is not advertising a route to the 14.2.10.0 network, thereby preventing North from learning that route, Central still has the route in its table

The second and third filters each fix the problem that was evident with the first filter However, a similar problem arises Connections from hosts on the 14.2.10.0 network can be made with hosts on the 14.2.9.0 network if the hosts on the latter network use South, instead of Central, as their default gateway This is because either Central is filtering the routes it receives (second filter) or South filters the routes it advertises (third filter) In either case, South still maintains a route to the 14.2.10.0 network because it is directly connected to it (Of course, the easiest way to prevent hosts on the 14.2.10.0 network from communicating with hosts on any other subnets is to simply turn off interface Ethernet0/1 on South, but that is a drastic approach.)

Migrating from RIP to OSPF: Security issues and concerns

Although RIP has withstood the test of time and proven itself to be a reliable routing protocol, OSPF is the superior routing protocol Both protocols are supported by virtually every routing vendor, but OSPF offers better scaling and faster convergence

If support for RIP is not an essential requirement, then migrating to OSPF is the recommended solution While both protocols support authentication, OSPF offers better convergence times, and using OSPF reduces the likelihood of accidentally sending out routing update packets on an unintended interface Migration procedures are beyond the scope of this document, see [2] for detailed directions However, an important step to remember is to remove RIP after OSPF has been enabled Failure to

do so will not cause a routing failure, but an attacker could then take advantage of RIP and insert a malicious route into the routing table The example below shows how to turn off RIP Remember to turn off RIP on all the routers after migration

Central(config)# no router rip

Central(config)#

After disabling RIP, check the configured protocols using the command

show ip protocols

4.4.5 Exterior Gateway Routing Protocol Security

Configuring an exterior gateway protocol can be very complex, and is outside the scope of this guide This sub-section presents four security mechanisms that you should when using BGP-4: the Generalized Time-to-Live (TTL) Security

Mechanism, MD5 authentication, prefix list filtering, and route flap damping

Control Plane Policing (CPP) can also help protect BGP operations, a brief

discussion of CPP appears in Section 4.3.7

The examples in this sub-section show how to configure the indicated BGP security mechanisms, but they do not show how to configure BGP routers in a large network For more information on BGP and BGP Security, consult [15], [17], [18], [21], [23], and [30] through [43]

Figure 4-6 shows the relationship between our example network, and the service provider that serves as its connection to the Internet In this particular case, our example network constitutes a single autonomous system, AS number 26625, while the service provider gateway router, named ISPCust7, is part of AS 27701

ISP Network Local

Network

North 14.2.0.20

AS 26625

ISPCust7

AS 27701

14.2.0.250

Other autonomous systems of the Internet

Figure 4-6: BGP Neighbors and their Autonomous System Numbers

This sub-section shows how to set up BGP authentication and other security

measures, it does not address operational issues that arise when deploying BGP infrastructure in a large network For more information on BGP operations, consult [15], [17], [21], and [31]

Generalized TTL Security Mechanism (GTSM)

The Generalized TTL Security Mechanism (GTSM), documented in RFC 3682 [32] and introduced in Cisco IOS 12.0(27)S and 12.3(7)T, utilizes the Time-to-Live (TTL) field of the IP header to protect exterior BGP (eBGP) peering sessions from remote attacks This mechanism uses the TTL value in a received packet and compares it to

an administrator defined hop count If the received IP packet contains a TTL value greater than or equal to the expected TTL value (i.e 255 minus an administrator defined hop count), then the packet is processed Otherwise, the packet is silently discarded Since remote attacks originate multiple router hops away from an intended target, limiting the hop count to the actual number of hops between eBGP peers will help prevent attacks initiated on any network that does not lie between the peers

The following example shows how to implement the GTSM between routers North and ISPCust7 in Figure 4-6 Before enabling GTSM, use the trace command to verify that the BGP peers are indeed separated by the expected number of hops Also, coordinate the implementation of GTSM between eBGP peers so that the command sequence is issued on both peers during a time interval less than the BGP hold time, otherwise the BGP session will terminate Additional information on GTSM may be found in [33]

North# trace ip 14.2.0.250

Type escape sequence to abort

Tracing the route to 14.2.0.250

Type escape sequence to abort

Tracing the route to 14.2.0.20

password guidance specified in section 4.1.5 and in the relevant IOS documentation

The following two-part example pertains to Figure 4-6 It shows how the network administrators of North in AS 26625 and the network administrators of ISPCust7 in

AS 27701 would use the shared key “r0utes4All” when configuring MD5

authentication for their peering session

The commands below would be performed on North by the local administrator

North# config t

Enter configuration commands, one per line End with CNTL/Z

North (config)# router bgp 26625

North(config-router)# neighbor 14.2.0.250 remote-as 27701

North(config-router)# neighbor 14.2.0.250 password r0utes4All North(config-router)# end

ISPCust7(config-router)# neighbor 14.2.0.20 remote-as 26625 ISPCust7(config-router)# neighbor 14.2.0.20 password r0utes4All ISPCust7(config-router)# end

ISPCust7#

Prefix List Filtering

Prefix list filtering is a common technique used to prevent damage such as DoS, traffic redirection, and prefix hijacking caused by malicious prefix advertisements Use prefix list filtering to enforce routing policy by disregarding advertisements and withdrawals of specific prefixes (Prefix filtering may be used to prevent an ISP from transiting traffic through a multihomed customer to another ISP.)

Prefix list filters can be used to filter both inbound and outbound route updates on a per-peer basis Although the use of prefix list filters is not restricted to BGP, prefix list filtering is an important technique employed by AS network administrators to filter BGP route advertisements

There are several general rules that you should consider when developing prefix lists and filters for your BGP routers:

1 AS ingress and egress prefix lists should filter martian address space (i.e

address space that should never be propagated through the Internet), including both RFC 1918 special use addresses [44] and bogon addresses [38] (i.e address space that IANA has not yet allocated) Team Cymru, Cisco, and others maintain bogon address lists; examples appear in [18] and [42]

2 AS ingress prefix lists should prevent internal prefixes from being advertised

to the AS by some other AS

3 ISP egress prefix lists should filter what is advertised to other ISP peers These filters should only permit advertisement of routes to networks that have been allocated or assigned to the ISP and its customers

4 ISP egress prefix lists should prevent ISP core network prefixes from being advertised to any other AS

5 ISP ingress prefix lists applied to advertisements from a customer should permit only those prefixes that have been assigned or allocated to the customer

6 ISP ingress prefix lists applied to advertisements from peer ISPs should prefixes that are more specific than those assigned by Internet registries (see [39] – [41]) At a minimum, ISP ingress prefix lists should deny advertised prefixes more specific than /24

The following example pertains to Figure 4-6 It shows how to configure and apply prefix list filters to prevent a subset of martian addresses, notably private addresses (i.e 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16), from being advertised by router North and accepted by router ISPCust7 The explicit permit all prefix list entry with sequence number 100000 is used so that after the deny filters are applied, no other prefixes will be affected by the implicit deny of the prefix list filter mechanism The sufficiently high sequence number 100000 is chosen so that many new entries can be added to the prefix list sequentially prior to the explicit permit all entry For more information on prefix filtering, refer to [35] and [42]

North# config t

Enter configuration commands, one per line End with CNTL/Z

North(config)# ip prefix-list NO-MARTIANS seq 60 deny

Enter configuration commands, one per line End with CNTL/Z

ISPCust7(config)# ip prefix-list NO-MARTIANS seq 60 deny

Route Flap Damping

Route flap damping is a method that may be used to provide router CPU and network stability while BGP routes are converging Damping controls the effect of route flapping which occurs when a route constantly transitions from an up-to-down or down-to-up state These transitions cause excessive BGP route update messages (i.e add/withdraw routes) to propagate through the network ISPs and other backbone providers may configure BGP damping to mitigate route flapping

The syntax for the bgp dampening command permits several optional parameters Cisco default parameters are shown below

bgp dampening [half-life] [reuse] [suppress-limit]

[max-suppress-time]

• half-life - range is 1-45 minutes; default is 15 minutes

• reuse - range is 1-20000; default is 750

• suppress-limit - range is 1-20000; default is 2000

• max-suppress-time - range is 1-225 minutes; default is 4 times the value of

the half-life parameter (e.g 60 minutes)

The following example shows the network administrator of ISPCust7 in AS 27701 enabling route flap damping with default parameter values

To display the dampened routes with the corresponding suppression time remaining, use one of the two commands shown below The list of dampened paths is useful in determining which remote networks are having instability problems

North# show ip bgp dampened-paths ! 12.2 and earlier

or

North# show ip bgp dampening dampened-paths ! 12.3

4.4.6 Using Black-Hole Routing

Many administrators configure their routers to filter connections and drop packets using basic and extended access lists Access lists provide the administrator with a high degree of precision in selectively permitting and denying traffic For example, access lists would allow an administrator to block only Telnet (TCP port 23) traffic from exiting their network The fine granuality access lists provide can impose significant administrative and performance burdens, depending on the network

architecture, router configuration, and traffic load Backbone routers, in particular, are often too heavily utilized to permit heavy use of access lists

An alternative to access lists for traffic control is a technique known as black hole routing, or null routing Null routing sacrifices the fine selectivity of access lists, it can be used only to impose a ban on all traffic sharing a specific destination address

or network There is no simple way to specify which protocols or types of traffic may

or may not pass If an address or network is null routed, ALL traffic sent to it will immediately be discarded Because this type of filtering is done as part of normal routing, it imposes little or no performance burden on normal packet flow

It is important to note that null routing can only discard traffic based on its addresses (usually only the destination) This makes it well-suited to mitigating attack

situations where ‘bad’ traffic into your network is all directed to one or a small number of address ranges It is also well-suited for discarding data directed to

unassigned or reserved addresses

Configuring Null Routing

The simple way to configure null routing is to set up a null interface and create a static route that directs the undesirable packets to it For example, to block packets with a destination address in the reserved range of 10.0.0.0/8 network, the following configuration would work:

Central# config t

Enter configuration commands, one per line End with CNTL/Z

Central(config)# interface null0

More sophisticated filtering with null routing is possible with more advanced

techniques It is possible to use a selective BGP or OSPF neighbor router to distribute

null routes throughout a network However, the configuration of such advanced null routing is beyond the scope of this guide Null routing can also be combined with filtering to support traceback of some types of DoS attacks, as described in [24] Additional practices for null routing are described in [15]

It is also possible to set up automatically triggered null routing in an entire network Setting up such a capability is beyond the scope of this guide, for a detailed look at the topic, consult [45]

4.4.7 Unicast Reverse-Path Forwarding Verification

Most Cisco routers running IOS 12.0 and later support a routing-based filtering feature called IP unicast reverse-path forward (Unicast RPF) verification When this feature is enabled on an interface, the router uses its routing tables to decide whether

to accept or drop individual packets arriving on the interface As noted in Section 4.3,

it is good security practice to reject a packet with a spoofed source address Unicast reverse-path verification supports rejecting such packets, and in some cases it can offer significant advantages over using access lists for that purpose Unicast reverse-path verification is not enabled by default; you must explicitly apply it to each interface where you want verification to be done Used correctly, and in situations where it applies, unicast RPF verification prevents most forms of IP address

spoofing

How Does Unicast Reverse-Path Verification Work?

All routers maintain a routing table that lets them decide how to forward packets Unicast reverse-path verification uses the routing table to decide whether a packet with a particular source address is valid: if the interface on which the packet with address A.B.C.D was received is the one that the router would use to send a packet to A.B.C.D, then the packet is considered ‘good’, otherwise it is ‘bad’ Good packets are forwarded normally, bad packets are discarded

Figure 4-7 shows two packets arriving at the router Central on its ‘inside’ interface, Eth0/1 The first packet bears a proper source address, it is from a host behind the South router The second packet bears a spoofed source address, it might have been generated by a piece of malicious software secretly installed somewhere on LAN 2

For packet 1, the router looks up its source address, 14.2.10.2, in the routing table It finds the interface Eth 0/1, which is the interface on which packet 1 has arrived This

is a match, so the router forwards packet 1 normally out interface Eth 0/0 For packet

2, the router looks up its source address, 7.12.1.20, in the route table It finds

interface Eth 0/0, which is not the interface on which packet 2 has arrived Because

the packet has arrived on the wrong interface, it fails unicast reverse-path

verification, and the router discards the packet

14.1.0.0/16

14.2.9.0/24

Eth0/1 14.2.9.250

Eth0/0 14.1.15.250

Destination

14.2.9.0/24 14.2.10.0/24 14.2.6.0/24 14.1.0.0/16 0.0.0.0/0

Gateway

14.2.9.64 14.1.1.20 14.1.1.250

Interface

Eth 0/1 Eth 0/1 Eth 0/0 Eth 0/0 Eth 0/0

Routing Table

Packet 1 src=14.2.10.2 dest=10.6.5.9

Packet 2 src=7.12.1.20 dest=7.12.1.20

Packet 1

Pa

et 2

Figure 4-7: IP Unicast RFP Verification

Because unicast RPF verification uses the route table, it automatically adjusts to most changes in network structure Access lists, while more broadly applicable, also require more maintenance

When to Avoid Unicast Reverse-Path Verification

This facility can be very useful for rejecting packets with improper IP source

addresses, but only when the network architecture permits it to be used Avoid unicast RPF verification if any of the following conditions apply; use access lists instead

• Router uses asymmetric routes –

if any of the interfaces on the router participate in asymmetric routes (one interface for sending, and a different one for receiving), then simple unicast RPF verification may not be used It will incorrectly reject packets arriving on the receive leg of the asymmetric route Cisco has stated that future IOS versions will perform unicast RPF correctly in these cases [11]

• Router does not support CEF – according to the Cisco documentation, unicast reverse-path verification depends on Cisco Express Forwarding If your router does not or cannot support CEF, then you cannot use unicast RPF

Unicast RPF verification is best suited for routers that act as part of the security boundary between two networks (e.g a filtering router between a LAN and the Internet) Used properly, it can provide better performance than an access list for ingress and egress address filtering For more details on how and where to apply unicast RPF verification, consult [10]

Configuring Unicast Reverse-Path Verification

Unicast RPF verification depends on a particular routing mode called Cisco Express Forwarding (CEF) Therefore, to use unicast RPF, first enable CEF, and then enable verification on the desired interfaces The transcript below shows how to enable verification on the router Central

Central# config t

Central(config)# ip cef

Central(config)# interface eth 0/0

Central(config-if)# ip verify unicast reverse-path

Central(config-if)# end

Central#

Cisco routers equipped with Versatile Interface Processors (VIPs) may require you to enable CEF with the command ip cef distributed instead of the simple version shown above Consult [10] for details about CEF requirements Note that you must not turn off CEF while unicast RPF is enabled

To check whether unicast RPF is enabled on a particular interface, or to view

statistics about dropped packets, use show ip interface interface-name The example below shows how the output will look when unicast RPF is enabled in IOS 12.3 Under 12.2 and earlier, only the lines about drops may appear

Central# show ip interface eth0/0

Ethernet0/0 is up, line protocol is up

To disable unicast RPF, enter interface configuration mode and use the command

no ip verify unicast reverse-path (12.0 through 12.2) or no ip verify unicast (12.3 and later)

Unicast Reverse-Path Verification and Access Lists

Cisco IOS version 12.1 and later include significant enhancements to unicast RPF In particular, access lists may be applied to RPF When a packet fails reverse-path verification, then the access lists are applied If the access list denies the packet, then

it is dropped If the access list permits the packet, then it is forwarded Thus, the access list allows you to create exceptions to unicast RPF’s usual functioning Also,

if the access list rule that denies a packet includes the log qualifier (see Section 4.3.1) then a log message is generated

For more information about advanced unicast RPF features, consult [11] and [15]

4.4.8 References

[1] Albritton, J., Cisco IOS Essentials, McGraw-Hill, 1999

An excellent introduction to basic Cisco IOS tasks Portions of this book that are particularly relevant to Routing Protocols are Chapters 2 and 7

[2] Parkhurst, W.R., Cisco Router OSPF - Design and Implementation Guide,

McGraw-Hill, 1998

Comprehensive and practical guide to OSPF use Includes discussion of design issues, security, implementation, and deployment

[3] Black, U., IP Routing Protocols, Prentice Hall, 2000

A very good survey of routing protocols and the technologies behind them

[4] Moy, J.T., OSPF – Anatomy of an Internet Routing Protocol, Addison-Wesley,

1998

Detailed analysis of OSPF and MOSPF, with lots of practical advice, too Includes a good section on troubleshooting

[5] Thomas, T.M., OSPF Network Design Solutions, Cisco Press, 1998

This book offers a good overview of IP routing and related topics, and also explains how to configure Cisco routers for OSPF in a variety of situations

[6] Stevens, W.R., TCP/IP Illustrated, Volume 1, Addison-Wesley, 1994

The most comprehensive and readable guide to the TCP/IP protocol suite; great technical background for any network analyst

[7] Chappell, Laura, Editor, Advanced Cisco Router Configuration, Cisco Press,

[9] Cisco Systems, “RIP and OSPF Redistribution”, Cisco Internetworking Case Studies, Cisco Systems, 2000

The IETF specification for ARP

[13] Smoot, C-M and Quarterman, J., “Using ARP to Implement Transparent Subnet Gateways”, RFC 1027, 1987

The IETF specification for Proxy ARP

[14] Rybaczyk, P., Cisco Router Troubleshooting Handbook, M&T Books, 2000

This pragmatic volume offers good advice for diagnosing and correcting problems with routing and routing protocols

[15] Greene, B and Smith, P., Cisco ISP Essentials, 1st Edition, Cisco Press, April

2002

This detailed Cisco guide for Internet Service Providers includes extensive discussion of routing protocols (especially BGP), and an in-depth treatment

of Unicast RPF, all with fully worked-out examples

[16] “Routing Basics”, Cisco Internetworking Technology Overview, Cisco Systems,

[17] Stewart, J.W., BGP4 - Inter-Domain Routing in the Internet, Addison-Wesley,

1999

Provides a good overview of BGP and practical advice on using it

[18] Thomas, R., “Secure BGP Template Version 4.1”, October 2005

available at: http://www.cymru.com/Documents/secure-bgp-template.html

This short but highly prescriptive document gives a detailed example of a locked-down configuration for a backbone or border router using BGP-4

[19] Doyle, J Routing TCP/IP - Volume 1, Cisco Press, 1998

Provides a basic understanding of routers and routing protocols through a thorough inspection of IP interior gateway routing protocols The

bookemphasizes techniques for designing efficient networks, an excellent reference for network engineers responsible for enterprise design

[20] “Enhanced IGRP”, Cisco Internetworking Technology Overview, Cisco

Systems, 2002

A white paper that describes the features and operation of EIGRP

[21] Parkhurst, W.R., Cisco BGP-4 Command and Configuration Handbook, Cisco

Press, 2001

A clear, concise resource for Cisco IOS software BGP-4 commands The command guide provides very good configuration, troubleshooting and verification guidance

[22] Cisco IOS IP Configuration Guide, IOS 12.2, Cisco Press, 2002

This volume of the Cisco IOS documentation offers extensive information on configuring all of the routing protocols discussed in this section

[23] Panigl, Schmitz, Smith, and Vistoli, “RIPE Routing Working Group

Recommendations for Coordinated Route-flap Damping Parameters”, Version 2.0, RIPE-229, RIPE, 2001

available at: http://www.ripe.net/ripe/docs/ripe-229.html

This note describes rationale for BGP route flap dampening, and includes links to examples for Cisco IOS

[24] Morrow, C., “BlackHole Route Server and Tracking Traffic on an IP Network”, October 2001

available at: http://www.secsup.org/Tracking/

This terse and technical note describes a technique for using null routing, BGP, and access control lists to trace back the sources of some DoS attacks

[25] “IP Routing Protocol Groups”, Cisco Technologies Documentation, Cisco Systems available under: http://www.cisco.com/en/US/tech/tk365/ tsd_technology_support_protocol_home.html

This page offers access to a large number of technical documents and examples about IOS-supported routing protocols, organized by protocol

[26] “IS-IS HMAC-MD5 Authentication and Enhanced Clear Text Authentication” IOS Release Notes for 12.0(21)ST and 12.0(22)S, Cisco Systems, 2001

Good reference describing the IOS command set for HMAC-MD5 authentication

[27] Martey, A., IS-IS Network Design Solutions, Cisco Press, 2002

The definitive IS-IS reference and design guide

[28] “Configuring IS-IS Authentication”, Cisco Technology White Paper, Cisco Systems, 2003

available at: http://www.cisco.com/warp/public/97/isis_authent.pdf

Provides a good overview of IS-IS authentication with an emphasis on plaintext authentication

[29] Shamin, F., Troubleshooting IP Routing Protocols, Cisco Press, 2002

A comprehensive hands-on guide for resolving IP routing problems

[30] Halabi, S., Internet Routing Architectures - Second Edition, Cisco Press, 2001

A thorough presentation of inter-domain routing concepts, issues, and scenarios

[31] Zhang, R and Bartell, M., BGP Design and Implementation, Cisco Press, 2004

A discussion of advanced BGP topics applicable to both enterprises and ISPs, including guidance on multiprotocol extensions

[32] Gill, Heasley, and Meyer, “The Generalized TTL Security Mechanism

(GTSM),” RFC 3682, February 2004

The IETF specification for GTSM

[33] “BGP Support for TTL Security Check”, Cisco IOS Release Notes for

12.0(27)S, 12.3(7)T, and 12.2(25)S, Cisco Systems, 2003

A reference for IOS configuration of the GTSM, containing command syntax and a detailed configuration procedure

[34] Heffernan, A., “Protection of BGP Sessions via the TCP MD5 Signature

Option,” RFC 2385, August 1998