Category: Cisco ASA

IPSec VPN – Key Terms

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

ISAKMP: Internet Security Association and Key Management Protocol

IKE: Internet Key Exchange

IPSec: Internet Protocol Security

ISAKMP is the framework for secure communication channel establishment. IKE is the actual implementation of ISAKMP framework. There are 2 main versions of IKE – IKEv1 and IKEv2. In this article, 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 a ISAKMP SA. IKE Phase II utilizes Quick Mode in order to establish IPSec SA. ISAKMP SA established in IKE Phase I is bidirectional. Two unidirectional IPSec SAs are established in IKE Phase II.

Cisco FirePower 9300

Cisco FP9300 is a chassis based enterprise grade firewall that provides high availability, scalability and throughput over 100+ Gbps depending on the hardware configuration.

A FP9300 chassis can have the following hardware components:

  • Chassis
  • Supervisor Module (SUP, Max 1 per chassis)
  • Security Module (SM, Max 3 per chassis)
  • Network Module (NM, Max 2 per chassis)

FP9300 Chassis

A Supervisor Module has the following ports:

  • RJ45
  • 1G Management Port.
  • 8*10G Built-in Ports

Network Modules (NM) can have the following port configuration:

  • 4*40G
  • 8*10G
  • 2*100G

Sup_NM_FP9300

Supervisor Module:

SUP attaches the SM to the Network.

SUP_HW_Diagram_FP9300

Security Module:

Security Modules (SM) comes in 2 main flavors:

  1. SM-36: 2 CPU, each with 36 cores for a total of 72 cores, 80Gbps
  2. SM-24: 2 CPU, each with 24 cores for a total of 48 cores, 60Gbps

Dual 800GB SSD in Raid-1 by default. SM modules have built-in Smart NIC & Crypto Accelerator.

SM_HW_Diagram_FP9300

Software:

Supervisor Module runs the FXOS software. An agent of the FXOS software will run on each of the Security Modules in order to enable the Supervisor to monitor and manage the SM.

Software_FP9300

Reference:

BRKSEC-3010 – Firepower 9300 Deep Dive (2016 Berlin)

Speaker(s)  Andrew Ossipov – Principal Engineer, Cisco

Cisco ASA – SNMP OID List

# show snmp-server oidlist

————————————————-
[0]    1.3.6.1.2.1.1.1.    sysDescr
[1]    1.3.6.1.2.1.1.2.    sysObjectID
[2]    1.3.6.1.2.1.1.3.    sysUpTime
[3]    1.3.6.1.2.1.1.4.    sysContact
[4]    1.3.6.1.2.1.1.5.    sysName
[5]    1.3.6.1.2.1.1.6.    sysLocation
[6]    1.3.6.1.2.1.1.7.    sysServices
[7]    1.3.6.1.2.1.1.8.    sysORLastChange

<Output Removed>

The above hidden command will provide the oid list in Cisco ASA.

RST & FIN Out of Order

There was a constant increase in “overrun” and “input errors” on the Cisco ASA Interface. Upon examination, using “show asp drop“, “tcp-rstfin-ooo” & “tcp-3whs-failed” were constantly increasing.

ASP-DROP

Using the following to capture real-time traffic, the IP addresses and the ports can be identified:

# capture ASP type asp-drop tcp-rstfin-ooo buffer 2048 real-time

In this case, we were able to isolate port 5666 for Nagios servers as a culprit in sending RST after FIN and this was breaking the TCP protocol. This is an environment with 100s of Servers that was monitored by Nagios. When 100s of Servers end up sending RST simultaneously, it can turn out to be a mini-self-DOS. With older Firewalls & Code Versions, this can cause reboots. When we searched online, we were able to identify the following bugs on Nagios:

https://bugs.launchpad.net/ubuntu/+source/nagios-nrpe/+bug/989156

http://tracker.nagios.org/view.php?id=305

Isakmp Keepalive – Cisco ASA & Checkpoint

Cisco ASA has Isakmp Keepalive Enabled by default. You can see this by running “show run all” and look under the tunnel-group configuration for the specific IPSec tunnel.

 

Default Setting for a tunnel-group:

tunnel-group 10.10.10.10 ipsec-attributes
ikev1 pre-shared-key *****
peer-id-validate req
no chain
no ikev1 trust-point
isakmp keepalive threshold 10 retry 2
no ikev2 remote-authentication
no ikev2 local-authentication

 

Configuration change required to disable isakmp:

tunnel-group 10.10.10.10 ipsec-attributes
isakmp keepalive disabled

 

After Change:

tunnel-group 10.10.10.10 ipsec-attributes
ikev1 pre-shared-key *****
peer-id-validate req
no chain
no ikev1 trust-point
isakmp keepalive disable
no ikev2 remote-authentication
no ikev2 local-authentication

 

Error Message Seen in the Cisco ASA Logs:

Jan 26 05:10:03 [IKEv1]IP = 10.10.10.10, Keep-alives configured on but peer does not support keep-alives (type = None)

 

The following is taken from Cisco documentation link provided:

“If you configure ISAKMP keepalives, it helps prevent sporadically dropped LAN-to-LAN or Remote Access VPN, which includes VPN clients, tunnels and the tunnels that are dropped after a period of inactivity. This feature lets the tunnel endpoint monitor the continued presence of a remote peer and report its own presence to that peer. If the peer becomes unresponsive, the endpoint removes the connection. In order for ISAKMP keepalives to work, both VPN endpoints must support them.”

In some situations, it is necessary to disable this feature in order to solve the problem, for example, if the VPN Client is behind a Firewall that prevents DPD packets.

http://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/81824-common-ipsec-trouble.html#solution07

In my experience, “Isakmp Keepalive” compatibility between vendors – Cisco & Checkpoint specifically doesn’t exist and it is better to disable it rather than leave it enabled on the Cisco ASA. If enabled between incompatible devices, it can lead to the tunnel dropping sporadically without reason.

Cisco ASA Deny Access-List

Does the Cisco ASA send a reset when a packet is denied by configured access-list ?

This depends on the configuration of the access-list – is it applied for inbound or outbound traffic on an interface & if there is any “service reset” command as specified here:

service resetinbound:
Sends TCP resets for all inbound TCP sessions that attempt to transit the adaptive security appliance and are denied by the adaptive security appliance based on access lists or AAA settings.

service resetoutbound: (Default)
Sends TCP resets for all outbound TCP sessions that attempt to transit the adaptive security appliance and are denied by the adaptive security appliance based on access lists or AAA settings.

service resetoutside:
Enables resets for TCP packets that terminate at the least secure interface and are denied by the adaptive security appliance based on access lists or AAA settings.

resetinbound ----> Send reset to a denied inbound TCP packet
resetoutbound ----> Send reset to a denied outbound TCP packet
resetoutside ----> Send reset to a denied TCP packet to outside interface

By default (service resetoutbound), Cisco ASA sends an explicit TCP reset for connections terminating at the Cisco ASA Firewall, if it is denied by access-list that is configured to block outbound connections like this:

access-list OUT line 1 extended deny ip host 1.1.1.1 host 2.2.2.2
access-group OUT out interface outside

For the same access-list, if it is configured for inbound access-list, the connection will be dropped without any discard being sent out:

access-list OUT line 1 extended deny ip host 1.1.1.1 host 2.2.2.2
access-group OUT in interface outside

Reference:

Service Reset – Cisco ASA

Inline IDS, WAF & CDN

Consider the following scenario when we have IDS deployed in “promiscous mode” (not “inline” with the traffic) with the ability to “shun/block” any malicious traffic based on the Client IP in the incoming packet. For any normal Client-Server interaction, malicious client IP will be blocked by the firewall after the IDS detects the attack and informs the Firewall to block the Client IP.

new_vijay_file (1)

If the site is being accessed via a CDN like Akamai, the client IP will be an Akamai IP address and the original client IP will be included in “X-Forwarded-For” header.

What if a Client accessing a site via Akamai starts attacking the site ? The IDS can be configured to auto-block based on the “X-Forwarded-For” header instead of the actual Client IP field. The IDS signature may be triggered and the IDS may send a “block” command to the Firewall.  So, IDS will send “Block <X-Forwarded-For IP>” command to the Cisco ASA Firewall or Cisco IOS Router and this will be implemented as a “shun <X-Forwarded-For IP>” on the Cisco ASA.

However, the Cisco ASA Firewall can block based on the Client IP address field in the incoming packet and not based on the “X-Forwarded-For” header. Thus, the IDS auto-block feature can fail for this specific type of deployment. Of course, you can manually block it or use a WAF 🙂

new_vijay_file (7)

IDS – Intrusion Detection System

WAF – Web Application Firewall

CDN – Content Delivery Network