---
title: Network Security Configuration
tags: Cisco IOS, networking, manual, reference, router, switch, technical, security
---
<header>
<h6>Network Security Configuration</h6>
> [toc]
</header>
---
<!--
# Types of Network Management Access
## In-Band
## Out-of-Band
-->
<!-- Cisco AutoSecure -->
{%hackmd r8ZvM3noSwKf-NviH6Qb3Q %}
# Dynamic Routing Protocol Security
Routing systems can be attacked by disrupting peer network routers, or by falsifying or spoofing the information carried within the routing protocols. Spoofing routing information may generally be used to cause systems to misinform each other, cause a DoS attack, or cause traffic to follow a path it would not normally follow.
## Cisco Discovery Protocol
```pug
// disable CDP globally on a device
R1(config)# no cdp run
// disable CDP on a port
R1(config-if)# no cdp enable
```
## Link Layer Discovery Protocol
```pug
// disable LLDP globally
R1(config)# no lldp run
// disable LLDP on an interface
R1(config-if)# no lldp transmit
R1(config-if)# no lldp receive
```
## OSPF Routing Protocol
### MD5 Authentication
OSPF supports routing protocol authentication using the MD5 algorithm. MD5 authentication can be enabled globally for all interfaces or on a per interface basis.
:::danger
MD5 is now considered vulnerable to attacks and should only be used when stronger authentication is not available.
:::
To enable OSPF MD5 authentication **globally**:
<ol class='step-list'>
<li>issue the <code><b>ip ospf message-digest-key</b> <i>key</i> <b>md5</b> <i>password</i></code> global configuration command.</li>
<li>Issue the <code><b>area</b> <i>area-id</i> <b>authentication message-digest</b></code> router configuration command.</li>
</ol>
:::warning
This method forces authentication on all OSPF enabled interfaces. If an interface is not configured with the **ip ospf message-digest-key** command, it will not be able to form adjacencies with other OSPF neighbors.
:::
To enable OSPF MD5 authentication on a **per-interface** basis:
<ol class='step-list'>
<li>issue the <code><b>ip ospf message-digest-key</b> <i>key</i> <b>md5</b> <i>password</i></code> interface configuration command.</li>
<li>Issue the <code><b>ip ospf authentication message-digest</b></code> interface configuration command.</li>
</ol>
:::info
The interface setting overrides the global setting.
:::
### SHA Authentication
To enable OSPF SHA authentication **globally**:
<ol class='step-list'>
<li>issue the <code><b>key chain</b></code> global configuration command.</li>
<li>Assign the key chain a number and a password with the <code><b>key</b></code> and <code><b>key-string</b></code> commands.</li>
<li>Specify SHA authentication with the <code><b>cryptographic-algorithm</b></code> command.</li>
<li>(Optional) Configure when the key will expire via the <code><b>send-lifetime</b></code> command.</li>
<li>Assign the new authentication key to the desired interfaces via the <code><b>ip ospf authentication key-chain</b></code> command.</li>
</ol>
```pug
Router(config)# key chain <name>
Router(config-keychain)# key <key-id>
Router(config-keychain-key)# key-string <string>
Router(config-keychain-key)# cryptographic-algorithm {hmac-sha-1 | hmac-sha-256 | hmac-sha-384 | hmac-sha-512 | md5}
Router(config-keychain-key)# send-lifetime start-time {infinite | end-time | duration <seconds>}
Router(config-keychain-key)# exit
Router(config)# interface <type> <number>
Router(config-if)# ip ospf authentication key-chain <name>
```
# MAC Overflow Attacks – Port Security
Port security prevents many types of attacks including MAC table overflow attacks and DHCP starvation attacks.
Port security can only be configured on manually configured **access ports
trunk ports** or manually configured **access ports
trunk ports**. By default, Layer 2 switch ports are set to dynamic auto (trunking on).
**Configure the port with the `switchport mode access` interface configuration command.**
```pug
S1(config)# interface f0/1
S1(config-if)# switchport port-security
Command rejected: FastEthernet0/1 is a dynamic port.
S1(config-if)# switchport mode access
S1(config-if)# switchport port-security
S1(config-if)# switchport port-security maximum 2
S1(config-if)# switchport port-security mac-address aaaa.bbbb.1234
S1(config-if)# switchport port-security mac-address sticky
S1(config-if)# end
S1#
```
**Use the `show port-security` command to display the current port security settings.**
```pug
S1# show port-security interface f0/1
! Port Security : Enabled
! Port Status : Secure-down
! Violation Mode : Shutdown
! Aging Time : 0 mins
! Aging Type : Absolute
! SecureStatic Address Aging : Disabled
! Maximum MAC Addresses : 1
! Total MAC Addresses : 0
! Configured MAC Addresses : 0
! Sticky MAC Addresses : 0
! Last Source Address:Vlan : 0000.0000.0000:0
! Security Violation Count : 0
S1# show port-security address
! Secure Mac Address Table
! -----------------------------------------------------------------------------
! Vlan Mac Address Type Ports Remaining Age
! (mins)
! ---- ----------- ----- ----- -------------
! 1 a41f.7272.676a SecureSticky Fa0/1 -
! 1 aaaa.bbbb.1234 SecureConfigured Fa0/1 -
! -----------------------------------------------------------------------------
! Total Addresses in System (excluding one mac per port) : 1
! Max Addresses limit in System (excluding one mac per port) : 8192
S1#
```
**After port security is enabled, other port security specifics can be configured.**
:::info
If an **active port** is configured with the **`switchport port-security`** command and **more than one device** is connected to that port, the port will transition to the **error-disabled** state. This condition is discussed later in this topic.
:::
## Limit MAC Addresses
To set the maximum number of MAC addresses allowed on a port, use the following command:
```pug
Switch(config-if)# switchport port-security maximum <value>
```
:::success
The default **port security** value is **1**. The maximum number of secure MAC addresses that can be configured depends the switch and the IOS.
:::
The switch can be configured to learn about MAC addresses on a secure port in one of three ways:
### Manually
The administrator manually configures a static MAC address(es) by using the following command for each secure MAC address on the port:
```pug
Switch(config-if)# switchport port-security mac-address <mac-address>
```
### Dynamically
When the <code><b>switchport port-security</b></code> command is entered, the current source MAC for the device connected to the port is automatically secured but is not added to the startup configuration. If the switch is rebooted, the port will have to re-learn the device’s MAC address.
### Dynamically (Sticky)
The administrator can enable the switch to dynamically learn the MAC address and “stick” them to the running configuration by using the following command:
```pug
Switch(config-if)# switchport port-security mac-address sticky
```
:::info
Saving the running configuration will commit the dynamically learned MAC address to NVRAM, preventing the MAC addresses from being lost in the event that the associated interface goes down.
:::
## Port Security Aging
Port security aging can be used to remove MAC addresses from a port without having to manually specify addresses to delete.
There are two types of aging that are supported per port:
* **Absolute** – The secure addresses on the port are deleted after the specified aging time.
* **Inactivity** – The secure addresses on the port are deleted only if they are inactive for the specified aging time.
**Aging of statically configured secure addresses can be enabled or disabled on a per-port basis:**
```pug
S1(config)# interface fa0/1
S1(config-if)# switchport port-security static
S1(config-if)# switchport port-security aging time 10
S1(config-if)# switchport port-security aging type inactivity
```
The options for the command are described below:
| Parameter | Description |
| --------- | ----------- |
| <div class='mono'>**static**</div> | Enable aging for statically configured secure addresses on this port (by default these are excluded from aging out). |
| <div class='mono'>**time** *time*</div> | Specify the aging time for this port. The range is 0 to 1440 minutes. If the time is 0, aging is disabled for this port. |
| <div class='mono'>**type absolute**</div> | Set the absolute aging time. All the secure addresses on this port age out exactly after the time (in minutes) specified and are removed from the secure address list. |
| <div class='mono'>**type inactivity**</div> | Set the inactivity aging type. The secure addresses on this port age out only if there is no data traffic from the secure source address for the specified time period. |
## Port Security Violation Modes
If the MAC address of a device attached to the port differs from the list of secure addresses, then a port violation occurs. By default, the port enters the error-disabled state.
**To set the port security violation mode, use the following command:**
```pug
Switch(config-if)# switchport port-security violation { protect | restrict | shutdown}
```
The following tables show how a switch reacts based on the configured violation mode:
| Mode | Description |
| ---- | ----------- |
| <div class='mono'>**shutdown**</div> (default) | The port transitions to the error-disabled state immediately, turns off the port LED, and sends a syslog message. It increments the violation counter. When a secure port is in the error-disabled state, an administrator must re-enable it by entering the <code><b>shutdown</b></code> and <code><b>no shutdown</b></code> commands. |
| <div class='mono'>**restrict**</div> | The port drops packets with unknown source addresses until you remove a sufficient number of secure MAC addresses to drop below the maximum value or increase the maximum value. This mode causes the Security Violation counter to increment and generates a syslog message. |
| <div class='mono'>**protect**</div> | This is the least secure of the security violation modes. The port drops packets with unknown MAC source addresses until you remove a sufficient number of secure MAC addresses to drop below the maximum value or increase the maximum value. No syslog message is sent. |
## Ports in error-disabled State
To re-enable a downed port, first use the <code><b>shutdown</b></code> command, then, use the <code><b>no shutdown</b></code> command to make the port operational:
```pug
S1(config)# interface fa0/1
S1(config-if)# shutdown
S1(config-if)#
! *Mar 1 00:39:54.981: %LINK-5-CHANGED: Interface FastEthernet0/1, changed state to administratively down
S1(config-if)# no shutdown
S1(config-if)#
! *Mar 1 00:40:04.275: %LINK-3-UPDOWN: Interface FastEthernet0/1, changed state to up
! *Mar 1 00:40:05.282: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to up
S1(config-if)#
```
## Port Security Reporting
The MAC address notification feature sends SNMP traps to the network management station (NMS) whenever a new MAC address is added to, or an old address is deleted from, the forwarding tables. MAC address notifications are generated only for dynamic and secure MAC addresses.
Use the <code><b>mac address-table notification</b></code> global configuration command to enable the MAC address notification feature on a switch.
## Verify Port Security
**Port Security for All Interfaces**
```pug
S1# show port-security
! Secure Port MaxSecureAddr CurrentAddr SecurityViolation Security Action
! (Count) (Count) (Count)
! ---------------------------------------------------------------------------
! Fa0/1 2 2 0 Shutdown
! ---------------------------------------------------------------------------
! Total Addresses in System (excluding one mac per port) : 1
! Max Addresses limit in System (excluding one mac per port) : 8192
S1#
```
**Port Security for a Specific Interface**
```pug
S1# show port-security interface fastethernet 0/1
! Port Security : Enabled
! Port Status : Secure-up
! Violation Mode : Shutdown
! Aging Time : 10 mins
! Aging Type : Inactivity
! SecureStatic Address Aging : Disabled
! Maximum MAC Addresses : 2
! Total MAC Addresses : 2
! Configured MAC Addresses : 1
! Sticky MAC Addresses : 1
! Last Source Address:Vlan : a41f.7273.018c:1
! Security Violation Count : 0
S1#
```
**Verify Learned ("sticky") MAC Addresses**
```pug
S1# show run interface fa0/1
! Building configuration...
!
! Current configuration : 365 bytes
! !
! interface FastEthernet0/1
! switchport mode access
! switchport port-security maximum 2
! switchport port-security mac-address sticky
! switchport port-security mac-address sticky a41f.7272.676a
! switchport port-security mac-address aaaa.bbbb.1234
! switchport port-security aging time 10
! switchport port-security aging type inactivity
! switchport port-security
! end
!
S1#
```
**Verify Secure MAC Addresses**
```pug
S1# show port-security address
! Secure Mac Address Table
! ----------------------------------------------------------------------
! Vlan Mac Address Type Ports Remaining Age
! (mins)
! ---- ----------- ---- ----- ------------
! 1 a41f.7272.676a SecureSticky Fa0/1 -
! 1 aaaa.bbbb.1234 SecureConfigured Fa0/1 -
! ----------------------------------------------------------------------
! Total Addresses in System (excluding one mac per port) : 1
! Max Addresses limit in System (excluding one mac per port) : 8192
S1#
```
# VLAN Attacks
A **VLAN hopping** attack enables traffic from one VLAN to be seen by another VLAN without the aid of a router. In a basic VLAN hopping attack, the threat actor configures a host to act like a switch to take advantage of the automatic trunking port feature enabled by default on most switch ports.
**Use the following steps to mitigate VLAN hopping and VLAN double-tagging attacks:**
<ol class="step-list">
<li>Disable DTP (auto trunking) negotiations on non-trunking ports by using the <code><b>switchport mode access</b></code> interface configuration command.</li>
<li>Disable unused ports and put them in an unused VLAN.</li>
<li>Manually enable the trunk link on a trunking port by using the <code><b>switchport mode trunk</b></code> command.</li>
<li>Disable DTP (auto trunking) negotiations on trunking ports by using the <code><b>switchport nonegotiate</b></code> command.</li>
<li>Set the native VLAN to a VLAN other than <code>VLAN 1</code> by using the <code><b>switchport trunk native vlan</b> <i>vlan_number</i></code> command.</li>
</ol>
```pug
S1(config)# interface range fa0/1 - 16
S1(config-if-range)# switchport mode access
S1(config-if-range)# exit
S1(config)#
S1(config)# interface range fa0/17 - 20
S1(config-if-range)# switchport mode access
S1(config-if-range)# switchport access vlan 1000
S1(config-if-range)# shutdown
S1(config-if-range)# exit
S1(config)#
S1(config)# interface range fa0/21 - 24
S1(config-if-range)# switchport mode trunk
S1(config-if-range)# switchport nonegotiate
S1(config-if-range)# switchport trunk native vlan 999
S1(config-if-range)# end
S1#
```
## Private VLAN Proxy Attacks
Private VLANs (PVLAN) provide Layer 2 isolation between ports within the same broadcast domain. However, the security provided by a PVLAN can be bypassed by using a connected router as a proxy.
:::info
See [VLAN Management](https://hackmd.io/@Faelin/cisco-ios-reference-guide/%2FF7KXRk3YSt-qz1k2TOPy3g) for more information about PVLAN configuration.
:::
Consider a typical PVLAN implementation, such as a hotel, where each room has an ethernet port configured as an **isolated** port. This kind of separation helps prevent bad actors from communicating with devices in other rooms. However, in order for internet requests to leave the hotel network, the switch connecting these rooms must have a configured **promiscuous** port attached to a router, so that all **isolated** traffic may be forwarded to the router.
In this scenario, an attacker may send packets that have the **source IP** and **MAC** of the **attacking** device, and the **destination IP** of the **target** device, but the **destination MAC** of the promiscuous **router**. The network switch will allow the frame to forward to the router due to the promiscuous port. The router will then rebuild the frame with the **target's** MAC address (based on the ARP table) and will forward the frame back to the network switch. The switch will then **complete the delivery to the original target**.
<br>
**To mitigate this type of attack, configure an ACL that will deny traffic with a source and destination IP address that belong to the same subnet:**
```pug
R1(config)# ip access-list extended PVLAN
R1(config-ext-nacl)# deny ip 172.16.0.0 0.0.0.255 172.16.0.0 0.0.0.255
R1(config-ext-nacl)# permit ip any any
R1(config-ext-nacl)# interface g0/0
R1(config-if)# ip access-group PVLAN in
R1(config-if)#
```
# DHCP Attacks – DHCP Snooping
DHCP spoofing attacks can be mitigated using DHCP snooping on trusted ports. Devices under your administrative control, such as switches, routers, and servers, are trusted sources. Any device beyond the firewall or outside your network is an untrusted source. In addition, all access ports are generally treated as untrusted sources.
DHCP snooping builds and maintains a **DHCP snooping binding database** that the switch can use to **filter DHCP messages** from untrusted sources. The DHCP snooping binding table includes the client MAC address, IP address, DHCP lease time, binding type, VLAN number, and interface information on each untrusted switchport or interface.
DHCP snooping also helps mitigate against **DHCP starvation** attacks by rate limiting the number of DHCP discovery messages that an untrusted port can receive.
When DHCP snooping is enabled on an interface or VLAN, and a switch receives a packet on an untrusted port, the switch compares the source packet information with that held in the DHCP snooping binding table. The switch will **deny** packets containing:
* Unauthorized DHCP server messages from an untrusted port
* Unauthorized DHCP client messages not adhering to the snooping binding table or rate limits
* DHCP relay-agent packets that include option-82 information on an untrusted port
:::info
Similar mitigation techniques are available for DHCPv6 and IPv6 clients. Because IPv6 devices can also receive their addressing information from Router Advertisement (RA) messages, there are also mitigation solutions to prevent rogue RA messages.
:::
<br>
**Configure DHCP Snooping on trusted ports to limit DHCP attacks:**
<ol class="step-list">
<li>Enable DHCP snooping by using the <code><b>ip dhcp snooping</b></code> global configuration command.</li>
<li>On trusted ports, use the <code><b>ip dhcp snooping trust</b></code> interface configuration command.</li>
<li>Limit the number of DHCP discovery messages that can be received per second on untrusted ports by using the <code><b>ip dhcp snooping limit rate</b></code> interface configuration command.</li>
<li>Enable DHCP snooping by VLAN, or by a range of VLANs, by using the <code><b>ip dhcp snooping</b> <i>vlan</i></code> global configuration command.</li>
</ol>
```pug
S1(config)# ip dhcp snooping
S1(config)# ip dhcp snooping vlan 10
S1(config)# interface f0/1
S1(config-if)# ip dhcp snooping trust
S1(config-if)# exit
S1(config)# interface range f0/5 - 24
S1(config-if-range)# ip dhcp snooping limit rate 6
S1(config-if-range)# exit
S1(config)# ip dhcp snooping vlan 5,10,50-52
S1(config)# end
S1#
```
Use the show <code><b>ip dhcp snooping</b></code> privileged EXEC command to verify DHCP snooping and show <code><b>ip dhcp snooping binding</b></code> to view the clients that have received DHCP information:
```pug
S1# show ip dhcp snooping
! Switch DHCP snooping is enabled
! DHCP snooping is configured on following VLANs:
! 5,10,50-52
! DHCP snooping is operational on following VLANs:
! none
! <...output truncated...>
! DHCP snooping trust/rate is configured on the following Interfaces:
! Interface Trusted Allow option Rate limit (pps)
! ----------------------- ------- ------------ ----------------
! FastEthernet0/1 yes yes unlimited
! Custom circuit-ids:
! FastEthernet0/5 no no 6
! Custom circuit-ids:
! FastEthernet0/6 no no 6
! Custom circuit-ids:
S1#
S1# show ip dhcp snooping binding
! MacAddress IpAddress Lease(sec) Type VLAN Interface
! ------------------ --------------- ---------- ------------- ---- --------------------
! 00:03:47:B5:9F:AD 192.168.10.11 193185 dhcp-snooping 5 FastEthernet0/5
```
# ARP Attacks - Dynamic ARP Inspection
All hosts receive and broadcast ARP Requests to determine the MAC address of a host with a particular IPv4 address. This is typically done to discover the MAC address of the default gateway.
According to the ARP RFC, a client is allowed to send an unsolicited ARP Request called a “gratuitous ARP.” When a host sends a gratuitous ARP, other hosts on the subnet store the MAC address and IPv4 address contained in the gratuitous ARP in their ARP tables.
An attacker can send a gratuitous ARP message containing a spoofed MAC address to a switch, and the switch would update its MAC table accordingly. Therefore, any host can claim to be the owner of any IP and MAC address combination they choose.
**Dynamic ARP inspection (DAI)** prevents **ARP spoofing** and **ARP poisoning** attacks.
To mitigate the chances of ARP attacks, follow these DAI implementation guidelines:
* Enable DHCP snooping globally.
* Enable DHCP snooping on selected VLANs.
* Enable DAI on selected VLANs.
* Configure trusted interfaces for DHCP snooping and ARP inspection.
:::success
It is generally advisable to configure all access switch ports as untrusted and to configure all uplink ports that are connected to other switches as trusted.
:::
```pug
S1(config)# ip dhcp snooping
S1(config)# ip dhcp snooping vlan 10
S1(config)# ip arp inspection vlan 10
S1(config)# interface fa0/24
S1(config-if)# ip dhcp snooping trust
S1(config-if)# ip arp inspection trust
```
:::info
DAI requires the DHCP snooping binding table to operate.
:::
**DAI can also be configured to validate the destination or source MAC and IP addresses:**
```pug
S1(config)# ip arp inspection validate src-mac
S1(config)# ip arp inspection validate dst-mac
S1(config)# ip arp inspection validate ip
S1(config)# do show run | include validate
! ip arp inspection validate ip
S1(config)#
```
:::danger
Only one ARP validation configuration can exist at a time. Entering another <code><b>ip arp inspection validate</b></code> command will overwrites the previous configuration. To include more than one validation method, enter them as a single command:
<br>
```pug
S1(config)# ip arp inspection validate src-mac dst-mac ip
S1(config)# do show run | include validate
! ip arp inspection validate src-mac dst-mac ip
S1(config)#
```
:::
# Address Spoofing Attacks – IP Source Guard
Address spoofing attacks occur when one host poses as another to receive otherwise inaccessible data, or to circumvent security configurations.
The method used by switches to populate the MAC address table leads to a vulnerability known as MAC address spoofing. MAC address spoofing attacks involve an attacker altering the MAC address of their host to match another known MAC address of a target host. This causes the switch to overwrite the current MAC table entry and assigns the MAC address to the port associated with the new host.
IP address spoofing is when a rogue host hijacks a valid IP address of a neighbor, or a uses a random IP address. IP address spoofing is difficult to mitigate, especially when it is used inside a subnet to which the IP belongs.
To protect against MAC and IP address spoofing, configure the **IP Source Guard (IPSG)** security feature. IPSG dynamically maintains **per-port VLAN ACLs (PVACL)** based on IP-to-MAC-to-switch-port bindings.
Initially, **all IP traffic** on the port is **blocked**, except for DHCP packets that are captured by the DHCP snooping process. A PVACL is installed on the port when a client receives a valid IP address from the DHCP server or when a static IP source binding is configured by the user. This process restricts the client IP traffic to those source IP addresses that are configured in the binding.
IPSG should be deployed on untrusted Layer 2 **access** and **trunk** ports. Configure IPSG using the <code><b>ip verify source</b></code> interface configuration command.
:::warning
Like [Dynamic Arp Inspection](#ARP-Attacks---Dynamic-ARP-Inspection), IPSG requires **DHCP Snooping**, which can be enabled via the <code><b>ip dhcp snooping</b></code> global configuration command.
:::
Verify IPSG via the <code><b>show ip verify source</b></code> command.
# STP Manipulation Attacks - PortFast/BDPU Guard
**Spanning Tree Protocol (STP)** is a **loop-prevention** network protocol that allows for redundancy while creating a loop-free Layer 2 topology.
All switches that participate in STP exchange **Bridge Port Data Unit (BPDU)** frames to **determine the root bridge**. Each non-root switch uses the spanning tree algorithm to determine the **shortest path** to the root bridge, and block all ports not on that path.
Threat actors can manipulate the Spanning Tree Protocol (STP) to conduct an attack by **spoofing the root bridge** and changing the topology of a network.
To conduct an STP manipulation attack, the attacking host broadcasts BPDUs containing configuration and topology changes that will force spanning-tree recalculations.
:::info
Note that these issues can sometimes occur when someone adds an Ethernet switch to the network without any malicious intent.
:::
There are four **STP stability mechanisms** that can be used to enhance the overall performance of the switches and to reduce the time that is lost during topology changes:
* **PortFast** — PortFast brings certain ports into a forwarding state immediately upon the interface becoming enabled. PortFast should be applied to all end-user ports where there is a host attached to the port, and not another switch.
* **BPDU Guard** — BPDU guard immediately error disables a port that receives a BPDU. It is typically used on PortFast enabled ports. Apply to all end-user ports.
* **Root Guard** — Root guard prevents an inappropriate switch from becoming the root bridge. Root guard limits the switch ports out of which the root bridge may be negotiated. Apply to all ports which should not become root ports.
* **Loop Guard** — Loop guard prevents **alternate** or **root** ports from becoming **designated** ports because of a failure that leads to a unidirectional link. Apply to all ports that are or can become non-designated.
## PortFast
PortFast immediately brings an interface configured as an access or trunk port to the forwarding state from a blocking state, bypassing the listening and learning states. Apply only to all end-user ports that attach to host devices. Never apply PortFast to any port attached to a switch.
:::danger
If PortFast is enabled on a port connecting to another switch, there is a risk of creating a spanning-tree loop.
:::
PortFast can be enabled on an interface by using the <code><b>spanning-tree portfast</b></code> interface configuration command. Alternatively, Portfast can be configured globally on all access ports by using the <code><b>spanning-tree portfast default</b></code> global configuration command.
```pug
S1(config)# interface fa0/1
S1(config-if)# switchport mode access
S1(config-if)# spanning-tree portfast
! %Warning: portfast should only be enabled on ports connected to a single
! host...
! %Portfast has been configured on FastEthernet0/1 but will only
! have effect when the interface is in a non-trunking mode.
S1(config-if)# exit
S1(config)# spanning-tree portfast default
! %Warning: this command enables portfast by default on all interfaces...
S1(config)# exit
S1#
```
To verify whether PortFast is enabled globally you can use either the <code><b>show running-config | begin span</b></code> command or the <code><b>show spanning-tree summary</b></code> command.
## BDPU Guard
:::danger
Always enable BPDU Guard on all PortFast-enabled ports.
:::
BPDU guard immediately error-disables a port that receives a BPDU. This means the port is shut down and must be manually or programatically re-enabled. Like PortFast, BPDU guard should only be configured on interfaces attached to end devices.
:::success
If any BPDUs are received on a BPDU Guard enabled port, that port is put into error-disabled state. Ports disabled in this way can be automatically recovered through the <code><b>errdisable recovery cause bpduguard</b></code> global command.
:::
BPDU Guard can be enabled on a port by using the <code><b>spanning-tree bpduguard enable</b></code> interface configuration command. Alternatively, use the <code><b>spanning-tree portfast bpduguard default</b></code> global configuration command to globally enable BPDU guard on all PortFast-enabled ports.
```pug
S1(config)# interface fa0/1
S1(config-if)# spanning-tree bpduguard enable
S1(config-if)# exit
S1(config)# spanning-tree portfast bpduguard default
S1(config)# end
S1#
S1# show spanning-tree summary
! Switch is in pvst mode
! Root bridge for: none
! Extended system ID is enabled
! Portfast Default is enabled
! PortFast BPDU Guard Default is enabled
! Portfast BPDU Filter Default is disabled
! Loopguard Default is disabled
! EtherChannel misconfig guard is enabled
! UplinkFast is disabled
! BackboneFast is disabled
! Configured Pathcost method used is short
! <...output truncated...>
S1#
```
## Root Guard
Root Guard provides a way to enforce the placement of root bridges in the network by **limiting which switch** can become the root bridge. Root guard is best deployed on ports that connect to switches that **should not** be the root bridge.
If a **root-guard** enabled port receives BPDUs that are superior to those that the current root bridge is sending, that port is moved to a **root-inconsistent** state. This is effectively equal to an STP listening state, and **no data traffic is forwarded** across that port. **Recovery occurs** as soon as the offending device ceases to send superior BPDUs.
Use the <code><b>spanning-tree guard root</b></code> interface configuration command to enable root guard.
To view Root Guard ports that have received superior BPDUs and are in a root-inconsistent state, use the <code><b>show spanning-tree inconsistent ports</b></code> command.
## Loop Guard
Traffic on **bidirectional links** flows in both directions. If for some reason traffic flow fails in one direction, this creates a **unidirectional link** which can result in a **Layer 2 loop**. This most often occurs when an STP port in a redundant topology stops receiving BPDUs and erroneously transitions to the **forwarding** state.
If an STP **Alternate** port with Loop Guard enabled stops receiving BPDUs, the port transitions to a **loop-inconsistent** blocking state, instead of the listening / learning / forwarding state.
Loop Guard can be enabled on all non-**Root Guard** ports using the <code><b>spanning-tree guard loop</b></code> interface configuration command.
Loop Guard can also be enabled globally using the <code><b>spanning-tree loopguard default global</b></code> configuration command. This enables Loop Guard on all point-to-point links.
# Network Monitoring
The day-to-day operation of a network consists of common patterns of traffic flow, bandwidth usage, and resource access. Together, these patterns identify normal network behavior. To determine normal network behavior, network monitoring must be implemented.
There are two common methods used to capture traffic and send it to network monitoring devices:
* Network taps, sometimes known as test access points (TAPs)
* Traffic mirroring using Switch Port Analyzer (SPAN) or other port mirroring approaches
## Network Taps
A network tap is typically a passive splitting device implemented inline between a device of interest and the network. A tap forwards all traffic, including physical layer errors, to an analysis device while also allowing the traffic to reach its intended destination.
Network performance is not affected or degraded by monitoring the connection. Taps are also typically fail-safe, which means if a tap fails or loses power, traffic between the firewall and internal router is not affected.
## Traffic Mirroring with SPAN
Network switches segment the network by design. This limits the amount of traffic that is visible to network monitoring devices. However, port mirroring enables switches to copy frames that are received on one or more ports to a **Switch Port Analyzer (SPAN)** port that is connected to an analysis device.
A variation of SPAN called Remote SPAN (RSPAN) enables a network administrator to use the flexibility of VLANs to monitor traffic on remote switches. The traffic for each RSPAN session is carried over a user-specified RSPAN VLAN that is dedicated (for that RSPAN session) in all participating switches.
In SPAN configuration, **source ports**—sources of traffic to be monitored—are mirrored to **destination ports**, which are ports connected to network monitoring devices.
The association between source ports and a destination port is called a SPAN session. In a single session, one or multiple ports can be monitored. Alternatively, a source VLAN can be specified in which all ports in the source VLAN become sources of SPAN traffic. Ports and VLANs cannot both be used as sources for the same session.
To associate a source port and a destination port with a SPAN session, use the <code><b>monitor session</b> <i>number</i> \{<b>source</b>|<b>destination</b>} \{<b>interface</b> <i>interface</i> | <b>vlan</b> <i>vlan</i>\}</code> global configuration command.
Verify the SPAN session via the <code><b>show monitor</b></code> command.
## IPS Signatures
Malicious traffic displays distinct characteristics or “signatures”.
Signatures have three distinctive attributes:
* **Type** - Atomic (single-packet) or Composite (multi-packet)
* **Trigger** - Also called the alarm
* **Action** - What the IPS will do in response
There are four general IPS signature trigger categories:
| Detection Type | Definition |
| -------------- | ---------- |
| **Pattern-Based Detection** | Simplest triggering mechanism as it searches for specific and pre-defined atomic or composite patterns, and triggers an alarm or prevents communication if a match is found. |
| **Anomaly-Based Detection** | Involves first defining a profile of what is considered normal network or host activity, usually defined by monitoring traffic and establishing a baseline. Once defined, any activity beyond a specified threshold in the normal profile will generate a signature trigger and action. |
| **Policy-Based Detection** | Although similar to pattern-based detection, in this case an administrator manually defines behaviors that are suspicious based on historical analysis. The use of policies enables a single signature to cover an entire class of activities without having to specify each individual situation. |
| **Honey Pot-Based Detection** | Uses a decoy server to distract attackers. This allows administrators time to analyze incoming attacks and malicious traffic patterns to tune their sensor signatures. |
## Snort IPS
### Step 1. Download the Snort OVA File
The Snort service OVA file is not bundled with the Cisco IOS XE Release images installed on the router. However, if the OVA file is be preinstalled in the flash of the router, it is recommended that the latest OVA file be downloaded from Cisco.com.
### Step 2. Install the Snort OVA File
```pug
R1# virtual-service install name MYIPS package flash:iosxe-utd.16.09.06.1.0.10_SV29130_XE_16_9.ova
! Installing package 'bootflash:/iosxe utd.16.09.06.1.0.10_SV29130_XE_16_9.ova' for virtual-service 'MYIPS'.
!
R1#
! *Oct 5 08:07:45.953: %VMAN-5-PACKAGE_SIGNING_LEVEL_ON_INSTALL: R0/0: vman: Package 'iosxe-utd.16.09.06.1.0.10_SV29130_XE_16_9.ova'
!
R1#
```
Use the <code><b>show virtual-service list</b></code> command to display the status of the installation of all applications installed on the virtual service container.
### Step 3. Configure Virtual Port Group Interfaces
Two VirtualPortGroup (VPG) interfaces must then be configured along with their guest IP addresses.
```pug
R1# configure terminal
R1(config)# interface VirtualPortGroup0
R1(config-if)# description Management interface
R1(config-if)# ip address 209.165.201.1 255.255.255.252
R1(config-if)# exit
R1(config)#
*Oct 5 08:13:10.970: %LINEPROTO-5-UPDOWN: Line protocol on Interface VirtualPortGroup0, changed state to up
R1(config)#
R1(config)# interface VirtualPortGroup1
R1(config-if)# description Data interface
R1(config-if)# ip address 192.168.0.1 255.255.255.252
R1(config-if)# exit
R1(config)#
*Oct 5 08:13:12.921: %LINEPROTO-5-UPDOWN: Line protocol on Interface VirtualPortGroup1, changed state to up
R1(config)#
```
### Step 4. Activate Virtual Services
Configure guest IPs on the same subnet for the container side and activate the virtual service.
```pug
R1(config)# virtual-service MYIPS
R1(config-virt-serv)# vnic gateway VirtualPortGroup0
R1(config-virt-serv-vnic)# guest ip address 209.165.201.2
R1(config-virt-serv-vnic)# exit
R1(config-virt-serv)# vnic gateway VirtualPortGroup1
R1(config-virt-serv-vnic)# guest ip address 192.168.0.2
R1(config-virt-serv-vnic)# exit
R1(config-virt-serv)# activate
R1(config-virt-serv)# exit
R1(config)#
```
### Step 5. Configure Snort Specifics
```pug
R1(config)# utd engine standard
R1(config-utd-eng-std)# logging host 10.10.10.254
R1(config-utd-eng-std)# logging syslog
R1(config-utd-eng-std)#
R1(config-utd-eng-std)# threat-inspection
R1(config-utd-engstd-insp)# threat {protection|detection}
R1(config-utd-engstd-insp)# policy {balanced|connectivity|security}
R1(config-utd-engstd-insp)#
R1(config-utd-engstd-insp)# signature update occur-at daily 0 0
R1(config-utd-engstd-insp)# signature update server cisco username Bob password class
R1(config-utd-engstd-insp)# logging level warning
R1(config-utd-engstd-insp)#
R1(config-utd-engstd-insp)# exit
R1(config-utd-eng-std)# exit
R1(config)#
```
### Step 6. Enable IPS Globally or on Desired Interfaces
```pug
R1(config)# utd
R1(config-utd)# all-interfaces
R1(config-utd)#
R1(config-utd)# engine standard
R1(config-engine-std)# fail {open|close}
R1(config-engine-std)# exit
R1(config-utd)# exit
R1(config)#
```
### Step 7. (Optional) Configure Allowed Signatures
```pug
R1(config)# utd threat-inspection whitelist
R1(config-utd-whitelist)# signature id 21555 comment traffic from Branch 1
R1(config-utd-whitelist)#
```
### Step 8. Verify Snort IPS
After Snort IPS is implemented, it is necessary to verify the configuration to ensure correct operation:
* <code><b>show virtual-service list</b></code> — The command displays an overview of resources that are utilized by the applications.
* <code><b>show virtual-service detail</b></code> — The command displays a list of resources that are committed to a specified application, including attached devices.
* <code><b>show utd engine standard config</b></code> — The command displays the UTD configuration.
* <code><b>show utd engine standard status</b></code> — The command displays the status of the UTD engine.
* <code><b>show platform hardware qfp active feature utd stats</b></code> — The command checks the data plane. It verifies increments for encap, decap, redirect, and reinject and displays a health of "Green".
---
---
{%hackmd 7PGmjAHeTXak2VUM3iw5Wg %}