Cisco AAA/802.1x Configuration Template

This post provides configuration template for a Cisco switch interacting with Clearpass NAC for AAA/802.1x setup. This has been tested out in a Cisco C9300/9500 switch running 16.12.x code version in a multi-vrf environment. 

#Enable AAA:
aaa new-model

#Define Radius Server:
radius server CLEARPASS-DC-1
 address ipv4 10.10.10.10 auth-port 1645 acct-port 1646
 key <KEY HERE>

#Create Radius Server Group:
aaa group server radius CLEARPASS
 server name CLEARPASS-DC-1
 ip vrf forwarding NETWORK_VRF
 ip radius source-interface Loopback0

#Load balancing:
radius-server load-balance method least-outstanding

#Change of Authorization:
aaa server radius dynamic-author
 client 10.10.10.10 server-key <KEY HERE>

#AAA Radius Configuration:
aaa authentication dot1x default group CLEARPASS
aaa authorization network default group CLEARPASS
aaa accounting dot1x default start-stop group CLEARPASS
aaa accounting update newinfo

#Radius Attributes:
radius-server attribute 6 on-for-login-auth
radius-server attribute 8 include-in-access-req
radius-server attribute 25 access-request include
radius-server dead-criteria time 10 tries 3
radius-server deadtime 5
radius-server vsa send authentication
radius-server vsa send accounting

#Enable 802.1x:
dot1x system-auth-control
authentication mac-move permit

Reference: https://www.ciscozine.com/dot1x-global-configuration-deployment-guide/

F5 Failover in AWS

F5 requires IMDSv1 in order to initiate failover between two F5 devices. IMDSv1 is susceptible to SSRF vulnerabilities as indicated in the AWS document. If IMDSv1 is disabled in AWS environment for security reasons, F5 failover will not be seamless and the F5 logs will have errors like this:

err logger[15542]: /usr/libexec/aws/aws-failover-tgactive.sh (traffic-group-1): Instance sanity check failed with error:

F5 is tracking support for IMDSv2 in AWS internally using ID 968657

F5 BIG-IP iControl REST vulnerability CVE-2022-1388

The vulnerability CVE-2022-1388 has a score of 9.8. Code upgrade to mitigate this vulnerability has been provided in the F5 knowledge article in the reference. The most important step is to restrict access to the F5 Self and Management IP addresses. Other than the mitigation provided in the K23605346, these configuration steps will help to reduce the attack surface:

This will allow the self-IP addresses on the F5 devices to listen on udp:1026 and tcp:4353 which are required for configuration sync and failover between F5 devices. In order to implement this, you should not be using the self-IP addresses for any management access (22/80/443 ports).

list net self all allow-service

Configuration Changes:

modify net self all allow-service replace-all-with { udp:1026 tcp:4353 }

This will limit access to httpd from source IP address of 192.168.0.0/255.255.0.0. As a quick note, this does not mitigate the vulnerability but it is a good practice to limit access to httpd only from specific internal IP addresses.

list /sys httpd allow

Configuration Changes:

modify sys httpd allow add { 192.168.0.0/255.255.0.0 }

The following set of configuration will create a set of filters on the management IP address and limits access to the management IP address for specific services like dns, ntp, snmp, https and ssh. This will reduce the attack surface on the management IP address.

list security firewall management-ip-rules

Configuration Changes:

modify /security firewall management-ip-rules rules add { mgmt-udp-access { action accept destination { ports add { 53 161 123 1026 } } ip-protocol udp log yes place-before first source { addresses add { 192.168.0.0/255.255.0.0} } status enabled uuid auto-generate } }

modify /security firewall management-ip-rules rules add { mgmt-tcp-access { action accept destination { ports add { 22 53 161 443 4353 } } ip-protocol tcp log yes place-before first source { addresses add { 192.168.0.0/255.255.0.0 } } status enabled uuid auto-generate } }

modify /security firewall management-ip-rules rules add { mgmt-deny-all { action drop destination {} source {} log yes place-after last status enabled uuid auto-generate }}

Reference:

https://support.f5.com/csp/article/K23605346

https://www.bleepingcomputer.com/news/security/cisa-tells-federal-agencies-to-fix-actively-exploited-f5-big-ip-bug/

Nornir – macOS Big Sur

I had a simple backup script (backup-script.py) for a multiple vendor device environment. The script was working fine before and failed after I upgraded my mac OS to Big Sur, 11.0.1.

macOS Big Sur, 11.0.1
Python 3.8.6

Traceback (most recent call last):
  File "backup-script.py", line 2, in 
    from nornir import InitNornir
  File "/Users/lib/python3.8/site-packages/nornir/__init__.py", line 3, in 
    from nornir.init_nornir import InitNornir
  File "/Users/lib/python3.8/site-packages/nornir/init_nornir.py", line 8, in 
    from nornir.plugins.connections.napalm import Napalm
  File "/Users/lib/python3.8/site-packages/nornir/plugins/connections/napalm.py", line 3, in 
    from napalm import get_network_driver
  File "/Users/lib/python3.8/site-packages/napalm/__init__.py", line 3, in 
    from napalm.base import get_network_driver
  File "/Users/lib/python3.8/site-packages/napalm/base/__init__.py", line 27, in 
    from napalm.base.base import NetworkDriver
  File "/Users/lib/python3.8/site-packages/napalm/base/base.py", line 21, in 
    from netmiko import ConnectHandler, NetMikoTimeoutException
  File "/Users/lib/python3.8/site-packages/netmiko/__init__.py", line 8, in 
    from netmiko.ssh_dispatcher import ConnectHandler
  File "/Users/lib/python3.8/site-packages/netmiko/ssh_dispatcher.py", line 4, in 
    from netmiko.a10 import A10SSH
  File "/Users/lib/python3.8/site-packages/netmiko/a10/__init__.py", line 2, in 
    from netmiko.a10.a10_ssh import A10SSH
  File "/Users/lib/python3.8/site-packages/netmiko/a10/a10_ssh.py", line 4, in 
    from netmiko.cisco_base_connection import CiscoSSHConnection
  File "/Users/lib/python3.8/site-packages/netmiko/cisco_base_connection.py", line 3, in 
    from netmiko.base_connection import BaseConnection
  File "/Users/lib/python3.8/site-packages/netmiko/base_connection.py", line 32, in 
    from netmiko.utilities import (
  File "/Users/lib/python3.8/site-packages/netmiko/utilities.py", line 9, in 
    import serial.tools.list_ports
  File "/Users/lib/python3.8/site-packages/serial/tools/list_ports.py", line 29, in 
    from serial.tools.list_ports_posix import comports
  File "/Users/lib/python3.8/site-packages/serial/tools/list_ports_posix.py", line 31, in 
    from serial.tools.list_ports_osx import comports
  File "/Users/lib/python3.8/site-packages/serial/tools/list_ports_osx.py", line 32, in 
    kIOMasterPortDefault = ctypes.c_void_p.in_dll(iokit, "kIOMasterPortDefault")

Reinstalling pyserial fixed the problem. 

pip3 uninstall pyserial
pip3 install pyserial

Throughput

Consider a link between two routers with bandwidth of 1Gbps and RTT of 200ms.

The maximum throughput of the link is 1Gbps (Bandwidth). In a normal link, the throughput will be lower than the bandwidth because of overhead in transmission and loss.

Assuming there is zero loss in the network, the maximum possible window size in order to maximize the throughput is provided by the Bandwidth * Delay product (BDP).  This is also the buffer that is allocated on the client and server side for receiving data.  For a bandwidth of 1Gbps and 200ms RTT, the BDP is (10^8)*(0.2) = 20Mbit or 2.5MByte.

Throughput for a single TCP session is (Window Size / RTT). Assuming a window size of 60,000Byte, throughput will be (60,000/.2) = 300,000Byte/s or 2.4Mbps. Increasing the throughput for a TCP connection can be done increasing the window size by utilizing window scaling.

For a link with losses, maximum data throughput will be less than (MSS/RTT)*(1 / sqrt(p)), according to the Mathis formula. 

Max DATA throughput rate < (MSS/RTT)*(1 / sqrt(p))

In order to increase throughput for a single TCP connection, the window size and MSS can be increased, RTT can be lowered (CDN usage), reduce loss percentage (p) by using a reliable link.

Basics – IPSec VPN

The following article is a brief introduction to IPSec VPN that is utilized to provide a logical connection between 2 sites (Site to Site) or a client and a site (Client to Site). The article is written to provide the key terms behind IPSec VPN implementation in a Cisco ASA Firewall or any other similar device.

IPSec Virtual Private Network (VPN) provides the following services:

  1. Authentication
  2. Confidentiality
  3. Integrity
  4. Anti-Replay

Internet Security Association and Key Management Protocol (ISAKMP):

  1. ISAKMP is a Framework for secure communication channel.
  2. Specifies that authentication/keying should occur.
  3. Procedures to negotiate, establish, modify and delete Security Associations (SA).

ISAKMP is the framework and IKE is the actual implementation of ISAKMP framework.

Internet Key Exchange (IKE):

There are 2 main versions of IKE – IKEv1 and IKEv2. In this document, we will stick with IKEv1.   IKE runs over UDP 500 and consists of 2 Phases.IKE Phase I can utilize either one of 2 modes – Main or Aggressive mode in order to establish ISAKMP SA. IKE Phase II utilizes Quick Mode in order to establish IPSec SA.

Phase I:

Establish a secure communication channel (SA) through verification and authentication of peer.

The following is performed during Phase I:

  1. Encryption and hashing algorithm are negotiated.
  2. Session key parameters using Diffie-Hellman (DH) are negotiated.
  3. Negotiate authentication and peer is authenticated.
  4. ISAKMP SA is established in Phase I . Only one SA (bidirectional) is setup for Phase I.
  5. Two Modes possible in Phase I. Main mode & Aggressive mode.

Phase II:

  1. Establish IPSec SA and protect communication between peers for secure symmetric key distribution/data communications.
  2. Pre-shared keys, Public Key Signatures and RSA encryptions are different authentication methods used.
  3. Quick mode occurs during IPSec Phase II SA establishment.

Main Mode:

  1. Initiator peer sends acceptable encryption/authentication algorithm.
  2. Responder Peer chooses to accept or not accept the proposed encryption/authentication algorithm. If accepted, negotiation continues.
  3. Initiator sends key and nonces (anti-replay).
  4. Responder responds with it DH key and nonces.
  5. Initiator signature, ID & shared key/certificate.
  6. Responder responds with its signature, ID & shared key/certificate.

1-4 steps are unencrypted and in the clear. 5-6 steps happen after in an encrypted environment.

Aggressive Mode:

  1. Originator provides keys (pre-shared keys/certificate) IKE-ID, nonce and encryption/authentication proposal.
  2. Responding peer: Key exchange, IKE_ID, nonces, encryption/authentication.
  3. Originating signature, hash and IKE_ID

IKE Phase II:

  1. Security protocol (AH/ESP)
  2. Algorithms for encryption and hashing.
  3. Proxy ID (Subnets)
  4. Perfect Forwarding Secret (PFS) Support.

Quick Mode: Two IPSec SA created. One in each direction.

IPSec uses the following protocols to perform various functions:

  • Authentication Header (AH)
  • Encapsulating Security Payloads (ESP)
  • Security Associations (SA).

AH: IP protocol 50. Supports Authentication & Integrity.

ESP: IP Protocol 51. Supports Authentication, Integrity, Encryption and Anti-replay.

IPSec Modes of Operation:

Transport Mode:

Only the payload of the IP packet is usually encrypted and/or authenticated.

Tunnel Mode:

The entire payload of the IP packet is usually encrypted and/or authenticated. Dynamic / Static NAT will work natively with ESP-Tunnel Mode.

Ansible hostfile Deprecated

While using Ansible 2.4.3 for the very first time after upgrading, I received the following error:

[DEPRECATION WARNING]: [defaults]hostfile option, The key is misleading as it can also 
be a list of hosts, a directory or a list of paths . This feature will be removed in 
version 2.8.

It looks like if you have hostfile = ./hosts within the ansible.cfg file, you would have to change it to inventory = ./hosts

Reference Link.

Serial Number – Viprion Blades and Chassis

# clsh tmsh show sys hardware | grep 'Host Board Serial'

The above command is run from bash shell on the F5 in order to identify the serial number of all the blades in an F5 Viprion device.

# tmsh show sys hardware | grep 'Chassis Serial'

The above command is run from bash shell on the F5 in order to identify the serial number of the chassis in an F5 Viprion device.