HackMD
Network Security Configuration
- Cisco AutoSecure
- Dynamic Routing Protocol Security
- MAC Overflow Attacks – Port Security
- VLAN Attacks
- DHCP Attacks – DHCP Snooping
- ARP Attacks - Dynamic ARP Inspection
- Address Spoofing Attacks – IP Source Guard
- STP Manipulation Attacks - PortFast/BDPU Guard
- Network Monitoring
- Network Taps
- Traffic Mirroring with SPAN
- IPS Signatures
- Snort IPS
- Step 1. Download the Snort OVA File
- Step 2. Install the Snort OVA File
- Step 3. Configure Virtual Port Group Interfaces
- Step 4. Activate Virtual Services
- Step 5. Configure Snort Specifics
- Step 6. Enable IPS Globally or on Desired Interfaces
- Step 7. (Optional) Configure Allowed Signatures
- Step 8. Verify Snort IPS
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
Link Layer Discovery Protocol
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.
MD5 is now considered vulnerable to attacks and should only be used when stronger authentication is not available.
To enable OSPF MD5 authentication globally:
- issue the
ip ospf message-digest-key key md5 passwordglobal configuration command. - Issue the
area area-id authentication message-digestrouter configuration command.
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:
- issue the
ip ospf message-digest-key key md5 passwordinterface configuration command. - Issue the
ip ospf authentication message-digestinterface configuration command.
The interface setting overrides the global setting.
SHA Authentication
To enable OSPF SHA authentication globally:
- issue the
key chainglobal configuration command. - Assign the key chain a number and a password with the
keyandkey-stringcommands. - Specify SHA authentication with the
cryptographic-algorithmcommand. - (Optional) Configure when the key will expire via the
send-lifetimecommand. - Assign the new authentication key to the desired interfaces via the
ip ospf authentication key-chaincommand.
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.
Use the show port-security command to display the current port security settings.
After port security is enabled, other port security specifics can be configured.
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:
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:
Dynamically
When the switchport port-security 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:
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:
The options for the command are described below:
| Parameter | Description |
|---|---|
static |
Enable aging for statically configured secure addresses on this port (by default these are excluded from aging out). |
time time |
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. |
type absolute |
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. |
type inactivity |
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:
The following tables show how a switch reacts based on the configured violation mode:
| Mode | Description |
|---|---|
shutdown (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 shutdown and no shutdown commands. |
restrict |
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. |
protect |
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 shutdown command, then, use the no shutdown command to make the port operational:
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 mac address-table notification global configuration command to enable the MAC address notification feature on a switch.
Verify Port Security
Port Security for All Interfaces
Port Security for a Specific Interface
Verify Learned ("sticky") MAC Addresses
Verify Secure MAC Addresses
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:
- Disable DTP (auto trunking) negotiations on non-trunking ports by using the
switchport mode accessinterface configuration command. - Disable unused ports and put them in an unused VLAN.
- Manually enable the trunk link on a trunking port by using the
switchport mode trunkcommand. - Disable DTP (auto trunking) negotiations on trunking ports by using the
switchport nonegotiatecommand. - Set the native VLAN to a VLAN other than
VLAN 1by using theswitchport trunk native vlan vlan_numbercommand.
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.
See VLAN Management 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.
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:
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
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.
Configure DHCP Snooping on trusted ports to limit DHCP attacks:
- Enable DHCP snooping by using the
ip dhcp snoopingglobal configuration command. - On trusted ports, use the
ip dhcp snooping trustinterface configuration command. - Limit the number of DHCP discovery messages that can be received per second on untrusted ports by using the
ip dhcp snooping limit rateinterface configuration command. - Enable DHCP snooping by VLAN, or by a range of VLANs, by using the
ip dhcp snooping vlanglobal configuration command.
Use the show ip dhcp snooping privileged EXEC command to verify DHCP snooping and show ip dhcp snooping binding to view the clients that have received DHCP information:
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.
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.
DAI requires the DHCP snooping binding table to operate.
DAI can also be configured to validate the destination or source MAC and IP addresses:
Only one ARP validation configuration can exist at a time. Entering another ip arp inspection validate command will overwrites the previous configuration. To include more than one validation method, enter them as a single command:
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 ip verify source interface configuration command.
Like Dynamic Arp Inspection, IPSG requires DHCP Snooping, which can be enabled via the ip dhcp snooping global configuration command.
Verify IPSG via the show ip verify source 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.
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.
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 spanning-tree portfast interface configuration command. Alternatively, Portfast can be configured globally on all access ports by using the spanning-tree portfast default global configuration command.
To verify whether PortFast is enabled globally you can use either the show running-config | begin span command or the show spanning-tree summary command.
BDPU Guard
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.
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 errdisable recovery cause bpduguard global command.
BPDU Guard can be enabled on a port by using the spanning-tree bpduguard enable interface configuration command. Alternatively, use the spanning-tree portfast bpduguard default global configuration command to globally enable BPDU guard on all PortFast-enabled ports.
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 spanning-tree guard root 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 show spanning-tree inconsistent ports 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 spanning-tree guard loop interface configuration command.
Loop Guard can also be enabled globally using the spanning-tree loopguard default global 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 monitor session number {source|destination} {interface interface | vlan vlan} global configuration command.
Verify the SPAN session via the show monitor 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
Use the show virtual-service list 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.
Step 4. Activate Virtual Services
Configure guest IPs on the same subnet for the container side and activate the virtual service.
Step 5. Configure Snort Specifics
Step 6. Enable IPS Globally or on Desired Interfaces
Step 7. (Optional) Configure Allowed Signatures
Step 8. Verify Snort IPS
After Snort IPS is implemented, it is necessary to verify the configuration to ensure correct operation:
show virtual-service list— The command displays an overview of resources that are utilized by the applications.show virtual-service detail— The command displays a list of resources that are committed to a specified application, including attached devices.show utd engine standard config— The command displays the UTD configuration.show utd engine standard status— The command displays the status of the UTD engine.show platform hardware qfp active feature utd stats— The command checks the data plane. It verifies increments for encap, decap, redirect, and reinject and displays a health of "Green".
