cisco press router security strategies phần 8 pot

Data PlaneIn this case study, and from the perspective of router PE-00, data plane traffic includes the following: • Internal to internal traffic: Data plane traffic in this category includ

Trang 1

other Customer A sites via the Internet For both connections of CPE-A0 and CPE-A1, the associated edge router (PE) interfaces are assumed to be Serial0/0/0 The

IP addresses assigned to these PE-CE links are shown in Figure 9-2 For all external PE-CE links, /30 subnet masking is assigned

• Internal: Internal interfaces connect network infrastructure wholly within one

administrative domain All SP edge and core routers shown in Figure 9-2 include at least two internal interfaces Interfaces Serial1/0/0 and Serial2/0/0 of PE-00 are considered internal to the SP network All internal interfaces within this case study are assigned from the 172.30.0.0/15 address block The IP subnets associated with these internal interfaces are carried within the SP IGP (OSPF in this case study)

• Loopback: All SP edge and core routers shown in Figure 9-2 implement a single

loopback interface that is used for control and management plane trafﬁc All loopback interfaces within this case study are assigned from the 192.168.1.0/24 address block,

as shown in Figure 9-2 The /32 IP subnets associated with these internal interfaces are also carried within the SP IGP (OSPF in this case study)

• Receive: All routers include by default a receive interface that “logically” represents

the slow path to the IOS process level on the RP The receive path applies to any ingress packets that must be punted from the CEF fast path to be processed locally by the router’s CPU whether transit or receive adjacency packets Because the receive path represents an exception packet processing path between the CEF fast path and IOS process level, it is not assigned or associated with a speciﬁc IP subnet However,

as you will see, control plane security features are applied to these logical interfaces.Figure 9-3 highlights in particular the router of focus for this case study, PE-00, and illustrates the relationship among its interfaces This router is also the focus for the sample IOS conﬁguration that follows

Router Conﬁguration

Security configurations may be derived based upon the preceding topology and functional requirements Router PE-00 is used as the focal point for the remaining discussions; however, the other Internet edge routers shown within the topology of Figure 9-2 have similar but locally specific configurations

Example 9-1 provides the derived Cisco IOS configuration that satisfies the preceding requirements and defense in depth and breadth security principles This configuration assumes that PE-00 is a Cisco 12000 series router (12416), and that it is running IOS Software Release 12.0(32)S with the SSH feature set Line numbers precede each configuration command shown in Example 9-1 and serve as reference points for the remainder of the discussion that directly follows, which is organized by IP traffic plane

Trang 2

Example 9-1 Case Study 1 SP Internet Edge Router PE-00 Conﬁguration

6 : service timestamps debug datetime msec localtime show-timezone

7 : service timestamps log datetime msec localtime show-timezone

22 : aaa authentication login default tacacs+ local

23 : aaa authentication enable default tacacs+ enable

24 : aaa authorization exec default tacacs+ none

25 : aaa accounting commands 1 default start-stop tacacs+

27 : enable secret 5 $1$rdYk$45iBa5oBI.QGmjoFDS9j00

28 : !

29 : username noc-admin secret 5 $1$z.rf$jFH3rwXPQdsXP8FxUeCV5.

30 : memory free low-watermark processor 100000

Trang 4

127 : ip ospf message-digest-key 1 md5 7 095F4B0A0B0003

128 : service-policy output diffserv-qos

Trang 5

173 : logging trap notifications

174 : logging source-interface Loopback0

175 : logging 192.168.255.50

176 : access-list 10 permit 192.168.252.0 0.0.3.255

177 : access-list 100 deny ip any 172.30.0.0 0.1.255.255

180 : access-list 100 deny ip 0.0.0.0 0.255.255.255 any

189 : access-list 100 permit ip any any

190 : access-list 101 permit ospf 192.168.1.0 0.0.0.255 any precedence internet

191 : access-list 101 permit tcp host 192.168.1.2 host 192.168.1.5 eq 179 precedence internet

192 : access-list 101 permit tcp host 192.168.1.2 eq 179 host 192.168.1.5 precedence internet

193 : access-list 101 permit tcp 192.168.252.0 0.0.3.255 host 192.168.1.5 eq 22

194 : access-list 101 permit tcp 192.168.252.0 0.0.3.255 eq 22 host 192.168.1.5

195 : access-list 101 permit udp 192.168.252.0 0.0.3.255 host 192.168.1.5 eq 123

Example 9-1 Case Study 1 SP Internet Edge Router PE-00 Conﬁguration (Continued)

Trang 6

196 : access-list 101 permit tcp 192.168.252.0 0.0.3.255 eq tacacs host 192.168.1.5 established

199 : access-list 101 permit icmp any any echo

200 : access-list 101 permit icmp any any echo-reply

201 : access-list 101 permit icmp any any ttl-exceeded

202 : access-list 101 permit icmp any any unreachable

203 : access-list 101 permit icmp any any port-unreachable

204 : access-list 101 permit icmp any any packet-too-big

205 : access-list 101 deny ip any any

214 : access-list 121 permit ip 192.168.252.0 0.0.3.255 any

215 : access-list 122 permit icmp 172.30.0.0 0.1.255.255 any echo

218 : access-list 122 permit icmp 172.30.0.0 0.1.255.255 any echo-reply

221 : access-list 122 permit icmp 172.30.0.0 0.1.255.255 any packet-too-big

224 : access-list 122 permit icmp 172.30.0.0 0.1.255.255 any ttl-exceeded

227 : access-list 123 permit icmp any any fragments

228 : access-list 123 permit udp any any fragments

229 : access-list 123 permit tcp any any fragments

238 : snmp-server trap-source Loopback0

239 : snmp-server enable traps tty

240 : snmp-server host 192.168.255.1 version 2c s3cr3t

continues

Trang 7

272 : **** AUTHORIZED ACCESS ONLY *****

273 : **** This system is the property of SP AS65001.

274 : **** Disconnect IMMEDIATELY if you are not an authorized user!

289 : process cpu threshold type total rising 80 interval 5 falling 20 interval 5

Trang 8

Data Plane

In this case study, and from the perspective of router PE-00, data plane trafﬁc includes the following:

• Internal to internal traffic: Data plane traffic in this category includes traffic that is

sourced by and destined to devices wholly within the administrative domain of the SP (AS 65001) In the case of PE-00, this includes all packets routed between the redundant uplinks (that is, only those packets routed between Serial1/0/0 and Serial2/0/0) Many

SP network designs are architected such that internal to internal data plane trafﬁc is

routed exclusively through core routers and not through edge routers except during multiple core failure conditions In this way, the PE-00 uplink interface capacity is used exclusively for trafﬁc routed between internal and external interfaces and, of course, control and management plane protocols Hence, in this case study and from the perspective of PE-00, no data plane trafﬁc is included in this category

• Internal to external traffic: Data plane traffic in this category includes traffic that is

sourced within the SP internal infrastructure but destined to external networks outside the SP’s administrative domain Support for such internal to external trafﬁc forwarding

is required by some external applications such as IP traceroute and Path MTU Discovery (PMTUD) For the purposes of this case study and from the perspective of PE-00, this type of internal to external data plane trafﬁc is limited to certain ICMP types—for example, Fragmentation Needed but Do Not Fragment Bit Set (Message Type 3, Code 4) and Time Exceeded (Message Type 11)—and comes from internal interfaces within the SP internal infrastructure preﬁx range 172.30.0.0/15

• External to internal traffic: Data plane traffic in this category includes traffic that is

sourced externally and destined for internal SP infrastructure, such as in the case of SPs with hosted content However, in this case study and from the perspective of PE-00, no legitimate data plane traffic is included in this category Therefore, such traffic is filtered at the network edge to mitigate the risk of an attack against the internal SP infrastructure

• External to external traffic: Data plane traffic in this category includes traffic that is

sourced externally and destined to an external network Such trafﬁc requires transit

Trang 9

from the SP and possibly the wider Internet for remote connectivity For SPs, this often represents the vast majority of the data plane traffic seen within the network In this case study and from the perspective of PE-00, this includes any traffic that ingresses an external interface, such as Serial0/0/0, and that is destined to a prefix only reachable through another external interface The egress external interface can exist

on either PE-00 or a different edge router within the SP network (AS 65001) Either way, external to external trafﬁc simply transits the SP network

Data Plane Security

From the perspective of PE-00, the techniques used for data plane security include the following:

• Interface ACL: A combined infrastructure and antispooﬁng ACL is applied to the

Serial0/0/0 interface to filter any ingress traffic destined to SP internal infrastructure, including the SP NOC, and any special-use and reserved IP addresses (per RFC 3330) This policy is defined through the extended ACL 100 (lines 177 through 189), which

is attached to the Serial0/0/0 interface in the input direction on line 110 Note that this input ACL applies to all ingress traffic Because PE-00 exchanges only data plane packets with CPE-A0, no permit ACL entries are included for control, management, and services plane traffic The only traffic that is filtered is traffic destined to internal

SP infrastructure addresses and spoofed trafﬁc that is using special-use and reserved

IP addresses All other traffic is allowed Although it is possible for the SP to also configure an egress ACL on Serial0/0/0 as well, rarely would it do so for unmanaged Internet access customers In this case, Customer A has taken the responsibilities for managing its Internet access (CPE) router itself, as was described in Chapter 8 The interface ACL policy mitigates the risk of both direct attacks against the SP internal infrastructure and spoofing attacks using special-use and reserved IP addresses

• uRPF: Unicast RPF strict mode is deployed on the PE-00 external interface to

Customer A for antispoofing protection The use of uRPF strict mode will filter (drop) any ingress traffic sourced from outside the Customer A HQ network public address blocks, including 172.16.0.0/24 and 209.165.200.226/32 Only ingress traffic having

an IP source address within these two address blocks is permitted by uRPF strict mode Configuration line 111 enables uRPF for antispoofing protection on the Serial0/0/0 interface The uRPF policy mitigates the risk of spoofing attacks

• QoS: QoS is deployed within the SP network in support of differentiated services

and to isolate important control plane traffic from the other IP traffic planes The associated policy map (lines 86 through 94) and class maps (lines 50 through 57) are defined using MQC The policy is then attached to the PE-00 uplink interfaces, including Serial1/0/0 and Serial2/0/0 per lines 128 and 137 If the PE-00 uplinks

Trang 10

become congested, QoS will reserve 20 percent of uplink bandwidth for control plane trafﬁc To ensure that low-priority external trafﬁc does not inadvertently or maliciously

enter the high-priority trafﬁc classes (in other words, gold, silver, control), a QoS

recoloring policy is applied to Internet access ports, including the PE-00 serial interface (Serial0/0/0) to CPE-A0 (line 119) The associated policy (lines 70 through 72) simply recolors all traffic with IP precedence 0 This prevents any transit Internet traffic from being classified into the SP’s high-priority traffic classes Hence, the queuing and recoloring policies mitigate the risk of resource (bandwidth) exhaustion attacks against high-priority traffic classes including control plane protocols

• IP options: IP packets with option headers are ﬁltered by the ip options drop global

conﬁguration command (line 35) The IOS default behavior of IP source routing is

also disabled with the no ip source-route global conﬁguration command (line 32)

Disabling IP options in this way mitigates the risk of IP options–based attacks

• ICMP techniques: On a per-interface basis, several ICMP best common practices

(BCP) are also applied ICMP Destination Unreachable and Redirect message

generation is disabled using the no ip unreachables (line 113) and no ip redirects

(line 112) interface conﬁguration commands, respectively Global rate limiting of ICMP Destination Unreachable message generation is also enabled via line 34 ICMPInformation Request and Address Mask Request processing is disabled by default

within IOS; hence, the no ip information-reply and no ip mask-reply interface

commands are applied by default Disabling ICMP processing in this way mitigates the risk of transit IP data plane attacks and ICMP-based control plane attacks

• IP directed broadcasts: The dropping of IP directed broadcast packets is the default

behavior in IOS 12.0(32)S and, hence, the no ip directed-broadcast interface

command is applied by default (line 114) Earlier versions of IOS forwarded IP directed broadcast packets by default You should conﬁrm the default behavior for your IOS release in order to properly mitigate the risk of directed broadcast based attacks

• Edge router external link protection: Whereas IP reachability from the wider Internet

to the CPE-A0 Serial0/0 interface is required for IPsec VPN services as outlined previously, it is not required to the PE-00 Serial0/0/0 interface To mitigate the risk of remote attacks against PE routers that leverage IP reachable external interface addresses, an aggregate static route to Null0 is configured on every edge and core router within the SP network (line 168) As a result, remote external traffic destined to an external PE-CE (Internet access) interface is now discarded as described in detail in Chapter 4 Because this configuration has the additional impact of making local eBGP

next hops no longer reachable, BGP next-hop-self (line 159) must be set for iBGP

sessions Further, to maintain IP reachability to CPE-A0 in support of IPsec VPN and NAT services, a static route for the host preﬁx 209.165.200.226/32 is also conﬁgured

(line 169) and redistributed into iBGP (line 157) The no peer neighbor-route

Trang 11

command (line 117) is also configured on the Serial0/0 interface to ensure that the 209.165.200.226/32 connected prefix does not appear in the router RIB, which would prevent the 209.165.200.226/32 static route from being redistributed into iBGP Redistributing 209.165.200.226/32 into iBGP enables remote IP reachability to CPE-A0 in support of IPsec VPN services Note that the generation of ICMP Destination Unreachable messages is also disabled on the Null0 interface via line 105 This is important, because without this configuration, ICMP Destination Unreachable messages would be generated by the Null0 interface, possibly causing high CPU utilization (Note that the Null0 interfaces will not appear in the router configuration

unless default interface conﬁguration parameters are modiﬁed, such as no ip

unreachables.) The PE-CE link protection policy using an aggregate static route to

Null0 mitigates the risk of remote attacks against PE external interfaces

• Remotely triggered black hole (RTBH) ﬁltering: As detailed in Chapter 4, RTBH

mechanisms must be predeployed before they can be used for security incident response The configuration necessary on PE-00 is simply a static route to the Null0 interface (line 167) This prepares the router for destination-based RTBH filtering, which would be invoked by a remote trigger router Because uRPF is also enabled on PE-00, as described previously in this list, source-based RTBH filtering can also be invoked by a remote trigger router

Control Plane

In this case study, and from the perspective of router PE-00, control plane trafﬁc includes the following:

• IGP trafﬁc: The SP uses OSPF as its IGP, which is enabled on all internal and

loopback interfaces throughout the SP infrastructure Because static IP default routing

is used by the Customer A CPE routers, neither OSPF nor BGP is enabled on the PE-00 external interface to CPE-A0 Although Customer A uses OSPF as its IGP between remote sites, it runs within the IPsec VPN services layer, and hence appears

as native data plane trafﬁc to the PE-00 Further, these two instances of OSPF are completely unique because they support completely unrelated administrative domains Therefore, no OSPF adjacencies are formed between PE-00 and CPE-A0 In the case of PE-00, OSPF is enabled on the uplinks, which represent the 172.30.4.1/30 and 72.31.4.1/30 networks, and on the 192.168.1.5/32 preﬁx associated with Loopback0

• BGP: Although eBGP is not used between PE-00 and CPE-A0, iBGP is enabled on

all edge and core routers within the SP network in support of interdomain (Internet) routing

Trang 12

• Layer 2 keepalives: L2 keepalives will be used on all of the Serial interfaces of

PE-00 L2 keepalives are not used for Ethernet nor are they applicable to virtual interfaces such as Loopback0

Control Plane Security

From the perspective of PE-00, the techniques used for control plane security include the following:

• Selective Packet Discard (SPD): SPD is turned on by default, and on 12000 series

routers, aggressive mode is the only mode available Hence, no additional conﬁguration

is required The hold-queue, headroom, and extended headroom default settings are adequate as well

• IP Receive ACLs: An IP rACL is applied to ﬁlter unauthorized trafﬁc destined to the

IOS process level on PE-00 Configuration lines 190 through 205 define the IP rACL policy using the extended ACL 101, which is then applied to the receive interface in the inbound direction on line 48 All traffic flows are denied by the IP rACL except for the following:

— OSPF trafﬁc sourced from 192.168.1.0/24 and with IP precedence 6

— Several types of ICMP packets (management plane trafﬁc) must be

permitted by the rACL for operational needs (Echo Reply, Time Exceeded, and certain IP destination unreachables) These ACE rules are conﬁgured on lines 199 through 204

Per Chapter 5, “Control Plane Security,” all CEF receive adjacency trafﬁc

has to be accounted for within the IP rACL policy, including both control and

management plane trafﬁc IP rACLs mitigate the risk of unauthorized

(attack) trafﬁc from reaching the IOS process level

• Control Plane Policing (CoPP): CoPP is enabled to protect IOS process level

functions, including control and management plane services Only distributed CoPP

is enabled by applying MQC service policies to the control plane, as shown on lines

242 through 269 The associated MQC policies that permit, deny, or rate limit control and management plane traffic flows are defined via lines 73 through 85 The MQC class maps and extended ACLs used for CoPP packet classification are configured via lines 58 through 67, and 206 through 230, respectively Because the catch-all

Trang 13

CoPP-remaining-IP trafﬁc class (line 82) directly precedes it, the class-default portion

of the CoPP policy map (lines 84 and 85) accounts for all Layer 2 keepalive traffic only Note, the routing and class-default traffic classes are unpoliced The management, normal (ICMP), and remaining IP traffic classes are rate limited Traffic classified into the undesirable class is dropped Per Chapter 5, all IOS process level traffic has to be accounted for within the CoPP policy, including control and management plane traffic

as well as exception data plane traffic CoPP mitigates the risk of unauthorized traffic and exception IP transit traffic from reaching the IOS process level

• OSPF MD5 authentication: OSPF is enabled on lines 139 through 146 Further,

within the OSPF routing process itself, passive-interface is conﬁgured for the

Loopback0 interface, as shown on line 143 MD5 authentication for conﬁgured OSPF areas is also enabled (line 142) MD5 authentication passwords are conﬁgured on each

of the internal physical interfaces, including Serial1/0/0 (line 127) and Serial2/0/0 (line 136) Note that even though the preﬁx associated with Loopback0 is enabled for OSPF, this interface does not require the MD5 key to be applied because it is a virtual interface and no adjacency is formed MD5 authentication helps to mitigate the risk

of attacks against OSPF

• BGP MD5 authentication: BGP is enabled on lines 148 through 163 BGP MD5

authentication (line 153) is enabled between PE-00 and the BGP route reﬂector (192.168.1.2/32) within the SP network MD5 authentication helps to mitigate the risk

of attacks against BGP

Management Plane

In this case study, and from the perspective of router PE-00, in-band management plane trafﬁc includes the following:

• Provisioning trafﬁc: Management plane trafﬁc in this category includes SSH and

TFTP trafﬁc and must be sourced internally from the SP NOC (192.168.252.0/22) Telnet and HTTP are not permitted In the case of PE-00, ingress management trafﬁc

of this type will be destined to the 192.168.1.5/32 address of Loopback0 Egress management trafﬁc of this type will be destined to the 192.168.252.0/22 preﬁx of the

SP NOC

• Monitoring trafﬁc: Management plane trafﬁc in this category includes SNMP,

NetFlow, and Syslog, and this traffic is only authorized to and from the internal network In the case of PE-00, ingress SNMP traffic will be destined to the 192.168.1.5/32 address of Loopback0 Egress management traffic of this type will

be destined to the 192.168.252.0/22 preﬁx of the SP NOC Local NetFlow collectors are not included in this case study, which would generally require export to an internal address outside of the SP NOC 192.168.252.0/22 address block

Trang 14

• Other trafﬁc: Several other protocols are conﬁgured within the management plane,

including NTP, DNS, and TACACS+ In the case of PE-00, management trafﬁc of this type will all be within the SP NOC 192.168.252.0/22 address block In addition, several types of ICMP packets must be permitted by the IP rACL and CoPP policies (see the preceding “Control Plane” section) for operational needs, including ICMP Echo Request, Echo Reply, Time Exceeded, and speciﬁc IP Unreachable types CDP

is disabled on external interfaces but enabled on internal interfaces

• Out-of-band trafﬁc: The console interface is used for OOB management access.

Management Plane Security

From the perspective of PE-00, the techniques used for management plane security include the following:

• Out-of-band management: Password authentication is enabled for terminal access

using the console port (line 280) Password authentication mitigates the risk of unauthorized access

• SNMP: SNMP parameters are conﬁgured via lines 237 through 240, which includes

sending SNMP traps in v2c format to the SP NOC (line 240) Only read-only SNMP access is allowed (line 237) given that no read-write community string is conﬁgured Further, SNMP read access is restricted to sources permitted within the SNMP conﬁgured standard ACL 10 (line 176) SNMP packets greater than 1500 bytes are

also discarded, given the IOS default behavior for snmp-server packetsize These

SNMP security techniques mitigate the risk of unauthorized access and network reconnaissance

• Disable unused services:

— BOOTP: BOOTP services are disabled on line 41.

— CDP: CDP is disabled on external interfaces only (line 118).

— DHCP: DHCP server functions are disabled on line 9

— DNS-based host name-to-address translation: DNS-based name

resolution by the router is disabled on line 45

— EXEC mode: Because the auxiliary port is not used for in-band or

out-of-band management, EXEC mode is disabled (line 282) on the auxiliary port

— Finger service: The ﬁnger service is disabled on line 37

— HTTP server: The (unsecure) HTTP server is disabled on line 170.

— Minor servers: Both the minor TCP and UDP servers are disabled by

default within IOS

Trang 15

— NTP: NTP is disabled on external interfaces only (line 116) The NTP

conﬁguration associated with internal interfaces is described later in this list

— PAD: The PAD service is disabled on line 3.

These management plane security techniques mitigate the risk of unauthorized access and network reconnaissance

• AAA: AAA is fully enabled for authentication, authorization, and accounting This

begins with the aaa new-model conﬁguration command (line 21) TACACS+ serves

as the primary authentication mechanism (lines 22 and 23) for both user-level and privilege-level (enable) EXEC mode access If PE-00 loses IP connectivity to the TACACS+ server for whatever reason, local username/password authentication will

be used for user-level EXEC mode access (line 22) and enable password authentication

will be used for privilege-level (enable) EXEC mode access (line 23) A local

noc-admin username and password is conﬁgured (lines 29) in support of local username/

password authentication The enable secret is conﬁgured (line 27) in support of enable password authentication Command authorization is conﬁgured to use TACACS+ and then none (in other words, no authorization) if IP connectivity to the TACACS+ server

is lost (line 24) Command accounting is also configured to use TACACS+ (lines 25 and 26) The TACACS+ server-related parameters are configured via lines 233 through 236 The configuration of the TACACS+ server itself is outside the scope of this book The preceding AAA policies mitigate the risk of unauthorized access and provide user accounting

• SSH services: Conﬁguring SSH requires that an IP domain name be speciﬁed (for

RSA key generation) This is done via line 46 The RSA encryption key is generated outside the conﬁguration during router setup SSH protocol parameters are conﬁgured

on lines 42 through 44, and VTY lines are restricted to SSH transport (line 287) Remote terminal access is further restricted to sources matching ACL 10, per lines

284 and 285 SSH provides secure remote terminal access to IP routers As such, it mitigates the risk of session eavesdropping, which may compromise router conﬁgurations, passwords, and so on and be leveraged for an attack

• Disable idle user sessions: Idle EXEC sessions are disabled after 5 minutes (lines

279 and 286) Further, TCP keepalives are enabled via lines 5 and 6 and serve to terminate connections where the remote host disappears (provide no positive acknowledgement [ACK]) Disabling idle user sessions in this way reduces the risk

of unauthorized access

• NTP: NTP is enabled to facilitate correlation of network events (line 290 through

295) Ingress NTP protocol messages are restricted to sources permitted within the NTP conﬁgured standard ACL 10 (line 294) Further, MD5 authentication is enabled for NTP protocol message exchanged with the conﬁgured NTP server (lines 290

Trang 16

through 292 and line 295) MD5 authentication helps to mitigate the risk of attacks against NTP, which is valuable for network event correlation, including security incident response.

• Syslog: Syslog parameters are conﬁgured on lines 173 through 175, which includes

directing Syslog messages to the SP NOC (line 175) Timestamps are also appended

to each Syslog (and debug) message per lines 7 and 8 In addition, Syslog is conﬁgured to report OSPF adjacency changes (line 141) and BGP neighbor state changes (line 151) In order to generate Syslog messages when free memory resources are low, low-watermark levels are set for processor memory on line 30 Further, in order to generate Syslog messages when CPU resources are low, processor CPU threshold levels are set on line 289 Syslog provides valuable network telemetry and

is useful for security incident response

• Other BCPs: Other BCP router security conﬁgurations related to the management

plane are implemented The router host name is configured on line 11 Global service settings are modified, including enabling timestamps for all debug and logging messages (lines 6 and 7) and enabling password encryption services (line 8) The router boot image is specified on line 14 (lines 13 and 15 are auto-generated) Buffered logging is enabled at debug level and the buffer size is set (line 17) The display of logging messages to the console is disabled (line 18) The enable secret is set on line 27 Several global settings for router self-generated TCP sessions are adjusted, including enabling Nagle services (line 2), enabling TCP keepalives per

“Disable idle user sessions” above (lines 4 and 5), increasing the TCP window size (line 38), reducing the TCP SYN wait time (line 39), and enabling PMTUD (line 40)

In order to generate Syslog messages when free memory resources are low, a watermark level is set for processor memory on line 30 A message of the day (MOTD) login banner is conﬁgured on lines 271 through 276 Finally, in order to generate Syslog messages when CPU resources are low, processor CPU threshold levels are set on line 289

low-Services Plane

In this case study, there are no services plane requirements from the perspective of router PE-00 All services plane requirements occur on the customer side of the network in the form of GRE + IPsec VPNs, and are instantiated on the CPE routers as was demonstrated

in Chapter 8

Case Study 2: MPLS VPN

Case Study 2 focuses on a typical scenario where an MPLS VPN service is used to connect customer headquarters and remote sites within a private IP VPN across the SP’s shared IP network infrastructure A description of the case study network topology, functional requirements, and translated security requirements follows

Trang 17

Network Topology and Requirements

The SP network topology and assigned IP addressing schemes used within this case study are illustrated in Figure 9-4 Customer B has three sites connected using a managed MPLS VPN service, and all three sites obtain their any-to-any VPN connectivity by direct connections to the same SP network Hence, the Inter-AS VPN architectural options (a), (b), and (c) per RFC 4364 section 10 (see Chapter 2, “Threat Models for IP Networks,” and Chapter 7, “Services Plane Security”) do not apply to this case study The conﬁgurations and security techniques for the managed CE routers are reviewed in the companion enterprise case study in Chapter 8

Figure 9-4 Conceptual Enterprise Network Architecture for MPLS VPN Case Study 2

Internet

Peer #1 Network

Peer #2 Network

Customer B

Remote 2

Service Provider IP/MPLS Core (AS 65001)

CE-B2

Customer A

HQ Network (AS 65002)

Serial0/0 209.165.202.146/30

Serial0/0/0

209.165.202.145/30

Serial0/0 209.165.201.6/30

198.168.252.0/22

Serial0/0/0 209.165.201.5/30

Serial2/0/0 172.30.4.1/30

Serial0/0/0 209.165.200.241/32

Serial0/0/0 209.165.200.242/30

Case Study 2

VRF CustB

PE-02 PE-01

MPLS VPN

Loopback0 192.168.0.3/32

Loopback0 192.168.1.1/32

PE-03

All internal network

interfaces within the SP

network are assigned IP

addresses within the

CE-B0

CE-B1

Loopback0 192.168.0.1/32

Loopback0 192.168.0.2/32

VRF CustB

MPLS

MPE P-02

VRF CustB

PE-04 PE-05

Management VRF

PE-00

Trang 18

The functional requirements assumed in this case study are as follows:

• MPLS VPN: The SP (AS 65001) provides any-to-any IP VPN connectivity between

all of the geographically disperse Customer B offices The IP VPN is built within the SP network using RFC 4364 MPLS VPNs BGP routing is used between the Customer B CE routers and the associated SP MPLS VPN PE routers to exchange Customer B prefix information The SP in turn carries these customer-specific prefixes within Multiprotocol BGP (MBGP) to provide reachability between customer sites within a single customer IP VPN and to provide addressing and routing separation between different customer IP VPNs

• Intranet Access: Access to Customer B’s MPLS VPN and associated network

preﬁxes is restricted to Customer B ofﬁces only There is no Internet access from the Customer B VPN, or vice versa External IP reachability is only provided between the

CE router loopback addresses and the SP NOC for management purposes given that the Customer B CE routers are managed (as described directly below)

• Managed CE router: All Customer B CE routers are managed by the SP For

operational reasons, then, the SP must have in-band access to each managed CE router The SP also manages the MPLS VPN PE and core (P) routers The PE and

P routers are managed both in-band and out-of-band using the console ports Management applications assumed in this case study include SSH, Syslog, SNMP, NTP, TFTP, and TACACS+

Figure 9-5 highlights the types and relationships of the interfaces associated with the MPLS VPN PE router in this case study

You were ﬁrst introduced to these interface types in Chapter 3 The following interfaces are included in this case study:

• Internal: Internal interfaces connect network assets wholly within one administrative

domain All SP routers shown in Figure 9-4 include at least two internal interfaces

In this case study, interfaces Serial1/0/0 and Serial2/0/0 of PE-03 are considered internal to the SP network For all internal interfaces, /30 subnet masking is used for the purposes of this case study The preﬁxes associated with these internal interfaces are routable within the IGP (OSPF in this case study) External reachability to these internal preﬁxes is not allowed per the MPLS VPN architecture, as outlined in Chapter 7

• External: External interfaces connect networks belonging to two different

administrative domains All SP MPLS VPN edge (PE) routers include at least one external interface Hence, by deﬁnition, an edge router normally includes at least one external interface In the MPLS VPN case, the PE-CE link is contained within a VRF Although the VRF routing table is customer speciﬁc, it is associated with customer

Trang 19

routing and not the SP IGP Hence, from the SP perspective, the PE-CE link is considered external Conversely, from the enterprise perspective, because the link is contained within the IP VPN, it may be treated as internal, per Chapter 8.

• Loopback: All SP edge and core routers shown in Figure 9-4 implement a single

loopback interface that is used for control and management plane trafﬁc All loopback interfaces within this case study are assigned from the 192.168.1.0/24 address block,

as shown in Figure 9-4 The /32 IP subnets associated with these internal interfaces are also carried within the SP IGP (OSPF in this case study)

• Receive: All routers include by default a receive interface that “logically” represents

the slow path to the IOS process level The receive path applies to any ingress packets that must be punted from the CEF fast path to be processed locally by the router’s CPU whether transit or receive adjacency packets Because the receive path represents

an exception packet processing path between the CEF fast path and IOS process level,

it is not assigned or associated with a speciﬁc IP subnet

Figure 9-5 IP Trafﬁc Plane Relationships to Router Interfaces for MPLS VPN Case Study 2

Figure 9-5 highlights in particular the router of focus for this case study, PE-03, and illustrates the relationship among its interfaces This router is also the focus for the sample IOS conﬁguration that follows

Internet Peer #1

Network

Peer #2 Network

Service Provider IP/MPLS Core PE-02

PE-03

Data Plane

Control Plane

Management Plane

Internal Interfaces

Loopback Interface Receive Interface

Management Plane Control Plane Data Plane

VRF Customer B

CE-B0

External Interface

Trang 20

Router Conﬁguration

Security conﬁgurations may be derived based upon the topology and functional requirements presented in the preceding section Router PE-03 is used as the focal point for the remaining discussions; however, the other MPLS VPN PE routers shown in the topology

in Figure 9-4 have similar but locally speciﬁc conﬁgurations Note that PE-02 represents a shared edge router supporting both Internet and MPLS services

Example 9-2 provides the derived IOS configuration that satisfies the preceding requirements and the defense in depth and breadth security principles This configuration assumes that PE-03 is a Cisco 12000 series router (12416), and that it is running Cisco IOS Software Release 12.0(32)S with the SSH feature set Similar to Example 9-1, line numbers precede each configuration command shown in Example 9-2 and serve as reference points for the remainder of the discussion that directly follows, which is organized by IP traffic plane

Example 9-2 Case Study 2 SP MPLS VPN Provider Edge Router Conﬁguration

6 : service timestamps debug datetime msec localtime show-timezone

7 : service timestamps log datetime msec localtime show-timezone

21 : aaa authentication login default tacacs+ local

22 : aaa authentication enable default tacacs+ enable

23 : aaa authorization exec default tacacs+ none

26 : enable secret 5 $1$rdYk$45iBa5oBI.QGmjoFDS9j00

27 : !

28 : username noc-admin secret 5 $1$z.rf$jFH3rwXPQdsXP8FxUeCV5.

29 : memory free low-watermark processor 100000

30 : ip subnet-zero

31 : no ip source-route

32 : no ip gratuitous-arps

continues

Trang 21

33 : ip icmp rate-limit unreachable 100

82 : class-map match-all CoPP-routing

Example 9-2 Case Study 2 SP MPLS VPN Provider Edge Router Conﬁguration (Continued)

Trang 23

Trang 24

185 : neighbor 192.168.1.2 send-community both

195 : neighbor 209.165.200.242 maximum-prefix 250 restart 2

196 : neighbor 209.165.200.242 ttl-security hops 1

205 : logging trap notifications

206 : logging source-interface Loopback0

227 : access-list 101 permit udp 192.168.1.0 0.0.0.255 any eq 646 precedence internet

228 : access-list 101 permit udp 192.168.1.0 0.0.0.255 eq 646 any precedence internet

continues

Trang 25

229 : access-list 101 permit tcp 192.168.1.0 0.0.0.255 any eq 646 precedence internet

230 : access-list 101 permit tcp 192.168.1.0 0.0.0.255 eq 646 any precedence internet

231 : access-list 101 permit icmp any any echo

232 : access-list 101 permit icmp any any echo-reply

233 : access-list 101 permit icmp any any ttl-exceeded

234 : access-list 101 permit icmp any any unreachable

235 : access-list 101 permit icmp any any port-unreachable

236 : access-list 101 permit icmp any any packet-too-big

237 : access-list 101 deny ip any any

243 : access-list 120 permit udp 192.168.1.0 0.0.0.255 any eq 646 precedence internet

244 : access-list 120 permit udp 192.168.1.0 0.0.0.255 eq 646 any precedence internet

245 : access-list 120 permit tcp 192.168.1.0 0.0.0.255 any eq 646 precedence internet

246 : access-list 120 permit tcp 192.168.1.0 0.0.0.255 eq 646 any precedence internet

265 : access-list 123 permit icmp any any fragments

266 : access-list 123 permit udp any any fragments

267 : access-list 123 permit tcp any any fragments

269 : !

Trang 26

271 : tacacs-server timeout 2

272 : no tacacs-server directed-request

273 : tacacs-server key 7 s3cr3t

274 : snmp-server community s3cr3t RO 10

275 : snmp-server trap-source Loopback0

276 : snmp-server enable traps tty

277 : snmp-server host 192.168.255.1 vrf CustB-VPN s3cr3t

278 : snmp-server host 192.168.255.1 version 2c s3cr3t

315 : **** AUTHORIZED ACCESS ONLY *****

316 : **** This system is the property of SP AS65001.

317 : **** Disconnect IMMEDIATELY if you are not an authorized user!

Trang 27

Data Plane

In this case study, and from the perspective of router PE-03, no data plane trafﬁc is included

in this category Rather VPN customer transit trafﬁc is handled within the IP services plane

Data Plane Security

External trafﬁc is not associated with the IP data plane in any way given that this is an MPLS VPN service External trafﬁc is associated with the control, management, and services planes only, as described in the respective sections that follow Therefore, in this case study, there are no data plane security requirements from the perspective of router PE-00

Control Plane

In this case study, and from the perspective of router PE-03, control plane trafﬁc includes the following:

• BGP: Control plane trafﬁc in this category includes eBGP trafﬁc between the PE-03

Serial0/0/0 address and the Serial0/0 address on CE-B0 BGP routing is used to dynamically exchange VPN preﬁx information between Customer B ofﬁces and the

SP network This category also includes MBGP trafﬁc, which operates between the PE-03 and its internal MBGP (M-iBGP) peers M-iBGP routing is used to

Trang 28

dynamically exchange VPN preﬁx information between SP MPLS VPN PE routers within the SP network Deployed in combination, eBGP and M-iBGP provide reachability between customer sites within a single customer IP VPN as well as addressing and routing separation between different customer IP VPNs.

• IGP trafﬁc: Control plane trafﬁc in this category includes OSPF, which is used as

the IGP within the SP network OSPF is conﬁgured for all internal and loopback interfaces within the SP infrastructure and provides IP reachability between BGP next hops and, optionally, to the SP NOC In the case of PE-03, OSPF is enabled on the uplinks, including the 172.31.5.1/24 and 172.30.5.1/24 networks, and on the 192.168.1.1/32 preﬁx for Loopback0

• Label Distribution Protocol: Control plane trafﬁc in this category includes LDP

(RFC 3036), which is used as the label distribution protocol by the SP in this case study LDP is configured for all internal interfaces within the SP infrastructure and distributes MPLS labels for all of the MPLS VPN PE /32 loopback prefixes carried within the IGP (OSPF in this case) Distributing labels only for /32 loopback addresses of PE routers results in MPLS label switched paths (LSP) being established between ingress and egress PE routers only In this way, only services plane traffic

is label switched across the SP network, and not internal SP data, control, and management plane trafﬁc Nevertheless, LDP serves as a control plane protocol for the establishment of MPLS LSPs across the SP network between ingress and egress MPLS VPN PE routers

• Layer 2 keepalives: L2 keepalives will be used on all of the Serial interfaces of

PE-03 L2 keepalives are not used for Ethernet nor are they applicable to virtual interfaces such as Loopback0

Control Plane Security

From the perspective of PE-03, the security mechanisms that will be used for control plane trafﬁc segmentation and control include the following:

• Selective Packet Discard (SPD): SPD is turned on by default, and on 12000 series

routers, aggressive mode is the only mode available Hence, no additional conﬁguration

is required The hold-queue, headroom and extended headroom default settings are adequate as well

• IP Receive ACLs: An IP rACL is applied to ﬁlter unauthorized trafﬁc destined to the

IOS process level on PE-03 Configuration lines 216 through 237 define the IP rACL policy using the extended ACL 101, which is then applied to the receive interface in the inbound direction on line 60 All traffic flows are denied by the IP rACL except for the following:

— OSPF trafﬁc sourced from 192.168.1.0/24 and with IP precedence

6 (line 216)

— BGP trafﬁc sourced from an internal BGP route reﬂector (192.168.1.2/24) and with IP precedence 6 (lines 217 and 218)

Trang 29

— BGP trafﬁc sourced from CE-B0 external Serial0/0 interface (209.165.200.242/32) and with IP precedence 6 (lines 219 and 220).

— Management trafﬁc sourced from the SP NOC 192.168.252.0/22 (lines 221 through 226)

— LDP trafﬁc sourced from 192.168.1.0/24 and with IP precedence 6 (line 227 through 230)

— Several types of ICMP packets (management plane trafﬁc) must be permitted

by the rACL for operational needs (Echo Reply, Time Exceeded, and certain

IP Destination Unreachables) These ACE rules are conﬁgured on lines 231 through 236

Per Chapter 5, all CEF receive adjacency traffic has to be accounted for within the IP rACL policy, including both control and management plane traffic IP rACLs mitigate the risk of unauthorized (attack) traffic from reaching the IOS process level

• Control Plane Policing (CoPP): CoPP is enabled to protect IOS process level

functions, including control and management plane services Only distributed CoPP

is enabled by applying MQC service policies to the control plane, as shown on lines

285 through 312 The associated MQC policies that permit, deny, or rate limit control and management plane traffic flows are defined via lines 88 through 100 The MQC class maps and extended ACLs used for CoPP packet classification are configured via lines 74 through 83, and 238 through 268, respectively Because the catch-all CoPP-remaining-IP traffic class (line 97) directly precedes it, the class-default portion of the CoPP policy map (lines 99 and 100) accounts for all Layer 2 keepalive traffic only Note, the routing and class-default traffic classes are unpoliced The management, normal (ICMP), and remaining IP traffic classes are rate limited Traffic classified into the undesirable class is dropped Per Chapter 5, all IOS process level traffic has to be accounted for within the CoPP policy, including control and management plane traffic as well as exception data plane traffic CoPP mitigates the risk of unauthorized traffic and exception IP transit traffic from reaching the IOS process level

• OSPF MD5 authentication: OSPF is enabled on lines 157 through 164 Further,

within the OSPF routing process itself, passive-interface is conﬁgured for the

Loopback0 interface, as shown on line 161 MD5 authentication for configured OSPF areas is also enabled (line 160) MD5 authentication passwords are configured on each of the internal physical interfaces, including Serial1/0/0 (line 143) and Serial2/0/0 (line 154) Note that even though the prefix associated with Loopback0 is enabled for OSPF, this interface does not require the MD5 key to be applied because it is a virtual interface and no adjacency is formed MD5 authentication helps to mitigate the risk of attacks against OSPF

Trang 30

• BGP MD5 authentication: BGP MD5 authentication is applied to the internal

M-iBGP session (line 171) MD5 authentication helps to mitigate the risk of attacks against BGP

• BGP TTL Security Check: GTSM is only supported for eBGP sessions and is also

conﬁgured on a per-neighbor basis Because PE03 and CE-B0 are directly connected eBGP peers, a GTSM hop count of 1 is conﬁgured (line 196) The BGP TTL Security Check helps to mitigate the risk of attacks against eBGP

• BGP prefix limits: Neighbor maximum prefix limits are configured on line 195

This prevents CPE-B0 from ﬂooding PE-03 with a large number of VPN preﬁxes and, thereby, consuming the full Customer B VPN routing table, which is limited to

1000 preﬁxes (line 53)

• VPN preﬁx maximum: To control the maximum number of routes within the

Customer B VPN routing table and the aggregate VPN routes maintained by PE-03, a maximum limit is imposed per customer VPN (line 53)

• LDP MD5 authentication: MD5 authentication is enabled for LDP (line 56) MD5

authentication helps to mitigate the risk of attacks against LDP

Management Plane

In this case study, all CE routers are assumed to be managed in-band by the SP Thus, the

SP assigns a globally unique IP address to each CE Loopback0 interface for management plane purposes These loopback interface addresses are reachable within the Management VPN deﬁned within the SP infrastructure Management plane trafﬁc from the perspective

of CE-B0 was reviewed in Chapter 8 From the perspective of router PE-03, management plane trafﬁc includes the following:

• Provisioning trafﬁc: Management plane trafﬁc in this category includes SSH and

TFTP trafﬁc and must be sourced internally from the SP NOC (192.168.252.0/22) Telnet and HTTP are not permitted In the case of PE-03, ingress management trafﬁc

of this type will be destined to the 192.168.1.1/32 address of Loopback0 Egress management trafﬁc of this type will be destined to the 192.168.252.0/22 preﬁx of the

SP NOC

• Monitoring trafﬁc: Management plane trafﬁc in this category includes SNMP,

NetFlow, and Syslog, and this traffic is only authorized to and from the internal network In the case of PE-03, ingress SNMP traffic will be destined to the 192.168.1.1/32 address of Loopback0 Egress management traffic of this type will be destined to the 192.168.252.0/22 prefix of the SP NOC Local NetFlow collectors are not included in this case study, which would generally require export to an internal address outside of the SP NOC 192.168.252.0/22 address block

Trang 31

• Other trafﬁc: Several other protocols are conﬁgured within the management plane,

including NTP, DNS, and TACACS+ trafﬁc In the case of PE-03, management trafﬁc

of this type will all be within the SP NOC 192.168.252.0/22 address block In addition, several types of ICMP packets must be permitted by the IP rACL and CoPP policies (see the preceding “Control Plane” section) for operational needs, including ICMP Echo Request, Echo Reply, Time Exceeded, and speciﬁc IP Unreachable types CDP

is disabled on external interfaces but enabled on internal interfaces

• Out-of-band trafﬁc: The console interface is used for out-of-band management

access

Management Plane Security

From the perspective of PE-03, the techniques used for management plane security include the following:

• OOB management: Password authentication is enabled for terminal access using the

console port (line 323) Password authentication mitigates the risk of unauthorized access

• SNMP: SNMP parameters are conﬁgured via lines 274 through 278, which includes

sending SNMP traps in v2c format to the SP NOC (line 278) Only read-only SNMP access is allowed (line 274) given that no read-write community string is conﬁgured Further, SNMP read access is restricted to sources permitted within the SNMP conﬁgured standard ACL 10 (line 274) SNMP packets greater than 1500 bytes are

also discarded, given the default IOS behavior for snmp-server packetsize These

SNMP security techniques mitigate the risk of unauthorized access and network reconnaissance

• Disable unused services:

— BOOTP: BOOTP services are disabled on line 40.

— CDP: CDP is disabled on external interfaces only (line 132).

— DHCP: DHCP server functions are disabled on line 9

— DNS-based host name-to-address translation: DNS-based name

resolution by the router is disabled on line 44

— EXEC mode: Because the auxiliary port is not used for in-band or

out-of-band management, EXEC mode is disabled (line 325) on the auxiliary port

— Finger service: The ﬁnger service is disabled on line 36

— HTTP server: The (unsecure) HTTP server is disabled on line 203.

— Minor servers: Both the minor TCP and UDP servers are disabled by

default

Trang 32

— NTP: NTP is disabled on external interfaces only (line 131) The NTP

conﬁguration associated with internal interfaces is described later in this list

— PAD: The PAD service is disabled on line 3.

These management plane security techniques mitigate the risk of

unauthorized access and network reconnaissance

• AAA: AAA is fully enabled for authentication, authorization, and accounting This

begins with the aaa new-model conﬁguration command (line 20) TACACS+ serves

as the primary authentication mechanism (lines 21 and 22) for both user- level and privilege-level (enable) EXEC mode access If PE-03 loses IP connectivity to the TACACS+ server for whatever reason, local username/password authentication will

be used for user-level EXEC mode access (line 21) and enable password authentication will be used for privilege-level (enable) EXEC mode access (line 22) The local

username noc-admin and password is conﬁgured (line 28) in support of local username/

password authentication The enable secret is configured (line 26) in support of enable password authentication Command authorization is configured to use TACACS+ and then none (that is, no authorization) if IP connectivity to the TACACS+ server is lost (line 23) Command accounting is also configured to use TACACS+ (lines 24 through 25) The TACACS+ server-related parameters are configured via lines 270 through

273 The conﬁguration of the TACACS+ server itself is outside the scope of this book The preceding AAA policies mitigate the risk of unauthorized access and provide user accounting

• SSH services: Conﬁguring SSH requires that an IP domain name be speciﬁed (for

RSA key generation) This is done via line 45 The RSA encryption key is generated outside the conﬁguration during router setup SSH protocol parameters are conﬁgured

on lines 41 through 43, and VTY lines are restricted to SSH transport (line 330) Remote terminal access is further restricted to sources matching ACL 10, per lines

327 and 328 SSH provides secure remote terminal access to IP routers As such, it mitigates the risk of session eavesdropping, which may compromise router conﬁgurations, passwords, and so on and be leveraged for an attack

• Disable idle user sessions: Idle EXEC sessions are disabled after 5 minutes

(lines 322 and 329) Further, TCP keepalives are enabled via lines 4 and 5 and serve

to terminate connections where the remote host disappears (provides no positive acknowledgement [ACK]) Disabling idle user sessions in this way reduces the risk

of unauthorized access

• NTP: NTP is enabled to facilitate correlation of network events (lines 333 through

339) Ingress NTP protocol messages are restricted to sources permitted within the NTP conﬁgured standard ACL 10 (line 337) Further, MD5 authentication is enabled for NTP protocol messages exchanged with the conﬁgured NTP server (lines 333

Trang 33

through 335 and line 338) MD5 authentication helps to mitigate the risk of attacks against NTP, which is valuable for network event correlation, including security incident response.

• Syslog: Syslog parameters are conﬁgured on lines 205 through 207, which includes

directing Syslog messages to the SP NOC (line 207) Timestamps are also appended

to each Syslog (and debug) message per lines 6 and 7 In addition, Syslog is conﬁgured

to report OSPF adjacency changes (line 159) and BGP neighbor state changes (line 169) In order to generate Syslog messages when free memory resources are low, low-watermark levels are set for processor memory on line 29 Further, in order to generate Syslog messages when CPU resources are low, processor CPU threshold levels are set on line 332 Syslog provides valuable network telemetry and is useful for security incident response

• Management VPN: The Management VPN is primarily used for management of

managed CE routers Nevertheless, it provides an alternate in-band management path

to PE routers in addition to the existing in-band access via the IGP (OSPF) and OOB access via the console port A route map is configured (lines 280 through 282) such that only the MPLS VPN PE-CE links are distributed (line 49) into the Management VPN Management plane functions—including but not limited to SNMP traps (line 277), NTP (line 339), and VTY access (line 327)—may also be configured to operate within the Management VPN Further, PE-03 is configured as a spoke within the Management VPN (line 52), which prevents IP reachability between any two PEs (and CEs) within the Management VPN

• Other BCPs: Other BCP router security conﬁgurations related to the management

plane are implemented The router host name is configured on line 11 Global service settings are modified, including enabling timestamps for all debug and logging messages (lines 6 and 7) and enabling password encryption services (line 8) The router boot image is specified on line 14 (lines 13 and 15 are auto-generated) Buffered logging is enabled at debug level and the buffer size is set (line 17) The display of logging messages to the console is disabled (line 18) The enable secret is set on line 26 Several global settings for router self-generated TCP sessions are adjusted, including enabling Nagle services (line 2), enabling TCP keepalives per “Disable idle user sessions” above (lines 4 and 5), increasing the TCP window size (line 37), reducing the TCP SYN wait time (line 5), and enabling PMTUD (line 39) In order to generate Syslog messages when free memory resources are low, a low-watermark level is set for processor memory on line 29 A message of the day (MOTD) login banner is configured on lines 314 through 319 Finally, in order to generate Syslog messages when CPU resources are low, processor CPU threshold levels are set on line 332

Định dạng
Số trang	67
Dung lượng	6,29 MB