PermitANY

Cisco ASA Security Hardening

Cisco ASAIntermediate

CIS-aligned hardening template for Cisco ASA: disable unused services, enforce strong SSH/TLS, enable threat detection, configure logging, and lock down management access.

↓ example.txt

What is it?

ASA hardening reduces the attack surface of your firewall by disabling services you don't need, enforcing strong encryption for management protocols, and enabling built-in threat detection. A default ASA installation has several features enabled that are not needed in most environments — SNMP with default community strings, HTTP/ASDM, Telnet, and weak SSH cipher suites. This template follows CIS Cisco ASA Benchmark recommendations and NIST guidelines.

✓ When to use

  • ·Immediately after the base Day-0 configuration — before putting the ASA in production
  • ·After any major OS upgrade — some settings may reset to defaults
  • ·As part of a periodic security audit (quarterly or annually)
  • ·Before a PCI-DSS, ISO 27001, or NIST audit

✗ When NOT to use

  • ·Without testing in a lab first — some hardening steps may affect existing functionality
  • ·Blindly applying all settings without understanding your environment — some settings depend on your specific use case

How it compares

vs Default ASA configDefault config has SNMP enabled with 'public' community, HTTP server enabled, no threat detection, no exec timeout, and weak SSH settings. This template disables all of those.
vs Palo Alto hardeningPalo Alto has strong defaults out of the box (admin account must be changed, HTTPS only, no Telnet). ASA requires more manual hardening steps. Both should go through a CIS Benchmark review.

Prerequisites

  • Base configuration must be complete (hostname, interfaces, management access) before applying hardening
  • Have console access available as a fallback — some hardening steps may lock you out if SSH is misconfigured
  • Document current configuration with 'show running-config' before making changes
  • Test in a maintenance window — hardening changes can disrupt monitoring (SNMP) and management (ASDM)

Config Generator

Only this network can SSH/ASDM into the ASA

Leave empty to disable SNMP

Verification commands

show ssh

Verify SSH is enabled with correct version and allowed sources

Expected: Should show version 2, timeout 10, and the management source network

show threat-detection statistics

Verify threat detection is active and counting events

Expected: Shows counters for scanning threats, bad packets, and rate-limited connections

show logging

Verify logging is enabled and syslog server is configured

Expected: Shows 'Logging: enabled', trap level informational, and the syslog server IP

show run ssl

Verify TLS version is restricted to 1.2+

Expected: Should show 'ssl server-version tlsv1.2' and 'ssl cipher tlsv1.2 high'

Debug commands

show threat-detection scanning-threat shun

Show IPs currently being blocked by scanning threat detection

Legitimate scanners (vulnerability scanners, monitoring tools) may get shunned. Whitelist them with 'threat-detection scanning-threat shun except ip-address <ip>'

Common mistakes & fixes

Locked out of management after applying hardening

Cause: SSH source restriction is too narrow, or management interface is wrong

Fix: Use console access to fix: 'ssh <correct-source> <mask> <interface>'. Verify the management interface nameif matches.

Monitoring system (PRTG, SolarWinds) stopped getting SNMP data

Cause: SNMP was disabled or community string changed

Fix: Re-enable SNMP with the correct community and restrict to your monitoring server IP: 'snmp-server host management <monitoring-ip> community <string>'

Legitimate hosts being shunned by threat detection

Cause: Vulnerability scanner or monitoring tool triggering scanning-threat detection

Fix: Exclude trusted IPs: 'threat-detection scanning-threat shun except ip-address <trusted-ip>'

Related configs