Grumpy Networkers Journal Documentation Release 0.0.7
Head In The Cloud
Oct 21, 2019
Contents:
1 Networking 3 1.1 Virtual Private Networks...... 3 1.2 Network Protocols...... 56
2 Security 59 2.1 Common Network Attacks...... 59 2.2 Securing the Switch Infrastructure...... 60 2.3 Segregating Networks using Firewalls...... 60 2.4 Cryptography Overview...... 65 2.5 Authentication Services...... 67
3 Cloud Services 69 3.1 Cloud Deployment Models...... 69 3.2 Cloud Service Models...... 69
4 Documentation 71 4.1 Sphinx...... 71
5 Study Notes 73 5.1 Cisco CCNP - Implementing Cisco Secure Mobility Solutions (300-209 SIMOS)...... 73 5.2 Cisco CCNP - Implementing Cisco Edge Network Security Solutions (300-206 SENSS)...... 74 5.3 Cisco CCNP - Implementing Cisco IP Switched Networks (300-115 SWITCH)...... 76
6 Vendor Implementations 163 6.1 Cisco Implementations...... 163
7 To Do 209
8 Glossary of Terms 213
9 External References 215 9.1 PPTP...... 215 9.2 Sphinx...... 215
10 Indices and tables 217
Bibliography 219
i Index 221
ii Grumpy Networkers Journal Documentation, Release 0.0.7
Warning: You agree to use anything included in this journal at your own risk, I make no guarantees that anything included will work in your environment or that it is even accurate. By making this journal public I hope that it is of use to fellow network/security engineers either in teaching them new things or troubleshooting that tricky problem. It is highly recommended that before trying any of the listed configurations that you do you own additional research to make sure it is compatible with your equipment and/or infrastructure.
Contents: 1 Grumpy Networkers Journal Documentation, Release 0.0.7
2 Contents: CHAPTER 1
Networking
dsfsdfsdfsdfsdfd
1.1 Virtual Private Networks
1.1.1 IPSEC VPNs
IKE Version 2
Overview
IKE Version 2 or simple IKEv2 for short was published in RFC4306 but has since been updated by a number of other RFCs, the latest being RFC 7296. It offers a number of improvements over the previous incarnation where weaknesses have been identified. Ihis is mostly a benefit it must be understand that the two versions whilst still similar are incompatible with each other and therefore both peers must support the new version of the protocol. The establishment of an IKEv2 VPN starts with an IKE_SA_INIT meesage whereby both peers negotiate a set of algorithms and agree on the secret key that is derived from additional key material. Additiona random data is added in the form of a nonce. Once established all furter messages will be encrypted and the integrity validated. The second part of the exchange called an IKE_AUTH is secured using the agreed properties from the first exchange. Each side of the exchange will authenticate each other using an integrity check generated from the secrets associated with their identity. Peers will then exchange algorithms that will be used to protect one or more IPSEC SAs using either ESP or AH that is then used to secure the actual user traffic. Each time an additional IPSec is required (Such as adding a new subnet to be encypted), an additional IKEv2 exchange will occur called a CREATE_CHILD_SA. In the case of IKEv22 these exchange are not referred to as Phase 2 SAs but instead called a Child SA.
3 Grumpy Networkers Journal Documentation, Release 0.0.7
Nonce
In order to make the output of the cryptographic function less predicatable. A certain amount of randomness is added. This is the purpose of the nonce and is a randomly generated value that is used as input to the data when authenticating peers. The nonce is sent by the initiator. The nonce must be a minimum of 128 bits an up to 2048 bits in size. In practice the nonce must be at least half the size of the output for the PRF function that is negotiated.
Denial of Service Protection
In order to offer more protection against Denial of Service IKEv2 provides defences in the form of cookies. These cookies are designed to defend against blind spoofing attacks as the initating party must be able to reply to the cookie request which is a lot less computationally expensive that a real IKEv2 exchange. In the event an IP address is spoofed, no reply will be forthcoming that the receiving party will not have wasted a lot resource establishing and storing the intial state for a peer that doesnt exist. The point at which this protection is enabled is configurable when a certain number of half connections are seen. This Denial of service protection only helps against attacks that are using faked IP addressing, in the situation where the real host (such as one involved in a botnet) is making the request and is able to reply resources would still be consumed. In the case of certain vendors, this protection is not enabled by default (such as Cisco). When enabled the initial IKE_SA_INIT is increased from a two way exchange to a four way exchange as the cookie needs to be send and received before the IKE responder will sent cryptographic material.
Certificate Request
In IKEv1 when certificate authentication was used the subject name of the CA was included. This introducted the risk that it could be duplicated. In IKEv2 this has been removed and now the responder can request that the initiator use a certifiate issued from a preferred cerificate authority by sending the SHA-1 hash of the public key of any trusted CA. The peer receiving the request can select a CA from one of those in the request.
Out-of-Band Certificate Lookup
Instead of receiving the request directly in the IKE exchange a peer can notify of it’s ability to retrieve a certificate via HTTP instead. The sending peer will then provide the 160-bit SHA-1 hash of the certifiate along with the URL where it can be be downloaded from. This is useful in situations where fragmentation may occur due to the size of the certificates or certificate chain. It should be noted that this method of authentication is not widely supported by all devices/vendors.
Extensible Authentication Protocol (EAP)
IKEv2 includes support for EAP as a valid method of authenticating an initiator. The responder must use a form of certificate (either RSA or ECDA) as it’s means of authentication when a reply is sent to the initiator. In this instance the initiator will repond first with it’s identity.
4 Chapter 1. Networking Grumpy Networkers Journal Documentation, Release 0.0.7
Initial Contact
In the event of a VPN peer crashing or other issue that causes it to loose the current cryptographic material IKEv2 includes a mechanism in which to detect if an existing SA is in place and to tear it down so a new session can be established. This is based on the premise that there is no point waiting resources trying to send encrypted packets to an endpoint that has no means to decrypted them. It is better to simply tear it down and start from scratch by agreeing new keying material.
Dead Peer Detection
IKEv1 included a means of sending keepalives to ensure that its peer were active and should be able to receive data. This however was wasteful on resources especially on a busy hub. An improvement was added to IKEv1 was an option called Dead Peer Detection. Whilst similar to keepalives, it is far more scaleable as it only sent keepalives when no data was being seen from that remote peer. As long as data was being seen or no data needed to be sent, the DPD mechanism would do nothing. One issue does exist however, because DPD will only sent a request when traffic needs to be sent over the VPN it may not notice the failed peer straight away. By using routing protocols over the tunnel however, this should not be an issue as they will notice the failure more quickly and where redundant links exist will reconverge as necessary. It is recommended that DPD be enabled so that in the event of failed peers the now unnecessary security assoications can be torn down. On the hub however if a large number of VPN peers fail this may place a lot of additional burden on this central device. Whilst DPD should be enabled on all spoke devices, care should be taken not to set the DPD timeout values too aggressive so that it doesn’t support from a Denial Of Service simply due to having to process to many DPD request/replies.
NAT-T
NAT-T offers a mechanism by which IPSec traffic can be sent through a NAT device. It was an optional features in IKEv1 but is mandatory in IKEv2. NAT-T works by encapsulating the ESP packets within a UDP packet (usually using UDP 4500) so that the NAT device can individually track the connections coming through it based on the source/destination port numbers. Prior to NAT-T it was necessary for devies to support IPSec Passthrough whereby the needed to keep track of the SPI information in the ESP headers to know what to do and this ofter limited the ability of the feature (for example only one IPSec device at a time). One problem that exists is when an IPSec connection is idle it isn’t sending or receiving any data so this would cause the NAT gateway to start the idle timer because according to RFC 3715 NAT entries should have finite lifetime. This is taken care of by sending NAT-T keepalives at certain intervals to avoid the NAT gateway tearing down the sessions. It should be noted that these keepalive packets whilst not carrying any protected data, are not encrypted in any way. A single payload of 0xFF is included in the packet. Note that because of the way in which Authentication Header (AH) validate the packet, it is still not possible to use AH and NAT with IKEv2 just as with IKEv1. NAT detection is included as part of the protocol and when detected the peers will automatically switch to encapsulat- ing the IKE and IPSec sessions within UDP (IP Protocl 17) over port 4500 (unless configured otherwise).
IKEv2 and IKEv1 Comparison
As previously mentioned although they perform the same function IKEv1 and IKEv2 and not compatible.
1.1. Virtual Private Networks 5 Grumpy Networkers Journal Documentation, Release 0.0.7
Two of the biggest advantages of IKEv2 are its inclusion of Next Generation Encryption (NGE) and anti denial-of- service capabilities. IKEv2 also includes EAP authenticaton which was not available as part of IKEv1. The overall packet structure of IKEv2 has also been redesigned to be more efficient, needing fewer packets and less bandwidth that IKEv1. The current form of IKEv1 is the combination of numerous RFCs which have resulted in a number of bolt-on features being added to IKEv1. Many of these features are now included in IKEv2 by default and therefore allowed for a cleaner design. IKEv2 no longer provides for Main Mode or Aggressive mode, instead there is a single IKE_SA_INIT as covered above. In IKEv1 the lifetime of the IKE SA was negotiated in the first pair of messages. This resulted in incompatibilities due to mismatched values. For IKEv2 the lifetime is now a locally configured value which is not negotiated between peers. A peer is responsible for deleting or rekying the SA when it’s local lifetime expires. Whilst ECDSA authentication was introduced to IKEv1 it was late coming and therefore has seen little adoption. It has however seen wide adoption in IKEv2 and a requirement for implementations to support the Suite B Profile (RFC 6380) IKEv1 has no support for high availability resulting in tricks such as DNS round robin or using a dedicated load balancer. IKEv2 provides for a redirection ability where a client can be told to connect to another VPN gateway. The IKEv2 provides for a wider range of traffic selectors as well as allowing the responder to select a narrower set than the initiator proposed, this can be done per Child SA. The official standard allows for a single IPSec SA to handle both IPv4 and IPv6 traffic however not allow Vendor (including Cisco) provide support for this. NAT has already been covered above, NAT-T and NAT detection were originally not included as part of the IKEv1 standard but they are now as part of IKEv2. IKEv1 did not include any method for pushing configuration to peers (such as IP addressing in the case of a remote access client). IKEv2 has inbuilt support for configuation data exchange via the use of a configuration payload. In IKEv1 when pre-shared keys were used it was not possible to based identity on anything other than the peer IP address. Because IKEv2 does not use the shared secret as part of its initial calcuation other identity details can be used. It is assumed that because the peer was able to perform these calculations that it must have possesion of the private key and therefore its identify can be more trustworthy. Because of the above IKEv1 needed to have a unique IP per pre-shared-key. IKEv2 does away with this limitation. IKEv2 is also considered more reliable as message exchanges are sent in pairs so a response is always expected. In IKEv1 all sets of cryptographic ciphers are transferred in seperate transforms. In IKEv2 all algorithms are sent within a single transform, or two where combined and non-combinded mode ciphers are used. IKEv2 is able to provide combined mode ciphers in which a single algorithm is able to perform both encryption and integrity protection. In IKEv1 it was possible for an IPSec SA to exist without a corresponding IKE SA. This is due to IKEv1 not operating in a noncontinuous channel mode. In IKEv2 this is not possible as for an IPSec SA to exist it must have a matching IKEv2 SA.
Introduction
It’s been mentioned already in the overview of VPN technologies that IPSec is not a single protocol instead a suite of protocols working together to provide the necessary security services. RFC 2401 defines the fundamental components of IPSec to be:
6 Chapter 1. Networking Grumpy Networkers Journal Documentation, Release 0.0.7
• Security Protocols • Key Management • Algorithms Due to the way in which IPSec works it’s not easy to understand one of these components without understanding the offers. Encryption is a fundamental part of various IPSec functions and the relevant terminalogy will be mentioend as nece- sary. For a more detailed understanding, consult the chapters in this journal on Cryptography These notes were written up as part of my studies for the CCNP SIMOS exam in May 2017 as served as part of my revision. They are not intended to be complete discussion of the entire IPSec Protocol stack.
Security Protocols
The purpose of IPSec is to provide protection for the data that is being transmitted over the network. Depending on the nature of the traffic a number of services can be offered as covered previously: • Access Control • Confidentiality • Data Integrity • Authentication • Protection against replay IPsec provides two protocols that offer different levels of protection to the data, these protocols are Encapsulating Security Payload (ESP) and Authentication header (AH). Each of these protocols again can be used along with different encapsulation methods depending on the type of network they are being used on. The methods of encapsulation are called Transport and Tunnel mode and will be covered first.
Transport vs Tunnel Mode
Transport Mode
Transport mode works by inserting the ESP or AH header between the original IP header and the upper layer protocol (e.g. UDP or TCP). The IP header remains the same except for the IP protocol field, the IP header checksum is recalculated. When this mode is used any routing is based on the original destination IP address. Because of this it is most use- ful when traffic between two hosts needs to be protected but becomes more difficult when moving to a site-to-site deployment. When combined with GRE, transport mode still has it’s uses as in this instance the GRE endpoint serves as the host endpoint. Another limitation of transport mode is that it cannot used along NAT translation between two IPSec peers. In the case of AH, this is because NAT changes the source IP address in the IP header therefore it will no longer match the AH header causing the receiving endpoint to drop the packet. For ESP, it is possible that NAT may work but as the higher level protocol is encrypted a NAT device cannot read more specific information (such as port numbers) so is more limited in the type of NAT it can do. Depending on the NAT device in front of the VPN device it may be limited to just one device, more advanced devices may be able to read the ESP information (such as the SA’s) and make enough sense out of them to determine the individual connections.
1.1. Virtual Private Networks 7 Grumpy Networkers Journal Documentation, Release 0.0.7
It is also potentially less efficient that tunnel mode due to the encryption engine having to displace (effectively rewrit- ing) the IP header rather than just encrypting the entire packet. The size of the packet will also be increased due to the additional headers which could lead the packet being oversized for the networks supported MTU. This however is not as much as concern as it is for Tunnel mode.
Tunnel Mode
Tunnel mode works by encrypting the entire original IP packet into another IP datagram and an AH or ESP header is added between the outer and inner headers. In the case of AH, the entire new packet is authenticated (excluding certain mutable fields, such as TTL). This means that it still will not work through a NAT gateway. For ESP, everything except the new IP Header is authenticated and the original packet along with ESP trailer is encrypted. Because the new IP header is not taken account of if the packet is modifed it can pass through NAT without issue (assuming the NAT gateway supports IPSec Passthrough otherwise same limitates as transport mode). The primary benefit however is that routing decisions are now based on the outer IP header meaning it can pass over public networks using globally unique IP addresses, keeping the inner (private) IP addresses completely hidden until the packet reaches the other VPN gateway. The downside to tunnel mode however is that because it includes an additional IP header along with ESP header, trailer this increases the packets size quite substantially which may take it over the allowed MTU of the given network.
Encapsulated Security Payload vs Authentication Header
IPSec offer two means by which the original packet data can be encapsulated. Sometimes all that is required is to ensure that the data has not been modified other times confidentiality is essential to offer as much protection as possible that the data has not been examined en route to it’s destination.
Encapsulating Security Payload (ESP)
The Encapsulating Security Payload header provides all of the necessary services for a secure VPN as covered under Security Protocols. This implementation is achieved by enclosing the encrypted version of the orignal payload inside of an ESP header and trailer. The ESP header is indicated by setting the upper layer protocol in the IP header to IP Protocol 50. One of the key fields inthe ESP header is the security parameter index (SPI), this along with the destination address and protocol in the IP header identifies the security association to be used to process the packet. The SPI can be used to looking the SA in the security association database (SADB). A sequence number is included in the header by the header and is simply a unique increasing number used to provide replay protection services. It should be noted that the ESP header itself is not encrypted otherwise the remote peer would not be able to identify which connection the packet is associated with. It also explains why for more advanced NAT gateway’s it may be possible for ESP traffic to pass through them without issue.
Authentication Header (AH)
Unlike ESP, Authentication Header doesn’t provide confidentiality and replay protection is optional.
8 Chapter 1. Networking Grumpy Networkers Journal Documentation, Release 0.0.7
AH sets the upper layer protocol in the original IP header to IP Protocol 51. Because AH creates the authentication data based on the entire packet, it’s possible some of this may change in transit resulting in the authentication failing. To combat this the following fields are zero’d out before the authentication digest is hashed: • ToS • Flags • Fragment Offset • TTL • Header checksum
Key Management And Security Associations
• Phase 2 – Quick Mode • IPSEC Packet Processing – SPD – SADB Key management is the process of generating, distributing and storing of encryption keys. In IPSec the Internet Key Exchange (IKE) protocol is is the default method for secure key negotiation. In order to exchange keys over an insecure transport medium, IKE uses the Diffie-Hellman Key management protocol.
Diffie-Hellman Key Exchange
The DH Key Exchange depends on the discrete logarithm problem where it assumes that it is computationally in- feasable to calculate a shared secret key given two public values. It works by calculating two values a generator (g) and a parameter (p). The two communicating parties (Alice and Bob) calculate a random private value (a and b respectively). A public value is then derived using the previos ‘p’ and ‘g’ values Alice will calculate her public value as 푋 = 푔푎 푚표푑 푝 Bob will calculate his public value as 푌 = 푔푏 푚표푑 푝 These public values are then exchanged between Alice and Bob. 푏 푎 Alice then calculates 푘푎푏 = (푔 ) 푚표푑 푝 푎 푏 Bob calculates 푘푏푎 = (푔 ) 푚표푑 푝
Because 푘푎푏 = 푘푏푎 = 푘 they now know the shared secret key 푘.
Security Association
A security association (or SA for short) is a basic building block of IPSec. The SA is an entry in th SA Database (SAdB) that contains information about the security that has been negotiated between two parties for IKE or IPSec. There are two types of SA, both of which are established between peers using the IKE protocol: • IKE or ISAKMP SA
1.1. Virtual Private Networks 9 Grumpy Networkers Journal Documentation, Release 0.0.7
• IPSec SA The IKE SA is used for traffic that controls the VPN tunnel such as when negotiating algorithms to use to encrypt IKE traffic and to authenticate peers. There is only one IKE SA between peers and commonly has less traffic along with a longer lifetime that IPSec SAs. IPSec SAs are used for negotiating the encryption algorithms to apply for IP traffic (the actual user data) between peers. Each IPSec SA is unidirectional so there will always be at least two IPSec SAs (one in each direction). It is also possible to have multiple pairs of SAs as each defines a unique set of IP hosts or IP data traffic (for example one pair per source/destination network specified). The establishment and maintenance of both types of SAs is the major function of the IKE protocol. The definition of how this key exchange and negotiaion is done is divided into IKE (RFC 2409), ISAKMP (RFC 2408), OAKLEY (RFC 2412) as well as the ISAKMP Domain of Intepretation (RFC 2407). Although ISAKMP and IKE are used interchangably they are different. ISAKMP provides the means to authenticate a peer and to exchange information for key exchange. IKE defines how the key exchange is done. IKE operates in two phases in order to establish the SAs for IKE and also IPSec: • Phase 1 provides mutual authentication of the VPN peers and establishment of the session key. This creates the ISAKMP SA or IKE SA using DH excahnge, cookies and an ID exchange. Once established all IKE communication between the initiator and responder is protected with both encryption and integrity checks. This then provides a secure channel so that Phase 2 negotiations can be performed safely. • Phase 2 provides the negotiation and establishment of IPSec SAs using either the ESP or AH protocols to protect IP data traffic.
IKE Phase 1 Operation
Phase 1 can be performed in one of two modes, Main or Aggressive. Either way the result is the establishment of an ISAKMP/IKE SA. The IKE SA has a number of mandatory parameters: • Encryption Algorithm (e.g. 3DES) • Hash/Integrity Algorithm (e.g. SHA1) • Authentication Method (e.g. Pre-shared keys) • Diffie-Hellman Group (e.g. Group 2) Other parameters are optional, such as SA Lifetime and most devices will have a default value for this if not defined (in terms of seconds or kilobytes)
Comparision of Main and Aggressive Mode
Main Mode
Main mode communicates 6 messages between peers starting with the Initiator. It offers identity protection and flexibility in terms of the parameters and configurations that can be negotiated. The exchange occurs as follows: 1. initiator sends initiator cookie and SA payload which contains the Phase 1 parameters. 2. The responder replies with the selected parameters for each of the proposals along with the SA header response and the ISAKMP Header with a responder cookie
10 Chapter 1. Networking Grumpy Networkers Journal Documentation, Release 0.0.7
3. The 3rd and 4th messages occur when the keying materials are being exchanged. and a number of different keys are derived used for the late exchanges. 4. The 5th and 6th messages are encrypted using the keys created in the previous steps and authenticated using the hashes derived. The proposals must be selected or denied in their entirety, the responder is not allowed to pick and choose elements from different properties. In addition in Main Mode the ID Payload is encrypted so the responder cannot determine who it is talking to therefore when authenticating using a pre-shared key, the identity can only be determined based on the source IP address.
Aggressive Mode
Aggressive Mode completes it’s exchange using only 3 messages which speeds up the IKE transaction processing. This speed however comes at a cost of some security. The 3 messages are exchanged as follows: #. Initiator sends the ISAKMP header, security association, DH public value, nonce and identification ID. 1. The responder then replies with the choosen transform set for each of the proposals and the DH half key. This message is authenticated but not encrypted. 2. The initiator then replied to the responder with the message authenticated so that the responder can make sure the hashes matches the one calculated. In the past one of the primary uses for Aggressive mode was for remote access IKE clients as the responder would have no prior knowledge of the source IP address of the initiator and pre-shared keys were used for authentication. Because identities are passed in the clear and DH parameters cannot be negotiated, Agressive Mode is deemed less secure. As a hash of shared secret is passed in clear text, if an eavesdropper was able to intercept this an offline brute force attack could be used to obtain the clear-text secret. In modern networks where sites are using dynamic IP addresses it is recommended to use digitial certificates for authentication and not pre-shared keys. This allows Main mode to be used with the identity being established from the details in the certificate.
Authentication Methods
One of the parameters exchanged as part of IKE Phase 1 is the authentication method. The most common methods used are pre-shared key and digital signatures.
Pre-Shared Key Authentication
In this method both peers must know a shared secret in advance which is communicated via an out-of-bands medium (such as courier or telephone call between the security engineers). Due to the simplicity by which the keys can be exchanged it is very widely used. They keys used by the Diffie-Hellman exchange are derived from this pre-shared key. As mentioned above, when pre-shared keys are used and the VPN peers do not have fixed IP addresses (such as in a remote access scenerio), Aggresive Mode is the only choice for this peers.
1.1. Virtual Private Networks 11 Grumpy Networkers Journal Documentation, Release 0.0.7
Digitial Signature Authentication
Peers are able to be authenticated with public key signaturues (either DSA or RSA). The Public Keys are normally obtained as Certificates and IKI allows for the exchange of them between intitiator and responder. The IKE Phase 1 process will exchange the public key (certificate) during the final 5th and 6th messages of a Main Mode exchange. The signers public key is used to decrypt and verify the messages being sent. Various details in the certificate can be used to identify the peer so it can be used in situations involving dynamic IP addresses. However due to the complexity of needing to setup a Public Key Infrastructure (PKI) this is none used as oftern as it should be. For more information on setting up a PKI and Certificate Authority Infrastructure, refer to the PKI section of this journal
IKE Phase 2 Operation
Once the IKE Phase 1 SAs have been establihed, Phase 2 can begin. Phase 2 only provides a single method of operation, known as Quick Mode. Once completed the two peers are ready to pass traffic using either ESP or AH. As mentioned previous, a minimum of two IPSec SAs are required for two-way communication between IPSec peers. Quick mode uses 3 message exchanges. All of these exchanges are protected by IKE and therefore encrypted and authenticated using the same keys derived in Phase 1. The Quick Mode Process is as follows: 1. The initiator will send the ISAKMP header and IPSec SA payload (including proposals and transforms) that will be used for bulk data. A new nonce is also exchanged between the peers. Because multiple quick mode exchanges may be ongoing, a Message ID is included to distinquish each transaction. 2. The responder replied with the choosen proposal along with the ISAKMP header, nonce and hash 3. In the 3rd message the initiator authenticates with a further hash value. This is then validated to avoid the possibility of earlier packets being replayed.
Perfect Forward Secrecy
By default the IPSec Keys are derived from the same initial key which could lead to an attacker with knowledge of the initial key being able to calculate all the current and future keys until IKE renegotiates. When Perfect Forward Secrecy (PFS) is enabled, new DH public values will be exchanged and the resulting shared secret will be used to generate new key material.
IPSec Packet Processing
The exact way in which IPSec packets are processed by a host or router is often down to a vendor chose to implement it so the above process should be seen as a top-level overview of the communication not exactly how vendors have designed their various solutions. RFC 2401 does describe a general approach that vendors should adopt to support interoperability that achieve the functional goals of IPSec. This model describes two databases that IPSec implementions with maintain: • Security Policy Database (SPD) • Security Association Database (SADB)
12 Chapter 1. Networking Grumpy Networkers Journal Documentation, Release 0.0.7
Security Policy Database
The SPD defines various selectors to identify packets that require IPSec Services: • Destination IP address • Source IP Address • Name • Data sensitivity level • Transport layer protocols • Source and Destination Ports One or more of these selectors will define the IP traffic encompassing the policy entry. Each entry will indicate whether traffic matching should be bypassed, discarded or subject to IPSec processing. If to be processed by IPSec the entries will include an SA (or SA bundle).
Security Association Database
Each entry in the SADB defines the parameters associated with one SA. Each an IPSec SA is created, the SADB is updated with all the parameters associated with it. The SA entry for an inbound packet is obtained by indexing the SADB with the destination IP in the outer IP header, SPI and IPSec security protocol (either ESP or AH). The SA entry for an outbound packet is obtained by a pointer to the SADB in the SPD. The SADB contains the following parameters: • Sequence Number • Sequence Number Overflow • Anti-replay window • SA lifetime • Modes • AH authentication algorithm • ESP authentcation algorithm • ESP encryption algorithm • Path MTU
IPSec Enhancements
• IKE Keepalives / DPD • Idle Timeout • Reverse Route Injection • NAT-T • Split Tunneling
1.1. Virtual Private Networks 13 Grumpy Networkers Journal Documentation, Release 0.0.7
IPSec and Fragmentation
1.1.2 SSL VPNs
SSL VPN Fundamentals
SSL VPN Introduction
Technology Overview
• Developed initially by Netscape • SSL v1 (not released, v2, v3 • SSL v3.0 served as basis of TLS 1.0 - IETF standard • Cisco SSL VPN uses TLS
SSL VPN Mode
Clientless
• No need for client installation of the PC as long as they have a supported Web Browser • Runs through the Browser • Gateway can proxy requests from the browser to internal resources (HTTP_, HTTPS_, FTP_)
Thin Client
• Designed for those non-web based applications that have static tcp port • Uses Thin Client for supported protocols (such as Telnet, SSH_, RDP_, VNC_) • Uses Java applets/ActiveX Plugins so clients must have Java installed on their PC • Popup blockers can also cause problem • Arbitary ports can be supported through the use of smart forwarding
Thick Client
• Requires installation of software on PC • Not suitable for non-managed devices • Requires Java/ActiveX installed for installation • Provides all functionality as if user was on the LAN (assuming permitted over the VPN) • Policies can be managed centrally
14 Chapter 1. Networking Grumpy Networkers Journal Documentation, Release 0.0.7
SSL VPN Connection Process
# Client initiated connection to server and requests a secure connection # Client provides a list of supported encryp- tion/integrity algorithms (Cipher suite) # TLS server replies with a cipher/hash function it also supports # Server also sends back it’s identity in the form of a digital certificate that should be provided from a trusted CA of the client. The servers public encryption key is also sent. # Client confirms validity of certificate and generates a session key # Client encrypts session key with the services public key and sends it to server # Server decrypts session key and begins encrypted session
Terms Used
SSL/TLS
Can operate in the following modes: • Clientless • Thin Client • Thick/Fat Client (TLS/DTLS)
DTLS
Old Pages
1.1.3 Vendor VPN Implementations
Cisco VPN Implementations
Cisco IKEv1
Cisco IOS IKEv1 VPN Configuration Examples
The following configurations will be demonstrated:
Cisco IOS IKEv1 VPN Legacy Crypto Map with Pre-shared Keys
In this section we will configure a pair of Cisco IOS routers to communicate over IPSec using IKEv1 using the older crypto map style of config and pre-shared key authentication It is assumed that the router already has basic IP connectivity to the public WAN and all private interfaces are config- ured. The default route is also assumed to be via the public WAN. 1. Define the pre-shared key for the remote peer 2. Define the Phase 1 ISAKMP policy 3. Define the Phase 2 IPSec Proposal and set the VPN encapsulation method 4. Define the Encryption Domain for the traffic which should be sent over the VPN 5. Combine all the various settings into a crypto map 6. Apply the crypto map to the public WAN interface
1.1. Virtual Private Networks 15 Grumpy Networkers Journal Documentation, Release 0.0.7
Configuration Steps
Step 1: Define the pre-shared keys crypto isakmp key
Step 2: Define the Phase 1 ISAKMP policy crypto isakmp policy
Step 3: Define the Phase 2 IPSec Proposal crypto ipsec transform-set
Step 4: Define the Encryption Domain
To define the traffic to be encrypted an ACL needs to be created. Each entry in this access list will create a new Phase 2 Security Association which will take up resources on the VPN gateways. Where it is possible to do so summarisation of networks should be done and also avoid the use of per-host ACE’s or those specifying individual ports and protocols (interface ACLS should be used for that purpose) access-list ˓→wildcard> Step 5: Define the crypto map crypto map Step 6: Bind the Crypto Map to the receiving interface interface 16 Chapter 1. Networking Grumpy Networkers Journal Documentation, Release 0.0.7 Complete example The example below is based of the below topology: Todo: Insert topology image On the VPN Hub configure the following: crypto isakmp key mysecretkey address 192.168.2.2 crypto isakmp policy 10 encryption aes hash sha lifetime 86400 group 14 authentication pre-share crypto ipsec transform-set ESP-AES128-SHA1 esp-aes 128 esp-sha-hmac mode tunnel ip access-list extended EACL-R1-TO-R2 permit ip 10.1.0.0 0.0.255.255 10.2.0.0 0.0.255.255 crypto map CM-PUBLIC-WAN 10 ipsec-isakmp match address EACL-R1-TO-R2 set peer 192.168.2.2 set transform-set ESP-AES128-SHA1 set security-association lifetime seconds 28800 interface FastEthernet0/0 crypto map CM-PUBLIC-WAN On the VPN Spoke configure the following: crypto isakmp key mysecretkey address 192.168.1.1 crypto isakmp policy 10 encryption aes hash sha lifetime 86400 group 14 authentication pre-share crypto ipsec transform-set ESP-AES128-SHA1 esp-aes 128 esp-sha-hmac mode tunnel ip access-list extended EACL-R2-TO-R1 permit ip 10.2.0.0 0.0.255.255 10.1.0.0 0.0.255.255 crypto map CM-PUBLIC-WAN 10 ipsec-isakmp match address EACL-R2-TO-R1 set peer 192.168.1.1 set transform-set ESP-AES128-SHA1 set security-association lifetime seconds 28800 interface FastEthernet0/0 (continues on next page) 1.1. Virtual Private Networks 17 Grumpy Networkers Journal Documentation, Release 0.0.7 (continued from previous page) crypto map CM-PUBLIC-WAN Verification Once the VPN configuration has been applied, it will likely be necesary to generate some traffic which matches the encryption domain in order for the vpn establishment to start. In this example we have a loopback interface configured on both the hub ( 10.1.1.1) and spoke (10.2.1.2) so initiating a ping between these hosts should be sufficient. Because the Hub could be busy with dealing with other VPNs, lets does this on the spoke instead as follows: ping 10.1.1.1 source 10.2.1.2 The first few pings are likely to fail whilst the VPN is coming up but after that they should reply without issue. If the pings are replying we can probably assume that the VPN is up but how do we know for sure. Firstly lets check if the Phase 1 SA is up: show crypto isakmp sa detail The output should be similar to that below: C-id Local Remote I-VRF Status Encr Hash Auth DH Lifetime Cap. 1001 192.168.2.2 192.168.1.1 ACTIVE aes sha psk 14 23:59:53 If the status is showing a ACTIVE that is good as it means the VPN is believed to be stable and no further action is being taken. If is saying anything else it could indicate the VPN is having issues or that it is renegotiating (such as during a rekey after the lifetime has expired). We can also see that the Phase 1 properties have negotiated to what we configured. Assuming all is well, lets check that packets are being successfully encrypted and decrypted as follows: show crypto ipsec sa peer 192.168.1.1 And the output should then be as follows: interface: FastEthernet0/0 Crypto map tag: CM-PUBLIC-WAN, local addr 192.168.2.2 protected vrf: (none) local ident (addr/mask/prot/port): (10.2.0.0/255.255.0.0/0/0) remote ident (addr/mask/prot/port): (10.1.0.0/255.255.0.0/0/0) current_peer 192.168.1.1 port 500 PERMIT, flags={origin_is_acl,} #pkts encaps: 9, #pkts encrypt: 9, #pkts digest: 9 #pkts decaps: 9, #pkts decrypt: 9, #pkts verify: 9 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts compr. failed: 0 #pkts not decompressed: 0, #pkts decompress failed: 0 #send errors 0, #recv errors 0 local crypto endpt.: 192.168.2.2, remote crypto endpt.: 192.168.1.1 path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0 (continues on next page) 18 Chapter 1. Networking Grumpy Networkers Journal Documentation, Release 0.0.7 (continued from previous page) current outbound spi: 0xA464B844(2758064196) PFS (Y/N): N, DH group: none inbound esp sas: spi: 0xAA697053(2859036755) transform: esp-aes esp-sha-hmac , in use settings ={Tunnel, } conn id: 5, flow_id: 5, sibling_flags 80004040, crypto map: CM-PUBLIC-WAN sa timing: remaining key lifetime (k/sec): (4311956/28771) IV size: 16 bytes replay detection support: Y Status: ACTIVE(ACTIVE) outbound esp sas: spi: 0xA464B844(2758064196) transform: esp-aes esp-sha-hmac , in use settings ={Tunnel, } conn id: 6, flow_id: 6, sibling_flags 80004040, crypto map: CM-PUBLIC-WAN sa timing: remaining key lifetime (k/sec): (4311956/28771) IV size: 16 bytes replay detection support: Y Status: ACTIVE(ACTIVE) The key information here, is whether packets are being encrypted and decrypted. If they are all is well and no futher action should be necessary. Other details that can be found out are whether the correct encryption and hashing is in place, whether PFS is being used, if reply detection is enabled and finally the remaining lifetime of the IPSec SA. The SPI’s shown for both the inbound and outbound direct can be useful when performing packet captures as part of troubleshooting as they are not encrypted so can be used to identify a given VPN connection where possible a few are coming from the same IP address (e.g. with multiple ACE entries in the encryption domain) Troubleshooting Problem: ISAKMP SA state reports ‘MM_KEY_EXCH’ and remote peer reports ‘%CRYPTO-4- IKMP_BAD_MESSAGE: IKE message from Cisco IOS IKEv1 VPN with Static VTI with Pre-shared Keys In this section we will configure a pair of routers to communicate over a statically configured VTI using GRE over IPSec. This is useful in situations where you need to carry non-IP traffic through IPSEC. It is assumed that the router already have basic IP connectivity and WAN routing is in place. After the IPSec tunnel is configured working we will also setup dynamic routing through the tunnel. 1.1. Virtual Private Networks 19 Grumpy Networkers Journal Documentation, Release 0.0.7 Configuration Steps 1. Configure the PSK Keyring 2. Configure the ISAKMP Policy 3. Configure the ISAKMP Profile 4. Configure the IPSec Proposal 5. Configure the IPSec Profile 6. Configure the VTI tunnel using GRE over IPSec encapsulation 7. Configure routing via the tunnel Step 1: Define the PSK Keyring crypto keyring Step 1: Confifigure the ISAKMP Policy crypto isakmp policy Step 3: Configure the ISAKMP Profile crypto isakmp profile Step 4: Configure the IPSec Transform Set crypto ipsec transform-set Step 5: Configure the IPSec Profile crypto ipsec profile 20 Chapter 1. Networking Grumpy Networkers Journal Documentation, Release 0.0.7 Step 6: Configure the VTI interface interface Tunnel Step 6a: Configure routing (EIGRP) router eigrp Step 6a: Configure routing (EIGRP) router ospf Complete Example The hub could be configured as follows: crypto keyring VTI-KEYRING pre-shared-key address 192.168.2.2 key mysecretkey crypto isakmp policy 10 authentication pre-share encryption 3des hash md5 group 2 lifetime 86400 crypto isakmp profile VTI-ISAKMP-PROF match identity address 192.168.2.2 keyring VTI-KEYRING crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac mode transport crypto ipsec profile VTI-IPSEC-PROF set transform-set ESP-3DES-MD5 set security-association lifetime seconds 28800 set isakmp-profile VTI-ISAKMP-PROF set pfs group2 (continues on next page) 1.1. Virtual Private Networks 21 Grumpy Networkers Journal Documentation, Release 0.0.7 (continued from previous page) interface Tunnel 12 tunnel mode gre ip tunnel source FastEthernet0/0 tunnel destination 192.168.2.2 tunnel protection ipsec profile VTI-IPSEC-PROF ip address 10.255.12.1 255.255.255.0 no shutdown router eigrp 10 no auto-summary network 10.255.12.0 0.0.0.255 network 10.1.0.0 0.0.255.255 The spoke could be configured as follows crypto keyring VTI-KEYRING pre-shared-key address 192.168.1.1 key mysecretkey crypto isakmp policy 10 authentication pre-share encryption 3des hash md5 group 2 lifetime 86400 crypto isakmp profile VTI-ISAKMP-PROF match identity address 192.168.1.1 keyring VTI-KEYRING crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac mode transport crypto ipsec profile VTI-IPSEC-PROF set transform-set ESP-3DES-MD5 set security-association lifetime seconds 28800 set isakmp-profile VTI-ISAKMP-PROF set pfs group2 interface Tunnel 12 tunnel mode gre ip tunnel source FastEthernet0/0 tunnel destination 192.168.1.1 tunnel protection ipsec profile VTI-IPSEC-PROF ip address 10.255.12.2 255.255.255.0 no shutdown router eigrp 10 no auto-summary network 10.255.12.0 0.0.0.255 network 10.2.0.0 0.0.255.255 22 Chapter 1. Networking Grumpy Networkers Journal Documentation, Release 0.0.7 Cisco IOS IKEv1 VPN with Dynamic VTI with Pre-shared Keys In this section we will configure a hub router that is able to offer VPN tunnels to a unknown number of dynamic VPN peers This is useful where you may need to rapidly deploy a varied number of sites and do not want to have to reconfigure the hub router everytime a new site is activated. The configuration we will be putting in place is suitable when the remote peers are using dynamic IP addressing but note that as we are using pre-shared key authentication the same key will be accepted from any IP address. This is not as secure as it could be and in a production deployment the use of digital signatures should be considerd. It is assumed that the router already have basic IP connectivity and WAN routing is in place. After the IPSec tunnel is configured working we will also setup dynamic routing through the tunnel. Configuration Steps On all devices: #. Configure a loopback to use a tunnel IP #. Configure the Keyring #. Configure the ISAKMP Policy #. Configure the ISAKMP Profile #. Configure the IPSec Proposal #. Configure the IPSec Profile #. Configure dynamic routing On the Hub: #. Configure the tunnel interface template On the Spokes: #. Configure a static tunnel interface Step 1: Define the Loopback Interface interface loopback Step 1: Define the PSK Keyring For the hub it’s necessary to define a wildcard PSK if the spokes will be using dynamic IP addresses. If they will be static they can be defined individually but that would loose some of the flexibility of the solution. crypto keyring On the spokes the PSK can be defined with just the Hubs IP: .. code-block:: none crypto keyring Step 1: Configure the ISAKMP Policy crypto isakmp policy 1.1. Virtual Private Networks 23 Grumpy Networkers Journal Documentation, Release 0.0.7 Step 3: Configure the ISAKMP Profile crypto isakmp profile Step 4: Configure the IPSec Transform Set crypto ipsec transform-set Step 5: Configure the IPSec Profile crypto ipsec profile Step 6: Define the tunnel interfaces On the Hub we will configure a template that will be cloned each time a client connects. interface virtual-template On the Spokes we can configure a nubmer tunnel interface: interface Tunnel Complete Example The Hub config could be performed as follows: interface loopback 0 ip address 10.0.0.1 255.255.255.255 crypto keyring DVTI-KEYRING pre-shared-key address 0.0.0.0 key mysecretkey (continues on next page) 24 Chapter 1. Networking Grumpy Networkers Journal Documentation, Release 0.0.7 (continued from previous page) crypto isakmp policy 10 authentication pre-share encryption 3des hash md5 group 2 lifetime 86400 crypto isakmp profile DVTI-ISAKMP-PROF match identity address 0.0.0.0 keyring DVTI-KEYRING virtual-template 1 crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac mode tunnel crypto ipsec profile IPSEC-PROF set transform-set ESP-3DES-MD5 set security-association lifetime seconds 28800 set isakmp-profile DVTI-ISAKMP-PROF interface virtual-template 1 type tunnel ip unnumbered loopback0 tunnel mode ipsec ipv4 tunnel destination dynamic tunnel source FastEthernet0/0 tunnel protection ipsec profile IPSEC-PROF router eigrp 10 no auto-summary network 10.0.0.0 0.0.0.255 network 10.1.0.0 0.0.255.255 The Spokes could then be configured as follows: interface loopback 0 ip address 10.0.0.2 255.255.255.255 crypto isakmp policy 10 authentication pre-share encryption 3des hash md5 group 2 lifetime 86400 crypto keyring DVTI-KEYRING pre-shared-key address 192.168.1.1 key mysecretkey crypto isakmp profile DVTI-ISAKMP-PROF match identity address 192.168.1.1 keyring DVTI-KEYRING crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac mode tunnel crypto ipsec profile IPSEC-PROF set transform-set ESP-3DES-MD5 set security-association lifetime seconds 28800 (continues on next page) 1.1. Virtual Private Networks 25 Grumpy Networkers Journal Documentation, Release 0.0.7 (continued from previous page) set isakmp-profile DVTI-ISAKMP-PROF interface tunnel 12 ip unnumbered loopback 0 tunnel mode ipsec ipv4 tunnel source FastEthernet0/0 tunnel destination 192.168.1.1 tunnel protection ipsec profile IPSEC-PROF router eigrp 10 no auto-summary network 10.0.0.0 0.0.0.255 network 10.2.0.0 0.0.255.255 When ever a new spoke needs to be deployed the same config as above can be used, just change the following: 1. Loopback IP 2. Subnets advertised by routing protocol • Static VTI Based IKEv1 VPN • Dynamic VTI Based IKEv1 VPN • Software-Based Remote Access IKEv1 VPN (Legacy IPSec Client) • Hardware-Based Remote Access IKEv1 VPN (EasyVPN Client) Cisco ASA IKEv1 VPN Configuration Examples The following configurations will be demonstrated: Cisco ASA IKEv1 VPN Configuration with Pre-Shared Keys Example Introduction In this example we’ll configure a Cisco ASA to talk with a remote peer using IKEv1 with symmetric pre-shared keys. Configuration Steps 1. Define the Encryption Domain 2. Specify the Phase 1 Policy 3. Specify the Phase 2 Proposal 4. Define the connection profile 5. Configure the Crypto Map 6. Bind the Crypto Map to the appropriate interface 7. Enable IKEv1 on the appropriate interface 26 Chapter 1. Networking Grumpy Networkers Journal Documentation, Release 0.0.7 Define the Encryption Domain The encryption domain specifies traffic that should be encapsulated within IPSec prior to leaving the external interface. Any traffic not matching this ACL will be sent out the interface in plain text, assuming it does not match any other configured VPNs. The ACL should also take into account of any NAT’ing that has taken place as the encryption occurs post-NAT. access-list ˓→ Specify the Phase 1 Policy crypto ikv1 policy Specify the Phase 2 Proposal In newer releases on Tunnel mode is support, Transport has been removed crypto ipsec ikev1 transform-set ˓→ Define the connection profile In general speak a connection profile defines the properties of how the VPN will run and what access will be permitted. It is called as such in the ASDM but through the CLI we need to configure a tunnel-group In earlier versions of the ASA code (pre-8.0) the preshared key was configured globally as with earlier IOS versions. tunnel-group Configure the Crypto Map Only a single Crypto Map can be bound to an interface, so if one already exists use a different sequence number to existing entries. If remote access is configured it is important to ensure that site-to-site entries have a lower sequence nubmer than the remote access one. 1.1. Virtual Private Networks 27 Grumpy Networkers Journal Documentation, Release 0.0.7 crypto map Bind the Crypto Map to the interface If this is the first VPN (either IKEv1 or IKEv2) being setup, it will be necessary to bind the Crypto Map to the interface facing the remote peer(s). Otherwise this will already have been configured. crypto map Enable IKEv1 on the the interface If this is the first IKEv1 VPN being setup, it will be necessary to bind the Crypto Map to the interface facing the remote peer(s). Otherwise this will already have been configured. crypto ikev1 enable Cisco IKEv2 Cisco IOS IKEv2 VPN Configuration Example Cisco ASA IKEv2 Configuration Example Cisco ASA IKEv2 VPN Configuration with Assymetric Pre-Shared Keys Example Introduction In this example we’ll configure a Cisco ASA to talk with a remote peer using IKEv2 with assymetric pre-shared keys. Configuration Steps 1. Define the Encryption Domain 2. Specify the Phase 1 Policy 3. Specify the Phase 2 Proposal 4. Define the connection profile 5. Configure the Crypto Map 6. Bind the Crypto Map to the appropriate interface Define the encryption domain access-list ˓→mask> 28 Chapter 1. Networking Grumpy Networkers Journal Documentation, Release 0.0.7 Define the Phase 1 Policy The ASDM location for these settings is: Configure → Site-To-Site VPN → Advanced → IKE Policies crypto ikev2 policy Define the Phase 2 Proposal The ASDM location for these settings is: Configure > Site-To-Site VPN-> Advanced > IPSec Proposals (Transform Sets) crypto ipsec ikev2 ipsec-proposal Define the connection profile The ASDM location for these settings is: :menuselect:‘Configure –> Site-To-Site VPN –> Advanced –> Tunnel Groups‘ tunnel-group Define the crypto map when creating the connection profiles in ASDM, part of the configuration includes the interface and protocols to be allowed. The selection can be seen on the connection profiles section of ASDM: Configure → Site-To-Site VPN → Advanced → Crypto Maps crypto map Bind the Crypto Map to the interface If this is the first VPN (either IKEv1 or IKEv2) being setup, it will be necessary to bind the Crypto Map to the interface facing the remote peer(s). Otherwise this will already have been configured. 1.1. Virtual Private Networks 29 Grumpy Networkers Journal Documentation, Release 0.0.7 In ASDM as soon as any VPN is configured it will automatically bind a crypto map to the selected interface. The binding can be seen at the following location: Configure > Site-To-Site VPN > Connection Profiles crypto map Enable IKEv1 on the the interface If this is the first IKEv2 VPN being setup, it will be necessary to bind the Crypto Map to the interface facing the remote peer(s). Otherwise this will already have been configured. In ASDM the selection of which protocol is enabled per-interface, can be seen on the connection profiles section: Configure > Site-To-Site VPN > Connection Profiles crypto ikev2 enable Cisco IKEv2 Overview This section covers details specific to the Cisco implementation of IKEv2. For a more general review, see IKE Version 2. Implementation Guides Cisco AnyConnect Overview Cisco Anyconnect Clientless Cisco Anyconnect Clientless ASA Implementation TBC Cisco Anyconnect Clientless IOS Implementation TBC Configuration Steps 1. Generate RSA Keys for use with SSL/TLS 2. Enable AAA 3. Enable the HTTP/HTTPS Server 4. Configure the WebVPN Gateway 5. Configure the WebVPN Context 6. Configure Local Accounts 30 Chapter 1. Networking Grumpy Networkers Journal Documentation, Release 0.0.7 Generate RSA Keys In order for the HTTP Server to also provide SSL/TLS services we need to generate the public and private keys that it will use: crypto key generate rsa modulus Enable AAA So that users can be authenticated and authorised, its necessary to enable the AAA sub-system and optionally different a method list specifying how users should be authenticated. ! Enable the AAA sub-system aaa new-model ! Optional - Define a specific method list for WebVPN authentication aaa authentication login Enable the HTTP/HTTPS Server In order for users to be able to access the SSL Portal, an HTTP/HTTPS server must be enabled on the IOS router as follows: ip http server ip http secure-server Configure the WebVPN Gateway To accomplish this the following information is needed: • IP Address • Port Number webvpn gateway ! Optional - Configure gateway hostname, should match certificate used hostname ! Optional - Redirect HTTP to HTTPS http-redirect ! Optional - Specify supported cipher suites ssl encryption [aes-sha1] [3des-sha1] [rc4-md5] ! Enable the gateway inservice 1.1. Virtual Private Networks 31 Grumpy Networkers Journal Documentation, Release 0.0.7 Configure the WebVPN Context A WebVPN context is a means by which a certain portal type can be displayed to users. The context can either be specified by the user or provided as part of the users authorization properties (e.g. from RADIUS). webvpn context ! Optional Specify how users should be authenticated, global config will ! be used if not specified aaa authentication list ! Create a policy for this context (multiples can exist) policy group banner ! Specifies the default policy to use if nothing is specified from AAA default-group-policy ! Associates this context with a specifiic SSL VPN gateway gateway ! Optional - Display a message on the login screen login-message ! Optional - Maximum allowed users under this context max-users ! Enable the context inservice Configure Local Accounts If user accounts will not be configured on a central authentication server, it is necessary to configure the users locally on the IOS router. username Troubleshooting The following commands can be useful in troubleshooting WebVPN debug webvpn aaa debug aaa accounting Reference Documents SSL VPN Configuration Guide, Cisco IOS Release 15M&T 32 Chapter 1. Networking Grumpy Networkers Journal Documentation, Release 0.0.7 http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_sslvpn/configuration/15-mt/ sec-conn-sslvpn-15-mt-book/sec-conn-sslvpn-ssl-vpn.html SSL VPN Remote User Guide http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_sslvpn/configuration/15-mt/ sec-conn-sslvpn-15-mt-book/sec-conn-sslvpn-remote.html TBC Cisco Anyconnect Full Client Cisco Anyconnect Full Client ASA Implementation TBC Cisco Anyconnect Full Client IOS Implementation TBC TBC TBC Anyconnect Client Requirements TBC Cisco Dynamic Multipoint VPN (DMVPN) Cisco Dynamic Multipoint VPN with PSK Basic Configuration In this section 3 routers will be configured to provide a basic DMVPN. One of the routers will act as a hub, the remaining two as the spokes. Hub Configuration Steps Step 1: Define the IKE Phase 1 Policy crypto isakmp policy 1.1. Virtual Private Networks 33 Grumpy Networkers Journal Documentation, Release 0.0.7 Step 2: Define the Pre-Shared Key ! Same key used for all spokes regardless of IP Address crypto isakmp key Step 3: Define the IPSec Proposal crypto ipsec transform-set Step 4: Define the IPsec Profile crypto ipsec profile Step 5: Create the tunnel interface interface tunnel tunnel key ip nhrp nhs map multicast dynamic ip nhrp authentication tunnel protection ipsec profile no shutdown Spoke Configuration Steps Step 1: Define the IKE Phase 1 Policy crypto isakmp policy 34 Chapter 1. Networking Grumpy Networkers Journal Documentation, Release 0.0.7 Step 2: Define the Pre-Shared Key ! Same key used for all spokes regardless of IP Address crypto isakmp key Step 3: Define the IPSec Proposal crypto ipsec transform-set Step 4: Define the IPsec Profile crypto ipsec profile Step 5: Define the Tunnel Interface inteface tunnel ip nhrp map ip nhrp authentication Routing Protocol Considerations DMVPN can work with either Link State or Distance Vector protocols. However considerations need to be made for each. Distance Vector Protocols In order to use routing protocols such as EIGRP and RIP, it necessary to disable split horizon so that routing adver- tisements from the spokes can be readvertised out of the single hubs interface. In addition the routing updates should still contain the original peer that advertised them, not the hops. To achieve this Next Hop Self should be disabled. In the case of EIGRP these can be configured on the tunnel interface as follows: 1.1. Virtual Private Networks 35 Grumpy Networkers Journal Documentation, Release 0.0.7 interface tunnel Link State Protocols Routing protocols such as OSPF will automatically ensure all peers receiving the routing updates because this is the Designated Routers (DR) responsibility. It however important to ensure that none of the spokes can become the DR. It is also vital that the tunnel interface is set to us the network type of “broadcast” to ensure that the DR/BDR election occurs. If this is not set and more than two router Ids are seen on the same subnet, this could result in flapping neighbour relationships. The above can be achieved by setting the priority of the spokes to 0 and manually setting the network type on the tunnel as shown below: interface tunnel When using dual-hub, its important that the priority of the primary hub is higher than that of the secondary. In the case of a primary hub failure, the spokes will notice for themselves when the hold time has expired and automatically start queying the secondary NHS. Introduction Dynmaic Multipoint VPN is a solution developed by Cisco that aimed to make large scale VPN deployments easier without needing to know all the endpoint in advance. It can be used for a traditional hub-and-spoke model especially when combined with endpoints that do not have fixed IP addresses but it’s really value comes from allowing direct spoke-to-spoke traffic, removing the burdan and potentional bottleneck from a central hub. As well as the existing requirements for IPSec, three additional functional components are needed: • Multipoint GRE Interfaces • Next Hop Resolution Protocol (NHRP) • IPSec Proxy Instantiation Multipoint GRE interfaces One of the problems with having to establish a large number of individual GRE tunnels is that each one takes up resources on the central router, the most critical of which is the Interface Descriptor Block (IDB) for which there are only a limited number. In addition for traditional static GRE tunnels the source and destination addressing needs to be known in advance which is not possible where VPN endpoints could be using dynamic IP addressing. Multipoint GRE, or mGRE solves both these issues. An mGRE interface is a single interface from which all GRE tunnels from the spokes can be termined. This removes a lot of repetative configuration and reducing the memory resource allocation as the mGRE interface only consumes a single IDB regardless of the number of tunnels. 36 Chapter 1. Networking Grumpy Networkers Journal Documentation, Release 0.0.7 When configuring the mGRE interface, only the tunnel source is specified, not the destination. An additional method is needed to communicate this information so the hub is aware of the remote peers tunnel endpoint IP. This is performed by the Next Hop Resolution Protocol (NHRP) Compared to individual tunnel interfaces, an multipoint interface is configured with a single subnet not a subnet per tunnel. This does cause issues with how route selection is done with certain routing protocols. Next Hop Resolution Protocol (NHRP) NHRP can be thought of as a Layer 3 ARP. Its role is to map the private IP used in the DMVPN “cloud” against the remote peers current public IP. The private IP will be used within all routing updates as the advertising endpoint but it is the public IP that is needed in order to establish the dynamic tunnel between two spoke sites. The Hub will be configured to dynamically resolve NHRP requests based on its available information. At the start it will not know of any endpoints and simply waits for a spoke to register and then for other spokes to query it for information. Upon initial bootup the spokes will establish a permenant tunnel with the spoke and register their private IP against their public IP using NHRP. The first time a spoke needs to communicate with a subnet located at a different spoke it will ask the hub (via an NHRP query) for the public IP associated with the private IP shown in the routing table. One obtained the spoke will store this information locally for a certain period of time and also update its CEF adjacency table to allow for faster forwarding of packets. Once the spoke knows how to communicate with another spoke it can dynamically establish the VPN tunnel with the other spoke without any prior knowledge that the spoke existed. Dynamic IPSec Proxy Instantiation In traditional VPNs it necessary to do one of the following 1. Manually configure an encryption domain ACL to specify what traffic should be permitted over the VPN. 2. Establish a GRE tunnel over IPSEC with the encryption domain being predefined as all GRE traffic between the two GRE peers. If no prior knowledge of the routes or peers is known, neither option is feasible. Through NHRP a spoke is able to determine the remote spokes public IP which can then be used as the IKE remote identity. Because the traffic is encapsulated within GRE prior to being encrypted the subnets used over the VPN are not relevant and the IPSec proxy profile will be the GRE traffic between the two internal IP addresses just like with a traditional GRE-over-IPSec tunnel. There is still however the issue of how to authenticate the spokes. A number of methods can be used: 1. Pre-configure a unique key per IKE identity (spoke) 2. Pre-configure a global (wildcard) pre-shared-key for every IKE identity 3. Implement a public key infrastructure. If any of the peers have dynamic IP addresses using a unique key is simply not possible. Even if the peers are all static, having to manage all the keys becomes increasing difficult as the number increases as all possible peers need to be updated. Using a global pre-shared-key would seem the simplest solution and in general is widely used, it needs to be understood however that making updates to this key is difficult and leads to a “flag day” where all devices need to be updated at once. This is generally frowned upon by businesses and operations teams. 1.1. Virtual Private Networks 37 Grumpy Networkers Journal Documentation, Release 0.0.7 The final solution is to use a PKI, this is certainly the most scaleable solution as it doesn’t require any prior peer relationship configuration and as long as no changes are made to the central CA, changes can be made (e.g. reissuing of certificates) without affecting all devices. It does however require more prior work in order to implement the PKI and issue certificates out to all participating devices. Once a spoke knows what public IP to communicate with and how to authenticate to it, the dynamic tunnel can be established and if successful traffic will then flow directly between the spokes and not through the hub. Establishing a Dynamic Multipoint VPN Below is a step-by-step review of how to setup spoke-to-spoke communication within a DMVPN. Step 1: Setup the Hub site Before any of the spokes can communicate it’s necesary for the hub to be established. Because all the spokes will be configured with a static NHRP entry for the hub, it cannot have any dynamic IP address. On the hub, a point-to-multipoint tunnel will be created that has a static IP address within the DMVPN Cloud„ this is known as the NBMA address and will show up in various command outputs. In order to secure the DMVPN traffic, the usual configuration elements required for IPSec IKEv1 are required, namely: 1. IKE Phase 1 Policy 2. IPSec transform set 3. Authentication details (unique/wildcard PSK or RSA Signatures) 4. IPSec Profile The tunnel interface will then be configured for protection using the IPSec profile. Note that a static encryption domain is not created. These will be created dynamically as required by each of the spoke-to-spoke tunnels. Finally it is necessary for the hub to accept dynamic NHRP registrations and queries. NHRP must be setup with a unique network ID for the DMVPN cloud as well as an optional authentication password. Various timers can also be adjusted to determine how long to hold onto adjancy information given by the spokes. Depending on the routing protocol used it may also be necesary to specify certain additional properties. This will be covered later. Steps 2: Once the hub is ready to accept connections we can now configure the spokes. Practically all of this configuration will be repeated for the spokes, the key changes being: • IP address assigned to the tunnel interface • The networks that are advised through the tunnel as part of the routing protocol. As with any VPN tunnel, we first need to configure the IKE Phase 1, authentication details and IPSec Phase 2 Transform set. These details should match what has been configured on the hub. Next the mGRE tunnel interface needs to be configured. This is where the bulk of the configuration will be placed as it is necessary to: 1. Define the source IP/interface of the tunnel 2. Define the tunnel (private) IP address of the spoke 38 Chapter 1. Networking Grumpy Networkers Journal Documentation, Release 0.0.7 3. Define the private and public IP address of the Hub 4. Define which IP address to query for NHRP mappings, the next hop server 5. Define the network ID for this DMVPN network 6. Configure any properties specific to the routing protocol 7. Specify which IPSec profile to use to encrypt the traffic It is not necessary to define the actual Hub as the tunnel endpoint as this will be handled by the Next Hop Server. This tunnel interface will be used for all connections, both hub and spoke. DMVPN Redundancy DMVPN redundacy can be implemented using one of two methods: #. Configure redundant hubs #. Configure seperate mGRE subnets, effectively to seperate DMVPN networks With a single DMVPN and redundant hubs the network is subject to the limitations of a single routing protocol. Where as if two DMVPN subnets are used it allows for flexibility in the assignemnt of unique routing protocols and cost metrics for the two networks. In IOS versions prior to 12.(4.2) it was necessary to assign a unique IKE identity (IP address) per DMVPN. In the case of a single DMVPN network with dual hubs the decision on which hub to use is left to the routing protocol. The secondary hub as well as acting as an NHS will also be a client to the primary NHS. If the primary hub were to fail eventually the records would time out and the spokes would query the secondary NHS instead. Routing between the spokes will be determined by the routing protocol. Cisco FlexVPN Cisco FlexVPN Basic Client/Server Configuration Overview This configuration will demonstrate the absolute minimum configuration that is required in order to get a FlexVPN spoke acting as a client to establish a vpn tunnel to a FlexVPN hub acting as the server. FlexVPN Server Configuration The following elements must be configured on the Hub acting as the FlexVPN server: 1. Enable AAA 2. Define the local subnets to be encrypted 3. Create Address Pool 4. IKEv2 Keyring 5. IKEv2 Authorisation Policy 6. IKEv2 Profile 7. IPSec Profile 8. Tunnel interface template It is assumed that basic LAN/WAN connectivity and routing is already in place and tested. 1.1. Virtual Private Networks 39 Grumpy Networkers Journal Documentation, Release 0.0.7 Enable AAA In case we need to configure multiple differnet authorisation policies we won’t change the default authorisation list, instead creating one unique for this deployment. This for example would allow one method to use local PSKs and another using RADIUS if so needed. aaa new-model aaa authorization network Define the local subnets ip access-list standard Create the Address Pool ip local pool Configure the IKEv2 Keyring For this example we will be using symmetric pre-shared keys but it is also possible to use assymetric by specifying different ‘local’ and ‘remote’ values. crypto ikev2 keyring Configure the IKEv2 Authorisation policy The authorisation policy specifies the attributes that will apply to clients who are successfully authorised against this policy. crypto ikev2 authorization policy ! Specify the local subnets that will be advertised to clients (split-tunnel) route set access-list Define the IKEv2 Profile crypto ikev2 profile 40 Chapter 1. Networking Grumpy Networkers Journal Documentation, Release 0.0.7 (continued from previous page) keyring local Define the IKEv2 Profile crypto ipsec profile Define the interface template interface virtual-template FlexVPN Client Configuration We will configure the following elements: 1. Enable AAA 2. Define the local subnets to be encrypted 3. IKEv2 Keyring 4. IKEv2 Authorisation Policy 5. IKEv2 Profile 6. IPSec Profile 7. Tunnel Interface 8. FlexVPN Client Profile Enable AAA Unlike the server we are less likely to need multiple policies on the client so in this instance we just change the defalt one. aaa new-model aaa authorization network default local Define the local subnets to be encrypted ip access-list standard 1.1. Virtual Private Networks 41 Grumpy Networkers Journal Documentation, Release 0.0.7 Create the IKEv2 Keyring crypto ikev2 keyring Create the IKEv2 Authorization Policy crypto ikev2 authorization policy Create the IKEv2 Profile Same config as the server but instead using the default authorization method list. crypto ikev2 profile Create the IPSec Profile crypto ipsec profile Create the tunnel interface interface tunnel Create the FlexVPN Client Profile crypto ikev2 client flexvpn TBC • FlexVPN Hub-And-Spoke 42 Chapter 1. Networking Grumpy Networkers Journal Documentation, Release 0.0.7 • FlexVPN Spoke-To-Spoke • FlexVPN Hardware-Based Remote Access • FlexVPN Software-Based Remote Access Cisco Group Encrypted Transport VPN (GetVPN) TBC GDOI • Used with MPLS networks to offer confidentiality and integrity services whilst still maintaining the any-to-any feature of MPLS • GDOI is used in GetVPN alongside IPSec to provide the key distribution services between peer in the same group. Site To Site VPNS with Cisco ASA Implementing Site-To-Site VPNs on Cisco ASA Basic ASA IKEv1 Site-To-Site VPN ASDM Configuration Requirements # Java installed on management PC # Following bootstrap configuration on the ASA • IP Addressing for management interface • Routing to management PC • Username/Password configured • HTTP Server enabled and acess granted from the Management PC • ASDM Image copied to ASA Flash and enabled Configuration # Start ASDM and login # Select Configuration # Navigate to Notes • Normal to receive certificate error when accessing as ASA is using self-signed certificate initially • Wizard also available, Wizards > VPN Wizards > Site-To-Site VPN Wizard 1.1. Virtual Private Networks 43 Grumpy Networkers Journal Documentation, Release 0.0.7 Basic ASA IKEv1 Site-To-Site VPN CLI Configuration # Configure Phase 1 Policy :: • For ASA less than 8.4.1 :: crypto isakmp policy Basic ASA IKEv1 VPN with RSA # Define hostname :: hostname 44 Chapter 1. Networking Grumpy Networkers Journal Documentation, Release 0.0.7 # Enroll with the CA :: crypto ca enroll # Configure IPSec SA Lifetime :: crypto ipsec security-association lifetime seconds Based ASA IKEv2 VPN with PSK # Create IKEv2 Proposal :: crypto ikev2 policy 1.1. Virtual Private Networks 45 Grumpy Networkers Journal Documentation, Release 0.0.7 # Crypto map :: crypto map Based ASA IKEv2 VPN with PSK Prequistes • Ensure hostname is set • Ensure domain name is set • Ensure time is correct Configuration # Define the Trusted CA :: crypto ca trustpoint 46 Chapter 1. Networking Grumpy Networkers Journal Documentation, Release 0.0.7 ASA VPN setup with IP SLA # Requirements • Configure IP SPA # Configure ICMP SLA :: sla monitor GetVPN Fundamentals Group Encrypted Transport VPN Overview Cisco GetVPN is a means of providing scaleable secure connectivity across private WANs (such as MPLS) whilst also maintaining the any-to-any connectivity of those networks. Benefits • Highly scaleable any to any mesh topology • Maintains network intelligence of MPLS networks • Helps ensure low latency and jitter by enabling full-time, direct communications between sites. • IP Address preservation enables encrypted packets to still carry the original source and destination addressing. • Two servers can be configured Cooperative Mode (COOP) in order to provide fault tolarance. Limitations • Only IKEv1 is supported between COOP servers • IKEv2 can be used between GMs but EAP is not supported for authentication • NAT is not supported • Port ranges cannot be used as classifiers • End-To-end PMTU does not work in GetVPN Support Platforms Software Requirements • IOS 12.4(15)T8 and 12.4(22)T2 1.1. Virtual Private Networks 47 Grumpy Networkers Journal Documentation, Release 0.0.7 • IOS-XE 12.2(33)XNC Key Server Platforms • Cisco 3845 • Cisco 7200 Group Members • Cisco 881 • Cisco 1811, 1841 • Cisco 3845 • Cisco 7200 • Cisco ASR 1004 GetVPN Functional Components The following components are required for GetVPN to function: • GDOI • Key Server (Ks) • Group Member (GM) Group Domain of Interpretation GDOI is a protocol that is used for Group Key and SA management. It uses ISAKMP for authenticating the Group Members (GMs) and Key Servers (KSs). GetVPN only supports time-based SA expiry as it does not have any information on the amount of traffic sent between peers. Key Servers The Key server (KS) has the responsibility of maintaining policies for the group, authenticating group members (GMs) and providing the session keys for encrypted traffic. A key server will authenticate the GMs at the time of registration. Only after this is successful can a GM particate in the group. The key server is not involved in the encryption of traffic between peers. In affect the Phase 1 IKE SA is done between the GMs and KS, whilst the actual Phase 2 IPSec SA is done directly between participating GMs. The key server will perioidically refresh the SAs and notify all participating group members prior to the expiry of the old SA. This can be done using either unicast or (for greater scaleability) multicast. Two types of keys are distributed by the Key Server. The Key Encryption Key (KEK) is used to securely rekey messages between the KS and GMs. Whilst the Traffic Encryption Key (TEK) is used to secure the traffic between GMs. 48 Chapter 1. Networking Grumpy Networkers Journal Documentation, Release 0.0.7 Group Members A Group Member (GM) registers with the key server in order to obtain the IPSec SA necessary to participate in the group. When registering the group member provides the group ID to the key server and then obtains the appropriate policy and keys for that group. GetVPN Configuration Key Server The following minimal components should be configured on the Key Server: • IKE Policy • RSA Key for re-keying • IPSec Policies • Traffic Classification ACL The IKE policy used as the authentication method between KS and GMs. Whilst pre-shared keys can be used, digital certificates are preferred for scaleability and greater security. The RSA Key is used to secure the re-key messages. Matching IKE Policy and authentication methods need to be configured on the KS and GMS in order for a successful registration. The IPSec Policies are used to secure the data traffic and are pulled from the KSs by the GMS at time of registration. The classification ACL is used to determine what traffic should be encrypted and that which should be excluded. Any changes to the ACL on the key server will result in a rekey occuring so that clients can obtain the new policy. Group Member The group member needs to be configured with the following: • IKE Policy • GDOI Policy • Interface Config The IKE Policy should match what has been configured on the Key Server to avoid problems with registration. The GDOI policy identifies what group the GM wishes to join and also the KS server to connect to. Once the GDOI policy is configured, it should be included in a crypto map so that it can be bound to the WAN interface. Verification Key Server Commands 1.1. Virtual Private Networks 49 Grumpy Networkers Journal Documentation, Release 0.0.7 show crypto gdoi show crypto gdoi ks show crypto gdoi ks acl show crypto gdoi ks coop show crypto gdoi ks members show crypto isakmp sa Group Member Commands show crypto gdoi show crypto gdoi ipsec sa show crypto gdoi gm show crypto gdoi gm acl show crypto isakmp sa show crypto ispec sa Troubleshooting The following commands can be used to clear existing SA and/or reset any statistics counters: clear crypto gdoi [ When troubleshooting an issue the following debug commands can be run to gain further insight into the issue: debug crypto gdoi debug crypto gdoi gm debug crypto gdoi ks debug crypto isakmp debug crypto ipsec A Number of syslog entries will also be recorded starting with the following prefixes: COOP_ GDOI_ GM_ KS_ External References Cisco IOS GETVPN Start Page http://www.cisco.com/go/getvpn Cisco GETVPN Configuration Guide (15.1M&T) - Last Update 2/10/2011 http://www.cisco.com/c/en/us/td/docs/ios/sec_secure_connectivity/configuration/guide/convert/sec_get_vpn_15_1_ book/sec_encrypt_trns_vpn.html Cisco GETVPN G-IKEv2 configuration Guiode (IOS XE 3S) - Last Update 9/2/2017 50 Chapter 1. Networking Grumpy Networkers Journal Documentation, Release 0.0.7 http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_getvpn/configuration/xe-3s/sec-get-vpn-xe-3s-book/ sec-get-vpn-gikev2.html GetVPN Group Member Configuration ddd GetVPN Key Server Configuration ddd VPN Support for IOS and ASA devices The table below lists which types of VPNs are supported on each major device type: VPN IOS ASA Site-To-Site Y Y Remote Access Y Y SSL Y Y DMVPN Y N GETVPN Y N FlexVPN Y N Functional Components ISAKMP Policy Defines the acceptable algorithms, authentication types and lifetimes for the Phase 1 Security Association. This policy is defined globally as the correct selection has to be done before anything else as part of the Main Mode exchange Crypto Keyrings When pre-shared key authentication is being used the device needs to know what is the valid authentication key sent by it’s peer. Whilst these can be defined globally a crypto keyring makes them more manageable and also supports multiple different network VPNs when defined as VRFs. If a VRF is specified the keyring is associated the front-door VRF (FVRF) specified in the configuration. The FVRF is the VRF which receives the encrypted packet, compared with the inside VRF (IVRF) which is the internal/private network for post-decryption forwarding lookups. ISAKMP Profiles An ISAKMP Profiles is seen as a placeholder for putting Phase 1 and Phase 1.5 (XAUTH/Mode Config) configuration that applies to multiple peers. An appropriate ISAKMP Profile is choosen by the device from either: • The Phase 1 IKE Identity such as IP address, FQDN, USER-FQDN, DN or ID_KEY_ID when pre-shared keys are being used 1.1. Virtual Private Networks 51 Grumpy Networkers Journal Documentation, Release 0.0.7 • Fields matched from the certificate forwarded by the peer during authentication if RSA signature authentication is used In order for fields to be matched form the certificate a mapping configuration must also be configured and specified in the ISAKMP Profile. IPSec Proposal The IPSec Proposal, more commonly called the Transform Set specifies the encryption and integrity algorithms to use for the Phase 2 Security Association. One other property that is often set is whether to use transport or tunnel mode. On most Cisco devices the suggestion is to use Tunnel mode so this won’t appear by default in most configuration outputs. IPSec Profile The IPSEC Profile is used to combine the IPSec Proposal along with the IKE (either v1 or v2) profile. In addition Perfect Forward Secrecy and lifetime settings can be changed if needed. Once defined this profile is then bound to the Tunnel Protection Profile so that peers are checked for the correct credentials prior to being allowed access to the network. Encryption Domain The encryption domain specifies what traffic should be sent through the VPN tunnel. This is communicates as part of the Phase 2 exchange and any mismatch can lead to either the VPN only working intermittantly or not working at all. For legacy VPN configuration using crypto maps (such as on the Cisco ASA firewalls) this is defined using an ACL with permit statements specifying what should be encrypted and denies being traffic that should be sent in plain text. In many of the newer IOS VPN implementations the Encryption Domain is defined automatically and can still be seen using the older commands. When using GRE over IPSEC for instance the encryption domain is specified as all GRE traffic (IP Protocol 47) from local peer ip (tunnel source) to remote peer ip (tunnel destination) However when using Raw IP within IPSec, the encryption domain is specified as all IP traffic regardless of source/destination. In both cases traffic destined for a configured tunnel interface will define what traffic is encrypted or not. Crypto Maps Crypto Maps are still the primary means of linking all the various components in a VPN together on a Cisco ASA Firewall. The Crypto map will define the peer, IPSec Proposal/Transform set, IPSec SA lifetime and encryption domain for that specific VPN tunnel. Crypto maps are defined globally and then linked to the interface from which VPN connections should be established. Whilst IOS VPNs can still use a crypto map and is still commonly done when connecting to other parties. It is more common to use the method discussed below. 52 Chapter 1. Networking Grumpy Networkers Journal Documentation, Release 0.0.7 Tunnel Protection Profiles To be able to more closely link the requirements of a VPN to it’s correct interface Cisco implemented the Tunnel Protection Profiles. Unlike Crypto Maps, Protection Profiles are specified on the correct tunnel interface and therefore allow encryption to be added after the fact to other tunnel encapsulations. The mode of tunnelling set on the interface determines how the tunnel is implemented and it’s important (as with any VPN) that both peers are configured in a similar (if not exactly the same) manner. Both a IPSec Profile and ISAKMP Profile (part of the IPSec profile on older IOS versions) can be specified allowing for a greater level of flexibility in what clients should be allowed to use that specific VPN. The Tunnel Protection Profiles is used almost universally across VTI, DVTI, DMVPN and FlexVPN implementations. Connection Profiles The Cisco ASA offers a consistent means of defining VPN settings across all the supported VPN protocols (whether it be IPSEC, SSL, or L2TP/IPSEC). The connection profile (or more usually called Tunnel Group from the CLI command) defines the VPNs that are permitted. In the case of traditional site-to-site VPNs the Connection Profile will be named after the remote peers IP. In the case of Remote Access VPNs that name will be the “Group Name” for the legacy IPSec VPN Client. For SSL/IKEv2 based VPNs the Connection Profile will be appended to the servers name and provides a means to identify what service the user is trying to access. Irrespective of what profile the user tries to connect to they can be moved to a more appropriate group during the authorisation phase. 1.1.4 Introduction What is a VPN VPNs are a private network service delivered over a public (or shared) network infrastructure. The two important characteristics of a VPN are that it is virtual and that it is private. The simplest form of a VPN connection could be considered a telephone call because it is virtual in the sense there is no direct physical link between the two parties and that it is private therefore protected (at least at a simple level) from eavesdropping. Motivations for VPN usage The primary motivation for deploying a VPN is in order to save cost. Whilst there is no real technical limitation in providing all of an enterprises locations (be they head office, branch office or remote worker) with a dedicated connection, the cost to do so would be unrealistic for most businesses. Practically all enterprises or organisations need some kind of Internet access therefore why not utilise this existing connectivity to connect all of the distant offices. Add to this this the requirement for users to be able to acces company resources whereever they may be (perhaps also using wifi, mobile or even satellite technology), the benefits of providing VPN services start to outway the downsides. The majority of organisations won’t use VPN’s exclusively and will make use of local WAN services (such as MPLS) where it is feasable. VPNs will then be used to provide connectivity to those offices where direct WAN connectivity is not possible (such as road warriors and/or mobile sites). This sites will make use of whatever connectivity they have available to connect back to a central site and then onto the larger WAN. 1.1. Virtual Private Networks 53 Grumpy Networkers Journal Documentation, Release 0.0.7 Risks of using a VPN The cost benefits of offering VPN services even with the need for specialised devices to terminate the connections soons becomes clear, it’s not without it’s downsides. The most obvious limitation is that there should be no assumed security of data when it is carried over the public net- work. Additional techniques are needed to secure the data which then carries it’s own problems in terms of complexity and impact on performance. The second risk is that public networks don’t offer any performance guarantees. Usually when choosing your private WAN supplier, part of the contract with them will include service level agreements (SLAs) that dictate what is accept- able performance (e.g. packet loss, round trip time, jitter, etc) and the supplier may be forced to pay penalties if this is not met, often Quality-Of-Service technology will be used to ensure these targets are met. None of this applies when running a VPN over a public network (especially the Internet). 1.1.5 VPN Technologies Over the years a number of different VPN protocols have come into existance. Whilst some no longer see wide spread use it’s possible you may come across them when migrating from legacy technologies. Broadly speaking the VPN technologies can be broken into: • Layer 2 VPNs • Layer 3 VPNs • SSL VPNs The way in which a VPN is used also has an impact on the VPN protocols development. The VPN technologies can again be categories as used for either: • Site-To-Site • Remote Access Layer 2 VPNs Layer 2 VPNs as their name suggests operate at the data-link layer of the OSI model. This means that they are independant of the protocol used to transfer the users data which would commonly operate at Layer 3 (such as IPv4, IPv6, etc). The most common Layer 2 VPNs are ATM and Frame Relay. Because of the way in which the protocols operate within a service providers infrastructure, they are inherintly only designed for site-to-site connectivity. Layer 3 VPNs Layer 3 VPNs operate at the network layer of the OSI model and therefore are tied to the protocol operating at that layer (such as IPv4, IPv6, etc). This could be considered a limitaion but it enables traffic to be carried over any network that supports the same Layer 3 protocol (such as the Internet). The most commonly deployed Layer 3 VPNS are IPSec, GRE and MPLS. IPSec is an industry standard VPN Solution that has been added as an extention to IPv4 but is built-in to the protocol for IPv6. In reality it is is not a single protocol and requires assistance from other protocols such as ISAKMP and Diffie-Helman to function. The most commonly deployed form of IPSec using IKE version 1 but with the increasing need for better security a newer version of protocol exists which not only helps standardise the original but also takes away some of it’s weaknesses. Probalby unsuprisingly this new version is called IKEv2. 54 Chapter 1. Networking Grumpy Networkers Journal Documentation, Release 0.0.7 Because of IPSecs functionality it can operate as either a site-to-site or remote access VPN solution. This flexibility does however come at a cost as whilst site-to-site connectivity is mostly standardised, anything beyond the most basic remote access solution ofter requires buying into a particular vendors implementation. IPSec clients are built-in to most modern operating systems that provide this basic connectivity either alone or when combined with L2TP. The L2TP protocol (RFC 2661) was designed for transporting PPP frames over an IP network. This was in the past used to allow users to dial-in to a local access server and then be able to transparantly access the corporate network over the service provider network via the L2TP tunnel. L2TP however does not offer any confidentiality guarantees so anyone with access to the service provider equipment could still spy on private data. When combined with IPSec however this limitation goes away and is a type of remote access service built-in to most of the popular operating systems (such as Windows, Android, etc). Because of the IPSec encapsulation it is not necessary to expose the L2TP services to the wider Internet, only those required for the IPSec (e.g. ISAKMP, ESP/AH and NAT-T) communication need to be available. GRE VPNs were originally developed by Cisco but then later published as a standard under RFC 1701 with the delivery header being defined in RFC 1702. Although GRE is considered a VPN because the data is encapsulated with the GRE headers, GRE as with L2TP does not offer any confidentiality guarantees. Even with limitation it is still very useful as when combined with IPSec it removes IPSECs limitation of only being able to carry IP traffic whilst also benefitting from the confidentiality features provded by IPSec. GRE in general should be considered a site-to-site VPN technology and not suitable for remote access purposes, however with various Cisco designs it is certainly possible to deploy GRE as a rapid site deployment solution. Just don’t expect this to be something your average road warrior would be want to deal with. PPTP was originally developer a number of vendors (including Microsoft) and whilst a specification was published under RFC 2637 it has not been proposed as an IETF standard. It was originally included with Windows 95 OSR2 in 1999. PPTP works by initiating a connection over TCP 1723 and the carrying the user traffic over a non-standard GRE packet format. Over the years a number of weaknesses have been found in the protocol therefore it is not recommended for any new deployment and should only be used as a last resort with non-critical data. MPLS is a type of VPN that is most commonly deployed across a service providers network. By using multiple levels of MPLS labels (or tags) its possible for a service provider to use the same network infrastructure to support multiple customers whilst also keeping all of the IP traffic (or other layer 3 protocols) and addressing seperate from one another. As a side note, MPLS technically operates between Layer 2 and 3 due to the way it encapsulates packets. MPLS by default does not offer any confidentiality guarantees so requires support from other VPN technologies to provide this. As MPLS is not deployed over a public network (such as the Internet) the majority of customers are not as concerned as with other environments. Those enterprises that do have strict compliance requirements over data privacy can choose to implement VPNs (such as IPSec) over the top of MPLS but this breaks the inherent benefit of the any-to- any connectivity that MPLS provides. Cisco has developed a type of VPN that overlays MPLS whilst still maintaining the any-to-any connectivity and also making the VPN infrastructure more managable by having the majority of the VPN configuration stored in a central location and pushed out to the network endpoints that are members of a group. This technology is called GetVPN and combines IPSec with another protocol, GDOI. SSL VPNs Most recently there has been a take up on a type of VPN that takes advantage of existing technologies to secure user traffic. This type of VPN is known as an SSL VPN and enables users to access the internal network securely over an untrusted network by using the the same (or similar protocols) to that used for normal Web Traffic. SSL VPNs would be using the same SSL (or newer TLS) protocols to offer the confidentiality and integrity guranatees expecting of a secure VPN. 1.1. Virtual Private Networks 55 Grumpy Networkers Journal Documentation, Release 0.0.7 Depending on the the deployment users can access the SSL VPN either directly through a supported Web Browser and/or through a full VPN Client just as with the above protocols. The more appropriate method will of course depend on what the user needs access and will be converted later in the relevent chapter. A final note is that unlike with the earlier protocols, SSL VPNs are inherently designed based on a particular vendors implementation so it should not be expected that one vendor would be able to communicate with another vendors device using this technology. SSL VPNs go by various names, some of the most common are: • Cisco AnyConnect • Palo Alto GlobalConnect • Microsoft SSTP • Pulse Secure • OpenVPN Not all of these implementations should be considered equal, for instance whilst OpenVPN and Microsoft SSTP are purely VPN clients the others offered by Cisco and Palo Alto (as 2 examples) offer a more complete solution including extra features suchas Endpoint protection. 1.2 Network Protocols 1.2.1 Secure Shell (SSH) General • Both versions generally use a host-specific key of 2048-bits. • Servers that support both SSH Version 1 and 2, usually indicate this by advertising version 1.99 in their connec- tion banner. • Minimum of 768-bits for RSA Key Version 1 • No defined standard, considered proprietary • Ciphers (3DES, Blowfish, DES) • Authentication (?) • Supports only RSA Keys • Forward Security provided through an additional server key, of 768-bits. This is commonly regenerated (e.g. once per hour) • Lack of strong mechanism for ensuring integrity of connection Version 2 • Initially RFC 4251 • Incompatible with version 1 • Minimum of 768-bits for RSA Key 56 Chapter 1. Networking Grumpy Networkers Journal Documentation, Release 0.0.7 • Supports DSA, ECDSA and RSA Keys • Forward Security provided through Diffie-Hellman (DH) Key Exchange • Integrity provided through HMAC (HMAC-HD5, HMAC-SHA1, etc) • Multiple supported authentication methods – Password – Public Key (at least DSA or RSA) – Keyboard Interactive / Generic Message Exchange Authentication – GSSAPI 1.2. Network Protocols 57 Grumpy Networkers Journal Documentation, Release 0.0.7 58 Chapter 1. Networking CHAPTER 2 Security 2.1 Common Network Attacks 2.1.1 Common Layer 2 Attacks • CAM Table OverFlow • ARP Spoofing • Rogue DHCP Server • Root Bridge Selection • Rogue Devices • Rogue Switches • VLAN Hopping 2.1.2 Common Layer 3 Attacks • Denial Of Service – TCP Flooding • Distributed Denial Of Service 2.1.3 Common Application Attacks • SQL Injection • Session Hijacking • Cross Site Scripting (XSS) • Cross Site Request Forging (CSRF/XSRF) 59 Grumpy Networkers Journal Documentation, Release 0.0.7 2.2 Securing the Switch Infrastructure • Protecting the Root Bridge • Defending against Rogue Hubs and Switches • Preventing Switching Loops • Preventing Rogue DHCP Servers • Defending againt Rogue Devices 2.3 Segregating Networks using Firewalls 2.3.1 Introduction As a general definition a Firewall is either a physical device or logical software who’s purpose is to to restrict the traffic which is allowed to flow either into the device/network or to exit the device/network. A network that doesn’t allow any traffic to flow is not a very useful or practical one, so a need for compromise exists between the organisations security team wanting absolute security and the people within the organisation being able to get their work done. In the past the primary concern was to deploy firewalls on the perimeter of the network, such as where the private (Trusted) network joins with a public (Untrusted) network such as the Internet. Traffic was generally permitted to leave the network but anything trying to come from the public network into the private network was highly restricted. As security has matured however there has been a greater emphasis on the need to also restrict the flow of traffic between even different trusted networks, such as where an office LAN connects with a critical datacentre environment. With the greater risk of malware and the use of the network to either take advantage of unsecured hosts (turning them into zombie hosts) and also exfiltrate valuable data from the network, organisations are now taking a more active look at restricted traffic which is leaving the network as well. In this chapter we will look at the different types of Firewalls and the advantages/disadvantages of both. We will also review how to write good firewall policies so that the organisations goals are met but also minimising the risk of a security breach. 2.3.2 Network-Based Firewalls When a firewall is mentioned, the first impression people think of is that of a physical device sitting in a server room or data centre and restricting what applications they can run over the Internet. This is not the only type of firewall however. The description above, is what is referred to as a Network-Based Firewall. Its role is to filter traffic for an entire LAN or in large scale environments the organisations entire network. Depending on its position in the network it either provides the last line of defence (such as when protecting outbound traffic at the network perimeter) or the first line of defence when defending against inbound traffic. A device of this nature is usually a physical device, however more recently there has been a need for deploying firewalls within a virtualised infrastructure such as HyperV, VMWare or KVM/Openstack in order to provide efficient filtering of traffic between different virtual machines. Examples of this include the Cisco ASAv and Palo Alto VM series. Most organisations will deploy a purpose built firewall from a major vendor (such as those mentioned in the last paragraph or Checkpoint) which makes it easier to meet compliance requirements and to keep up-to-date with security patches. These purpose built devices are hardened to only provide the features needed to filter network traffic and not 60 Chapter 2. Security Grumpy Networkers Journal Documentation, Release 0.0.7 have unnecessary software or libraries which the average desktop or server operating system would have installed and could be exploited. A large number of the current market of firewalls use some kind of Linux-based operating system under the hood and it’s certainly possible to roll your own firewall appliance either directly (using tools such as IPTables/NetFilter), communitity projects also exist which can provide equivilent features to most of the major vendors for what a small organisation should need (such as PFSense or Smoothwall Express). Almost all network devices can be made to do some level of firewalling but in many cases this is nothing more than a basic traffic filter requiring a bit more work to ensure the firewalls allow return traffic but still not offering the same level of security as a dedicated firewall. An example of this would be a Cisco IOS router with basic interface ACLs or a Linux device with the minimal IPTables configuration and no additional modules to maintain the state of connections. A basic firewall should be capable of filtering traffic on at least the following: • Protocols (e.g. IP, TCP, UDP) • IP addresses (source and destination) • Service Port Numbers (source and destination) These are capabilities of a basic packet filter. 2.3.3 Personal Firewalls A personal firewall is intended only to defend the host upon which it’s running on. Whilst this can be cause of much frustration for users and administrators when the firewalls blocks something they want to use, it’s location can be very beneficial to defending the network and stopping maliscious traffic from ever going out onto the network. The personal firewall can be either built into the operating system (such as Windows Firewall or IPTables) or installed as a seperate piece of software (such as ZoneAlarm). Many Anti-Virus vendors provide suites of products that also include Firewall capabilities and allow all of the features to be managed from a single interface or even manage multiple hosts from a central management station. Because the personal firewall is running on the host, it can gain much greater detail than that of a network-based firewall. Usually the firewall software (either built-in or addon) will have some view it what programs are running on the host and the traffic they are generating/receiving, this means it can make decisions based not only the basic packet filtering capabilities above but also: • User running the application • Name of the application/process • The hash value of the executable on the machine Using this additional insight can enable an administrator to prevent malicious applications even getting a single packet on the network. It can also be used to permit traffic based on the application where it may use dynamic IP addressing that can’t be written as a traditional packet filter rule. 2.3.4 Next Generation Firewalls The current trend is in a next wave of firewalls that are said to offer a number of “Next Generation” features. This is nothing new as was seen before in what used to be referred to as Unified Threat Management (UTM) devices. The basic idea behind these NGFWs is to offer feature beyond that of just making decisions based on the protocol, IP addresses and service ports. The NGFW can also pull in external information that allows it to judge the reputation of either then sender or desti- nation of the traffic, such as banning traffic to/from known botnets. Blocking traffic based on the domain name being accessed. 2.3. Segregating Networks using Firewalls 61 Grumpy Networkers Journal Documentation, Release 0.0.7 They can also do deeper levels of inspection, in the same way as what an IDS/IPS would do by comparing traffic against known signatures. Certain vendors preach that their key benefits are the ability of their platform to determine the application involved by analysing the stream of data as it comes through. The ability to analysis the traffic will of course by hampered by the use of encryption so many NGFW’s also include the ability to a man-in-the-middle and break the communication between sender and receiver so they can snoop into what is being sent. Where this is used for HTTP/HTTPS traffic, the NGFW is taking on an additional role that previous was the responsibility of dedicated web filtering appliances. The NGFW can make decisions based on URL categories rather than having to deal with specific IP addresses or URLs. 2.3.5 Firewall Methodologies Packet Filtering A packet filtering firewall makes decisions purely based on the most simple of details in the packet. This is often referred to as the Packet Tuple and includes: • Protocol • Source IP • Destination IP • Source Port • Destination Service Port This type of firewall is available quite cheaply and most home broadband routers will include these basic features. It does however suffer from a number of weakernesses • Only considers the basic details above so is subject to IP spoofing • No session information is maintained therefore traffic must be permitted in each direction regardless of if an active flow is currently maintained. • Cannot handle applications with dynamic ports, the rules must be open all the time even if not currently neeeded. Application Layer Gateway Sometimes also called a Proxy Firewall or Application Gateway. These devices are able to operate at OSI levels 3 and above and included specilised software which enables them to decode the application traffic. Often acting as an intermediate devie so there is no direct communication between client and server. Because the ALG can look all the way up the network stack it can make very fine grained decisions. The disadvantage of this is that the ALG must also be written to know how to handle the application and cannot understand that which it hasn’t been programmed to process. The example of the Web filtering used in NGFW’s would be an example of an ALG, also in older firewalls the ability for them to handle dynamic ports used by either FTP or SIP traffic is also the realm of an ALG to handle. Older Cisco firewalls offer basic ALG features as described above where as Palo Alto tout one of the main features of their products is the ability for them to understand hundreds (if not thousands) of different applications and make their policy decisions based upon the appliation detected. 62 Chapter 2. Security Grumpy Networkers Journal Documentation, Release 0.0.7 Stateful Packet Filtering Almost all modern firewalls are at least capable of performing Stateful Packet Filtering. The key difference between a basic packet filter and stateful packet filter is that the firewall remembers what has occured in the session up to that point. In the case of TCP sessions for example, a firewall is aware of if the 3-Way handshake has occured and in what order. If a packet is marked with incorrect flags the firewall can choose to drop the packet as an invalid selection. More advanced stateful firewalls will also maintain additional details such as sequence numbering so as to provide anti-replay detection. As covered under the Application Layer Gateway section, a stateful firewall can also look deeper into the packets and discern additional detail (such as FTP port commands to open dynamic connections). Unlike the ALG it does this without acting as a proxy so is more limited and is further constrained where any kind of encryption is involved. Transparent Firewalls Most firewalls are implemented so that traffic needs to be routed to them (such as using them as the default gateway on a LAN). This however can mean quite substantial changes if the network curretny does not have any firewalling in place. The solution is to implement a Transparent Firewall. This differents from a typical firewall deployment in that no changes are needed on the network as the firewall is not assigned an IP address (except perhaps for management). By doing this a firewall can be deployed into an existing network in order to segregate hosts or subnets. In the case of a network that never had traffic filtering applied. The policy on the transparent firewall can be slowly built up until all traffic is accounted for, at which point for more substantial change can be planned to move to routed firewall model. 2.3.6 Firewall Policy Management Policy Enforcement A firewall acts as an enforcement point in the network for the policy as dictated by the organisations management. It is important that the firewall is deployed in such a way as to secure the network but not limit the ability of users to go about there daily tasks. One of the most common tasks for a Firewall Administrator is to maintain the rulebase on the firewall so that they are meeting the security needs of the organisation yet still not allowing anything inbound or outbound that has not been authorised. Determing Policy Whenever the firewall admin is planning to make a change to the existing configuration he needs to ask himself the following questions: 1. Is the request reasonable and not too wide reaching? 2. Is there any existing policy which either allow or prevents me implementing this request? 3. Is all the information provided correct? 4. How can ensure that the implemented policy is managable? 5. What additional information do I need to ensure the changes can be suitably audited in the future? 2.3. Segregating Networks using Firewalls 63 Grumpy Networkers Journal Documentation, Release 0.0.7 Many users will request that changes are made to the firewall without fully understanding what the issue is. Even technical users (e.g. developers) fall into this category and will often request the rules be placed on the firewall which really don’t need to be as unrestricted as they think. It is the role of the firewall administrator to make this judgement call and only puts rules on the firewall which meet the requirement and do not provide any more access than is absolutely necessary. All of the changes the firewall admin make to the firewall must have a precedent in the organisations security policy. For instance, if the security policy states that telnet is not allowed then the firewall admin should not make any change which permits this without checking with either the security or management team. They can then make the decision either to deny it or to update the security policy accordingly. Often the request received from the user will be very vague simplying being “I need to access Application X”. It is the role of the firewall admin to gather further information from the user/requester so that it can be suitable implemented on the device. At the very least the 5-tuple information should be known so that further validation can be done. It’s all well and good to know the technical details to implement the firewall rule but it is needs to be validated that this is correct and covers all the requirements going forward. Too many times a new rule will be implemented only for a seperate (seemly unrelated) request to come in the following day which results in a second rule being added for the same thing. This is how a policy which is only really handing 10-15 different applications ends up having hundreds if not thousands of seperate rules. The solution to this is to gather as much information as possible so that the rules can be implemented in a way which allows easier identification and possibly grouping of related rules together. Most vendors will provide the following features to make the entire firewall policy more managable: • Named IP addresses and Subnets • Named Applications and Services • Grouping of related IP addresses,Networks, Service Ports and Application so many rules can be implemented as one (or fewer rules). When changes are made to a firewall, larger organisations often require that changes are approved before being made. The process for doing this can range from a simple request to another colleague to a full on meeting, often called the Change Approval Board (CAB) whereby all changes are reviewed and changes have to be planned for a certain date and time. Either way this information should be recorded in the firewall policy documentation and preferably on the firewall itself so that any changes made can be linked with the approval. A vendors firewall information should include an area to put a comment on a rule so that a (potentially non-technical) auditor can review the policy and ensure it is meeting the security requirements without any approved changes. An example of a good comment could be: “20170220-CR12345-JB: Remote Management of Hosted Azure Servers” The above comment includes a freeform text to give a non-technical description of why the rule exists along with when it was applied, the Change Reference and the engineer who applied the change. Information that could potentially be gained elsewhere (such as who requested the rule or the date of the request) should be recorded elsewhere (such as in the organisations ticketing system) and it isn’t something that would be needed at quick glance. A regular firewall review may take place to ensure that all rules are still needed and this is where the requestor information is useful but it is not something that would be helpful when troubleshooting an issue. 2.3.7 Firewall Management Plane Hardening Best Practice The following lists the most basic actions to take in order to secure the management of a Firewall: • Use HTTPS and SSH for device access instead of HTTP and Telnet where possible • Configure logging for all actions performed • Configure AAA for role-based access control 64 Chapter 2. Security Grumpy Networkers Journal Documentation, Release 0.0.7 • Use a local fallback account in case AAA server is unreachable • Use NTP to synchronize the time • Authenticate routing neighbors and log neighbor changes 2.4 Cryptography Overview 2.4.1 Suite B Crytography • Published as RFC 4869 • Specify optional suites to be used as part of IPSEC • AES • GCM (Galois/Counter Mode) - https://tools.ietf.org/html/rfc4106 2.4.2 Public Key Infrastructure Overview Vendor Implementations Setting Up Cisco IOS Router as CA Server Configuration Steps Pre-Requisites 1. Configure interface on which to service request 2. Configure approrpiate static/dynamic routing to reach requesting devices 3. Ensure time on the device is correct (NTP recommended) Generate the public/private keys crypto key generate rsa general-keys exporting label Export the keys (Public and private) crypto key export rsa Enable HTTP Server for SCEP requests ip http server 2.4. Cryptography Overview 65 Grumpy Networkers Journal Documentation, Release 0.0.7 Create CA Server crypto pki server Note: You will be prompted to enter a password to protect private key Verification Steps Verify server is running show crypto pki server Using OpenSSL to setup a CA Server Todo: Document how to use OpenSSL to setup a CA Server including intermediate CAs, issuing of certificates, SCEP as well as OCSP/CRL revocation checks. Todo: Research other implementations (e.g. Microsoft, Open Source such as DogTag, Cloud Hosted such as LetsEn- crypt) PKI Introduction • Framework for managing the security attributes between peers who are enagaged in secure communication PKI Message Echange Process • Host generates RSA Signature (Public and private key) and sends public key to CA (CSR) for signing • CA will sign the certificate request with it’s private key, validating it origin in form of a certificate • Host will save certificate and use as the public key portion in communicating with other peers 2.4.3 Encryption Algorithms Symmetric Encryption 66 Chapter 2. Security Grumpy Networkers Journal Documentation, Release 0.0.7 Asymmetric Encryption 2.4.4 Hashing Algorithms 2.4.5 Elliptic Curve Cryptography 2.5 Authentication Services Todo: Document RADIUS and TACACS services for all the AAA functions 2.5. Authentication Services 67 Grumpy Networkers Journal Documentation, Release 0.0.7 68 Chapter 2. Security CHAPTER 3 Cloud Services 3.1 Cloud Deployment Models • Infrastructure as a service (IAAS) • Platform as a service (PAAS) • Software as a service (SAAS) 3.2 Cloud Service Models • Private • Community • Public • Hybid 69 Grumpy Networkers Journal Documentation, Release 0.0.7 70 Chapter 3. Cloud Services CHAPTER 4 Documentation 4.1 Sphinx 4.1.1 External Reference reStructuredText Primer http://www.sphinx-doc.org/en/stable/rest.html Todo: Document Sphinx formatting characters that have been used in this document for easier refrence 71 Grumpy Networkers Journal Documentation, Release 0.0.7 72 Chapter 4. Documentation CHAPTER 5 Study Notes 5.1 Cisco CCNP - Implementing Cisco Secure Mobility Solutions (300-209 SIMOS) 1.0 Secure Communications (32%) 1.1 Site-to-site VPNs on routers and firewalls 1.1.a Describe GETVPN 1.1.b Implement IPsec (with IKEv1 and IKEv2 for both IPV4 & IPV6) using IOS and ASA 1.1.c Implement DMVPN (hub-Spoke and spoke-spoke on both IPV4 & IPV6) 1.1.d Implement FlexVPN (hub-Spoke on both IPV4 & IPV6) using local AAA 1.2 Implement remote access VPNs 1.2.a Implement AnyConnect IKEv2 VPNs on ASA and routers 1.2.b Implement AnyConnect SSLVPN on ASA and routers 1.2.c Implement clientless SSLVPN on ASA and routers 1.2.d Implement FLEX VPN on routers 2.0 Troubleshooting, Monitoring, and Reporting Tools (38%) 2.1 Troubleshoot VPN using ASDM & CLI 2.1.a Troubleshoot IPsec 2.1.b Troubleshoot DMVPN 2.1.c Troubleshoot FlexVPN 2.1.d Troubleshoot AnyConnect IKEv2 and SSL VPNs on ASA and routers 2.1.e Troubleshoot clientless SSLVPN on ASA and routers 3.0 Secure Communications Architectures (30%) 73 Grumpy Networkers Journal Documentation, Release 0.0.7 3.1 Design site-to-site VPN solutions 3.1.a Identify functional components of GETVPN, FlexVPN, DMVPN and IPsec 3.1.b VPN technology considerations based on functional requirements 3.1.c High availability considerations 3.1.d Identify VPN technology based on configuration output 3.2 Design remote access VPN solutions 3.2.a Identify functional components of FlexVPN, IPsec and Clientless SSL 3.2.b VPN technology considerations based on functional requirements 3.2.c High availability considerations 3.2.d Identify VPN technology based on configuration output 3.2.e Identify AnyConnect client requirements 3.2.f Clientless SSL browser and client considerations/requirements 3.2.g Identify split tunneling requirements 3.3 Describe encryption, hashing, and Next Generation Encryption 3.3.a Compare and contrast Symmetric and Asymmetric key algorithms 3.3.b Identify and describe the cryptographic process in VPNs: • Diffie-Hellman • IPsec – ESP, AH, IKEv1, IKEv2 • Hashing Algorithms MD5 and SHA • Authentication methods 3.3.c Describe PKI components and protection methods 3.3.d Describe Elliptic Curve Cryptography 3.3.e Compare and contrast SSL, DTLS and TLS 5.2 Cisco CCNP - Implementing Cisco Edge Network Security Solu- tions (300-206 SENSS) 1.0 Threat Defense (25%) 1.1 Implement firewall (ASA or IOS depending on which supports the implementation) 1.1.a Implement ACLs on IOS, ZBFW and ASA 1.1.b Implement static/dynamic NAT/PAT (on IOS and ASA devices) 1.1.c Implement object groups 1.1.d Describe threat detection features 1.1.e Implement botnet traffic filtering 1.1.f Configure application filtering and protocol inspection 1.1.g Describe ASA security contexts 74 Chapter 5. Study Notes Grumpy Networkers Journal Documentation, Release 0.0.7 1.2 Implement Layer 2 Security 1.2.a Configure DHCP snooping 1.2.b Describe dynamic ARP inspection 1.2.c Describe storm control 1.2.d Configure port security 1.2.e Describe common Layer 2 threats and attacks and mitigation 1.2.f Describe MACSec 1.2.g Configure IP source verification 1.3 Configure device hardening per best practices 1.3.a Routers 1.3.b Switches 1.3.c Firewalls 2.0 Cisco Security Devices GUIs and Secured CLI Management (25%) 2.1 Implement SSHv2, HTTPS, and SN- MPv3 access on the network devices 2.2 Implement RBAC on the ASA/IOS using CLI and ASDM 2.3 Describe Cisco Prime Infrastructure 2.3.a Functions and use cases of Cisco Prime 2.3.b Device Management 2.4 Describe Cisco Security Manager (CSM) 2.4.a Functions and use cases of CSM 2.4.b Device Management 2.5 Implement Device Managers 2.5.a Implement ASA firewall features using ASDM 3.0 Management Services on Cisco Devices (12%) 3.1 Configure NetFlow exporter on Cisco Routers, Switches, and ASA 3.2 Implement SNMPv3 3.2.a Create views, groups, users, authentication, and encryption 3.3 Implement logging on Cisco Routers, Switches, and ASA using Cisco best practices 3.4 Implement NTP with authentication on Cisco Routers, Switches, and ASA 3.5 Describe CDP, DNS, SCP, SFTP, and DHCP 3.5.a Describe security implications of using CDP on routers and switches 3.5.b Need for dnssec 4.0 Troubleshooting, Monitoring and Reporting Tools (10%) 4.1 Monitor firewall using analysis of packet tracer, packet capture, and syslog 4.1.a Analyze packet tracer on the firewall using CLI/ASDM 4.1.b Configure and analyze packet capture using CLI/ASDM 5.2. Cisco CCNP - Implementing Cisco Edge Network Security Solutions (300-206 SENSS) 75 Grumpy Networkers Journal Documentation, Release 0.0.7 4.1.c Analyze syslog events generated from ASA 5.0 Threat Defense Architectures (16%) 5.1 Design a Firewall Solution 5.1.a High-availability 5.1.b Basic concepts of security zoning 5.1.c Transparent & Routed Modes 5.1.d Security Contexts 5.2 Layer 2 Security Solutions 5.2.a Implement defenses against MAC, ARP, VLAN hopping, STP, and DHCP rogue attacks 5.2.b Describe best practices for implementation 5.2.c Describe how PVLANs can be used to segregate network traffic at Layer 2 6.0 Security Components and Considerations (12%) 6.1 Describe security operations management architectures 6.1.a Single device manager vs. multi-device manager 6.2 Describe Data Center security components and considerations 6.2.a Virtualization and Cloud security 6.3 Describe Collaboration security components and considerations 6.3.a Basic ASA UC Inspection features 6.4 Describe common IPv6 security considerations 6.4.a Unified IPv6/IPv4 ACL on the ASA 5.3 Cisco CCNP - Implementing Cisco IP Switched Networks (300-115 SWITCH) 5.3.1 Cisco CCNP SWITCH - Exam Objectives 1.0 Layer 2 Topics (65%) 1.1 Configure and verify switch administration 1.1.a SDM templates 1.1.b Managing MAC address table 1.1.c Troubleshoot Err-disable recovery 1.2 Configure and verify Layer 2 protocols 1.2.a CDP, LLDP 1.2.b UDLD 1.3 Configure and verify VLANs 76 Chapter 5. Study Notes Grumpy Networkers Journal Documentation, Release 0.0.7 1.3.a Access ports 1.3.b VLAN database 1.3.c Normal, extended VLAN, voice VLAN 1.4 Configure and verify trunking 1.4.a VTPv1, VTPv2, VTPv3, VTP pruning 1.4.b dot1Q 1.4.c Native VLAN 1.4.d Manual pruning 1.5 Configure and verify EtherChannels 1.5.a LACP, PAgP, manual 1.5.b Layer 2, Layer 3 1.5.c Load balancing 1.5.d EtherChannel misconfiguration guard 1.6 Configure and verify spanning tree 1.6.a PVST+, RPVST+, MST 1.6.b Switch priority, port priority, path cost, STP timers 1.6.c PortFast, BPDUguard, BPDUfilter 1.6.d Loopguard and Rootguard 1.7 Configure and verify other LAN switching technologies 1.7.a SPAN, RSPAN 1.8 Describe chassis virtualization and aggregation technologies 1.8.a Stackwise 2.0 Infrastructure Security (20%) 2.1 Configure and verify switch security features 2.1.a DHCP snooping 2.1.b IP Source Guard 2.1.c Dynamic ARP inspection 2.1.d Port security 2.1.e Private VLAN 2.1.f Storm control 2.2 Describe device security using Cisco IOS AAA with TACACS+ and RADIUS 2.2.a AAA with TACACS+ and RADIUS 2.2.b Local privilege authorization fallback 3.0 Infrastructure Services (15%) 3.1 Configure and verify first-hop redundancy protocols 5.3. Cisco CCNP - Implementing Cisco IP Switched Networks (300-115 SWITCH) 77 Grumpy Networkers Journal Documentation, Release 0.0.7 3.1.a HSRP 3.1.b VRRP 3.1.c GLBP 5.3.2 Cisco CCNP - Implementing Cisco IP Switched Networks (300-215 SWITCH) - Study Notes Cisco - Enterprise Campus Network Design Collision Domain • A shared network segment upon which multiple hosts compete for usage • Collisions occur when two or more hosts attempt to transmit at the same time • Network segmentation is used to reduce the sie of a collision Domain • Switches allow for micro segmentation where each port on the switch is its own collection when running at full duplex Broadcast Domain • Broadcast traffic is seen by all hosts on the segment • Excessive broadcast traffic causes performance problems and can monopolise bandwidth • Size of broadcast domains can be reduced by segmenting networks into VLANs VLAN • Defines the boundary of a broadcast domain • Passing traffic between VLANs requires a Layer 3 device Predictable Network Model • Low maintenance • High Availability • Designed around traffic flows, not type of traffic • Arranged so users are a consistent distance from needed resources Hierarchical Network Design • Efficient, Intelligent, Scaleable, Easily Managed • Distinct Layers of devices – Core – Distribution 78 Chapter 5. Study Notes Grumpy Networkers Journal Documentation, Release 0.0.7 – Access • Traffic Flow type – Local – Remote – Enterprise Access Layer • End user connectivity at Layer 2 (VLANs) • Building Access Switches • High Port Density with Low Cost Per Port • Scaleable Uplinks with High Availability • Converged Network Services (Data, Voice, Video) • Security Features and QoS Distribution Layer • Interconnects the Access and Core Layers • Building Distribution Switches • Aggregation of Multiple Access Layer Switches • High Layer 3 Routing Throughput, Layer 3 Boundary For Access Layer VLANs • Security And Policy Based Functions • QoS • Scaleable and redundant high speed links to Core and Access layers Core Layer • Connectivity Between Switches in the Distribution Layer • Backbone • Switches traffic as efficiently as possible • Very High Layer 3 Routing Throughput • No unnecessary Packet Manipulation • Redudancy and Resilience • Advanced QoS • Smaller networks may combine core and distribution layers, known as a collapsed core. Not an independent building block 5.3. Cisco CCNP - Implementing Cisco IP Switched Networks (300-115 SWITCH) 79 Grumpy Networkers Journal Documentation, Release 0.0.7 Best Practices • Design each layer with a Pair of switches • Connect each switch to next layer with redudant links • Connect each pair of distribution switches with at least one link • Do not connect access layers unless a stack or chassis switch • Do not extend VLANs beyond distribution switches Modular Network Design • Permits the network to grow in a logical predictable manner • A switch block is a group of access layer switches with one or more distribution layer switches • Takes redudancy and scaleability into account • Core/Backbone layer used to connect all switch blocks • Other elements (such as a Datacenter block) can be added as needed Switch Block Sizing • Traffic Types andd Behaviour • Size and number of common workgroups Oversized switch block problems • Bottlenecks at distribution layer (CPU, Memory, Throughput, etc) • Broadast/Multicast traffic slows the switches in the switch block Switch Block Redundancy • Multiple Power Supplies on different power sources • Multiple distribuion switches • Use a FHRP on the destribution switches (HSRP, VRRP, GLBP) • Avoid Layer 2 loops where possible • Do not use same VLAN across multiple access switches Network Core • Required to connect two or more switch blocks • As efficient and reliable as possible • Links between core and distribution shoul be layer 3 • Consider average aggregate link utilisation when scaling links 80 Chapter 5. Study Notes Grumpy Networkers Journal Documentation, Release 0.0.7 • Deploy two multilayer switches (MLS) as a dual-core for Redundancy • Add more core switches to form a multi-node core when needed, fully mesh if possibble • Number of core switch peerings is limited only by number of distribution layer switches Choosing Cisco products to use at each layer • Access Layer - High Port Densityy, Low Cost – 2960-X, 3650, 3850 with 48 ports each – 4500E For a single chassis switch • Distribution/Core Layer - High Layer 3 Switching Throughput, High Density, High Bandwidth Ports – 4500-X, 45000E, 6807-XL – 3750-X For smaller switch blocks/networks Traffic Flow Paths • Local (Access Layer Only) • Remote (Access To Distribution) • Enterprise (Access To Distribution To Core) Cisco - Switch Operation Layer 2 Operation On Legacy Networks • A Network where all hosts share the same bandwiddth is called a shared media network. Used in legacy netwroks with hubs and CSMA/CD Scheme • Carrier Sense Multiple Access with Collection Detect (CSMA/CD) determine when devices were allowed to transmit • Collision occurs when two or more hosts transmit at the same time. Hosts must operate in half-duplex mode (Transmit or Receive, no both) • Hosts must “back off” for a random perioud befoe trying to transmit again • All frames must be processed by all hosts, even those not addressed to them and also frames with errors Layer 2 Operation On Switched Networks • Switches operate at layer 2, unlike hubs that operate at layer 1 • Switches decide where to send frames based on their destination MAC addressed • Media no longer shared with other hosts as long as the port is running in full-duplex • Host isolation – Each switch port is its own collision domain – Host connections operate in full duplex mode 5.3. Cisco CCNP - Implementing Cisco IP Switched Networks (300-115 SWITCH) 81 Grumpy Networkers Journal Documentation, Release 0.0.7 – Bandwidth on a port is no longer shared – Switches check frames for errors, dropping or forwarding as appopriate (Store And Forward) – Broadcast Traffic can be limited to a given threshol (Storm Control Feature on Cisco Switches) – Intelligent Filtering/Forwarding Features available Transparent Bridging • Layer 2 switch is a multi-port transparent bridge, each port an isolated LAN segment • Frame forwarding based entirely on the destination MAC address in the frame • A switch must be told on what port an address exists or learn it for itself • Dynamic Learning/Forwarding – Switch Listens To Incoming Frames – Source MAC address along with incoming port and VLAN are stored in a table kept in the switches memory – Forwarding table is checked for destination MAC address, port and VLAN. If found frame is forwarded out of that port only – When not found, frame is referrred to as an “Unknown Unicast” and is “Flooded” out of all ports in same VLAN excep the originating port – After a response is received the switch will know the port and VLAN so no further flooding is needed for that MAC address – Broadcast and Multicast Frames cannot be learned so are always flooded Layer 2 Catalyst Switch Decision Process • Coming frame placed in switch ports ingress queue – Queues can have different priority or service levels to allow time sensitive data to be processed first • For each frame, as its pulled from the ingres queue 3 decisions are made – Layer 2 Forwarding Table (or “CAM Table”) is checked for port and vlan using the destination MAC as the index – Security ACLs stored in the “TCAM” are checked to see if a frame should be forwarded – QoS ACLs are checked to classify, policy or control rate of traffic and mark QoS Parameters in the frame – Single parallel table lookup is used for all decisions • Once all table lookups performed, frame is placed in an appropriate egress queue, determined by QoS values in the frame or passed along with the frame. Multi-Layer Switch Operation • Types of Multi-Layer Switching (MLS) – Route Caching (1st Generation MLS) – Topology Based (2nd Generation MLS) 82 Chapter 5. Study Notes Grumpy Networkers Journal Documentation, Release 0.0.7 • MLS is a method of forwarding frames based on Layer 3 & 4 information • Layer 2 switching is still performed • Cisco IOS Catalyst Switches only support 2nd Generation Topology Based MLS • Route Caching (1st Generation MLS) – Required a Router Processor (RP) and Switch Engine (SE) – RP processes first packet in flow to determine destination – SE listens and caches result for use on subsequent packets – Known By NetFlow LAN, Flow-Based or Demand-Based switching – “Route Once, Switch Many” – Still Used to generate traffic flow info and statistics • Topology Based (2nd Generation MLS) – Specialised Hard with Distinct RP and SE functions – RP takes Layer 3 routing info to a single database of the network topology, stored in hardware – Database is consulted and packets forwarded at high rates by the SE – Hardware database can be updated with no performance penalty – Known as “Cisco Express Forwarding” (CEF) – Routing process downloads routing table into a area of hardware known as the “Forwarding Information Base” (FIB) – The control plane includes the RP – The data plane exists in the SE Layer 3 Catalyst Switch Decision Process • Packet is pulled off the ingress queue, inspecte for Layer 2 and Layer 3 destination addresses • Deciding where to forward a packet – Layer 2 Forwarding Table (CAM) is checked to see if destination is a port on the actual switch. Determines is frame should be layer 3 switched – Layer 3 Forwarding Table (FIB) is checked using destination IP as a index. Longest match is found (Address and Mask), Next-Hop Layer 3 Address along with Layer 2 MAC address, Egress port an Vlan ID is obtained to avoid further lookups • Deciding How to forward a packet * Security ACLs for inbound and outbound are compiled into TCAM to allow a decision on a single lookup * QoS ACLs for classification, policing and marking all performed as a single lookup on QoS TCAM • Packet is placed in appropriate egress queue on the correct port • Packet will be rewritten just like on a router (eg. checking DST MAC, decrementing TTL) • Entire ethernet frame is rewritten in hardware 5.3. Cisco CCNP - Implementing Cisco IP Switched Networks (300-115 SWITCH) 83 Grumpy Networkers Journal Documentation, Release 0.0.7 Multi-Layer Switching Exemptions Any of the list below are processed more slowing in software • ARP Request/Replies • IP Packets requiring a router response (TTL expired, Max MTU, Fragmentation, etc) • IP Broadcasts received as Unicast (DHCP Requests/IP Helpers) • Routing Protocol Updates • CDP Packets • Packets needing encryption • Packets requiring NAT • Legacy Multiprotocol Packets (IPX, Appletalk, etc) Content Addressessable Memory (CAM) • Used for layer switching • Source MACs are recorded as frames arrive on a switch port • If a MAC moves port, new entry recorded then old entry deleted • CAM table space is finite, stale entries removed afer a specified aging time time (default : 300 seconds/5 minutes) Managing the CAM Table Show the current contents of the CAM table show mac address-table [ Check the size of the CAM Table show mac address-table count Adjust CAM table time for removing stale elements mac address-table aging-time Add static CAM table entries mac address-table tatic Clearing CAM Table Entries clear mac address-table dynamic [ 84 Chapter 5. Study Notes Grumpy Networkers Journal Documentation, Release 0.0.7 Ternary Content Addressable Memory (TCAM) • Packets are evaluated using a single lookup on a table implemented in hardware • Avoids latency of traditional routing when matching, filtering or controlling specific traffic • Most switches have multiple TCAMs so inbound/outbound and QoS ACLs are evulated simultaneously or in parallel with layer 2/3 forwarding decisions • Components of TCAM operation in IOS – Feature Manager (FM) compiles/merges ACLs into the TCAM table – Switching Databae Manager (SDM) configures or tunes the TCAM partitions to optimise for specific functions • TCAM is fixed on the 4500/6500 platforms, cannot be repartitioned through SDM • TCAM Structure – Extends the CAM table concept – Uses three values (0,1, “Don’t care”) known as a terniary combinatio – Entries may up a value, mask and result (VMR) combination – Values and Masks are 134-bit quanities – Results are the action that should be taken after lookup (e.g. permit/deny, Qos Policier, Next-Hop, etc) – If IPv6 is used some address compression is required to store in the TCAM – TCAM is organised by mask with associated value patterns – Operations involving any other than exact matches requires use of an “Logical Operation Unit” (LOU) which are limited in number – Exceeding the numbber of LOU’s require ACE’s to be expanded so they only may use of the “eq” operator • The TCAM cannot be manipulated directly, to see the current utilisation use show platform tcam utilisation Managing Switching Table Sizes • The Catalyst 4500/6500 has ample resources for core, distribution or access layer switches and does not allow modification of table sizes • Other platforms should have their resource assigned as follows – Switches running at Layer 2 should have a larger CAM table – Switches running at Layer 3 should have a larger FIB table • The switching database manager (SDM) managed how the switches memory is partitioned and these are defined as templates – Desktop (Default, Access, VLAN, Routing) – Dual-Ipv4-And-IPv6 – Indirect-Ipv4-And-IPv6 • Display the current table sizes 5.3. Cisco CCNP - Implementing Cisco IP Switched Networks (300-115 SWITCH) 85 Grumpy Networkers Journal Documentation, Release 0.0.7 show sdm prefer • Change the current template (requires reboot) sdm prefer Media Access Control (MAC) Addresses • “Unique” address assigned to a network interface • Sometimes called hardware address or burned-in address (BIA) • Can be assigned by the manufacturer (Globally Unique) – First 3 octets (24 bits) are the organisationally unique identifier (OUI) – Last 3 octets (24 bits) are NIC specific – Bit 1 of 1st octet set to 0 (zero) for globally unique • Can be assigned by an organisations admin (Locally Administered) • Bit 1 of 1st octet set to 1 (onee) for locally administered • Total size of MAC Address is 4 bits • Globally unique MAC addresses maanged by the IEEE • MAC Addresses are written in trannsmission order, least significant bit first (Left-To-Right) as done for ethernet • Token ring uses most significant bits first Cisco - Switch Port Configuration Ethernet Overview • Determining Bandwidth Requirements – Types of applications used – Traffic flow in use – Size of user community • Links between access, distribution and core should be scaled to match required load • Ethernet based on IEEE 802.3 standard • A shared medium becoming both a collision and broadcast domain • Based on Carrier Sense Multiple Access with Collision Detection (CSMA/CD) • More “Crowded” segments likely to suffer more collisions and therefore operate ineffectively • switching eliminates the collection problem by dividing a single segment into multiple segments, each port is a unique collision domain • Hosts/stations can operate in full duplex when using switched, effectively doubling bandwidth. 86 Chapter 5. Study Notes Grumpy Networkers Journal Documentation, Release 0.0.7 Scaling Ethernet • Originally 10Mbps per segment • 100Mbps, 1Gbps, 10Gbps, 40Gbps and 160Gbps standard exist • Fast Ethernet (100Mbps) – Supported on UTP, STP and fibre-optic cables – UTP/STP limited to 100 Metres – 62.5/125 Multimode fibre (MMF) supported 400 Metres (half-duplex) or 2000M (Full Duplex) – Single Mode fibre (SMF) max 10KM – Can be bundled into etherchannels to increase bandwidth • Gigabit Ethernet (1Gbps) – Uses same 802.3 frame format – Physical later modified to increase transmission speeds – Merges 802.3 and ANSI X3T11 Fibre Channel Standards – Supported on STP up to 2M (1000Base-CX) – UTP Cat 5 upto 100M (1000Base-T) – Fibre Optic * 1000Base-SX MMF 62.5 (275M) or 50 (550M) * 1000Base-LX/LH MMF 62.5 (550M) or 50 (550M), SMF 9 (10KM) * 1000Base-ZX SMF 9 (70KM), 8 (100KM) – “Gigabit over copper” switch ports can operate at 10/100Mbps or 1Gbps – Gigabit Ethernet offers up to 16Gbps (Full Duplex) • 10-Gigabit Ethernet (10Gbps) – Layer 2 details unchanged – Uses different transceivers - Physical Mediia Dependant (PMD) Interfaces – LAN PHY - Connects switches to Campus (Core) Layer – WAN PHY - Connects existing SONET/SDH, typically found in Metropolitan Area Networks (MAN) – PMD Interfaces use “10GBASE” prefix – Runs over MMF (33M - 330M) – Runs over SMF (10KM) – Copper: CX4 with Infiniband (15M) – Transceiver Types * Wavelength - S = Short, L = Long, E = Extra Long * PHY Type - R = LAN PHY, W = WAN PHY * LX4/LW4 Long Wave length, X/W indicate the coding used, 4 is number of wavelengths * WWDM = Wide Wavelength Division Multiplexing • Beyond 10-Gigabit Ethernet 5.3. Cisco CCNP - Implementing Cisco IP Switched Networks (300-115 SWITCH) 87 Grumpy Networkers Journal Documentation, Release 0.0.7 – 40Gbps bonds 4 x 10Gbps using a Quad SFP+ Module (QSFP+) – 100Gbps bonds multiple channels/lanes – 40/160Gbps defined in 802.3ba Standard Duplex Operation Over Ethernet • Max throughput only possible when one device is connected to switch port • Switch ports are capabble of negotiating both speed and duplex, both ports muust be configured for auto- negotiation • Link speed is determined by electrical signaling, highest common speed is used • Duplex mode involves and exchange of information. Both ports must be auto otherwise half-duplex is the default • Errors on a link will occur when there is a duplex mismatch • Cisco recommendation is to use manual setings in order to avoid unusable connections • Catalyst switches 10/100/1000 auto sensing ports using RJ-45 connections with UTP cable • UTP cabling uses 4 pairs (Pins 1/2, 3/6, 4/5, 7/8) to connect straight through to other end • Gigabit provides SFP modules – Hot swappable – LC/MT-RJ Fibre Optic, RJ45 UTP Copper connectors • 10 Gigabit Ethernet uses X2 and SFP+ modules Configuring Switch ports • Performed through global configuration mode Selecting a single switch port interface Selecting multiple ports interface range Using Interface macros define interface-range Adding Comments to interfaces 88 Chapter 5. Study Notes Grumpy Networkers Journal Documentation, Release 0.0.7 interface Manually setting port speed interface Manually setting duplex mode interface Managing Error Conditions On Switch Ports General notes on error Conditions • Network management applications can poll devices to check for errors • Catalyst switches can detect errors an take action automatically • By default switches will detect errors on every port for all causes • By default switch ports must be manually shutdown then restored in order to recover • Ports are disabled for 300 seconds by default if automatically error recovery is enabled Tune trigger clauses globally [no] errdisable detect cause {all| Enable Auto Recovery errdisable recovery cause {all| Change recovery timer errdisable recovery interval Troubleshooting Port Connectivity Check Port State - Up/Up is expected for normal operation show interfaces [ Get Summary of all switch port states show interface status Show ports in error disabled states show interface status err-disabled 5.3. Cisco CCNP - Implementing Cisco IP Switched Networks (300-115 SWITCH) 89 Grumpy Networkers Journal Documentation, Release 0.0.7 Checking for speed/duplex mismatches • Check for error count greater than 0 • “Runts” are packets truncated before being fully received • Input” errors usually show • Check if running at half-duplex, indicating unsuccessful auto-negotiation Discovering Connected Devices Cisco Discovery Protocol • Automated method for devices to advertise prescense to directly connected neighbors • Cisco propietary feature • One-Way, no response expected • Sent at the Data Link Layer (Layer 2) every 60 seconds • Information advertised – Hostname – Connected Interface – Device Capabilities – Hardware Platform – Software Version – Duplex Mode – Power Info – Management IP(s) • Cisco routers and switches have CDP enabled by default See advertised neighbours show cdp neighbors [ Disable/Enable CDP globally on the switch [no] cdp run Disable/Enable CDP per interface [no] cdp enable View CDP info for named device show cdp entry 90 Chapter 5. Study Notes Grumpy Networkers Journal Documentation, Release 0.0.7 Link Layer Discovery Protocol • Based on IEEE 802.1ab • Supported By Multiple Vendors • Extendable through Type-Length-Values (TLV) structures • Specific Media Endpoint TLVs (LLDP-MED) • Must use either bbasic LLDP or LLDP-MED per interface, not both • By default globally disabled Globally disable/enable LLDP [no] lldp run Display LLDP Advertisements Received show lldp neighbors [ Disable/Enable LLDP Per interface [no] lldp {receive| transmit} Using Power Over Ethernet (POE) • PoE can be used to provide power to IP phones and wireless access points (WAPs) • Provide a means of centralised power management, unlike using individual wall warts • PoE can be managed, monitored and offerred only to known devices • Best Practice: Connect switch to UPS so power can be maintained in the event of a power outage How PoE Works • Switches must be rated to supply power to external devices • PoE methods – Cisco Inlne Power (ILP) - Cisco proprietary upto 7W – IEEE 802.3AF (PoE) up to 15.4W – IEEE 802.3AT (PoE+) up to 25.5W – Cisco Universal Power (UPoE) - Cisco propertiary up to 60W Detecting A Powered Device • Power is disabled when port is down • Small voltage is sent across transmit/receive pairs • Resistance is measured and if detected a device must be present • Resistance values determine a specific power clauses 5.3. Cisco CCNP - Implementing Cisco IP Switched Networks (300-115 SWITCH) 91 Grumpy Networkers Journal Documentation, Release 0.0.7 – Class 0 - Default (15.4W) – Class 1 - 4.0W – Class 2 - 7.0W – Class 3 - 15.4W – Class 4 (802.3AT) - Upto 30W • Class 0 used when device/switch does not attempt discovery • Max of 15.4W is usually offered • CDP/LLDP can be used to request power up to 30W • Special TLVs used with CDP/LLDP for UPoE (Catalyst 4500 only) Configuring PoE • General Notes – By default each port auto-detects if power is needed – If a device requests more power than configued, a log message is generated and port remains in non- connected state Configure Power offered on a port power inline auto [max Verifying PoE ** Monitor power available/used/total ** show power inline [module Cisco - VLANs And Trunks Virtual LANs (VLANs) Flat Network • Layer 2 only switched Network • Single Broadcast Domain • Cannot contain redudant paths 92 Chapter 5. Study Notes Grumpy Networkers Journal Documentation, Release 0.0.7 What is a VLAN • A VLAN is a single broadcast Domain • VLANs allow a flat network to be divided into multiple smaller networks • VLAN members can be connected anywhere in a campus network • Switches are configured so that each port is mapped to a VLAN • A Layer 3 device is required to enable communication between two or more VLANs VLAN Membership • Static VLAN – Port-based where port is manually assigned to a specific VLAN – No configuration required on the host – Port VLAN ID (PVID) – Hardware level switching via ASICs • Dynamic VLAN – Ports assigned to VLAN based on the connected hosts MAC address – Requires external database hosted on a VLAN Membership Policy Server (VMPS) – Flexibiliy and Mobility – Greater administrative overhead Static VLAN configuration • VLAN Created with ID and Name • VLAN 1 is default for every switch port • Standard VLAN range 1-1005 • Extended VLAN range 1006-4094 • Extended VLAN Range can only be used in VTP version 3 or on VTP transparent switches • Legacy VLANS 1002-1005 used for Token Ring and FDDI switching • Name is optional, upto 32 characters with no spaces • Switch port is configured as an “access” port when access to a single VLAN is required Deploying VLANs • Cisco recommendes one-to-one relationship between vLAN and IP Subnet • Should not allow VLAN to extend beyond Layer 2 domain of a distribution switch – Keep broadcasts out of core layer – VLAN stays within switch block – Limits Failure domain 5.3. Cisco CCNP - Implementing Cisco IP Switched Networks (300-115 SWITCH) 93 Grumpy Networkers Journal Documentation, Release 0.0.7 • VLAN scaling methods – End-To-End VLANs – Local VLANs End-To-End VLANs • Campus wide, spans entire switch fabric • Maximum Flexibility and Mobility • Users not tied to physical location • VLAN must be available at access layer of every switch block • VLAN must be available on Core Layer • Users should have same traffic flow patterns • 80/20 Rule - 80% traffic stays in workgroup, 20% remote • Not recommended unless good reason • Broadcasts are carried across entire switch fabric • Broadcast storm or Layer 2 bridging issue could affect entire network Local VLANS • Traffic Flow should follow 20/80 Rule • 20/80 Rule - 20% local traffic, 80% remote traffic • Centralised Intranet/Internet Resources • VLANs assigned around user communities based on Geographic boundaries • Little regard for amount of traffic leaving VLAN • Can be Implemented on single switch to an entire building • Layer 3 functions handle Inter-VLAN traffic loads • Maximum Availability and scaleability with redudant paths • Small Failure Domain VLAN Trunks • Trunk links transport traffic for one or more VLANs Over a single switch port • Most used between a switch and other switches/routers • Not assigne to a specific VLAN 94 Chapter 5. Study Notes Grumpy Networkers Journal Documentation, Release 0.0.7 VLAN Frame Identification • Uses Frame “Tagging”, added to each frame when carried over a trunk link • “Tag” is removed when frame is sent over a non-trunking (Access) port • Identification Methods – Inter-Switch Link (ISL) Protocol - Cisco Proprietary – IEEE 802.1Q - Standards Based • Both ISL and IEEE 802.1Q increase frame size and can result in a frame exceeding the maximum transmission unit (MTU). Referred to as “baby giants” Inter-Switch Link Protocol (ISL) • Cisco Proprietary • Original Frame Encapsulated Between ISL Header and Trailer, 30 bytes overhead – Header (26 bytes) contains 15-Bit VLAN ID (1-4094) – Trailer (4 bytes) contains CRC value for data integrity • Only supported on higher end Cisco devices IEEE 802.1Q Protocol • Standardised cross-vendor protocol • Tagging information embedded into Layer 2 frame (single/internal tagging) • Supports “Native” VLAN Where frames are sent over trunk link untagged • 4-Byte tag added after source MAC Address in the original frame • Tag contains 2 byte TPID, always has value 0x8100 • 2 bytes of TCI Field – 3 bit priority field for CoS – 12 bits for VLAN ID (VID • VLAN IDs 0,1 andd 4095 are reserved • Adds 4 bytes of overhead to each frame Dynamic Trunking Protocol • Cisco Proprietary • Used to negotiate common trunking mode between switches • Can negotiate if trunking is allowed and what protocol is used (either ISL or 802.1q) • Must be used within same VTP domain or one or both switches have a null domain • DTP frames are sent every 30 seconds • ISL is preferred over 802.1Q if both devices support it 5.3. Cisco CCNP - Implementing Cisco IP Switched Networks (300-115 SWITCH) 95 Grumpy Networkers Journal Documentation, Release 0.0.7 • Enabled by default (using “dynamic auto” mode) but only if requested by far end device • DTP can be disabled on a per port based when not desired Trunking modes • Trunk - Port is permenantly trunking however DTP is stil operational • Dynamic Desirable - Port actively tries to establish trunk with connected device • Dynamic Auto - Port can form a trunk but only if far end requests it Voice VLANs • Most Cisco IP phones contain an internal 3-port switch • Link between IP phone upstream port and switch can negotiatiate a conditional trunk • Conditional trunk allows for voice/data seperation and QoS prioritisation • Voice packets are carried over the special “Voice VLAN” (VVID) • The switch must be informed of the voice VLAN per-port • DTP and CDP are used to negotiate trunk when needed Support Voice VLAN Methods • Specific VLAN ID - Trunk enabled, voice carried over vlan, data untagged • dot1p - trunk enabled, VLAN 0 used for voice, data untagged • untagged - Trunk enabled, voice and data untagged • none - Default, no trunk, access VLAN used for both data and voice traffic Wireless VLANs • Wireless Access Points (APs) provide connectivity etween wired and wireless devices • APs Suports Autonomous and Lightweight operating modes Autonomous APs • Independant operational • Connects VLAN to WLAN one-to-one • Requires a trunk link where multiple WLAN/VLAN mappings are used 96 Chapter 5. Study Notes Grumpy Networkers Journal Documentation, Release 0.0.7 Lightweight APs • Cooperates with centralised Wireless LAN Controller (WLC) • VLWN-WLAN trafffic encapulsated via a speciai tunnel to the WLC • Tunnel uses “Control And Provisioning of Wireless Access Points” (CAPWAP) protocol • Only needs access port configuration in order to communicate with WLC where loccal breakout is not used VLAN Configuration Commands Create a VLAN vlan Assign a port to a single vlan (access port) interface List VLANs known to the switch and their assigned ports show vlan [ Configure a VLAN trunk interface ˓→list>}} switchport mode { trunk| dynamic {desirable| auto}} Disable/Enable DTP interface Verify Switch Port configuration and operational state show interface Verify Trunking Information for a port show interface Configure Voice VLAN NOTE: Ensure VLAN has been created first 5.3. Cisco CCNP - Implementing Cisco IP Switched Networks (300-115 SWITCH) 97 Grumpy Networkers Journal Documentation, Release 0.0.7 interface Verify Voice VLAN is carried over the conditioanl trunk show interface Cisco - VLAN Trunking Protocol (VTP) VLAN Trunking Protocol (VTP) Overview • Cisco Proprietary • Manages VLANs across the campus network • Uses Layer 2 trunk frames • Switches running as servers store the VLAN info in a “vlan.dat” file on the local switches flash memory. • VLAN information maintained after poweroff • By default switches will not have any domain name set, known as the “Null” domain • Any switch that hears a summary advertisement sent non-securely will configure itself with the contained infor- mation. VTP Versions • Valid versions are 1,2 and 3 • Versions are not fully interoperable, recommended to use same on all switches • Version is the default version • Switches will attempt to change to version 2 from version 1 if they see a V2 advertisement. Known as “VTPv2 Capable” • Switches running VTPv3 will send scaled down advertisemenets if it hears a VTPv1 switch. Extended VLANs not included VTPv2 Features • Version dependant transparant mode • Consistency checks • Token ring support • Unrecognised TLV support VTPv3 Features • Extended VLAN range • Enhanced Authentication 98 Chapter 5. Study Notes Grumpy Networkers Journal Documentation, Release 0.0.7 • Database Propagation • Primary and Secondary Servers • Per-Port VTP VTP Domains • An Area with common VLAN requirements • Switches only belong to one VLAN domain at a time • Advertisement contents – Domain Name – Revision Number – Known VLANs – Specific VLAN Parameters • Advertisements are used to notify other switches of VLAN changes VTP Modes • Server – Full control over VLAN info – All VTP information advertised to other switches – Default mode for Cisco switches • Client – Cannot make changes to VLANs – Lisens for VTP advertisements – Relays advertisements out of all trunk links • Transparent – Does not participate in VTP – Version 1 will not relay advertisements – Version 2/3 will relay advertisements – Local VLANs not propagated • Off – Switch does not participate in VTP – Will not relay advertisements 5.3. Cisco CCNP - Implementing Cisco IP Switched Networks (300-115 SWITCH) 99 Grumpy Networkers Journal Documentation, Release 0.0.7 VTP Advertisements • Can be either Summary, Subset or Request advertisements • VTP versions are not fully backward compatible • By default version 1 advertisements are used • Advertisements sent as multicast frames • Advertisements relayed by all switches except those not running VTP (“Off” mode) • Advertisements sent non-secure by default, a password can be configured • Revision number used to track most recent information, starting at 0 (zero) • Advertisemenets “usually” originate from a switch running in “server” mode • “Client” switches will also originate advertisements on first boot Advertisement Types • Summary – Servers send advertisemenet ever 300 seconds and on a VLAN change – Contains info about the VTP domain and revision number – For each VLAN change, a subset advertisemenet will follow • Subset – Sent after each VLAN change, list specific changes made to the VLAN database • Request – Sent from clients who are missing VLAN information VTP Synchronisation • Switches will overwrite local VLAN ddata if a VTP advertisement contains a newer revision number • Ensure new switchhes have a lower revision number by resetting to 0 by the following methods – Change VTP mode on the switch to transparent then back again – Change VTP domain to “non-existant” one and back to the original one • An old switch replacing “live” information on a production network is referrred to as a “VTP Synchronisation Problem” • When first booted even “Client” switches can replace live VLAN information as they send out summary adver- tisements. This can cause even “server” switches to replace their information • As “end-to-end” VLANs are now considered a legacy design model, Cisco recommends all switches be set to either “off” or “transparent” 100 Chapter 5. Study Notes Grumpy Networkers Journal Documentation, Release 0.0.7 VTP Pruning • Assists with limiting size of broadcast domain when a VLAN is not used • Avoids having to manually remove VLANs from a trunk • Extension to VTP version 1 using additional VTP message type • Switches will still run a spanning-tree instance even if the VLAN is pruned • Disabled by default • Enabling on the server also enables on all switches in the domain • By default VLANs 2-1001 are eligible for pruning, list can be modified • VLAN 1 and 1002-1005 can never be pruned • No affect on transparent mode switches VTP Configuration Set VTP Version vtp version {1|2|3} Set VTP Management Domain Up to 32 characteers, no spaces vtp domain Set VTP mode vtp mode { server| client| transparent| off } Set VTP Password Password is never sent, only a hash is calculated Hidden password is not shown inn the configuration, only a hash vtp password Verify VTP Status show vtp Status Define this switch as the VTP Primary Server (Version 3 only) vtp primary [force] Enable VTP Pruning vtp pruning Define VLANS eligible for pruning interface 5.3. Cisco CCNP - Implementing Cisco IP Switched Networks (300-115 SWITCH) 101 Grumpy Networkers Journal Documentation, Release 0.0.7 VTP Troubleshooting show vtp status show vlan brief show interface Alternatives to VTP GARP VLAN Registration (GVRP) • Standards based VLAN management protocol for IEEE 802.1Q trunks • Defined in IEEE 802.1D and 802.1Q (Class 11) • Not supported by Cisco Catalyst Switches Cisco - Traditional Spanning Tree Protocol (STP) IEEE 802.1D Overview • STP is defined IEEE 802.1D • Provides link redundancy and Automatic Failover Recovery Transparent Bridge Operation • Listen for frames coming into its ports • Builds table of MAC addresses based on the information stored in the frames (Source MAC address) • Updates table on any MAC address moves • Broadcasts flooded out all except source port • Frames are not modified by the bridge Bridging Loops • Occur when a single frame continuously goes around and round between two or more switches. • There is no Layer 2 equivilent of TTL unlike at Layer 3 so the frame cannot be stopped • Bridging loops without spanning-tree can only be stopped by unplugging cables Preventing Loops with Spanning-Tree-Protocol • Bridging loops occur due to parrallel switches not being aware that other switches exist • STP developed so that switches are aware of each other and to enable use of redudent switches or switch paths • STP is used to negotiate a loop free path • Any loops are discovered before being made available for use 102 Chapter 5. Study Notes Grumpy Networkers Journal Documentation, Release 0.0.7 • Each switch executes the STP algorithms independent of other switches • Redudant paths are put into a “Blocking” or standby state to prevent them forwarding frames Bridge Protocol Data Units (BPDUS) • A form of data message used for inter switch communication • Sent out of all switch ports configured for trunking • A unique MAC address is used on each port if supported by the switch platform • Destination is defined as the multicast address 0180.c200.0000 • A BPDU can be either the type “Configuration” or “Topology Change Notification” (TCN) • The “Configuration” BPDU is used to notify other switches of a change to STP Configuration • A TCN BPDU is used to announce a change on the network, such as a port coming up or down • The exchange of BPDUS is used to elect a reference point for the network and build a stable topology • BPDUs are sent out of all trunk ports every 2 seconds by default Spanning Tree Election Process Root Bridge Election • Root bridge is a common reference point for all switches • Bridge ID is assigned to each switch composed of “Bridge Priority” (2 Bytes) and MAC address (6 bytes) • On first power up switch sends BPDUs • Once Root bridge is elected only it will sent configuration BPDUs • The best root bridge is decided by lowest priority an lowest MAC address if a tie • Default priority for Cisco switches is 32768. can be set in incremeent of 4096 Root Port Election • Decides the “best” path to reach the root bridge • A path cost is calulated based on cost of all links leading to root bridge • Only root path cost is carried in the BPDU, path cost is known only to local switch • Switches modify root path cost as BPDU is propagated across the network • Initial root path cost in root bridge BPDU is 0 (zero) • Next switch adds path cost based on interface speed as BPDU is received • Switch updaed BPDU with root path cost before relaying it on Cisco Path Cost Values 5.3. Cisco CCNP - Implementing Cisco IP Switched Networks (300-115 SWITCH) 103 Grumpy Networkers Journal Documentation, Release 0.0.7 Interface Speed New Value Legacy Value 4Mbps 250 250 10Mbps 100 100 16Mbps 62 63 45Mbps 39 22 100Mbps 19 10 155Mbps 14 6 622Mbps 6 2 1Gbps 4 1 10Gbps 2 0 Choosing Best Designated ports • A designated port is the path is used by the local segment to reach to the root bridge • Only a single designated port exists per segment in order to avoid bridging loops • The port with the lowest cumulative root path cost is choosen Resolving a tie situation • Lowest Root bridge ID • Lowest Root path cost to root bridge • Lowest sender bridge ID • Lowest sender port id Spanning Tree Port States • Disabled – Not part of the normal STP Port progression process – Used for ports that are “Administatively Shutdown” • Blocking – Port initialised – Receive only BPDUs • Listening – Receive BPDUs – Send BPDUs • Learning – Changes to this state after the Forward Delay timer has expired – Send/Receive BPDUs – Learn MAC addresses • Forwarding 104 Chapter 5. Study Notes Grumpy Networkers Journal Documentation, Release 0.0.7 – Full operation – Send/Receive BPDUs – Learn MAC addresses – Send/Receive data frames Manually calculating STP topology • Identify Path Cost on links • Identify Root Bridge • Select Root Ports (1 per switch) • Select Designated Ports (1 per segment) • Identify Blocking Ports STP Timers • Hello Timer – Defaults to 2 seconds – Frequency at which configuration BPDUs are sent by the root bridge – Locally configured Hello time is used to time TCN BPDUs • Forward Delay Timer – Defaults to 15 seconds – Delay between a port moving from listening to learning state • Max Age Timer – Defaults to 20 seconds – Time a BPDU is stored before being discarded – If no more BPDUs received, switch assumes topology change mus have occurred Topology Changes • Annouced through TCN BPDUs • Changes occur when – Ports move into the forwarding state – Port moves from forwarding/learning to Blocking state • TCN BPDUs not sent if change was detected on a “PortFast” configured port • TCN BPDUS sent ever hello time interval until acknowledgment received • Upon received TCN BPDU, root bridg will – Send acknowledgement – Sets topology change flag in the config BPDU 5.3. Cisco CCNP - Implementing Cisco IP Switched Networks (300-115 SWITCH) 105 Grumpy Networkers Journal Documentation, Release 0.0.7 – Relay BPDU to all other switches • Switches receiving BPDU with change flag set will redice their bridge table aging (default: 300 seconds) to the forward delay value (15 seconds) in order to cause MAC addresses to be flushed more quickly from the briding table. • Topology changes can be either direct or indirect Direct Topology Changes • Changes detected on a switch interface • Root bridge sends config BPDU with change flag set • Other switches receive BPDU and shorten aging time • Switches update root port accordingly • Connectivity will will be 2 x forward delay timer (30 seconds) Indirect Topology Changes • Failure which does no cause link status to change • No TCN BPDU sent • Stored BPDU is flushed after Max Age time expires (Default: 20 seconds) • Switch waits to receive BPDU from root bridge • Port progresses through blocking, listening, learning to forwarding • Upto 1 minute of connectivity loss could occur (2+15+15+20) Insignificant Topology Changes • Ports connected to end user devices by default will still cause TCN BPDUs to be generated • Cause unnecessary flushing of CAM tables • Results in more unknown unicast traffic • “PortFast” is configured on ports connected to end user devices causing TCN BPDUs not to be sent • “PortFast” causes ports to brought up directly into the “Forwarding” state Types of STP • STP originally designed to support only a single VLAN • IEEE and Cisco approached STP differently 106 Chapter 5. Study Notes Grumpy Networkers Journal Documentation, Release 0.0.7 Common Spanning Tree (CST) • IEEE 802.1Q standard • Single instance for all VLANs • CST BPDUS send over trunks using native VLAN untagged frames • Does not allow use of redudant links Per-VLAN Spanning Tree (PVST) • Cisco Proprietary • Seperate STP instance for each VLAN • Load balancing possible using redudant links, over different VLANs • Requires use of ISL trunk encapsulation • Interoperability issues with CST Per-VLAN Spanning Tree (PVST+) • Cisco Proprietary • Improves interoperability with PVST and CST • Operates over both 802.1Q and ISL Redudant Link Convergence Cisco provides additional means in order to reduce the time taken to establish a stable topology following a failure: • PortFast (Access Ports) • UplinkFast (Access Layer Uplinks) • BackboneFast (Redudant Backbond links PortFast • Reduces listening and learning timers • Port moves immediately to forwarding state • Loop detection still in operation • Disabled by default • Can be enable globally for non-trunking links or manually per port • TCN BPDUs not sent when link goes down • Port looses PortFast status if BPDU is seen on the port 5.3. Cisco CCNP - Implementing Cisco IP Switched Networks (300-115 SWITCH) 107 Grumpy Networkers Journal Documentation, Release 0.0.7 UplinkFast • Disabled by default • Can be enabled globally, not per port • Not supported on the root bridge • Maintains one or more redudant root ports • Upon failure of a link anoher upliink is brought into operation immediately • If enabled, bridge priority changed to 491522 and port cost increased to 3000 • When failure detected, dummy multicast frames are sent for all stations in the CAM table so that other switches learn the new path as quickly as possible. BackboneFast • Uses interactive process to detect alternative paths • Root Link Query (RLQ) protocol is used to interact with directly connected switches • When reply is received on non-root port, Max age timer immediately expires • Reduces convergence delay from 50 to 30 seconds Cisco - Spanning Tree Configuration Spanning-Tree Global Configuration Disable/Enable Spanning Tree Protocol On a VLAN Note: Can be used either globally or on a per-port basis [no] spanning-tree vlan Configure Bridge ID Format • Traditional 802.1D (STP) Uses a unique MAC address • 802.1t uses a non-unique MAC address with bridge ID plus VLAN ID • 802.1t is the default where a switch cannot suport 1024 uniquq MAC adresses • Disabling “extended system ID” reverts to 802.1D bridge id format (if supported) [no] spanning-tree extend system-id Manually set Bridge ID Priority *Note: Must be uset in increments of 4096 spanning-tree vlan Automatically set primary/secondary root bridge with macro Note: command will not show in the config directly spanning-tree vlan 108 Chapter 5. Study Notes Grumpy Networkers Journal Documentation, Release 0.0.7 Tuning Port ID/Priority Note: Port number is fixed, only priority can be changed interface Tune global STP timers spanning-tree [vlan Verifying Spanning Tree Operation Display STP Bridge Priorities show spanning-tree [vlan Verify port cost show spanning-tree interface Monitoring STP show spanning-tree [detail| summary] show spanning-tree [vlan PortFast Disable/Enable Portfast global for all non-trunk ports [no] spanning-tree portfast default Disable/Enable PortFast on specific interfaces interface Automatically apply optimal configuration for an end user port Note: Enables PortFast, sets to be an access port, disables PAgP interface Verify PortFast status show spanning-tree interface 5.3. Cisco CCNP - Implementing Cisco IP Switched Networks (300-115 SWITCH) 109 Grumpy Networkers Journal Documentation, Release 0.0.7 UplinkFast Enable UplinkFast globally spanning-tree uplinkfast [max-update-rate Verify UplinkFast Status show spanning-tree uplinkfast BackboneFast Enable BackboneFast Globally spanning-tree backbonefast Verify BackboneFast Status show spanning-tree backbonefast Cisco - Advanced Spanning Tree Protocol Rapid Spanning Tree Protocol (RSTP) • Traditional STP is considered too slow for modern networks • RSTP is defined in IEEE 802.1w • When combined with PVST+ it is called RPVST+ • Used as part of MST (IEEE 802.1s) • Allows switches to interact through each port to gain quicker convergence times • Uses same election process as traditional STP (IEEE 802.1d) • Different Names are used for the port roles than in STP – Root Port - Has the best root path cost, won’t exist on the root bridge – Designated Port - One per segment, best port to reach root on each segment – Alternate Port - The next-best path to the root bridge – Backup Port - Redudant connection on each segment • Different port states are also used than in STP – Discarding - Combines the STP disabled, Blocking and Listening states – Learning - Frames dropped, MAC adresses learned – Forwarding - Full Operation 110 Chapter 5. Study Notes Grumpy Networkers Journal Documentation, Release 0.0.7 BPDUs in RSTP • Uses 802.1D BPDU format • Sending switches identify by role and state • BPDU version is set to 2 • Neighbouring switches negotiate using BPDU flags • Sent every hello interface out all switch ports • 3 lost BPDUs (6 seconds) mark the neighbour as down causing information to be aged out • Can operate with traditional STP based on received BPDU version • BPDU version is help until “Migration Delay Timer” expires RSTP Convergence • Two stages – Common Root bridge is elected – Switch port states assigned to build loop free topology • Upon first joining network, RSTP bases it’s forwarding decision on port type • RSTP Port Types – Edge Port - Single host, portfast configure port – Root Port - Best Cost to Root bridge – Point-To-Point port - Any switch connecting to another switch and becomes designated port • Ports running half-duplex cannot be point-to-point, traditional STP (802.1d) convergence used on these ports • Complete convergence is done via propagation of handshakes over point-to-point links • After each successful decision, the handshake moves to the next switch towards the edge of the network • During handshaking, loops are avoided via a synchronisation process RSTP Synchronisation • Non-edge ports begin in discarding state • After root bridge identifed thhrough BPDU exhcnage, port receiving support BPDU becomes root port • Each switch assumes its port should be designated for the segment. Proposal sent to neighbouring switch • If proposal is superior, synchronisation occurs – All non-edge ports put into discarding state – Aggrement message sent in reply – Root port moved to the forwarding state – On each non-edge port currently discarding, a proposal is sent to the next neighbour switch – Aggrement message received – Non-Edge port moved to forwarding state 5.3. Cisco CCNP - Implementing Cisco IP Switched Networks (300-115 SWITCH) 111 Grumpy Networkers Journal Documentation, Release 0.0.7 • No timers are used • If no agreement is received, falls back to 802.1d rules Topology Changes and RSTP • Detected only when non-edge port transitions to forwarding state • Used only so briding tables are updates • Topology Change (TC) messages propagate through the the network • MAC Addresses flushed from the CAM table Rapid Spanning Tree Configuration Set a port as an RSTP edge port interface Force a port to act as a point-to-point port interface Enable use of RPVST+ spanning-tree mode rapid-pvst Revert To PVST+ spanning-tree mode pvst Verify STP mode used by Switch and neighbours show spanning-tree [vlan Multiple Spanning Tree (MST) Protocol Overview • Allow for better management oof switch resources whilst still permitting load balancing over redudant links • One or more VLANs are mapped to a single STP instance • Multiple instances of STP Implementing MST • Determine numbber of STP instances • Map a set of VLANs to each instance 112 Chapter 5. Study Notes Grumpy Networkers Journal Documentation, Release 0.0.7 MST Regions • Defined by a set of attributes – Configuration name (32 characters) – Revision number (0 - 65535) – Instance to VLAN Mapping (0 - 4096 entries) • Two switches with same attributes are in the same MST region • MST BPDUs contain the attributes • Region boundaries are defined where attributes differ or 802.1d (STP) is used • Mapping of VLANs must be configured on each switch as they are not sent in the BPDU Spanning-Tree Instances within MST • MST interoperates with all forms of STP • MST treats the entire network as a single Common Spanning Tree (CST) topology • CST regards each MST instance as a “Black Box” with no idea what happens inside • CST maintains a loop free topology with links connecting outside the region Internal Spanning Tree (IST) Regions • An IST instance uns to calculate a loop free topology within an MST region • IST presents the entire region as a single bridge to the CST outside • BPDUs exchanged at BPDU boundaries only over native VLAN trunks MST Instances (MSTI) • Maximum of 15 MSTIs (0-15) • MSTI 0 (zero) is reserved for the IST • Instances define the VLAN mapping for each topology • Only the IST (MSTI 0) is permitted to send BPDUs • M-Records are added to MST BPDU’s for each MSTI • A single BPDU is needed regardless of number of instances • If a BPDU is detected on more than one VLAN, MST assumes PVST+ is used so the BPDU is replicated to all VLANs on the trunk link. MST Configuration Enable MST on a Switch spanning-tree mode mst 5.3. Cisco CCNP - Implementing Cisco IP Switched Networks (300-115 SWITCH) 113 Grumpy Networkers Journal Documentation, Release 0.0.7 Enter MST configuration mode and define attributes spanning-tree mst configuration name Show pending MST configuration changes show pending Commit outstanding changes from MST configuration mode exit Set The MST root bridge via a macro spanning-tree mst Manually set MST Bridge Priority spannning-tree mst Set MST port cost interface Set MST timers spanning-tree mst hello-time Cisco - Aggregating Switch Links Switch Port Aggregation with Ether Channels • Under normal circumstances STP will only allow a single link to forward traffic • Etherchannels bundle multiple parallel links to at a single link • Between 2 - 8 Fast, Gigabit or 10Gb ethernet interfaces can be bundled to give full-duplex bandwidths of: – FEC - Up to 1600Mbps – GEC - Up to 16Gbps – 10GEC - Upto 160Gbps • The bundled link acts as a single access or trunk link • When created on Cisco devices the interface type is known as a “Port-Channel” • Traffic is distributed based on the defined load balancing algorithm • Traffic will be distributed across the links but not necessarily equally • Muliple links increase redudancy with the STP port cost adjusted according 114 Chapter 5. Study Notes Grumpy Networkers Journal Documentation, Release 0.0.7 • STP reconvergence is only needed as a last resort as long as it least one link in the EtherChannel is available • If the platform supports switch stacking, the EtherChannel can be distributed across multiple stack members • Higher end switches that support Virtual Switching System (VSS) can form the EtherChannel across the switch chassis’s into a Multi-Chassis EtherChannel (MEC) • All interfaces that are combined into a single EtherChannel must have identical settings • Etherchannel can be used on both Switched (Layer 2) and Routed (Layer 3) ports Distributing Traffic In An EtherChannel • Traffic is distributed over all the links in the bundle in a deterministic way • Traffic is not ballanced equally depending on the trafffic flow • Hashing Algorithm used takes into account – Source/Destination IP addresses – Source/Destination MAC Addresses – Source/Destination TCP/UDP Port Numbers • Output of the algorithm determines the link to be used • An XOR operation on one or more lower order bits is used depending on the number of links in the bundle – 2 Links - 1-bit XOR operation – 4 Links - 2-bit XOR operation – 8 Links - 3-bit XOR operation • Host-To-Host communication always goes over sam3 link as long as addresses remain constant • Load balancing is globally defined, not per port • All models can load balance using MAC and IP addresses • Higher End switches (4500, 6500) can also use TCP/UDP port numbers • When using a router-to-router (layer 3) connection, consider using IP instead of MAC addresses for better distribution • If non-IP traffic is seen, load balancing based on MAC addresses is used automatically EtherChannel Negotiation Protocols • EtherChannels can be negotiated for use when needed • Two protocols are available – Port Aggregation Protocol (PAgP) - Cisco Proprietary – Link Aggregation Control Protocol (LCAP) - Standards Based • When negotiation is used, an additinal 15 second delay may occur • Configure the negotion mode to “on” to not use negotiation 5.3. Cisco CCNP - Implementing Cisco IP Switched Networks (300-115 SWITCH) 115 Grumpy Networkers Journal Documentation, Release 0.0.7 Port Aggregation Protocol (PAgP) • Cisco Proprietary protocol • EtherChannel can only be formed when identical parameters configued • Member port config is modified if EtherChannel is changed • Port modes – Desirable - Actively try to establsh an EtherChannel – Auto - Form an EtherChannel but only if requested to do so Link Aggregation Control Protocol (LACP) • Standards Based on IEEE 802.3ad • Up to 16 links can be configured in the EtherChannel but only 8 active at any one time • Switch which has the lowest system priority (2-bytes) chooses which ports are active in the EtherChannel • Links selected are based on port priority • Unused ports put in standby state • Port modes – Active - Try to establish EtherChannel with neighbour switch – Passive - Wait for neighbour switch to request negotiation of EtherChannel Avoiding Misconfiguration with EtherChannel Guard • Enabled by default • Issues unlikely to occur when PAgp/LACP are used • Likely to be an if configured to EtherChannel unconditionally • Ports are port inn errdisable state if misconiguration (i.e. cabling) issue detected Troubleshooting An EtherChannel • Ensure both switches are configured for unconditional etherchannel or one should actively to negotiate • Ensure configuration is consistent across all ports to be bundled on both switches • Check cabling is correct EtherChannel Configuration Global Configuration Set the Load Balancing Method port-channel load-balance 116 Chapter 5. Study Notes Grumpy Networkers Journal Documentation, Release 0.0.7 Verify Load Balancing Method show etherchannel load-balance Disable/Enable EtherChannel Guard [no] spanning-tree etherchannel guard misconfig Check if ports are disabled due to EtherChannel Guard show interface status err-disabled PAgP EtherChannel Configuration interface LACP EtherChannel Configuration lacp system-priority Troubleshooting EtherChannels Enable interface following misconfiguration interface port-channel Status/Validation Commands show etherchannel summary show etherchannel {port| port-channel| detail} show running-config interface Cisco - Multilayer Switching Inter-Vlan Routing • VLANs are isolated broadcast domains • Layer 3 device is required to pass traffic between them 5.3. Cisco CCNP - Implementing Cisco IP Switched Networks (300-115 SWITCH) 117 Grumpy Networkers Journal Documentation, Release 0.0.7 • Traditional Inter-VLAN routing techniques – Inter-VLAN Router * Seperate interface per VLAN * Not scaleable beyond a few VLANs – Router with trunk interface * Single Interface used for all VLANs * “Router On A Stick” or ” One-Armed Router” * Interface becomes the bottleneck Routing And Switching functions using a multilayer switch (MLS) • SDM templates may need changing depending on IPv4/IPv6 requirements • Layer 3 interfaces can also be configured in an EtherChannel Interface Types • Layer 2 - Switching occurs between interfaces that are assigned as layer 2 on VLANs and trunk • Layer 3 - Layer 3 switching occurs between any interface which support an assigned layer 3 address • SVI - Switched Virtual Interface, A Layer 3 address assign to represent the entire VLAN Steps To Configure Inter-VLAN routing • Enable IP routing on the switch • Configure Static and/or Dynamic routing • Configure Layer 2 ports • Configure Layer 3 ports • Configure SVIs Configuring an SVI interface • Create VLAN • Configure SVI (VLAN) Interface with assigned IP address SVI Autostate • By default SVI interface will not show as active until one or more ports in the correct VLAN are also active • Can be overridden in special circumstances (E.g. port mirroring) 118 Chapter 5. Study Notes Grumpy Networkers Journal Documentation, Release 0.0.7 Multilayer switching with CEF • Cisco Expres Forwarding (CEF) is the current generation of Cisco multilayer switches • Used to forward packets based on Layer 3 and 4 information • Topology-Based MLS Traditional MLS • Dual effort between route processor (RP) and switching engine (SE) • “Route Once and Switch Many” • “Shortcut Pathh” avoided subsequent packets needing to goto the RP • Known as “NetFlow Switchin” or “Route Cache Switching” • Used on Legacy Hardware – Catalyst 6000 supervisor 1/1a – Multilayer Switch Feature Card (MSFC) – Catalyst 5500 with Route Switch Module (RSM) – Catalyst 5500 with Route Switch Feature Card (RSFC) CEF Overview • High Performance Packet Forwarding • Runs By default on modern Cisco switches • Takes advantage of special Hardware • Functional Blocks – Layer 3 Engine (Routing Table, ARP Table) – Layer 3 Forwarding Engine (FIB, Adjacency Table) • Layer 3 Engine build routing information that Layer 3 Forwarding engine can use to switch packets • Some packets cannot be CEF switched and are sent to L3 Engine, known as “CEF punt” – Entry not located in the FIB – FIB table is full – IP TTL expired – MTU Exceeded and Fragmentation needed – ICMP Redirect – Unsupported Encapsulation Type – Packets need to be tunnelled, compressed or encrypted – Access List logging – NAT Operation required 5.3. Cisco CCNP - Implementing Cisco IP Switched Networks (300-115 SWITCH) 119 Grumpy Networkers Journal Documentation, Release 0.0.7 Forwarding Information Base (FIB) • A reordered copy of the routing table so that most specific route is listed first • Contains next-hop for each entry • Host routes (/32) are included for directly connected (adjacent) hosts • Layer 3 engine sends updata to FIB when topology changes • FIB also updated when next-hop or MAC address changes or is aged out • Version number and nuber of changes (Epoch) are tracked CEF Optimization • Accelerated CEF (aCEF) – Multiple Layer 3 Forwarding Engine – Individual line cards on chassis switches – Only used a portion of the FIB known as a “FIB Cache” – CEF accelerated on the line card but not at sustained wire speed • Distributed CEF (dCEF) – FIB Completely distributed among multiple Layer 3 Forwarding engines – Catalyst 6500 line cards support dCEF, each has own FIB an Forwarding Engine – Central Layer 3 Engine maintains routing table and downloads FIB to each line card Adjacency Table • Routers usually maintain Routing Table (Layer 3) and ARP table (Layer 2) seperately • FIB maintains the Layer 3 next hhop for each entry • FIB also has Layer 2 information for next hop, the area of the FIB is known as the “Adjacency Table” • Adjacencies kept for each next hop router and each directly connected host • Entries contain both IP address and MAC address • Built from the ARP table • Updates as new ARP replies are received • Unknown entries (CEF Glean) must be sent to Layer 3 Engine with packets being dropped until the entry is known to avoid exhausting the input queue • Adjacency Types can be one of Null, Drop, Discard or Punt • Null Adjency – Packets to be sent to null interface – Absorbs packet without forwarding • Drop Adjacency – Switches packets that cannot be forwarded 120 Chapter 5. Study Notes Grumpy Networkers Journal Documentation, Release 0.0.7 – Silently dropped – Used for encapsulation failures, unsupported protocols, no valid route, no adjancy, etc • Discard Adjacency – Packets to be dropped due to access list or other policy action • Punt Adjacency – When packets must be sent to the Layer 3 Engine – Incomplete adjacencies (NO_ADJ) – Incomplete ARP resolution (NO_ENCAP) – Unsupported Packet Features (UNSUPP’TED) – ICMP Redirects (REDIRECT) – Packets destined for switch interfaces (RECEIVED) – IP Options (OPTIONS) – Access list evaluation failure (ACCCESS) – Fragmentation Failures (FRAG) Packet Rewrite • Last step prior to forwarding requires packets to be rewritten • Layer 2 destination address changes to next hop MAC address • Layer 2 source address changes to outbound L3 swiitch interface mac • Layer 3 IP TTL decremented by 1 • Layer 3 IP Checksum updated • Layer 2 Frame checksum updated • CEF uses dedicated hardware for efficient rewrite and table lookups Multilayer Switch Configuration Global Configuration Create a VLAN NOTE: Should be done before creating an SVI/VLAN interface vlan Disable/Enable CEF NOTE: CEF cannot be disabled on all platforms [no] ip route-cache cef [no] ip cef 5.3. Cisco CCNP - Implementing Cisco IP Switched Networks (300-115 SWITCH) 121 Grumpy Networkers Journal Documentation, Release 0.0.7 Interface Configuration Configure interface to operate at Layer 2 interface Configure interface to operate at Layer 3 interface Create an interface to route in/out of the VLAN (SVI) interface Vlan Exclude interface from affecting SVI autostate interface Verification Commands Verify Switch Port Mode show interface Display FIB Table for Specific Interface show ip cef [ Display FIB Table by IP Prefix show ip cef [ Display Adjacency Table show adjacency [ **Display CEF entries without valid ARP (CEF Glean) show ip cef adjacency glean Display Statistics for CEF Drop reasons show cef drop Display Statistics for packets not processed by CEF show cef not-cef-switched List configured VLANs 122 Chapter 5. Study Notes Grumpy Networkers Journal Documentation, Release 0.0.7 show vlan Display IP Information about switch interfaces show ip interface Display Summary of Layer 3 Interfaces show ip interface brief Display Entire FIB show ip cef Cisco - Configuring DHCP Using DHCP With A Multilayer Switch • Dynamic Host Configuration Protocol (DHCP) is defined in RFC 2131 • Provides features to configure hosts with specific settings • Client/Server model • Hosts run a DHCP client • The server will issue a leased IP address to the client that is only valid for a specified time • Client must renew the IP address before it expires in order to continue using it • DHCP only works within a single broadcast domain • Using a DHCP Relay, the request can be forwarded to a DHCP server on a different subnet DHCP Negotiation Process • DHCP Discover message sent from client as a Broadcast • DHCP Offer messsage sent from server as a Broadcast with lease information – IP Address – Subnet Mask – Default Gateway – Other options if configured – Server IP to identify where offer came from • DHCP Request from client sent as a broadcast • DHCP Ack (Acknowledgement) from server, defaults to unicast but can also be broadcast 5.3. Cisco CCNP - Implementing Cisco IP Switched Networks (300-115 SWITCH) 123 Grumpy Networkers Journal Documentation, Release 0.0.7 DHCP Configuration Steps • Configure Layer 3 address on an SVI • Configure IP addresses to exclude – The switches own IP address and broadcast are automatically excluded • Configure DHCP Pool – Must correlate with a configure IP Interface – Default lease time is 1 day Configuring a manual DHCP binding • Requires one pool per binding • The client can request an IP using either it’s MAC address or “Client Identifier” • Client Identifier Format – EtherType followed by MAC Address – Client ID uses “01” for the Ethernet EtherType DHCP Options • Allow additional configuration items to be supplied to client • Each option is identified by a number, followed by a value • Common DHCP Options – 43 - Location of WLC (Value is an IP address) – 69 - Location of SMTP Server (Value is an IP address) – 70 - Location of POP3 Mail Server (Value is an IP address) – 150 - Location of TFTP server for Cisco IP Phones (Value is an IP address) • Many options are industry standards but vendors can implement custom options for their needs • Common options (such as default gateway) have predefined configuration commands so it’s not necessary to define the options manually Configuring A DHCP Relay • Facilitates locating a DHCP server in a central location where it can be used or multiple subnets/VLANs • Relay will forward any DHCP broadcasts to the configured servers as a unicast message • Configured on each Layer 3 interface which faces the client devices • Most then one DHCP server can be configured for redudancy 124 Chapter 5. Study Notes Grumpy Networkers Journal Documentation, Release 0.0.7 Configuring DHCP To Support IPv6 IPv6 Refresher • IPv6 can auto-configure the host by discovering a local IPv6 router • Host learns network prefix to generate a link-local address • Link local addresses start with FE80::/10 • Link local addresses is made up of prefix and host MAC address • Duplicate address detection (DAD) is used to ensure no conflict Stateless Auto-Configuration • Clients generate it’s own IP address • 64-bit Layer 3 subnet prefix • EUI-64 ID (64-bits) – Upper half of interface MAC (24 bits) – Static Value FFFE (16 bits) – Lower half of interface MAC (24 bits) • Client can learn default router and MTU from the router • Router advertises it’s prescense periodicall or client can request on demand DHCPv6 • Routers specify if DHCPv6 is offered in their advertisements • Clients can also request the service • Excluding addresses is not permitting in DHCPv6 • Manual address bindings are not supported • DHCPv6 Lite – Combines stateless auto-configuration wwith options provided by DHCPv6 – Prefix not specified in pool to prevent clients obtaining an IP address • DHCPv6 Relay Agent – Permits the DHCPv6 server to be located on a different subnet to the clients DHCP Server Configuration Exclude addresses from allocation ip dhcp excluded-address Configure DHCP Pool 5.3. Cisco CCNP - Implementing Cisco IP Switched Networks (300-115 SWITCH) 125 Grumpy Networkers Journal Documentation, Release 0.0.7 ip dhcp pool Clear currently active leases clear ip dhcp binding {* | Configure Manual Binding ip dhcp pool Configure DHCP Relay Note: Applied to either a Layer 3 or VLAN interface interface DHCPv6 Configuration Configure IPv6 Interface interface Configure DHCPv6 Pool *Note: To configure DHCPv6 Lite Pool, do not specify “address prefix” ipv6 dhcp pool Associate DHCPv6 Pool With Interface interface Configure DHCPv6 Lite On an Interface interface Specify DHCPv6 Relay interface Clear Active DHCPv6 Bindings 126 Chapter 5. Study Notes Grumpy Networkers Journal Documentation, Release 0.0.7 clear ipv6 dhcp bindings {* | Verification and Troubleshooting Display Current DHCP server Address Assigments show ip dhcp bindings Debug DHCP transactions from the switch debug ip dhcp server Display DHCPv6 Address Bindings show ipv6 dhcp pool Cisco - Monitoring Campus Networks - Logging Logging Overview • Used to monitor events taking place on the switch • Having accurate time is important to correlate events across the entire network • Detect failures and assist with troubleshooting Syslog Messages • Audit trail describing important events that have occured • Identify what, when and how an event occured • Message Format – Timestamp – Facility Code – Severity (0-7, 0 being most severe) – Mnumonic – Message Text • Severity Levels (Highest to Lowest Severity) – Emergencies (0) – Alerts (1) – Critical (2) – Errors (3) – Warnings (4) – Notification (5) – Informational (6) 5.3. Cisco CCNP - Implementing Cisco IP Switched Networks (300-115 SWITCH) 127 Grumpy Networkers Journal Documentation, Release 0.0.7 – Debugging (7) Logging Destinations • Console – Defaults to the debugging (7) severity level – Only by default logs to serial console • Internal Buffer – Stored in internal memory – Lost if switch crashes/powered off/reloaded – Disabled by default – Default buffer size of 4096 bytes • Remote Syslog Server – Uses UDP over port 51 by default – Severity and server IPs must be defined Adding Timestamps to Syslog Messages • Important for viewing non-real time historical events • Default timestamp is the “Uptime” of the switch • The Uptime will become more coarse over time (E.g. 3w2d) • Clock Sync options – Manually – NTP / Authenticated NTP – SNTP • Timezone can be defined as can offset from UTC • Daylight Saving Time (DST) must be configued Manually Using NTP to Synchronising with External Time Source • Ensures consisten time across multiple devices • Accounts for delay during NTP synchronisation • A hierarchy of servers can be defined by specifying the “Stratum” value • Higher Stratums are considered more accurate • Multiple tiers of NTP servers allow for greater scaleability • The server configured with the lowest stratum value is preferred over others 128 Chapter 5. Study Notes Grumpy Networkers Journal Documentation, Release 0.0.7 NTP Modes • Server – Synchronise with a lowest stratum source – Provides time sync to other servers/devices • Client – Syncs its clock with an NTP server • Peer – Exchanges time with another peer device • Broadcast/Multicast – Operates as an NTP server – Pushes time information to listening devices – Not as accurate as other modes Securing NTP • Methods – NTP Authentication – Restrict access by IP and Activity • NTP Authentication – Does not encrypt data – Ensures client is talkin to a “trusted” server – Does not restrict access even when “key” is configured • Restrict access by IP and Activity – Configuring an authentication key only validates the server – Access List can be used to define what action the listed IP/subnets can carry out – Valid Activities * Serve-only - Only Sync Request permitted * Serve - Sync and control requests, cannot sync * Peer - Sync and control requests, can sync time * Query-Only - Permit only control queries • Using SNTP to Synchronise Time – A reduced set of NTP functions – Operates as client only – Time Sync is simplified but less accurate 5.3. Cisco CCNP - Implementing Cisco IP Switched Networks (300-115 SWITCH) 129 Grumpy Networkers Journal Documentation, Release 0.0.7 Configure Logging Set Severity For Console Logging (Default: Debugging) NOTE: Severity can be either a number (0 being most severe) or the descriptive name (E.g. critical) logging console Set Severity For Internal Buffer (Default: Disabled) NOTE: Severity can be either a number (0 being most severe) or the descriptive name (E.g. critical) logging buffered Set Size of Internal Logging Buffer (Default: 4096 bytes) logging buffered Set Severity To Send To Remote Syslog Server NOTE: Severity can be either a number (0 being most severe) or the descriptive name (E.g. critical) logging trap Set Syslog Servers To Receive Messages Note: Multiple servers can be configured and all will receive the messages logging host Disable/Enable Logging Of Interface Status Changes [no] logging event link-status Set The Timestamp To Include On Log Messages NOTE: Applies to all logged message irrelevent of logging destination service timestamps log datetime [localtime] [show-time-zone] [msec] [year] Show Messages In The Internal Bufffer And Logging Settings show logging Configuring Clock On A Switch Manually Set the Client NOTE: Completed from privileged exec mode, not configure mode clock set[ Define The Local Timezone clock timezone Define Daylight Saving Times NOTE: Use one of the below methods* 130 Chapter 5. Study Notes Grumpy Networkers Journal Documentation, Release 0.0.7 clock summer-time ˓→mins>] clock summer-time Define NTP Server ntp server Setup NTP Authentication ntp authentication-key Restrict Access To NTP access-list Configure SNTP With Authentication sntp authentication-key Verifying NTP Synchronisation show ntp status Display A Summary Of Configured NTP Relationships show ntp associations Cisco - Monitoring Campus Networks - SNMP SNMP Overview • Simple Network Management Protocol (SNMP) • Data is stored in a Management Information Base (MIB) Database • Provides a means to monitor devices and obtain various statistics • The manager will communicate with the device (agent) over UDP Port 161 (Manager to Agent) • Agent will send messages to the manager over UDP Port 162 (Traps and Informs) 5.3. Cisco CCNP - Implementing Cisco IP Switched Networks (300-115 SWITCH) 131 Grumpy Networkers Journal Documentation, Release 0.0.7 SNMP Versions • Valid versions are 1, 2c and 3 • SNMP version 1 (RFC 1157) – Simple Get & Set requests – Supports Traps – Uses simple “community string” to gain access to agent – No encryption, community string sent in plain text • SNMP version 2c (RFC 1901) – Adds 64-bit counters – Bulk requests supported – Added acknowledged Traps, called Informs • SNMP version 3 (RFC 3410 - 3415) – Authentication through usernames – Users can be organised into groups – Users/Groups can have restricted access through “Views” – Encryption supported – Data Integrity guarantees SNMP Components • Manager – Polls And Receives data via SNMP – Runs in a central location • Agent – Runs on the network device – Respoonses to SNMP Polls – Sends “unsolicited” alerts as either Traps or Informs SNMP Request Types • GET Request - Poll for one specific MIB value using the OID • GET NEXT Request - Poll for the next value following an initial get request • GET BULK Request - Poll for entire table or list of values • SET Request - Asks the device to set a MIB variable to a specific value 132 Chapter 5. Study Notes Grumpy Networkers Journal Documentation, Release 0.0.7 SNMP Traps And Informs • The device sends real time alerts to the manager • Use UDP port 162 • A Trap is a one-way acknowledgement that something significant has happened. No acknowledgement is ex- pected • An Inform operates same as a Trap but requires an an acknowledgement to be received from the manager by echoing it back Configuring SNMP version 1/2c Define Access to Agent by IP access-list Specify Who can Access the Switch via SNMP snmp-server community Define where to send trap/informs snmp-server host Configure SNMP version 3 NOTE: Use an access-list list restrict who can acess the SNMP agent via IP Define a View for which MIB vales can be read/write snmp-server view Create A User Group snmp-server group Define User and Map to Group snmp-server user Define where to send trap/informs snmp-server host Cisco - Monitoring Campus Networks - IP Service Level Agreement IP SLA Overview • IP Service Level Agreement (IP SLA) 5.3. Cisco CCNP - Implementing Cisco IP Switched Networks (300-115 SWITCH) 133 Grumpy Networkers Journal Documentation, Release 0.0.7 • Used to gather information on how the work is performing from a point actually within the network • Takes the place of remote probes, all managed from central location • Legacy names – Response Time Reporter (RTR) – Service Assurance Agent (SAA) • Basic tests only require the source device to be configured • Advanced tests (E.g. Jitter) need a peer device to be configured as a “Responder” in order to collec the statistics • Control connection is setup between source and responder to carry out – Test setup – Time stamping of packets to account for latency • NTP is recommended to keep clocks synchronised • Tests can be triggered via SNMP as long as write access is permitted Features • Generate SNMP Trap when thresholds are exceeded • Schedule further IP SLA tests when thresholds are exceeded • Track IP SLA to trigger NHRP failover • Gather voice quality measurements frm all over the network Supported Tests • ICMP-Echo • Path-Echo • Path-Jitter (requires responder) • DNS • DHCP • FTP • HTTP • UDP-Echo • UDP-Jitter (requires responder) • TCP-Connect Configuring IP SLA NOTE: In IOS prior to 12.2(33) the commands has the “ip sla monitor” prefix Enable responder on destination 134 Chapter 5. Study Notes Grumpy Networkers Journal Documentation, Release 0.0.7 ip sla responder Enable IP SLA Authentication key chain Create a new test Note: In order to modify a test the existing test must be unscheduled then deleted before being recreated ip sla Schedule the test to run ip sla schedule Configure Specific Test Types Setup An ICMP Echo Test ip sla Setup UDP Jitter Test NOTE: Ensure that IP SPA Responder is running on the remote device ip sla Advanced IP SLA Usage Enable HSRP Failover based on IP SLA Result track 5.3. Cisco CCNP - Implementing Cisco IP Switched Networks (300-115 SWITCH) 135 Grumpy Networkers Journal Documentation, Release 0.0.7 Verify IP SLA Display Configuration show ip sla configuration [ Display IP SLA Test Result show ip sla statistics [aggregated] [ Cisco - Using Port Mirroring To Monitor Traffic Port Mirroring Overview • Switched Port Analyzer (SPAN) • Allowing a network analyzer to be attached to a switch receive all packets irrespetive of any MAC learning or VLAN • Packets received on source port are copied to the destination port SPAN Types • Local Span - Both Source and Destination ports on the same switch • Remote Span - Source and Destination ports on different switches Local SPAN • Span session is setup by specifying both a source and destination • Source and destination must be on the same switch • Session can be configured to mirror received, transmitted or both directions of traffic to the destination • Source can be a single port, EtherChannel or Vlan • Destination must be a single port • Source and destinations should have equivilent traffic handling capabilities otherwise packets could be lost • STP is disabled on the destination port • Any traffic that is received on the destination port is by default dropped Local SPAN Configuration Define SPAN Source monitor session Define SPAN destination 136 Chapter 5. Study Notes Grumpy Networkers Journal Documentation, Release 0.0.7 monitor session ˓→protocols as well [ingress {dot1q vlan Filter VLANs to capture from Trunk Source monitor session Remote Span • Enables the traffic analyzer to be located in a different part of the campus network to the source device • Uses a special VLAN marked for Remote SPAN use • If the source and destination switches are not directly connected, each switch along the path must know of the RSPAN VLAN • It is recommended to remove the RSPAN VLAN from all trunks except those in the path • VTP will correctly propagate the RSPAN VLAN and auto prune (if enabled) from unnecessary links • Use One RSPAN VLAN for each each RSPAN session • STP must run on the RSPAN VLAN therefore BPDUS can’t be monitored Remote SPAN Configuration Create RSPAN VLAN on all potential switches in the path vlan Configure RSPAN Source Device NOTE: Ensure RSPAN VLAN has been created first* monitor session ** Configure RSPAN Destination Device** NOTE: Ensure RSPAN VLAN has been created first* monitor session Managing SPAN Session Show Configured Sessions 5.3. Cisco CCNP - Implementing Cisco IP Switched Networks (300-115 SWITCH) 137 Grumpy Networkers Journal Documentation, Release 0.0.7 show running-configuration| include monitor show monitor [session { Delete SPAN Session no monitor session { Cisco - Understanding High Availability Leveraging Logical Switches • Switches as each network layer should be deployed in pairs for redundancy • Traditional devices provided redudancy but don’t allow all links to be used • Redudancy only provided at core and distribution layers, not access • Logical switches permits grouping the redudant links into an etherchannel, no blocked links • Two approaches to logical switches – StackWise – Virtual Switching System (VSS) StackWise • StackWise and StackWise Plus options available • Supported on Catalyst 3750-E, 3750-X and 3850 • Uses special “stacking” cables deployed in a daisy-chain to form a ring • Traffic is carried bi-directional across the stacking switch fabric • Switches can be added/removed as long the ring is kept intact in one or both directions • One switch is appointed as the master to perform management functions • Single management IP is assigned to the entire switch stack Virtual Switching System • Two identical Chassis switches working as a single switch • Supported on Catalyst 4500R, 6500 and 6500 series switches • Referred to as a “VSS Pair” • Multiple interfaces connect the switches called the “Virtual Switch Link” (VSL) SuperVisor And Route Processor redundancy • FHRP protocols (VRRP, HSRP, GLBP) provide HA only for the default gateway IP, no assistane for directly connected hosts • Chassis switch can support multiple supervisors, offering redundancy within the switch itself 138 Chapter 5. Study Notes Grumpy Networkers Journal Documentation, Release 0.0.7 • Some switches also have multiple power supplies offering the ability to support dual power feeds in the event of power failure Redudant Switch supervisors • First of the two supervisors to boot becomes active, others take on a standby role • Active supervisor boots to a fully initialised and operational state • Standby only initialised to a certain level depending on configured/supported modes – Route Processor Redudancy (RPR) – Route Processor Reudancy Plus (RPR+) – Stateful Switch Over (SSO) - Best • Single Router Mode (SRM) indicates two route processors but one one is active • Dual Router Mode (DRM) indicates both route processors are active, commonly alongside HSRP • SRM is not comatile with RPR/RPR+ • SRM is inherent with SSO, can be seen as “SRM with SSO” • Route Processor Redundancy (RPR) Mode – Supervisor only partially booted – Every module in switch is reloaded when active fails – Layer 2/Layer 3 not initialised • Route Processor Redundancy Plus (RPR) Mode – Supervisor and Route Engine Initialised – No Layer 2/Layer 3 functions started – No reload of modules needed when active fails – Switch ports retain existing state • Stateful Switch Over (SSO) Mode – Supervisor Fully Booted And Initialised – Startup/Running config synchronised – Layer 2 information maintained – No change to interface states – Layer 3 protocols and routing protocol convergence happens upon active failure Non-Stop Forwarding (NSF) • Focuses on quickly rebuilding routing information base (RIB) • RIB used to generate FIB for CEF • Router can use NSF to get assistance from other NSF-Aware neighbours • Avoids waiting on routing protocol convergence • NSF must be supportd by the routing protocol (BGP, EIGRP, OSPF, IS-IS) 5.3. Cisco CCNP - Implementing Cisco IP Switched Networks (300-115 SWITCH) 139 Grumpy Networkers Journal Documentation, Release 0.0.7 • NSF is Cisco Proprietary Configuring High Availability Set the redundancy mode for the chassis NOTES: • Needs to be configured on both switches the first time it is setup • To support RPR+ both chassis must have identical IOS otherwise fails back to RPR redundancy mode { rpr| rpr-plus| sso } Verify Redundancy Status show redundancy status Configure Suprvisor Synchronisation NOTE: By default startup and running configurations are sync’d redudancy main-cpu auto-sync standard # default setting auto-sync { startup-config| config-register| bootvar } Configure NSF For BGP router bgp< as> bgp graceful-restart Configure NSF For EIGRP router eigrp< as> nsf Configure NSF For OSPF router ospf Configure NSF For IS-IS router isis [ Cisco - Layer 3 High Availability Overview • Switches have support for router redundancy protocols 140 Chapter 5. Study Notes Grumpy Networkers Journal Documentation, Release 0.0.7 • Sometimes called First Hop Redudancy Protocols (FHRP) • Protocols Supported – Hot Standby Router Protocol (HSRP) – Virtual Route Redundancy Protocol (VRRP) – Gateway Load Balancing Protocol (GLBP) • Used to avoid a single router becoming a single point of failure for traffic needing to leave the subnet/VLAN Packet Forwarding Review • Hosts use ARP to find devices on the local subnet • An Intermediate System (a router) is required to reach another subnet • Hosts that understand routing will ARP for the gateway MAC to send packets to • Hosts that don’t understand routing will ARP for all IPs (even remote ones) the route must reply with it’s own MAC in the form of a proxy ARP • The gateway/IS/Router availability is critical for the network to function Hot Standby Router Protocol (HSRP) • Cisco Proprietary • Documented in RFC 2281 • One router is elected as “Active”, another as “Standby” • Routers other than the Active/Standby remain in a LISTEN state • Hello messages exchanged so other routers know of their existance (default: 3 second interval) • Routers assumed down if they miss 3 hello interfaces (default: 10 seconds) • Uses multicast 224.0.0.2 (“All Routers”) over UDP port 1985 • Routers arranges into groups (ID 0 - 255) • Upto 16 groups supported on the switch as a whole but be reused on multiple VLANs Router Election • Priority Value (0-255), Default: 100 • Highest priority becomes active router, highest IP used as a tie break HSRP State Transition • HSTP States * Disabled (not a true HSRP state, used for interfaces that are adminitrative down) * Learn * Listen * Speak * Standby * Active • Only router in “Standby” state monitors hellos from the “Active” router • Election of new standby occurs after current standby assumes active role 5.3. Cisco CCNP - Implementing Cisco IP Switched Networks (300-115 SWITCH) 141 Grumpy Networkers Journal Documentation, Release 0.0.7 • By default the previous active router cannot be come active until current active fails • Preemption can be used to ensure the highest priority router is always active • Hosts are configured to talk to a virtual IP, not an IP assigned directly to a single router • Virtual IP used has a MAC address of 0000.0C07.ACxx (xx = Group ID) Authentication • Used to avoid peers with default configuration or unauthorised devvices participating in the HSRP group • Supported Autentication Methods – Plain Text – MD5 • Plain Text Authentication – Offers basic protection to prevent misconfigured peers participation in the group – Default key string is cisco • MD5 Authentication – Authentication hash computered on a part of each HSRP message – Secret key known own to legitimate HSRP group peers – Only hash is sent across in packets – Hash used to validate message contents – Key string (up to 64 characters) must be configured on each HSRP router in the group Conceding The Election • Used to sway the election in the event of interface and (e.g. route peering) failures • Gateway will reduce it’s priority, making it less likely to be the active router Load Balancing with HSRP • Multiple HSRP groups can exist on a subnet/vlan, each with a unique ID • Both routers on the subnet can be used at the same time whilst still providing redundancy • Each router is configured as the primary for it’s own group and secondary for the peer routers group • Hosts must be configured to use the most approrpiate gateway either manually or via DHCP Virtual Router Redundancy Protocol (VRRP) • Standards based protocol, documented in RFC 2338 • One router is appointed as “Master” router, others are “Backup” routers • Master based on highest priority value (1-254), default: 100 • Uses virtual IP and MAC with prefix 0000.5E00.01xx (xx = Group ID) 142 Chapter 5. Study Notes Grumpy Networkers Journal Documentation, Release 0.0.7 • Group ID is 0 to 255 • Advertisements sent at 1 second intervals, interval can be learned from master router • Premption enabled by default • Advertisements sent with multicast IP 224.0.0.18 using IP protocol 112 • Introduced in IOS 12.0(18)ST, not supported on all switch platforms • Can use inteface tracking • Multiple groups supported per VLAN for load balancing Gateway Load Balancing Protocol (GLBP) • HSRP/VRRP can provide load balancing but requires external assistance to point hosts as the appropriae virtual IP • GLBP provides both redudancy and load balancing without needing client or server configuration • Cisco Proprietary • Introduced in IOS 12.2(14)5, no consistent support on switch platforms • Switches/Routers assigned to a common group • All routers participate in forwarding a portion of the traffic • Load balancing achieved through virtual MAC addresses • Each client will receive a different ARP reply even though same gateway IP is used Active Virtual Gateway (AVG) • Only one router is elected as the AVG • Election based on highest priority, then highest IP • Responsible for answering all ARP requests • MAC returned depends on configured load balancing method • Response for assigning MAC to router in the group (AVF) • Upto 4 virtual MAC addresses supported • AVG also assigned secondary roles • Group ID can be 0 - 1023 • Priority can be 1 - 255, default: 100 • Premption is supported, not enabled by default • Hellos sent every 3 seconds by default • Peer assumed failed after holdtime expires (default: 10 seconds) • Holdtime should be 3 times the hello interval • Timers only need to be configured on the AVG which will advertise to other routers 5.3. Cisco CCNP - Implementing Cisco IP Switched Networks (300-115 SWITCH) 143 Grumpy Networkers Journal Documentation, Release 0.0.7 Active Virtual Forwarder (AVF) • Responsible for forwarding traffic received from clients • Virtual MAC prefix of 0007.B4xx.xxyy – xx.xx = 0 bits followed by 10 bit group ID – yy = 8-bit virtual forwarder number • Handling AVF Failure – If hellos are missed, AVG will assign AVF role to another router – AVG will continue to process traffic on olf MAC until “Redirect Timer” expires – Redirect timer by default is 600 seconds – When timeout expires old MAC and AVF are flush from all GLBP peers – Clients must refresh ARP to find new MAC address after it has been flushed • Weighting – Used to determine which router becomes the AVF for a virtual MAC – Weight value between 1 and 254, default: 100 – weight decreased as interfaces go down – AVF role is given up if weight is below lower threshold – Router can resume AVF role when weight is above upper threshold – GLBP must be configured with interfaces to track – AVF cannot preempt another AVF with a higher weight GLBP Load Balancing • MAC address handed to clients in a deterministic fashion • Supported load balancing methods – Round Robin (Default) - Even traffic load across all AVFs – Weighted - AVFs receive traffic based on configured weight values – Host Dependant - host is given consistent MAC every time HSRP configuration Specify Router Priority NOTE: Default priority is 100 interface Set HSRP Timers NOTE Default timers are 3 seconds (hello) and 10 seconds (holdtime) 144 Chapter 5. Study Notes Grumpy Networkers Journal Documentation, Release 0.0.7 interface Enable higher priorty router to take over from current active router interface Configure plain-text authentcation interface Configure MD5 authentication key chain Configure Priority changed based on interface status NOTE: Default decrement value is 10 interface Specify Virtual IP To Use For Group interface Enable HSRP for IPv6 interface Verify HSRP Status show standby [brief] [vlan VRRP configuration Set Router Priority interface Set advertisement interval interface 5.3. Cisco CCNP - Implementing Cisco IP Switched Networks (300-115 SWITCH) 145 Grumpy Networkers Journal Documentation, Release 0.0.7 Configure advertisement learning interface Disable/Enable Prempting NOTE: Enabled by default interface Set Authentication String interface Assign Virtual IP interface Enble Interface Tracking interface Check VRRP Status show vrrp [brief] [all] GLBP Configuration Assign Priority To A Router interface Enable Prempting NOTE: Disabled by default interface Set Timers Default: 3 second hello, 10 second holdtime interface **Set AVF Redirect/Timeout Timers interface Configure Tracking Object 146 Chapter 5. Study Notes Grumpy Networkers Journal Documentation, Release 0.0.7 track Set Weighting Thresholds Note: Default max 100 interface Define tracking criteria interface Set Load Balancing Method interface Set Virtual IP NOTE: Must be configured on the AVG, learnt by other routers interface Enable GLBP for IPv6 interface Verify GLBP show glbp [ Cisco - Securing Switch Acccess Port Security • Controls access to a port based on MAC Address • MAC addresses are statically configured or dynamically learned • Limits the number of stations that can be used on a given port, by default 1 • MAC addresses learned as hosts transmit frames • Learned addresses are lost upon reboot by default unless “Sticky Addresses” is enabled • By default learned addresses do not age out, this can be configured Violation Actions • Shutdown (Default) – Port put in errdisabled state – No traffic flow 5.3. Cisco CCNP - Implementing Cisco IP Switched Networks (300-115 SWITCH) 147 Grumpy Networkers Journal Documentation, Release 0.0.7 – Manual or error disabled recovery needed • Restrict – Port stays up – Frames for invalid MACs are dropped – Sends SNMP Trap • Protect – Port stays up – All traffic from violated MACs dropped – No record of violation recorded Port-Based Authentication • Combination of AAA Authentication and Port Security • Based on IEEE 802.1x • User is required to successfully authrnticate before traffic will flow • Requires support on the switch (Supplicant) and the end user device (client) • Client configured with 802.1x will still allow traffic to flow when switch is not configured to authenticate • Uses EAP Over LAN (EaPOL), A layer 2 protocol • Port returns to an unauthorised state when end user logs out or disconnects port • Authentication is done from the switch to an authentication server using RADIUS • Switch ports can be configued into 1 of 3 states – Force Authorised - No authentication needed (default) – Force Unauthorised - Port will never successfully authenticate – Auto - Requires sucessful 802.1x authentication • By default only a single host is supported on an authenticated port, muliple hosts can be configured Configuration Steps • Enable AAA Globally On the switchh • Define RADIUS servers • Define Authentication Methods for 802.1x • Enable 802.1x globally on the switch • Configure individual ports to use 802.1x authentication by changing them from “Force Authorised” to “Auto” 148 Chapter 5. Study Notes Grumpy Networkers Journal Documentation, Release 0.0.7 Using Storm Control • Switches allow networks to be more efficient by only sending frames to the host(s) that need them • Swiitches cannot optimise the all frame times and must flood them – Broadcast – Multicast – Unknown Unicast • Storm Control helps by preventing hosts sending excesive amounts of these packet types • Configured per interface • Individual thresholds for each frame type • Thresholds are specified as a percentage of interface bandwidth in either bps or pps • hosts breaching thresholds can cause certain actions to occur Storm control actions • Drop (Default) - Exceeding frames are dropped • Shutdown - Port is placed in error disabled state • Trap - Frames dropped and SNMP trap sent Best Practices for securing Switches • Configure secure passwords • Use system banners • Secure/Disable the web interface • Secure the console ports • secure telnet/SSH access • Use SSH in preference to Telnet where supported • Use SNMPv3 where possible and restrict to read-only access • Secure unused switch ports • Secure STP operation (e.g. BPDU Guard) • Secure use of CDP/LLDP to only connections with trusted devices Configuring Port Security Enable Port Security interface Define number of allowed MAC addresses on a port 5.3. Cisco CCNP - Implementing Cisco IP Switched Networks (300-115 SWITCH) 149 Grumpy Networkers Journal Documentation, Release 0.0.7 interface Set Dynamically learned addresses to be sticky interface Manually define the MAC address permitted on a port interface Define the action tkane upon detected an unknown MAC NOTE: Default action is “Shutdown” interface Clear MAC addresses from the port cache clear port-security {all| configured| dynamic| sticky } [address ˓→ Shows status for an interface show port-security [interface Show summary of error disabled interfaces show interfaces status err-disabled Manually restore an interface interface Configure Learned MAC address ageing NOTE: Disabled by default interface Configuring Port-Based Authentication Enable AAA Globall aaa new-model Define external RADIUS servers radius-server host { Define authentication method used for 802.1x 150 Chapter 5. Study Notes Grumpy Networkers Journal Documentation, Release 0.0.7 aaa authentication dot1x default group radius Enable 802.1x supplicant on the switch dot1x system-auth-control Set The authentication mode on an interface interface Allow multiple hosts on a single port dot1x host-mode multi-host Verify 802.1x operation show dot1x all Configuring Storm Control Enable Storm Control Thresholds interface Enable Additional Actions When Thresholds Breached NOTE: Default is to drop exceeding packets interface Display Storm Control Status show storm-control [ Cisco - Securing VLANs VLAN Access Lists (VACLs) • Normal router access lists (RACLs) only filter traffic between VLANs • VACLs filter traffic that stays within a VLAN • VACLs are merged into the TCAM • Support additional “Redirect” action • Configured globally for the VLAN not per interface • Evaluated in sequence • Can match IP addresses as well as MAC addresses however they need to be in different ACLs • Action and Match is performed as frames within a VLAN or routed in/out of a VLAN 5.3. Cisco CCNP - Implementing Cisco IP Switched Networks (300-115 SWITCH) 151 Grumpy Networkers Journal Documentation, Release 0.0.7 • Packets are filtered in hardware • The “Redirect” action causes traffic to be forwarded onto a specified interface Private VLANs • Allows for segmenting of hosts within a VLAN without needing to assign ACLs or different subnets • Hosts are limited to being able to talk to hosts on the “Primary” VLAN (e.g. a router) but not hosts on a different “Secondary” VLAN • Secondary VLANs must be mapped to one Primary VLAN • VTP does not pass information relating to private VLANs, making them locally significant only • Each switch port must be configuered to be either a “Promiscuous” or “Host” Port Secondary VLAN Types • Isolated – Can only communicate with the primary VLAN – Cannot communicate with hosts on the same or different secondary VLANs • Community – Can commmunity with primary VLAN – Can communicate with hosts on same Secondary VLAN – Cannot communicate with hosts on different Secondary VLAN Port Modes • Promiscuous - Can communicate with any other host • Host - Only communicate with same community or promiscuous port Configuration Steps • Create the Private VLANs and specify the secondary VLAN type • Create Primary VLANs and associate with secondary VLANs • Set the secondary VLAN mode per interface • Associate host ports with primary and secondary vlan • Associate promiscuous ports with the primary and one or more secondary VLANs • Map SVI interfaces to Secondary VLANs 152 Chapter 5. Study Notes Grumpy Networkers Journal Documentation, Release 0.0.7 Example Configuration In this example we will configure a port which is connected to a single router that will serve as the gateway for both a community and isolated VLAN: Step 1: Create the Secondary VLANs ! Hosts that only need to communicate with the router vlan 100 name PV-GUESTS private-vlan isolated ! Hosts that need to talk amongst themselves and to the the router vlan 200 name PV-HOSTS private-vlan community Step 2: Create the Primary VLAN vlan 10 name PV-GATEWAY private-vlan primary private-vlan association 100,200 Step 3: Configure the port connected to the router (Primary VLAN) interface FastEthernet0/1 switchport mode private-vlan promiscuous switchport private-vlan mapping 10 100,200 Step 4: Configure the host ports and associate with the primary VLAN ! For the isolated hosts interface FastEthernet0/2 switchport mode private-vlan host switcport private-vlan host-association 10 100 ! For the community hosts interface range FastEthernet0/3-5 switchport mode private-vlan host switchport private-vlan host-association 10 200 Securing VLAN Trunks Switch Spoofing • Don’t use DTP • Manually configure expected behaviour on each port • Prevent a maliscous host fromm forming a trunk VLAN Hopping • Attacker will send double tagged frames with the outer tag as the native VLAN 5.3. Cisco CCNP - Implementing Cisco IP Switched Networks (300-115 SWITCH) 153 Grumpy Networkers Journal Documentation, Release 0.0.7 • Switch will see the outer tag as being the same as the native VLAN and remove it • Switch will now sent the frame onto the trunk with the previously hidden inner VLAN • Attacker has now gained access to the other VLAN • Conditions required to work – Attacker connected to access port – Same switch must have an 802.1q Trunk – Trunk must have attacker access VLAN as it’s native VLAN • Solution – Set Native VLAN to an unused VLAN ID – Prune the Native VLAN off both ends of the trunk Configuring VLAN Access Lists Configure the VACL along with conditions vacl access-map Apply the VACL to one or more VLANS vlan filter Configure Private VLANs Create Secondary VLAN vlan Create Primary VLAN and Map to Secondary VLANs vlan ˓→list>} Set the Interface Port Modes interface Associate Host Port With Primary And Secondary VLAN NOTE: Host ports can only be associated with one primary and one secondary VLAN interface 154 Chapter 5. Study Notes Grumpy Networkers Journal Documentation, Release 0.0.7 Associate Promiscuous Ports with Primary and one or more Secondary VLANs NOTE: A promiscuous port belongs to one primary VLAN but can be mapped to more than one secondary VLAN interface ˓→list>} Associate Layer 3 SVI with one or more secondary VLANs NOTE: Only create for “Primary” VLANs, any SVIs for a secondary VLAN will be shutdown interface vlan Verify Private VLANs show vlan private-vlan show interface switchport show interface private-vlan mapping Vlan Trunk Secure Configuration Statically Configure An Interface as an access port interface Change the Native VLAN of Trunk and remove from the trunk interface Specify the tag should be added even for native VLAN NOTE: This is a global setting, not per interface vlan dot1q tag native Cisco - Preventing Snooping Attacks DHCP Snooping • Mitigates the risk of a rogue DHCP server existing on the network • Ports configured as trusted or untrusted • All DHCP requests are intercepted by the switch • DHCP replies on untrusted ports are discarded and source port is shutdown • Switch creates database of DHCP “Bindings” as legitimate replies received • Configuration Steps – Define Trusted Ports 5.3. Cisco CCNP - Implementing Cisco IP Switched Networks (300-115 SWITCH) 155 Grumpy Networkers Journal Documentation, Release 0.0.7 – Enable DHCP Snooping – Define What VLANs to enable DHCP snooping on IP Source Guard • Mitigates the risk of maliscious hosts spoofing their source IP address • Takes advantage of MAC-To-IP mappings stored in the DHCP snooping database • Static entries can also be configured for non-DHCP hosts • Packets must pass conditions in order to pass thhrough switch – Source IP identical to IP learned by DHCP snooping/Static entry – Source MAC identical to MAC learned by switch and DHCP Snooping/Static entry • Dynamic ACL or port security is used to filter traffic • Configuration Steps – Enable DHCP Snooping – Enable Port Security (if detecting MAC Spoofing is required) – Configure Static Entries for non-DHCP hosts – Enable Source Guard (Per Interface) Dynamic ARP Inspection (DAI) • Mitigates the risk of ARP poisoning/ARP spoofing • Uses either static entries or those learned through DHCP snooping • Ports classed as trusted/untrusted • Ports connecting other switches should be trusted • Switches checks ARP replies received on untrusted port • Invalid ARP replies are dropped and logged • Configuration Steps – Define trusted interfaces – Confiigure ARP access-list for non-DHCP hosts – Enable DAI on required VLANs • MAC Access-list (Filter is checked first then the DHCP snooping database • Checking of DHCP snooping database can be skipped if required • Only MAC/IP in the ARP reply are checked, additional ethernet level checks can be enabled – Source MAC – Destination MAC – IP 156 Chapter 5. Study Notes Grumpy Networkers Journal Documentation, Release 0.0.7 Configure DHCP Snooping Enable DHCP Snooping ip dhcp snooping Specify VLANs to have DHCP Snooping applied ip dhcp snooping vlan Specify Trusted Interfaces interface Limit rate of DHCP requests interface Add option 82 to DHCP request Note: Enabled By Default [no] ip dhcp snooping information option Verify DHCP Snooping show ip dhcp snooping [binding] Configuring IP Source Guard Configure Static Binding ip source binding Enable IP Source Guard on an interface interface Verify IP source Guard Status show ip verify source [interface Verify Source Bindings show ip source binding [ ˓→ Configuring Dynamic ARP Inspection (DAI) Configure Trusted Interfaces 5.3. Cisco CCNP - Implementing Cisco IP Switched Networks (300-115 SWITCH) 157 Grumpy Networkers Journal Documentation, Release 0.0.7 interface Enable DAI on required VLANs ip arp inspection vlan Define MAC Access List foor non-DHCP hosts arp access-list Apply Filter ip arp inspection filter Apply additional packet validations ip arp inspection validate {[src-mac] [dst-mac] [ip]} Display DAI Status show ip arp inspection Cisco - Managing Switch Users AAA Overview • Used to manage user activity by controlling and reporting on their actions • AAA Functions – Authentication - Who is the user? – Authorization - What is the user allowed to do? – Accounting - What did the user do? • After successfull login, users are given “User Exec” level privileges • An “Enable” secret is entered which grants additional privileges • Local usernames can be configured on the switch, not scaleable • Centralised authentication can be done through TACAC+ or RADIUS Centralised Authentication • Client/Server model • Switches as clients known as “Network Access Device” (NAD) or “Network Access Server” (NAS) • Cisco provides AAA services through two products – Identity Service Engine (ISE) – Secure Access Control Server (ACS) 158 Chapter 5. Study Notes Grumpy Networkers Journal Documentation, Release 0.0.7 Terminal Access Controller Access Control System (TACACS+) • Cisco Proprietary • Uses TCP Port 49 for secure/encrypted communication Remote Access Dial-In User Service (RADIUS) • Standards Based • Uses UDP Ports 1812 (Authentication) and 1813 (Accounting) • Not all traffic is encrypted Method Lists • Used to group vvarius authentication/authorisation methods for easier reuse • Authentication methods – TACACS+ - Try each server defined until success or positive denial – RADIUS - Try each server defined until success or positive denial – LOCAL - Check the entered details against configured users on the local switch – LINE - Authenticate against password defined on VTP/console, does not use a username • Authorization Methods – Commands - Server must give permit for any command at any privilege level – Config-Commands - Server must give permission for config commands – Configuration - Server must vie permisson to enter config mode – Exec - Server must give permission to run exec session – Network - Server must return permission to use network related sessions – Reverse-Access - Server must give permission for reverse telnet sessions • Only TACACS+ supports per-command authorisation, RADIUS is all or nothing Accounting • Records activities performed by a user • Supported by RADIUS and TACACS+ • Accounting Levels – System - Major swich events (E.g. reload) – Exec - User authenticated into an Exec session (IP, Time and duration are recorded) – Commands - Info on commands running at the specified level • Accounting Times – Start-Stop - Events recorded at both beginning and end – Stop-Only - Events recorded at end of action 5.3. Cisco CCNP - Implementing Cisco IP Switched Networks (300-115 SWITCH) 159 Grumpy Networkers Journal Documentation, Release 0.0.7 – none - No events recorded Configuring Authentication Enable AAA on the Switch aaa new-model Create Local Users username Define RADIUS server radius-server host { Define TACACS+ server tacacs-server host { Define Server Groups and Included Servers aaa group server {radius|tacacs+} Define Method List For Authentiation aaa authentiation login {default| Apply the method list to a switch line line {vty|con} Configure Authorisation Define Authorization Method List aaa authorization {commands|config-commands|configuration|exec|network|reverse-access} {default| Apply method list too specific line line {vty|con} Configure Accounting Define Accounting Method List aaa accounting {system|exec|commands 160 Chapter 5. Study Notes Grumpy Networkers Journal Documentation, Release 0.0.7 Apply method list to required lines line {vty|con} 5.3. Cisco CCNP - Implementing Cisco IP Switched Networks (300-115 SWITCH) 161 Grumpy Networkers Journal Documentation, Release 0.0.7 162 Chapter 5. Study Notes CHAPTER 6 Vendor Implementations 6.1 Cisco Implementations 6.1.1 Cisco Firewall Features Cisco ASA Firewall Cisco ASA Management Services • ASDM (HTTP) • CLI (SSH/Telnet) Cisco ASA Monitoring Services • SNMP (1, 2c, 3) • NetFlow / NSEL Cisco ASA Firewall - Rules Management Overview The Cisco ASA is a dedicated firewall appliance and has much more structure to the way in which traffic filtering is applied that a general purpose router firewall. Unlike a router the filtering of traffic to the firewall is handled seperately than transit traffic through the device, so there is no risk of loosing management access when amending user policies. 163 Grumpy Networkers Journal Documentation, Release 0.0.7 Unified ACL Prior to version 9.0(1) it was necessary to manage IPv6 and IPV4 access lists seperately. Later versions have unified this functionality and removed the IPv6 specific commands. This now means that a single access-list can now include a mixture of both IPv4 and IPV6 hosts and networks. Object groups can also be include a mixture of these addresses as well befoe being bound to the ACL. In order to support this the ‘any’ keyword has been modified to include both IPv4 and IPv6 addressing. The new ‘any4’ and ‘any6’ keywords now refer to their respective IP addressing version (IPv4 and IPv6 respectively). Although the new features allow the specifying of an IPv4 and and IPv6 destination (and vice versa), communication between these devices will only work if NAT46/NAT64 has been configured to map the addresses to a valid address in the other IP version. Without NAT46/NAT64 the commands are still valid but only communication betwee the same IP versions will function correctly. Objects and Object Groups Objects can be used to make a firewall configuration more readable by giving the various host IPs, subnets, ranges as well as service ports a readable name that will be easier to reference for the administrator. Objects can also be used to define a NAT rule along with the real IP where the configuration needed is very basic. This is called an Object or Auto NAT. Object Groups can be used to combine multiple related hosts, networks or services together ino a single entity. Doing this will make the firewall rulebase more managable in the long term as well as aligning the firewall policy with the organisations documented security policy. Different types of Objects and Object Groups exist (namely service and network), it is not possible to mix these two different types together but they can be used in the same access control entity where permitted. Implementation In order to implementing filtering on the firewall the following steps must be done: Necessary Steps 1. Create Host, Network or Service objects 2. Create Network/Service Object Groups 3. Combine raw IP addresses, subnets and/or objects/object groups into an ACL 4. Apply the ACL to an interface either inbound or outbound. Create Host, Network or Service Objects Objects are used on the firewall in order to reduce duplication and enable easier management of the firewall in general. An object can be used to represent a single host or network as well as a specifically named service or protocol. Note: The ability to create named objects on the firewall was added in ASA version 8.3. Prior to this it was necessary to use name statements but this only supported hosts, not networks or services. 164 Chapter 6. Vendor Implementations Grumpy Networkers Journal Documentation, Release 0.0.7 To define needed objects, the following syntax applies for Network objects: object network And for Service objects: object service Define Object Groups Object Groups are used to allow either a group of hosts/networks or services to be combinded into a single configura- tion item. This can then be added to an ACL and allows the specified group to be used multiple times, helping to make the firewall policy more managable. For a network group: object-group network ! Add a previously configured network object group group-object ! Add an existing object to group network-object object ! Use a raw IP address network-object host ! Use a raw subnet network-object Note: Ability to use object groups was added in ASA version 7.0(1). Ability to use mixed IPv4 and IPv6 was added in a single group was added in 9.0(1) Define ACL Once all the objects are defined an ACL an then be created from them: access-list ˓→ip-spec> [ Bind ACL to interface Each interface can have a unique ACL in the inbound and outbound direction. Inbound ACLs are more common but outbound is applied in some special cases. 6.1. Cisco Implementations 165 Grumpy Networkers Journal Documentation, Release 0.0.7 access-group It is also possible to use a global ACL which applies to all interfaces. The global access list is applied after the interface specific ACL. access-group Cisco ASA - Network Address Translation Overview NAT Order of Operations Pre-8.3 1. NAT Excemption 2. Static NAT 3. Static PAT 4. Policy NAT/PAT 5. Identity NAT 6. Dynamic NAT 7. Dynamic PAT Version 8.3 and Later 1. Manual NAT (Section 1) 2. Auto NAT (Section 2) 3. Manual NAT (Section 3) with after-auto NAT Control In versions of ASA prior to 8.3 a feature existed called NAT Control which caused any traffic that did not have a corresponding NAT rule to be dropped. It could be enabled/disabled as follows: [no] nat-control This feature is no longer available in later ASA versions. Static NAT/PAT Static NAT/PAT is useful when you want to have a host or group of hosts to always appear as the same IP address on another network. this provides a one-to-one mapping between the real and translated address. 166 Chapter 6. Vendor Implementations Grumpy Networkers Journal Documentation, Release 0.0.7 Most commonly these feature is used where you need to provide a service to users and need to be able to provide them with consistennt information. The primary difference with Static NAT/PAT is that whilst both can translate the IP address, PAT (or Port Redirection) can also translate the port number. This can be useful when you want to conserve IP addresses and use a single IP address for multiple services where each service (such as TCP 25, TCP 443, TCP 53) are all directed to different hosts on the internal network. Pre-8.3 configuration Post-8.3 configuation Dynamic NAT/PAT As the name suggests Dynamic NAT/PAT does not provide a real host IP with a consistent one-to-one mapping. Instead when a connection is needed from a host the ASA wil dynamically assign an IP address out of a pool of addresses based on availability. In the case of Dynamic PAT the source ports will also potentially be modified which allows for the potential of an entire network to be hidden behind a single public IP address (up to 65535 translations). ASA 8.4(3) and above extend this by allowing up to 65525 translations per service, not address. Example of post-8.3 Dynamic PAT object-network ˓→ Policy NAT/PAT Where as Static and Dynamic NAT/PAT apply to all connections, a Policy NAT can be made to only be used when certain criteria is met (such as to only specific destinations). Identity NAT Identity NAT is used where you don’t want translation to occur. This may be necessary where you already have a Dynamic NAT rule in place for general Internet access but need to exclude traffic across a VPN from translation. Cisco ASA Transparent Firewalls Overview An ASA Firewall is capable of operating at Layer 2 when running in transparent mode. This allows it to be installed into the network with minimal distruption becaue no IP addressing changes are needed on the network. This type of firewall is sometimes called a Layer 2 or “Stealth” Firewall as it does not appear as a hop on the network and therefore is invisible to users, a bump-in-the-wire. Packets are forwarded from one interface on the ASA to another based on their MAC adress. This requires the ASA to mantain a MAC address table so that it knows which hosts exist on each of it’s interfaces. 6.1. Cisco Implementations 167 Grumpy Networkers Journal Documentation, Release 0.0.7 What differs the ASA from a switch is that whilst a switch will flood packets for unknown packets out of all interfaces, the ASA instead will try to discover the destination interface by the following methods: • ARP Request when the destition IP is located on a directly connected subnet to the ASA. • Ping Request when the destination IP adress is located on a distant subnet. This allows the ASA to learn either the next-hop routers MAC. Advantages • Ability to filter traffic between hosts using higher-level protocols (e.g. IP addressing and ports) without read- dressing the network. • Can forward non-IP packets Limitations • No support for VPN transit traffic, management only. • No QoS • No Multicast • No Dynamic routing protocols • No DHCP relay • No Dynamic DNS • Unified Communications is not supported Implementation Each of the ASAs interfaces need to be grouped into one or more bridge groups. Each of these groups acts as an independent transparent firewall. It is not possible for one bridge group to communicate with another bridge group without assistance from an external router. As of 8.4(1) upto 8 bridge groups are supported with 2-4 interface in each group. Prior to this only oe bridge group was supported and only 2 interfaces. When running in muliple context mode, each context can support multiple bridge groups but each context must use a set of interfaces that is different from that of another context. All of the interfaces in the bridge group must share the same IP subnet. Packets however are still inspected without the Layer 2 limitations which allows policy decisions to be made on the full IP tuple (i.e. extended ACLs). ASA versions 8.0(2) and above can also integrate with NAT when running in transparent mode. Whilst a firewall operating in routed mode can forward only IP packets, a transparent firewall doesn’t share this limitation. This requires a special EtherType access-list. In order to manage the firewall the dedicated management port must be used or an IP address must be configured on one of the interfaces. 168 Chapter 6. Vendor Implementations Grumpy Networkers Journal Documentation, Release 0.0.7 Configuration Steps 1. Change the firewall mode 2. Configure interface groups 3. Assign IP address to the group 4. Create any management static routes 5. Configure Security Policies Change the firewall mode This can only be done from the CLI, not through ASDM firewall transparent No reload is required after applying the command however the running configuration will be cleared to remove any inapppriate settings. Configure interface groups This can be configured via ASDM: Configuration → Device Setup → Interfaces Each bridge group is assigned a number. From the CLI do the following for each interface: interface Assign IP address to bridge group In ASDM it’s necessary to create a new Bridge Virtual Interface (BVI). Through the CLI do the following: interface BVI Create management static routes It the ASA needs access to any external networks (such as the Internet or management networks), static routes need to be created (Dynamic routing not supported). Through the CLI this can be created as follows: router 6.1. Cisco Implementations 169 Grumpy Networkers Journal Documentation, Release 0.0.7 Configure Security Policies controlling IP traffic is configured in the same way as with a normal routed firewall using access-list and access-group commands with the advantage that non-IP trafffic (such as routing protocols, e.g. OSPF) can also be permitted/denied. It is also possible to configure rules for which the ASA does not have inbuilt definitions by creating an EtherType rule. In ASDM this done through: Configuration → Firewall → Ethertype Rules And the CLI: access-list This EtherType ACL will be applied together with any existing IP access list, one of each type is allowing per inteface in each direction. ARP Inspection and Spoofing Because the ASA needs to learn which interface a given MAC address exists on, an attacker could abuse ARP to leverage a man-in-the-middle attack. Unlike higher-end switches the ASA cannot make use of the DHCP snooping table but it is possible to configure the ASA with static ARP entries. This only helps if the ARP requester and responder are located on different ASA interfaces. If the ARP information received conflicts with the statically configured entry, the ASA will assume the packet is spoofed and drop the packet. The ASA can also be configured not to learn MAC addresses. This can however become a high intesity management task as all MAC addresses would then have to be configured statically. In order to enable this feature: 1. Configure static ARP entries for all hosts 2. Enable ARP ispection 3. Disable MAC Address Learning (optional) Configure Static ARP entries In ASDM this can be done via: Configuration → Device Management → Advanced → ARP → ARP Static Table Via the CLI: arp Enable ARP inspection ARP inspection is enabled on a per interface basis. It is also possible to configure the ASA to drop the packet if no ARP enty is found, the default is to flood the packet so that it can be received. Through ASDM ARP is enable via: Configuration → Device Management → Advanced > ARP > ARP Inspection 170 Chapter 6. Vendor Implementations Grumpy Networkers Journal Documentation, Release 0.0.7 And the CLI: arp inspection Disable MAC Address Learning Stops the ASA from dynamically learning any MAC addresses as packets are forwarded. All MAC addressess must be statically defined. To disable through ASDM on per-interface basis: Configuration → Device Management → Advanced → Bridging → MAC Learning Alternatively through through the CLI: mac learn Further Information For further reading please refer to the the Cisco CLI Guide on Transparent Firewalls [c3]. Cisco ASA BotNet Filtering Overview The Cisco ASA Botnet filter provides a means to detect and potentially block traffic heading to known Botnet desti- nations. It can do this by using both known IP addresses as well as by monitoring DNS traffic for known bad DNS queries. It has a number of pre-requisites: • Seperate BotNnet (subscription) license required • ASA configured to use DNS in order to lookup names and address in static database • DNS Snooping enabled • Live connectivity to the Internet so that latest database an be downloaded. Implementation In order to implement the Botnet traffic filter the license must be enabled. This can be checked via the show version command on the CLI. If the license is not installed, the configuration options will not be shown in ASDM but the commands will still be available via the CLI. Configuration Steps 1. Configure dynamic database 2. Configure the static database 3. Enable DNS snooping 6.1. Cisco Implementations 171 Grumpy Networkers Journal Documentation, Release 0.0.7 4. Enable the Botnet traffic filter Configure the dynamic database Via ASDM the database can be configured through: Configuration → Firewall → Botnet Traffic Filter Select the following options: • Enable Botnet Updater Client • Use Botnet data dynamically downloaded from updater server After clicking Apply the database will be automatically downloaded the first time. To manually download the latest database select Fetch Botnet Database. Or via the CLI: dynamic-filter updater client enable dynamic-filter use database Configure the static ddatabase Under Botnet Traffic Filter select Black and White Lists Any entries in the whitelist will be allowed and not checked against the database or static entries. Entries in the blacklist will be used in conjunction with the database and monitored by the Botnet filter. Or via the CLI: dynamic-filter { blacklist | whitelist } {name Enable DNS Snooping Under Botnet Traffic Filter select DNS Snooping. For global DNS Snooping, simply check the DNS Snooping Enabled option under the global interface. Or via the CLI: ! By default the global policy is called 'global_policy' policy map Enable the Botnet Traffic Filter Under Bonet Traffic Filter select Traffic Settings. In most situations it will be necessary to enable the Botnet filter on the external facing interface. Check the option for Traffic Classified on the appropriate interface. It is also possible to only filter specific traffic, this can be done by selecting Manage ACL and defining the appropriate traffic. It’s also possible to specific what level of traffic will be dropped. 172 Chapter 6. Vendor Implementations Grumpy Networkers Journal Documentation, Release 0.0.7 Note: The default traffic level to be dropped is moderate and above with all traffic being dropped. Or via the CLI: dynamic-filter enable [ interface ! Optionally - Drop connections involved in botnet activity dynamic-filter drop blacklist [interface ˓→level {eq Cisco ASA Threat Detection Overview Available in ASA versions 8.0 and above, Threat Detection provides firewall administrators with the necessary tools to identify, understand, and stop attacks before they reach the internal network infrastructure. It acts like a simple IDS by detecting unusual traffic patterns and possibily preventing the anomaly traffic from reaching the internal network. Primarily this features is intended to provide protection to internal hosts against DoS and DDoS attacks as it can only act on the rates of various traffic patterns, not on details included in the traffic as would be done with a signature-based IDS/IPS. Components • Basic Threat Detection • Advanced Threat Detection • Scanning Threat Detection Limitations • Supported on ASA 8.0(2) and later, not supported on ASA 100V platform • Does not support multiple context mode • Only through-the-box traffic is detected. • TCP connection attempts that are reset by the targeted server are not counted as a SYN attack or scanning threat. Basic Threat Detection This component monitors the rates that packets are dropped by the ASA for a number of reasons, such as ACL drop, Bad Packets, Connection Limits, ICMP attacks, etc. The rates at which packets are dropped is measured over a configured time period, called Average Rate Interval (ARI) which can be from 600 seconds to 30 days. If the number of events that occur within the ARI exceeds the configured rate threshold it is considered the event a threat. An aditional smaller time period is also monitored, call the burst rate interval (BRI). If the calculated value exceeds this threshold it is also considered an adttack. 6.1. Cisco Implementations 173 Grumpy Networkers Journal Documentation, Release 0.0.7 Basic threat detection is enabled by default on the ASA running versions 8.0(2) and later. When a threat is deteced, the ASA simply logs an event with ID ASA-4-733100 to alert the administrator. No action is taken to stop the offending traffic. Advanced Threat Detection Advanced Threat Detection enables the tracking of more granula objects. This tracking can be done for host IPs, ports, protocols, ACLs and servers protected by TCP intercept. By default it is only enabled for ACL statistics. Multiple time periods are tracked; 20 minutes, 1 hour, 8 hours and 24 hours. These time periods are not configurable but the number of periods that are tracked per obbject can be adjusted. When TCP intercept is configured, Threat Detection can keep track of the top 10 serers which considered to be under attack. Just like with Basic Threat Detection, the ASA only sends a syslog using IDs ASA-4-733104 and ASA-4-733105 which are triggered for average and burst rates respectively. No other action is taken. Advanced Threat Detection is also used by ASDM to generate the graphs on the firewall dashboard. Scanning Threat Detection Scanning Threat Detection build o the concept of Basic Threat Detection, making use of the same rate-interval, average rate (ARI) and burst rate (BRI) settings. The scanning detection however maintains a database of atttacker and target IP addresses that can provide more context around the hosts involved in the scan. Only traffic that is received by the target host/subnet is considered by this feature. Basic Threat Detection can still tricker if the traffic is dropped by an ACL. One of the benefits of scanning detection is that it can optionally react by shunning the attacker IP. This means that it is the only threat detection feature which can activelly afffect connections through the ASA. When an attack is detected, ASA-4-733101 is logged. If the shun feature is enabled, ASA-4-733102 is logged to alert he administrator. Configuration Basic Threat Detection To enable basic threat detection, use the command: threat-detection basic-threat A number of ‘rates’ can be viewed using the command: show run all threat-detection In order to reconfigure these rates, simply reconfigure the appropriate rate command accountingly such as: threat-detection rate acl-drop rate-interval 1200 average-rate 2500 burst-rate 550 174 Chapter 6. Vendor Implementations Grumpy Networkers Journal Documentation, Release 0.0.7 Advanced Threat Detection Use the below command to enable Advanced Threat Detection: threat-detecion statistics This setting is available for acccess-list, host, port, protocol and tcp-intercept. Custom rates can also be configured as wel Basic threat Detection. Scanning Threat Detection To enable Scanning Threat Detection: threat-detection scanning-threat As with Basic Threat detection the rates can be reconfigured using commands prefixed with: threat-detection rate scanning-threat .... To enable shunning of a suspect attacker and configure how long they should be shunned use: threat-detection scanning-threat shun duration IP addresses and object-group can be set as exceptions to shunning by specifying them as follows: threat-detection scanning-threat shun except ip-address Cisco ASA Troubleshooting Packet Captures The packet capture process is useful when you troubleshoot connectivity problems or monitor suspicious activity. In addition, you can create multiple captures in order to analyze different types of traffic on multiple interfaces. The packet capture feature can be used to capture packets as the enter an interface (Ingress) as well as when they leave (Egress). If both are runningit’s possible that duplicate packets may be captured as each capture on an interface occurs seperately. When performing captures on the Egress interface, it is important to take NAT into account. Default Settings The default type is raw-data. The default buffer size is 512 KB The default Ethernet type is IP packets. The default packet-length is 1,518 bytes (68 bytes for circular buffe) 6.1. Cisco Implementations 175 Grumpy Networkers Journal Documentation, Release 0.0.7 Running Packet Captures through ASDM Once logged into the ASDM GUI, the Packet Capture Wizard can be run from: Using the wizard it is possible to capture both source traffic (Ingress) and destination traffic (Egress). when specifying the packet match criteria it is important to take NAT into consideration. Both capture buffer size and packet size can be specified. At the end of the wizard, ASDM will send a temporary set of commands that will start the capture, possibly including an ACL. It is then possible to retrieve the captures through the GUI and also to save the capture as either a PCAP or ASCII file. Running Packet Captures through the CLI The capture command is used to run a packet capture from a CLI. Originally it was required for an ACL to be included along with the capture command. This is still supported but as of 7.2(1) it’s possible to use a simpler match statement. The ACL method is still preferred where more complex (such as multiple source/destination) captures are needed. To create a capture using a match statement use this syntax: capture Upto 3 match criteria can be specified per line To capture using an access-list use this syntax: capture The access-list must already exist Once the criteria has been set, specify the interface upon which the capture should be performed: capture Other options, such as buffer size and packet size are also available. It is also possible to capture packets that would normally be dropped. To do this specify a type of asp-drop. Other special types are available. Obtaining the captured packets through a Web Browser Once packets have been captured the file can be downloaded as either ASCII or PCAP using one of the following URLS: ASCII File https:// 176 Chapter 6. Vendor Implementations Grumpy Networkers Journal Documentation, Release 0.0.7 PCAP File https:// Further Information For more detailed information consult the Cisco configuration examples and tech notes [c1]. Cisco ASA Firewall Virtualisation Overview As of ASA version 7.0(1) it has been possible to make a single ASA device to act as multiple standalone firewalls. Each firewall behaves independently with its own configuration. It is possible to setup independent administrative access so one administrator can manage one context but not another one. Cisco called this individual firewalls Security Contexts for which there are 3 different types: • System Execution space (system context) • Admin context • One o more user contexts (customer contexts) System Execution Space The system context does not have any layer 2/3 interfaces or network settings. It is used purely for the purpose of managing other security contexts. The three most important settings for each context are: • Context Name • Location of the contexts startup configuration • Interface Allocation Other settings such as interface, NTP, Resource Management, failover and boot parameters are also configuered in the system context. It is possible to retrieve the configuration files for the security contexts via TFTP, FTP, HTTP or HTTPS. Admin context The admin contet provides connectivity to the network resources such as AAA and syslog servers. It is recommended that the management interface of the security appliance be on the admin context. If an administrator has access to the admin context, he can also jump to all the other security contexts. The admin context is used by the system context for any actions that require Layer 2 or Layer 3 functionality. Therefore the admin context must be created before you define any other contexts. When a firewall is changed from a single device to multiple contexts, the network related config is moved into the admin context. By default this context is name ‘admin’. 6.1. Cisco Implementations 177 Grumpy Networkers Journal Documentation, Release 0.0.7 Although the admin context acts just like a regular user context it is not recommended to do so due to the it’s importants to the overall system. User Context Each user context holds the specific configuration for that context. Such as: • IPS • Dynamic Routing (EIGRP and OSPFv3 as of 9.0.1) • Packet Filtering • NAT • Site-To-Site VPN (as of 9.0.1) • IPv6 • Device management Licensing Depending on the model of the device there is a maximum number of security contexts is limited. For example the 5510/5515-X supports up too 5 contexts where as the 5585-X with an SSP-20 supports upto 250 which is the maximum for all platforms. Note: The ASA 5505 does not support running any virtual firewalls. Implementation In order to identify which context the ASA needs to direct packets to it can use one of two methods: • Non-Shared Interface (Physical or Virtual) • Shared Interface With the shared interface method, if a non-unique MAC address is used (i.e one shared across all contexts) then NAT rules must be setup on each security context so that the ASA can learn about the subnets located behind each context. It is recommended that in a shared interface environment that either a MAC address is assigned manually to each context or the system is allowed to automatically generate a system MAC when the context is created (Default in 8.5.1 and above). Resource Management To prevent one firewall from consuming all resources on the system it is possible to limit each contexts use of the following: • Number of concurrent address translations (xlates) • Number of concurrent connections • Number of concurrent hosts • Inspection rate 178 Chapter 6. Vendor Implementations Grumpy Networkers Journal Documentation, Release 0.0.7 • Conn Rate • Syslog Rate • Telnet, ASDM and SSH Management Systems • Routes • MAC Addresses (Tranparent mode) By default no limits are imposed on the contexts. It is also possible to oversubscribe the available resources. Resource Management is configure through a Resource Class Configuration Steps 1. Change to Multiple Mode 2. Setup the system space 3. Configure Interfaces 4. Specify configuration URL 5. Configure Admin context 6. Configure User context 7. Manage the security contexts (optional) 8. Setup Resource Management (optional) Change to Multiple Mode mode multiple When entered the ASA will prompt to reload the device. After the reboot the mode can be configured by: show mode Setup System space The original management address will be moved to the admin context an this is where the administator starts after logging in. To ensure the system context use: changeto system Monitoring and troubleshooting The following commands can be used to assist with troubleshooting any issues: show mode show context show admin-context (continues on next page) 6.1. Cisco Implementations 179 Grumpy Networkers Journal Documentation, Release 0.0.7 (continued from previous page) show cpu usage context all show asp drop Cisco IOS Firewall Overview The Cisco IOS firewall offers basic stateless firewall features. This type of firewall should be used only as a last resort where no other options are available. Limited tracking of established connections is available to avoid having to specifically allow all inbound traffic. The functional components of the IOS firewall are: • ACL specifying the traffic to allow or deny • Internet to ACL binding via an access group The same set of commands is available for IPV6 but instead of ip use ipv6 as the prefix. Implementation Steps Necessary 1. Create any object groups necessary 2. Define the Access Control List that meets the security requirements 3. Bind the Access Control List to the relevant interface, inbound and/or outbound. Create Object Groups Object groups can be either for specifying groups of IP addresses (subnets or hosts) and/or for specifying groups of service ports. Note: This feature is available since IOS 12.4(20)T object-group network It is also possible to nest groups within another group. The group must exist before being included in another one: object-group network 180 Chapter 6. Vendor Implementations Grumpy Networkers Journal Documentation, Release 0.0.7 Define the ACL The ACL is where all the source/destination IPs and port numbers are combined so that the policy can be defined. Prior to IOS 12.4 it was necessary to recreate the entire ACL when any edits needed to be made other than at the end, this was done through the access-list command. Since 12.4 however the “ip access-list” command is preferred as it allows line numbers to be specified so rules can be inserted anywhere there is a gap in the numbering. It is recommended to leave gaps (e.g. in intervals fo 10) to allow for further changes. Here is example of the pre-12.4 way of implementing an ACL: access-list ˓→mask> And the newer style post-12.4: ip access-list extended ˓→mask> [eq For TCP based connections the established keyword can also be specified to permit established connections back through the firewall. It is also possible to renumber the ACL using the following command: ip access-list resequence Bind the ACL to an interface Once created the ACL must be bound to the appropriate interface. This can be done either inbound or outbound: Warning: When applying ACL to the interface through which the device is being monitored, it is important that the management traffic also be permitted otherwise the session will be disconnected. interface Verifying The following commands can be used to verify the status of an access list: To see the hits against the various rules use: show access-list To see what access list is bound to a specific interface use: show ip interface 6.1. Cisco Implementations 181 Grumpy Networkers Journal Documentation, Release 0.0.7 Troubleshooting If you need to verify what packets are being denied or allowed, it is possible to log the packets being matched by using the log argument on the individual ACE. Note that this does put additional burden on the device so should not be done for long periods of time. Cisco Zone Based Firewall Overview Cisco Zone-based Firewall or ZBFW for short is an updated means of providing firewall features in a WAN environ- ment. The benefits of ZBFW over the Legacy IOS Firewall (known as Context-Based Access Control or CBAC) include: • Stateful Packet Inspection (no more need for established keyword) • VRF-aware • URL filtering (basic) • Denial-Of-Service (DoS) mitigation • Application Inspection Note: Initial zone based firewall features were added in 12.4(6)T with the newer application inspection added in 12.4(9)T A number of IOS Firewall features are however not supported: • Authentication Proxy • Statefull Firewall Failover • Unified Firewall MIB • IPv6 Stateful Inspection • TCP out-of-order support Note: The above limitations is correct up to 12.4(15)T Implementation In order to implement ZBFW it is necessary to understand where the security boundaries (zones) exist as far as the router interfaces are concerned. Each interface can only be in a single zone however by default, all interfaces in the same zone can communicate. Note: Unlike with the Legacy IOS CBAC Firewall, applying filtering to the interface through which the device is being monitored, will not result in a loss of connectivity. A pre-defined zone called self exists on the router and traffic to this must be explicitly denied in order for traffic to the router to be blocked, this is the opposite of transit traffic through the router. 182 Chapter 6. Vendor Implementations Grumpy Networkers Journal Documentation, Release 0.0.7 Configuration Steps 1. Define matching rules for policy traffic (class-map) 2. Apply actions to policy traffic (policy-map) 3. Define zones (zone) 4. Define zone pairs (zone-pair) 5. Assign interfaces to zones (zone-member) Define matching rules for policy traffic ZBFW uses the same command set as also used with QoS, namely the Modular QoS CLI. It is composed a number of commands that allow traffic to matched either by an access-list or known protocol (such as TCP or HTTP). This class-maps are used for application inspection. For example: class-map type inspect [match-any | match-all] If the protocol is known then the state of the connections will be tracked. Apply Actions to policy traffic Once the traffic that needs to be either permitted or denied is known, it is necessary to apply the action to it. The action can either be: • Drop - Traffic is denied • Pass - Allow traffic but do not track the state of the connection • Inspect - Allow traffic and provide stateful firewall tracking to the connection The policy is applied as follows: policy-map type inspect ! Specify the traffic class(es) created in the previous step class type inspect Define Zones A zone defines a area of the network which has a different security requirement that other zones. For example a router may be configured with a trusted, untrusted and DMZ zone. A zone is created as follows, all zones must have unique names: zone security 6.1. Cisco Implementations 183 Grumpy Networkers Journal Documentation, Release 0.0.7 Define zone Pairs A pair of zones defines a location where policy must be implement, if traffic is to be allowed to be initiated in both directions two zone pairs are needed for example (trust-to-untrust, untrust-to-trust). Because of the stateful nature of ZBFW it is not necessary to define rules for the return traffic of a connection already allowed in the opposite direction. zone-pair security Assign zones to interfaces The last step is to put the interfaces in the appropriate zone: interface Verification To see what interfaces are in a given (or all zones): show zone security [ To see the policy attached to a given zone or zone-pair: show zone-pair security [source To see the statistics for a specific zone pair, use the following command: 6.1.2 Cisco Network Managmement Features Cisco Security Manager (CSM) Overview CSM is a management tool that enables more complex environments to efficiently manage their security infrastructure. It helps to ensure consiste policy enforcement and rapid troubleshooting of security events with in-built reporting capabilities across the security deployment. This is achevied by enabling reuse of security rules and objects to monitor security threats and minimizae potential errors. Integrated end-to-end tools are used to facilitate the consistent enforcement of policy and to aid in rapid troubleshooting. Security events from multiple devices are consolidated to help enable viewinng of real-tme and historical events. Along with the included features, CSM can also integrate into Cisco Talos for further insight into potential threats. Depending on the version purchase CSM can support a wide range of devices, such as: • Cisco ASA 5500 and 5500-X • IPS 4200, 4300 and 4500 • Cisco SR 500 Secure Routers 184 Chapter 6. Vendor Implementations Grumpy Networkers Journal Documentation, Release 0.0.7 • Cisco AnyConnect Secure Mobility Client • Cisco FirePower 4100 series (in CSM 4.11 and above) CSM is based on a client/server module, the users access to the server database via a software program installed on their workstation. Some of the tools available to the administrator are: • Configuration Manager • Event Viewer • Report Manager • Software Image Upgrade Wizad A managers dashboard is available via a web based interfaces which gives a birdseye view of the health, functioning and other major performance indicators of the network security infrastructure. An API-Based interface is also available to assist with interating into other network services such as Compliance and security analysis sytems. CSM can be deployed in a high-availabity setup either for local HA or Disaster Recovery. This solution is based on the Symantec Veritas Storage Foundation and High Availability Solutions. Note that direct access to PRSM from Security Manager using SSO is only supported in HA mode. Features The following general features available: • Policy and Object Management • Event Management • Reporting and Troubleshooting • Image Management • Health and Performance Monitoring (HPM) • API Access For ASA series devices CSM provides centralised management for features such as Botnet Traffic Filter, Clusterig, syslog forwarding. Support for the AIP modules is also included. Integration with Cisco Prime Security Manager (PRSM) is also included when an ASA-CX device is detected. For IOS devices, zone-based firewall, TrustSec, content filtering and VPN (GETVPN, DMVPN, GRE and IPSec) technologies is included. Versions and Licensing As of June 2017 the latest available release of CSM is 4.14 It is a available in 3 different versions (Standard, Professional and the UCS server bundle). The standard version is intended to manage less than 25 devices and supports the most common devices found in a small-to-medium enterprise such as ASA 5500 Firewalls, IPS 4200/4300, AnyConnect client as well as ISR G1 & G2 routers. It does not hower support higher-end devices such as service modules or modular devices. The number of devices supported is fixed at time of purchase (beween 5 and 25 devices) The Professional Version is aimed at medium to large deployments (50 to Hundreds of devices). It supports all the features of the standard vesion as well as support for service modules (ASASM and FWSM) as well as higher ends 6.1. Cisco Implementations 185 Grumpy Networkers Journal Documentation, Release 0.0.7 devices (6500 switches and 7600 routers). The Northbound API is also included. Initial licenses can be purchase as 50, 100 and 250 with additional incremental licenses available the same size blocks. Both of the above versions require an available hardware platform that is running at least Windows Server 2008 Enterprise R2 with a recommended 16GB of RAM, 4-core CPU and 500GB HDD. The final version is the UCS server bundle (UCS C220 M3). It provides all the same features as Professional with the ability to manage 50 to 150 devices (although additional licens can be purchased in same size blocks as professional). The key difference between Professional and UCS is that hardware is provided as part of the purchase with UCS, Professional is just the licensed software. The licenses are permitted onl to be used on a single server. However if a standby service is made available to support High Availability, a seperate license is not required if only one server is used at a time. The Administrator is responsbiel for manually restoring the database from the active to the standby server on a regular basis. Where a firewall is operating in multiple context mode, each context will consume a device license in addition to the parent device. Any devices that exist in CSM but are not selected for “Manage in Cisco Security Manager” do not consume a device liense. The same is true for any devices added to the topology map but that do not appear in the device invventory. Server System Requirements For CSM versions upto 4.8, the server must be running a supported operating system, currently: * Windows Server 2008 R2 SP1 Enterprise 64-Bit (CSM 4.7 and below) * Windows Server 2012 Standard/Datacente 64-bit For CSM versions 4.9 and above: * Windows Server 2012 Standard/Datacentre (R1 an R2) 64-bit * Windows Server 2016 Standard/Datacentre 64-bit The system should have a Quadcore Xeon 5R6500 series or abbove. In order to run will all features 16GB of RAM is needed. Services such as Event Management and Report Management are affected if less memory is detected. When less than 8GB of RAM is available the Event Management and Report Manager are automatically disabled. Be- tween 8 and 12GB the two services listed can be turned off manually through the “Tools” section of the Configuration Manager A minimum of 100GB operating system Partition is recommended. 150GB is recommended for the application parti- tion with 7GB being the minimum required. Seperate OS and applications are recommended Client system Requirements The client must have a CPU with minimum of 2GHzand be running Windows 7 , 8, 10 or Windows Server 2012 as a minimum. A minimum of 2GB of RAM is required for 32-bit systems, 4GB for 64-bit. 10GB free disk space is required. The client must have a supported Web Browser (IE 8-11, Firefox 15 and above) Java is not required to e installed seperately as the Security Manager client includes an embedded version of Java. The logged in user account is recommended to have full administrator privileges. This is the only supported user account by Cisco. 186 Chapter 6. Vendor Implementations Grumpy Networkers Journal Documentation, Release 0.0.7 Client to Server Communications In order for the Client to communicate with the server TCP ports 443 (HTTPS) / 1741 (HTTP) must be open between the Client and Server. The client must also be running the same version of the software as the server. A prompt will appear requesting to download the update if there is a mismatch. Device Management ASA The CSM server uses the same interface as ASDM in order to commmunicate with the firewall, therefore TCP 443 (HTTPS) is required to be open. Other Devices Most other network devices can be connected to using the standard management services HTTPS (TCP 443), SSH (TCP 22), Telnet (TCP 23) Configuration Rollback TFTP is used to transfer the configuration therefore UDP 69 needs to be open to/from the CSM server to the device. ACS If CSM is integrating with ACS, TCP 2002 should be open Managing Users After then initial installation only ‘admin’ account exists. This account can be used add additional acccounts of the following types: • Local Account • ACS Account • Non-ACS Account CSM provides a number of pre-defined roles which determines the permissions for the the user in question: • System Admin • Security Admin • Security Approver • Network Admin • Approver • Network Operator • Helpdesk 6.1. Cisco Implementations 187 Grumpy Networkers Journal Documentation, Release 0.0.7 External References Cisco Security Manager 4.14 Product Overview http://www.cisco.com/c/en/us/support/security/security-manager-4-14/model.html Cisco Security Manager 4.14 User Guide http://www.cisco.com/c/en/us/td/docs/security/security_management/cisco_security_manager/security_manager/414/ user/guide/CSMUserGuide.html Cisco Security Manager 4.14 Installation Guide http://www.cisco.com/c/en/us/td/docs/security/security_management/cisco_security_manager/security_manager/414/ installation/guide/IG.html Cisco Prime Security Manager (PRSM) Overview Note: Cisco Prime Security Manager is no longer a current Cisco product and along with the ASA-CX module has been replaced by Cisco FirePower and the Cisco FirePower Management Console (FMC). It should also not be confused with Cisco Prime Infrastructure (PI) which is still a current product. PRSM provides a centralised, simple and scaleable tool to manage Cisco ASA 5500-X appliances and ASA-CX modules. It provides context-aware capabilities for Application Visibility and Control (AVC), Web Security Essentials (WSE) and Intrusion Prevention Systems (IPS). Available as both a built-in user interface (ASA-CX module) as well as standalone server (Physicl Appliance or ESXi VM) it provides for both single and multi-device management with a consistent administration experience. Features • Network Visibiliy • Granular Application, User and Device Control • Flexibility Management Architecture Versions and Licensing Prime Security Manager is only available in one version but can be purchased as either a Software Virtual Appliance or Physical Appliance. Both form factors can be be initial purchased with licensing for managing 5,10,25,50 and 100 devices. After tis initial purchased further management licenses can be managed in he same size blocks. The latest and last version of PRSM available is 9.3 System Requirements 188 Chapter 6. Vendor Implementations Grumpy Networkers Journal Documentation, Release 0.0.7 Inventory Management • Health Monitor Managing Upgrades Reporting • Traffic Summary • Applications • Users • Endpoint • URL • Device • Threats Flexible Management Architecture A consistent management interface is provided regardless of if a single device or multiple devices are being managed. When managing multiple devices all accces requests are redirected to the primary manager to ensure efficient, cen- tralised control. When migrating from the management of a single device to multiple devices existing network definitions can be imported from other ASA security devices and used to contruct new policy rules. After migration to multi-device mode, policies can be shared across multiple firewalls again ensuring consistent policy enforcement. Limited configuration is available in order to manage the ASA itself through Firewall NAT and events. Commands can also be previewed prior to deployment. ASA-CX Failover The ASA-CX modules do not exchange configuration or onnection state information with their peer. Failover must be configured independently of the parent ASA. PRSM Multiple Device Mode can be used in order for the configuration to be kept in sync but does not allow connection state information to be communicated. When a failover event occurs the newly active ASA will only redirect new connections through the CX services. Existing connections will not be redirected. Managing ASA-CX in Multiple Device Mode In order to manage the ASA-CX in PRSM Multiple-Device Mode the CX module needs to be put in Managed Mode. Once this is done you cannot configure the CX module through it’s web interface, all configuration and monitoring must be done via the PRSM interface. The CLI is still available for troubleshootting and basic configuration (IP addressing, DNS, NTP and passwords). 6.1. Cisco Implementations 189 Grumpy Networkers Journal Documentation, Release 0.0.7 If an ASA that contains a CX is added to the Inventory of PRSM the CX module will also be addeded. The device is placed in managed mode once changes are committed. Features of Managed Mode • Unified Monitoring of multiple devices • Shared Objects and Policies • Universal Policies (9.2+) to ensure consistent top an bottom-evel policy enforcement • Deployment Manager for scheduled configuration deployment • Centralised License Management • CX Failover Support to ensure configuration parity • ASA Management limited prior to 9.2 but now includes unified object, interfaces, ACLs, NAT, logging and failover suppot. Implications of Managed Mode • All discovered policy elements are added to the PRSM database. For anything that is not discovered (e.g. Signatue Updates and Network Particiption), the settings are replaced with the settings currently defined in the PRSM database. • A CX device can only be managed by a single PRSM server and maintains awareness of which server it is being managed by. • Events from the CX device are forwarded autoamtically to the PRSM server • PRSM automatically collects database data from all managed devices • The CX device’s web interface will indicate that the device is in Managed Mode along with a lin to the PRSM server that is managing the device. • PRSM uses SSL (HTTPS) in order to communicate with the ASA, the HTTP server must therefore be enabled so that PRSM can connect to it. It must use an IPv4, not IPv6 for management. • PRSM can only manage an ASA in single-context routed or transparent-mode. If the ASA is configuredi in multiple-context mode the CX module can still be managed. • Active/Standby failover on the ASA is supported, Active/Active is not. • ASA CX in monitor-only mode is not supported Cisco Prime Infrastructure (PI) Overview Note: Cisco Prime Infrastructure should not be confused with Cisco Prime Security Manager (PRSM). PRSM was both a built-in tool and standalone server used to manage the EOL’d Cisco ASA-CX Module which has now been replaced by Cisco Firepower and it’s manageable tool, the FireSight Management Centre (FMC). Prime Infrastructure is Cisco’s vision for “One Management, One Assurance and One Network”. 190 Chapter 6. Vendor Implementations Grumpy Networkers Journal Documentation, Release 0.0.7 It is said to provide a comprehensive solution to manage, visualise and monitor thhe network from a single graphical interface. It provides the following general features: • Lifecycle Management • Assurance Visibility • Troubleshooting capabilities network wide It can integrate with other tools such as: • Cisco Identity Services Engine (ISE) • Cisco Mobility Services Engine (MSE) • Cisco ClearAir New versions include even more features suh as the Configuration Compliance Engine which enables operators to provide the baseline configuration upon which to audit the network devices and the configurations stored in the archive. This helps identify devices that are out of compliance for EoL/EoS monitoring other compliance frameworks, such as PCI or HIPAA. Features • Single-pane-of-glass management • Simplified deployment of Cisco capabilities • Deep Application Visibility • Comprehensive coverage of enterprise mobility • Unified assurance across network and computer • Centralised Visibility of distrubted networks As of version 3.0, PI includes: • Platform Enhancements • Wireless Management • Routing IWAN Management • Data Centre Management • APIC-EM Integration Workflow Lifecycle Don’t Disregard Others Right Away - Memorable Phase 6.1. Cisco Implementations 191 Grumpy Networkers Journal Documentation, Release 0.0.7 • Design - Assess, plan, and create configurations required to roll out new network services and technologies. Create templates used for monitoring key network resources, devices, and attributes. Default templates and best practice designs are provided for quick out-of-the-box implementation automating the work required to use Cisco validated designs and best practices. • Deploy - Schedule the rollout and implementation of network changes. Changes may include published tem- plates created in the design phase, software image updates, and support for user-initiated ad hoc changes and compliance updates. This accelerates service rollout, minimizes chances for errors, and is highly scalable. • Operate - Predefined dashboards provide up-to-date status monitoring on the overall health of the network. Simple one-click workflows and 360-degree device views enhance troubleshooting and reduce the time to re- solve network issues. Unified alarm displays with detailed forensics provide actionable information and the ability to automatically open service requests with the Cisco Technical Assistance Center (TAC). • Report - Provides a wide variety of predefined reports for up-to-date information on the network including detailed inventory, configuration, compliance, audit, capacity, end-of-sale, security vulnerabilities, and many more. • Administer - Provides an easy-to-use set of workflows that help to maintain the health of the application and keep devices, users, and the software up to date, allowing the IT staff to focus on other important activities. Versions As of June 2017, Prime Infrastructure 3.1 is the latest version. Prime Infrastructure is available as a Virtual or Physical appliance in the following versions: • Express (Upto 500 devices) • Express-Plus (Upto 3000 devices) • Standard (Upto 10000 devices) • Professional (Upto 14000 devices) • Hardware Appliance Gen 2 (Upto 24000 devices) 192 Chapter 6. Vendor Implementations Grumpy Networkers Journal Documentation, Release 0.0.7 Licensing Licensing for Prime Infratructure is divided into base license and corresponding features licenses. The maximum number of license files that can be added is 25. When performing a first time installation, the lifecycle and assurance features are accessible using a built-in evaluation license which is valid for 60 days and 100 devices. Six types of licenses are available: • Base (Required) • Lifecycle (Total number of devices under Prime Infrastructure Management) • Assurance (Total Number of NetFlow devices under management). Also requires a Lifecycle license. • Collector (Total Number of NetFlow data flows per second that can be processed). Also requires an Assurance license. • Data Centre (Number of Blade Servers being managed by UCS devices, not including Nexus switches or MDS devices) • Data Centre Hypervisor (Total number of hosts on VCentre being managed) Lifecycle, Assurance and Data Centre are available for both evaluation and permenant licensing. All others do not have an explicit evaluation version. An additional licensed feature is for Prime Infrastructure Operations Centre which enables support for managing multiple instance of PI from a single instance. A maximum of 10 managed instances is supported. System Requirements Managing Upgrades Prime Infrastructure provides facilities to assist with planning, scheduling and downloding and monitoring the software image updates. The images are stored on the Prime infrastructure acording to the image type and version. In order manage software images the devices must be cofigured with Telnet/SSH credentials as well as SNMP read- write community strings. Note that only SFTP, SCP and FTP are supported for image distribution. TFTP is not supported. Prime can also import the software images from the devies. The same protocols as above as wwell as TFTP are supported, SFTP or SCP is recommended. Software Images are managed via the Inventory under: Inventory → Device Management → Software Images Prime supports the Cisco devices below for distribution and activation using the Software Image Management Server: • WLC • Nexus 3K, 5K, 7K, 9K • Cat 4K, 6K, 5760, 3750, 2960 • Catalyst 3650/3850 • ASR 9K • ISR 1841, 1900, 2800, 2951, 3825, 3845, 890 6.1. Cisco Implementations 193 Grumpy Networkers Journal Documentation, Release 0.0.7 • ME 3800 • IE 4000 • ASR 1000 Prior to performing upgrade, Prime Infrastructure can run a report to help determine the prerequisites for new software image deplyment. This will provide information on if the device has sufficent, RAM, Flash storage as well as if the image is suitabble for the device. To run this report go to the same menu item as above and select Upgrade Analysis. 6.1.3 Cisco Switching Features Cisco Defenses against common Layer 2 Attacks • Spanning Tree Attack • Root Guard • BPDU-Guard • Layer-2 PDU Rate Limiter • VTP Attacks • MAC Flooding – Port Security • MAC Spoofing – Port Security – DAI • DHCP Attacks – Port Security – DHCP Snooping • ARP Exploits – DAI • IPv6 Exploits * Secure ND Cisco PortFast Overview The Cisco PortFast feature is not directly intended for security but as it is referenced by a number of the other features, a description of its operation is important. When Spanning-Tree runs a port has to transition through a number of states before being able to transmit or receive traffic. This can cause problems for end-user devices as whilst this negotiation is running it’s possible for the device to assume it’s not connected to a network and make alternative decisions. Some of the problems that can occur: • Failure to receive DHCP addresses • Failure to receive response from Windows Domain Controller leading to local logins 194 Chapter 6. Vendor Implementations Grumpy Networkers Journal Documentation, Release 0.0.7 • Failure to detect trusted network, resulting in the device putting itself in a locked down state. Whilst the above problems are not caused by any fault in the network and can often be fixed by adjusting various timers and so forth in the operating system of the end user device, the blame useful falls on the network team and it is up to them to resolve the issue. Cisco thankfully came up with a solution to this in the name of PortFast. PortFast works by skipping the Listening and Learning States when a port is plugged in to a device, immediately transitioning it to the Forwarding state. This could sound risky as if no learning has taken place, how can a loop be detected. The good news is that the switch is smart and continues to listen for BPDUs on the PortFast enabled port. As soon as a BPDU is seen on the port it immediately looses it’s PortFast status and has to transition through all the spanning-tree port states. An additional benefit to PortFast is than when enabled, if the port changes state (such as users unplugging their devices) it does not cause a Topology Change Notification (TCN). This helps to avoid constant STP recalcuations and therefore gives a more stable topology. In a stable network, the number of topology changes recorded per VLAN should be minimal so a large increase should be cause for investigation and not end up being just because of users going about their normal business. By default only Access ports can be configured with PortFast but through an additional option, trunk ports can be made PortFast as well. This is useful where a non-user device exists and needs to transition quickly. In the case of the new Virtualised Infrastructure it is very useful as often a VM Host will be configured to use multiple VLANs and therefore needs to be a trunk port. Care must be taken however that a loop is not caused on the virtualisation switching layer as many of those virtual switches do not fully implement the Spanning Tree Protocol. Implementation PortFast can be enabled globally on all access ports using: spanning-tree portfast default It can also be enabled on a per-port basis as follows: interface Verification show interface switchport Troubleshooting Because a port automatically transitions into a non-portfast state when BPDUs are detected, no action should usually be detected. The most likely issue is where PortFast is not enabled and users are complaining about a lack of network access (such as failure to receive a DHCP address due to it timing out). Cisco Root Guard 6.1. Cisco Implementations 195 Grumpy Networkers Journal Documentation, Release 0.0.7 Overview In standard Spanning Tree there is no means by which to securely enforce the switched Layer 2 Topology. When spanning tree calculates the topology of the network it is based on the location of the root bridge and any switch with the lowest bridge ID will traditionally take on this role. Without some additional controls the administrator cannot enforce the position of the root bridge. Cisco has added an enhancement called Root Guard to the Spanning Tree Protocol which gives administrators a means by which to say where the root bridge is expected to be. This feature ensures that the port on which root guard is enabled is the designated port. Normally root bridge ports are all designated ports. The feature works by detecting superior STP BPDUs on a root guard-enabled port. When such a BPDU is detected the port upon which the BPDU is seen is put in the root-inconsistent state and not allowed to communicate any further on the network. This feature is useful for protecting against a rogue switch being deployed on the network and attempting to become the root bridge. If such a switch is connected to a port of a switch under the administrators control and it has root guard enabled, the port will be put back in the listening state effectively preventing it communicating its BPDUs onto the network. Once the port with Root Guard enabled stops receiving BPDUs, it will unblock the port. No manual intervention is required. Each time the port is blocked a syslog entry will be logged so that monitoring and alerting systems can detect the event: %SPANTREE-2-ROOTGUARDBLOCK: Implementation Root Guard is enabled on a per port basis and should be configured on all ports where superior BPDUs are not expected to be seen. An example of this would be all the ports where end user devices are connected and those that connect to unmanaged/3rd party switches. It can be imagined as setting up a perimeter around the network where the STP root should be located. It should be obvious however to be clear, do not configured Root Guard on the ports facing the root bridge. Enabling the feature is a simple one line command that needs to be applied to all ports where the root bridge will not be seen: interface When implementing care must be taken to ensure a proper understanding of the network topology. This becomes more difficult when two potential root bridges are used for high availability (such as dual Cisco 3750 stacks or a pair of Cisco 6500 switches). A well designed network topologies that follow best practice (such as the Hierarchical Switch Design from Cisco) can make it easier to identify where Root Guard should be deployed. In a basic sense ensure that the root BPDUs never have to traverse a non-managed switch or user enabled port. Ports between Access, Distribution and Core devices switches should be the only places where Root Guard is not deployed unless there is good reason not to. Verification Troubleshooting The status of a port can be determined by: 196 Chapter 6. Vendor Implementations Grumpy Networkers Journal Documentation, Release 0.0.7 show spanning-tree vlan Any ports that have been blocked by Root Guard will show as ‘ROOT_Inc’ External Reference Cisco - Spanning Tree Protocol Root Guard Enhancement http://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/10588-74.html Roger Perkin - Spanning Tree Root Guard http://www.rogerperkin.co.uk/spanning-tree/spanning-tree-root-guard/ Cisco BPDU Guard and Filter Overview It a badly managed network a device capable of sending BPDUs can be plugged in pretty much anywhere. This can cause issues for the network administrator trying to maintain a stable environment for there users, especially when it could be the users causing problems for themselves. It is not uncommon for users to need more than the single wall port that the IT team has provisioned for them. This kind of problem is even more prevelant in the engineering and scientific work place where users often need to have network access for more than one device. The impatient user or helpful IT desktop support team member often solves this problem by plugging in a cheap (most likely unmanaged) hub or switch into the port. The users problem is now solved as he can plug in any many devices as the “rogue” switch has available. The problem with this is that if the switches in the network (including those managed by the IT team) are deployed with default configurations, they most likely will have a default Bridge Priority this could be the same as the rogue switch and results in sub-optimal network topologies where the root bridge is seen through a low bandwidth port or device. Another issue is that some cheap hubs (and switches) don’t correctly implement the spanning tree protocol and can cause loops in the network where more than one cable from the rogue device is connected to the managed network via two seperate cables. In practice either the managed switch or the rogue switch should disable one of its ports to prevent the loop but this doesn’t always happen (and hubs don’t even know how). BPDU Guard Cisco has created an enhacement to deal with the first issue known as BPDU Guard. A second feature know as Loop Guard which helps deal with the second issue will be discussed seperately. Unlike with Root Guard, the BPDU Guard features don’t given any consideration to the values in the BPDU. If any BPDU is seen on a port with BPDU Guard enabled, it is immediately put into the errdisable state. When this occurs a syslog message is logged to alert the network team: %SPANTREE-2-RX_PORTFAST:Received BPDU on PortFast enable port. Disabling 6.1. Cisco Implementations 197 Grumpy Networkers Journal Documentation, Release 0.0.7 BPDU Filter A companion or alternative feature to BPDU Guard is to use BPDU Filter. Unlike BPDU Guard, the BPDU Filter does not shut the port down instead it simply prevents the port from sending or receiving BPDUs. If a BPDU is received on PortFast enabled interface the interfaces loses it’s PortFast status and BPDU filtering is disabled. It should be noted that enabling this feature effectively disables spanning-tree on the port and therefore could result in loops in the network topology. BPDU Filter can be useful in preventing BPDUs from going beyond the managed network. Some known attacks exploit receiving BPDUs and deliberately setting their Priority lower than the root bridge. In general it is recommended to deploy BPDU Guard and not BPDU Filter as it leads to a more controlled and predicatable network topology. Implementation BPDU Guard is deployed alongside PortFast. This is useful as it is assumed that any port which has PortFast enabled should generally be an end user device, not a switch so if a user were to plug a switch into the port it is correct that the port should be disabled and the network team notified so they can take corrective action. To enable BPDU Guard/Filter on all ports that have PortFast enabled, use the following command: ! Use or or the other, not both spanning-tree portfast bpduguard default spanning-tree portfast bpdufilter default At the port level BPDU Guard/Filter can be enabled individually: interface ! Use one not both of these options spanning-tree bpduguard enable spanning-tree bpdufilter enable If it is preferred to have the port return to an operational state without the network teams intervention, a recovery interval can be configured with: errdisable recovery cause bpduguard errdisable recovery interval If the interval is not specified it defaults to 300 seconds (5 minutes). Verification To confirm if BPDU Guard has been enabled, use this command: show spanning-tree summary totals Cisco Loop Guard 198 Chapter 6. Vendor Implementations Grumpy Networkers Journal Documentation, Release 0.0.7 Overview Spanning Tree is used to resolve a loop-free network topology where there may be multiple redudant links. It does this by forming a tree-like struction and removes/disables sub-optimal branches so that the structure is loop-free. It does this by sending out BPDUs and waiting for other switches to send their own BPDUs. After a certain time period the Root Bridge is selected based on the preferred (lowest Bridge Priority or Bridge ID in a tie). All subsequent calcuations are based of the location of the root bridge in the network. The problem with this is that some loops may not be detected if BPDUs are not received through certain ports. For example due to hardware (such as faulty cables) or software (buggy software), some devices (such as Hubs) do not even process BPDUs so will blindly send them on to other devices or via another port on the same device. Cisco developered a feature known as LoopGuard which is intended to assist with this issue. LoopGuard takes additional steps to ensure that BPDU are being received from other devices when it is enabled on non-designated ports. If BPDUs are not received on the port LoopGuard assumes there is a problem and puts the port into a loop-inconsistent state. This may seem counter productive but if a port is a designated port it should be sending BPDUs so the lack of them indicates an issue. When a port is put into the loop-inconsistent state, a syslog message will be generated: %SPANTREE-2-LOOPGUARD_BLOCK: Loop guard blocking port Interoperability with Other Switch Security Features Root Guard Loop Guard and Root Guard cannot be deployed together. This makes sense as Root Guard is deployed on Designated Ports where as Loop Guard works on Non-Designated Ports. If Loop Guard is configured, Root Guard is automaticaly disabled on the Port. PortFast / BPDU Guard LoopGuard cannot be enabled on ports with BPDUGuard. It should also be noted that LoopGuard cannot be enabled on dynamic VLAN ports. Uplink Fast / Backbone Fast Uplink and Backbone Fast are transparent to LoopGuard so they do not trigger LoopGuard in any way. LoopGuard and UDLD LoopGuard shares much of its functionality with another feature known as Uni-Directional Link Detection (UDLD) however whilst LoopGuard is intended to defend against STP Loops UDLD is a more general feature to defend against a number of hardware (e.g. wiring errors) issues. The changes of a uni-directional link are considered more likely than that of an STP issue and UDLD also provides benefits where EtherChannel is used as only a single interface would be disabled, not the entire EtherChannel. LoopGuard and UDLD can be enabled together. 6.1. Cisco Implementations 199 Grumpy Networkers Journal Documentation, Release 0.0.7 Implementation Originally Loop Guard could only be enabled on a per-port basis, now it is supported to be enabled globally. If this is done it will be enabled on all point-to-point links (all ports that are full-duplex). To enable globally use the following command: spanning-tree loopguard default To enable per-interface use: interface Verifying To verify if Loop Guard is enabled use: show spanning-tree summary Troubleshooting When a port is put into the loop-inconsistent state, a syslog message will be generated: %SPANTREE-2-LOOPGUARD_BLOCK: Loop guard blocking port Cisco DHCP Snooping Overview One of the problems that exists on all networks is how to ensure that a DHCP reply has indeed come from an approved DHCP server, this helps defeat Man In The Middle attacks. Outside of the security realm it can also assist with prevent- ing users being able to plug that random router they found at home into the network and use it as a switch. . . forgetting that it was also running a DHCP server for their old broadband connection. DHCP snooping works by tracking the communications between the end-user device and the the DHCP server. Any responses from untrusted DHCP servers are dropped. Sources of DHCP information are defined as either Trusted or Untrusted. This is done on port level. A port where DHCP replies should be seen, such as the uplink to a server switch or access port connected to the DHCP should be marked as Trusted. All user access ports should be marked as untrusted. Because the default trust state of all interfaces is untrusted, all trusted ports must be manually configured. The DHCP Snooping feature maintains a binding database, it contains an entry for each untrusted host with a leased IP address if the host is associated with a VLAN that has DHCP snooping enabled. It will not contain entries for hosts connected through trusted interfaces. The binding maintains the MAC address of the host and leased IP address and the bindings is maintained until the lease expires or the switch sees a DHCPRELEASE message from the host. The switch will forward the packet unless any of the following conditions match for packets on an untrusted interface where the assigned VLAN has DHCP snooping enabled: 200 Chapter 6. Vendor Implementations Grumpy Networkers Journal Documentation, Release 0.0.7 • The switch receives a DHCP packet from a DHCP server outside the network • A packet is received on an untrusted interface where the source MAC and DHCP client hardware address do not match (only if MAC address verfication is enabled). • The switch receives a DHCPRELEASE or DHCPDECLINE from an untrusted host with an entry in the DHCP snooping binding table and the information in the table does not match the interface on which the message received. • The switch receives a DHCP packet that includes a relay agent IP which is not 0.0.0.0 An optional feature that can be enabled is MAC Address Verification. This feature verifies that the source MAC address and the client hardware address in the DHCP packets on untrusted ports match. A number of other features (such as DAI) can make use of the DHCP snooping database in order to secure the network further. Features • DHCP Snooping disabled by default on all VLANs • MAC Address Verification enabled by default • Relay Agent disabled by default • Information Option (Option 82) enabled by default on IOS (disabled on NX-OS) • All interfaces untrusted by default • Host Tracking is disabled by default Implementation The following represents a minimal configuration with the following steps: 1. Ensure the DHCP server is operational 2. Ensure that the DHCP server is connected through a trusted interface 3. Enable DHCP snooping on at least one VLAN 4. Configure the DHCP snooping database agent 5. Enable DHCP snooping globally Configure the trusted interfaces where DHCP traffic should be seen interface Enable DHCP snooping on a VLAN ip dhcp snooping vlan 6.1. Cisco Implementations 201 Grumpy Networkers Journal Documentation, Release 0.0.7 Enable DHCP snooping globally ip dhcp snooping ! Optional ip dhcp snooping information option [replace | allow-untrusted ] ! Optional - Required for MAB operations with 802.1x ip dhcp snooping trust host ! Optional - Verify that the MAC address in the DHCP packet matches that in to Layer ˓→2 Frame ip dhcp snooping verify mac-address ! Optional - Enable DHCP Server Detection ip dhcp snooping detect spurious vlan Configure the DHCP Snooping Database Agent If the switch were to reboot and the DHCP database this could lead to network distruption. It is recommended that the the database is stored on a TFTP server so that when the switch reloads it will retrieve the latest database and reload the bindings without taking unnecessary space on the switches flash memory. ip dhcp snooping database Add Static entries to the database If a device with a static IP address is on a VLAN with DHCP snooping enabled, it needs to have a static entry added otherwise frames may be dropped: ip dhcp snooping binding ˓→ Verification To verify that DHCP Snooping is enabled use: show ip dhcp snooping show ip dhcp snooping database show ip dhcpd snooping binding show ip dhcp snooping track host show ip dhcp snooping detect spurious Troubleshooting To clear the DHCP snooping tracking cache: 202 Chapter 6. Vendor Implementations Grumpy Networkers Journal Documentation, Release 0.0.7 clear ip dhcp snooping track host To reload the DHCP snooping database form the specified URL : renew ip dhcp snoop data External Reference Cisco - Catalyst 6500 Release 12.SX Software Configuration Guide http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/12-2SX/configuration/guide/book/snoodhcp. html Packet Pushers - Five things To Know About DHCP Snooping http://packetpushers.net/five-things-to-know-about-dhcp-snooping/ Cisco Dynamic ARP Inspection (DAI) Overview Within a Layer 2 broadcast domain, hosts can be vulnerable to MAC spoofing attacks as there is is no way to verify that indeed the host that replied to a ARP request is indeed to host who owns the required IP address. Hosts will also accept a gratuitous ARP reply even when they have not requested this information leading to a com- promise of the hosts ARP cache. Cisco’s Dynamic ARP Inspection (DAI) feature can help prvent these types of attacks by ensuring only valid ARP requests and response are relayed. It does this by relying on an existing trusted database, either statically configured or via the DHCP snooping databae. Hosts are considdered either trusted or untrusted. Commonly connections between other switches are trusted whereas those connected to host devices are untrusted. Trusted ports bypass the DAI security checks. DAI should be enabled on all switches as if one switch does not have DAI enabled and is connected to a trusted port, even if the other switch has DAI enabled it will trust all the ARP/MAC information from the non-DAI switch. DAI also can be used to prevent ARP DoS attacks by rate limiting the number of ARP packets that are incoming. By default the rate is 15 pps on untrusted interaces. If this rate is existed the port is put in an error disabled state and by default manual intervention is required to recover the port but error disable recovery can also be enabled to recover the port after a given period of time. DAI can be combined with an ARP ACL to filter packets irrelevent of the DHCP snooping database. If a packet is denied by the ARP ACL is will be dropped irrespectivve of any entries in the DHCP snooping ddatabase. Implementation By default DAI is disable on all VLANS and all interfaces are configured as untrusted. The default rate limiting of incoming ARP packets is 15pps on untrusted interfaces with a burst interval of 1 second. There is no rate limiting applied on trusted interfaces. No additional validation checks are performed by default. DAI only checks packets as they are incoming, nothing is checked for packets leaving an interface. 6.1. Cisco Implementations 203 Grumpy Networkers Journal Documentation, Release 0.0.7 DHCP Snooping must be enabled prior to enabling DAI. If DHCP Snooping is not enabled or in non-DHCP environ- ment, use ARP ACLS to permit or deny packets on a per-vlan basis. Configuration Steps 1. Enable DHCP Snooping (if required) 2. Enable DAI on the VLAN(s) 3. Configure the DAI interface trust state 4. Applying ARP ACLs for DAI Filtering 5. Configure ARP Packet Rate Limiting 6. Enabling DAI error-disabled recovery 7. Configure additional validation 8. Configure DAI Logging Enable DHCP Snooping If DAI needs to be able to check the DHCP database, ensure the DHCP snooping is enabled on the same VLAN as DAI and also enabled globally on the switch. Refer to the Cisco DHCP Snooping section for further information Enable DAI on the VLAN(s) DAI is enabled on a per-VLAN basis not globally as follows: ip arp inspection vlan {vlan-id> | Configure the DAI interface trust state By default all interface are untrusted, for ports connected to other switches the ports should be configured as trusted. interface Apply ARP ACL for DAI filtering If you want to specifically deny/allow certain MAC Addresses irrespective of the DHCP Snooping database an ARP ACL can be used on a per VLAN basis. ip arp inspecion filter If the static keyword is specified an explicit deny will be used meaning that any entries in the DHCP Snooping database will not be used. Without this the DHCP snooping database will be consulted to determine if a packet should be denied or not. 204 Chapter 6. Vendor Implementations Grumpy Networkers Journal Documentation, Release 0.0.7 Configure ARP rate limiting Configuring rate limiting can assist with prevenint ARP based denial of service attacks such as DoS and CAM table floooding. By default if more than 15 ARP packets are seen per second it will be seen as an attack and the port will be error disabled. interface Using the no version of the command does not disable rate limiting, it simply returns it to the default rate-limiting value. Enable DAI Error-Disabled Recovery To ease the administrative burden of manually recovering ports due to DAI, the switch can be configured to automati- cally recover the port after a certain amount of time: Enable additional validation By default DAI will discard ARP packets with invalid IP-to-MAC address bindings. Additional verification can be enabled for: • Destination MAC (Verifies the target MAC in Ethernet to target MAC in ARP) • Sender/Target IP addresses (Checks for invalid/unexpect IPS, such as wildcard or broadcast) • Source MAC (verifies source MAC in ethernet against sender MAC in ARP body for both requess and responds) ip arp inspection validate {[dst-mac] [ip] [src-mac]} DAI Logging If a packet is dropped by DAI an entry is logged in the buffer which is rate-controlled. This entry will include the receiving VLAN, port number, source and destination IP an MAC details. Because of the rate control, a single log entry may represent more than one packet. If many packets on the same VLAN with same ARP parameters, DAI combines this into a single log buffer entry. The buffer size can be configured with: ip arp inspection log-buffer entries The aggregation of events can be controlled through: ip arp inspection log-buffer logs For example, if the number of messages is set to 12 and the interval is set to 2 seconds, 12 messages will be logged every 2 seconds (assuming an event occurs). The types of log entries can also be controlled as follows: ip arp inspection vlan ˓→bindings {all | none | permit}} 6.1. Cisco Implementations 205 Grumpy Networkers Journal Documentation, Release 0.0.7 Monitoring and Troubleshooting The follow commands can be useful for troubleshooting and monitoring DAI: ! display the ARP ACLs show arp access-list [ ! Displays the current DAI status and ACL configuration per vlan as well as any ˓→additional validations show ip arp inspection vlan {vlan-id> | ! Displays the current trust stte, rate and burst interval of each interface show ip arp inspection interfaces ! Disables the recovery status for the various causes show errdisable recovery ! Displays the ARP inspection log show ip arp inspecion log Further Reading The following documentation provides further information: 15.1SY Supervisor Engine 2T Software Configuration Guide [c6] Cisco Storm Control Overview A traffic storm ocurs when packets are flooding the LAN which results in excessive trafic and degraded network performance. The traffic storm control feature prvents LAN ports from bein distrupted by broadcast, multicast or unicast trafffic storms on physical interface. Traffic Storm control is also sometimes called traffic suppression and it monitors incoming traffic levels of a 1 second interval. During this interval the trafffic level is comparred with the storm control level which has been configured. This level is a percentage of thhe total available bandwidth on the port. Each port has a single trafic storm control level that is used for all types of traffic (broadcast, multicast and unicast). By default when traffic exceeds the configured level the traffic is dropped until the trafffic storm control interval ends. It is also possible to simply send an SNMP trap when a traffic storm occurs. When both multicast and broadcast storm control is enabled if broadcast and/or multicast traffic exceeds the configured level, both types of traffic are dropped. Configuration Configuration is done at the physical interface or Port Channel level. In the case of port channel interfaces, do not configure storm control on the individual member ports. 206 Chapter 6. Vendor Implementations Grumpy Networkers Journal Documentation, Release 0.0.7 interface ! Only supported on Gigabit Ethernet interfaces storm-control multicast level ! Ony supported on Gigabit Ethernet interfaces storm-control unicast level Monitoring and Troubleshooting show interfaces switchport show interfaces counters storm-control Further Reading Release 15.1SY Supervisor Engine 2T Software Configuration Guide [c8] Cisco MACSec Overview MACSec (IEEE 802.1AE) is a layer 2 encryption specification to provide wire-rate encryption at gigabit speeds. Providing both confidentiality and integrity of all communications over the link. Often MACSec is combinded with other technologies such as 802.1X in order to provide additioal identification of users/devices on the network. Theres not point spending resources encrypting traffic that is to/from an unauthorised user/device. MACSec can provide protection against man in the middle or “shadow” uses who snoop the wire between the end user and the network switch. AES-GCM is used as the authenticated encryption algorithm using a 128-bit symmetric key for encryption and de- cryption. GMAC authenticates each packet. MKA MACsec encryption is used for host-to-switch encryption Either SAP or NDAC are used for Switch to Switch encyption. These cannot be used alongside Cisco NEAT which intended for compact switches. Further Reading For more details refer to the following external documentation: Catalyst 4500 Series Switch Software Configuration Guide, Release IOS XE 3.3.0SG and IOS 15.1(1)SG [c7] 6.1. Cisco Implementations 207 Grumpy Networkers Journal Documentation, Release 0.0.7 6.1.4 Cisco Implementations of Network Protocols Cisco Secure Shell (SSH) SSH Implementation on Cisco ASA SSH Implementation on Cisco IOS Cisco SSH Limitations • Cisco SSH Client cannot propose public key authentication method. Cisco SSH Version 2 Enhancements Note: Cisco SSH implementations of version 2 require a miminum key modulus size of 768-bits. • VRF-Aware • DH Group Exchange • Supports Keyboard-Interactive (RFC 4256) and Password-Based authentication • Supports RSA-based public key authentiation for client/server • SSH debug enhancements External References Secure Shell (Wikipedia) https://en.wikipedia.org/wiki/Secure_Shell Secure Shell Configuration Guide, Cisco IOS Release 15S http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_usr_ssh/configuration/15-s/sec-usr-ssh-15-s-book/ sec-secure-shell-v2.html#GUID-A906A0EE-3C84-4672-BD12-064A2A5BD7F2 208 Chapter 6. Vendor Implementations CHAPTER 7 To Do Todo: Document Sphinx formatting characters that have been used in this document for easier refrence (The original entry is located in /home/docs/checkouts/readthedocs.org/user_builds/grumpy-networkers- journal/checkouts/latest/source/DOCUMENTATION/SPHINX.rst, line 12.) Todo: Write up the purpose of this chapter (The original entry is located in /home/docs/checkouts/readthedocs.org/user_builds/grumpy-networkers- journal/checkouts/latest/source/NETWORKING/VPNS/SSL/SSLVPNACASA8x.rst, line 11.) Todo: Verify exact syntax (The original entry is located in /home/docs/checkouts/readthedocs.org/user_builds/grumpy-networkers- journal/checkouts/latest/source/NETWORKING/VPNS/SSL/SSLVPNACASA8x.rst, line 54.) Todo: How to get group value from RADIUS/LDAP attribute (The original entry is located in /home/docs/checkouts/readthedocs.org/user_builds/grumpy-networkers- journal/checkouts/latest/source/NETWORKING/VPNS/SSL/SSLVPNACASA8x.rst, line 100.) Todo: Document troubleshooting steps (The original entry is located in /home/docs/checkouts/readthedocs.org/user_builds/grumpy-networkers- journal/checkouts/latest/source/NETWORKING/VPNS/SSL/SSLVPNACASA8x.rst, line 182.) 209 Grumpy Networkers Journal Documentation, Release 0.0.7 Todo: Document the below configurations (The original entry is located in NETWORKING/VPNS/SSL/ASA8x_AnyConnect_Examples.rst.inc, line 1.) Todo: Document methods of uploading to flash (The original entry is located in /home/docs/checkouts/readthedocs.org/user_builds/grumpy-networkers- journal/checkouts/latest/source/NETWORKING/VPNS/SSL/SSLVPNACASA9xASDM.rst, line 36.) Todo: Document RADIUS and TACACS services for all the AAA functions (The original entry is located in /home/docs/checkouts/readthedocs.org/user_builds/grumpy-networkers- journal/checkouts/latest/source/SECURITY/AUTHENTICATION/AAA.rst, line 5.) Todo: Document how to use OpenSSL to setup a CA Server including intermediate CAs, issuing of certificates, SCEP as well as OCSP/CRL revocation checks. (The original entry is located in /home/docs/checkouts/readthedocs.org/user_builds/grumpy-networkers- journal/checkouts/latest/source/SECURITY/CRYPTOGRAPHY/PKI/VENDOR/OPENSSL_CA_INSTALL.rst, line 5.) Todo: Research other implementations (e.g. Microsoft, Open Source such as DogTag, Cloud Hosted such as LetsEn- crypt) (The original entry is located in /home/docs/checkouts/readthedocs.org/user_builds/grumpy-networkers- journal/checkouts/latest/source/SECURITY/CRYPTOGRAPHY/PKI/VENDOR/VENDOR_IMPLEMENTATIONS.rst, line 11.) Todo: Check if this is even valid? (The original entry is located in /home/docs/checkouts/readthedocs.org/user_builds/grumpy-networkers- journal/checkouts/latest/source/STUDY_NOTES/FLEXVPN_VIDEO_NOTES.rst, line 90.) Todo: Is it possible to do an IPv4 public IP but then do IPv6 private subnets? (The original entry is located in /home/docs/checkouts/readthedocs.org/user_builds/grumpy-networkers- journal/checkouts/latest/source/STUDY_NOTES/FLEXVPN_VIDEO_NOTES.rst, line 312.) Todo: Cisco ASA IPSec (Pre-8.3) configuration examples: Config, Verification and Troubleshooting (The original entry is located in /home/docs/checkouts/readthedocs.org/user_builds/grumpy-networkers- journal/checkouts/latest/source/VENDOR/CISCO/VPN/CISCO_IKEV1/ASA_IKEV1_CONFIG_PRE_83.rst, line 5.) 210 Chapter 7. To Do Grumpy Networkers Journal Documentation, Release 0.0.7 Todo: Insert topology image (The original entry is located in /home/docs/checkouts/readthedocs.org/user_builds/grumpy-networkers- journal/checkouts/latest/source/VENDOR/CISCO/VPN/CISCO_IKEV1/IOS_IKEV1_LEGACY_CRYPTOMAP.rst, line 93.) Todo: what is the purpose of the network id? (The original entry is located in /home/docs/checkouts/readthedocs.org/user_builds/grumpy-networkers- journal/checkouts/latest/source/VENDOR/CISCO/VPN/DMVPN/DMVPN_FUNDAMENTALS.rst, line 44.) Todo: What is the purpose of the tunnel key? (The original entry is located in /home/docs/checkouts/readthedocs.org/user_builds/grumpy-networkers- journal/checkouts/latest/source/VENDOR/CISCO/VPN/DMVPN/DMVPN_FUNDAMENTALS.rst, line 53.) Todo: What about ‘ip nhrp shortcut’? (The original entry is located in /home/docs/checkouts/readthedocs.org/user_builds/grumpy-networkers- journal/checkouts/latest/source/VENDOR/CISCO/VPN/DMVPN/DMVPN_FUNDAMENTALS.rst, line 117.) Todo: Complete example configuration for OSPF router ospf (The original entry is located in /home/docs/checkouts/readthedocs.org/user_builds/grumpy-networkers- journal/checkouts/latest/source/VENDOR/CISCO/VPN/DMVPN/DMVPN_HUB_CONFIG.rst, line 109.) Todo: Document OSPF configuration (The original entry is located in /home/docs/checkouts/readthedocs.org/user_builds/grumpy-networkers- journal/checkouts/latest/source/VENDOR/CISCO/VPN/DMVPN/DMVPN_SPOKE_CONFIG.rst, line 117.) 211 Grumpy Networkers Journal Documentation, Release 0.0.7 212 Chapter 7. To Do CHAPTER 8 Glossary of Terms 3DES Triple Data Encryption Standard AES Advanced Encryption Standard AH Authentication Header CA Certificate Authority CSR Certificate Siging Request DES Data Encryption Standard DH Diffie-Helman Protocol DMVPN Dynamic Multipoint VPN DoS Denial of Service DTLS Datagram Transport Layer Security ECC Eliptic Curve Cryptography ESP Encapsulated Securely Payload GDOI Group Domain of Intepretation (GetVPN) GetVPN Group Encrypted Transport VPN ICV Integrity Check Value IKE Internet Key Exchange IP Internet Protocol IPSec IP Security ISAKMP Internet Security Association Key Management Protocol L2TP Layer 2 Tunnelling Protocol MD5 Message Digest Version 5 MPLS Multi-protocol Label Switching 213 Grumpy Networkers Journal Documentation, Release 0.0.7 NAT Network Address Translation NAT-T Network Address Translation Traversal NTP Network Time Protocol PKI Public Key Infrastructure PPTP Point-To-Point Tunnelling Protocol RSA Named after the original creators (Rivest, Shamir, Adleman) of the encryption algorithm used with PKI SA Security Association SAD Security Association Database SCEP Simple Certificate Enrollment Protocol SHA1 Secure Hashing Algorithm Version 1 SHA2 Secure Hashing Algorithm Version 2 SPD Security Policy Database SPI Security Parameter Index SSL Secure Socket Layer SSTP Secure Socket Tunnelling Protocol TLS Transport Layer Security TTL Time To Live UDP User Datagram Protocol VoIP Voice Over IP VPN Virtual Private Network 214 Chapter 8. Glossary of Terms CHAPTER 9 External References 9.1 PPTP Microsoft Technet on PPTP 9.2 Sphinx Official Sphinx Documentation 215 Grumpy Networkers Journal Documentation, Release 0.0.7 216 Chapter 9. External References CHAPTER 10 Indices and tables • genindex • search 217 Grumpy Networkers Journal Documentation, Release 0.0.7 218 Chapter 10. Indices and tables Bibliography [c1] ASA Packet Captures with CLI and ASDM Configuration Example (Cisco, August 18 2015) http://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/ 118097-configure-asa-00.html [c2] Cisco Nexus 7000 Series NX-OS Security Configuration Guide, Release 4.1 (Cisco, October 31 2013) http://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/4_1/nx-os/security/configuration/guide/sec_ nx-os-cfg/sec_rbac.html#wp1454261 [c3] CLI Book 1: Cisco ASA Series General Operations CLI Configuration Guide, 9.6 (Cisco, May 16 2017) http://www.cisco.com/c/en/us/td/docs/security/asa/asa96/configuration/general/asa-96-general-config/intro-fw. html [c4] Cisco Guide to Harden Cisco ASA Firewall (Cisco, February 2016) http://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/ 200150-Cisco-Guide-to-Harden-Cisco-ASA-Firewall.html [c5] Cisco SAFE Reference Guide (cisco, December 10 2013) http://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Security/SAFE_RG/SAFE_rg.html [c6] Release 15.1SY Supervisor Engine 2T Software Configuration Guide - DAI (Cisco, August 15 2016) http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/15-1SY/config_guide/sup2T/15_1_sy_ swcg_2T/dynamic_arp_inspection.html [c7] Catalyst 4500 Series Switch Software Configuration Guide, Release IOS XE 3.3.0SG and IOS 15.1(1)SG (Cisco, Date unknown) 219 Grumpy Networkers Journal Documentation, Release 0.0.7 http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4500/15-1/XE_330SG/configuration/guide/config/ swmacsec.html [c8] Release 15.1SY Supervisor Engine 2T Software Configuration Guide (Cisco, August 15 2016) http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/15-1SY/config_guide/sup2T/15_1_sy_ swcg_2T/traffic_storm_control.html [c9] Security Configuration Guide, Cisco IOS XE Release 3SE (Catalyst 3650 Switches) (Cisco, April 25 2017) http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3650/software/release/3se/security/configuration_ guide/b_sec_3se_3650_cg/b_sec_3se_3650_cg_chapter_01101.html 220 Bibliography Index Symbols N 3DES, 213 NAT, 214 NAT-T, 214 A NTP, 214 AES, 213 AH, 213 P PKI, 214 C PPTP, 214 CA, 213 CSR, 213 R RSA, 214 D DES, 213 S DH, 213 SA, 214 DMVPN, 213 SAD, 214 DoS, 213 SCEP, 214 DTLS, 213 SHA1, 214 SHA2, 214 E SPD, 214 ECC, 213 SPI, 214 ESP, 213 SSL, 214 SSTP, 214 G GDOI, 213 T GetVPN, 213 TLS, 214 TTL, 214 I ICV, 213 U IKE, 213 UDP, 214 IP, 213 IPSec, 213 V ISAKMP, 213 VoIP, 214 VPN, 214 L L2TP, 213 M MD5, 213 MPLS, 213 221| remote} [detail]