Cisco 300-720 SESA cheat sheet

Deployment modes: physical appliance, virtual appliance (ESAv), and cloud. AsyncOS is the shared OS; CLI access via SSH, serial console, or the web GUI on HTTPS (default port 443, admin user).

Initial setup via the System Setup Wizard requires: network settings (IP, gateway, DNS), hostname, default gateway, and at least one listener. A listener binds an interface/port to a mail flow policy.

Two upgrade methods: CLI upgrade (from configured update servers or a URL) and GUI System Administration > System Upgrade. upgrade list shows available async versions; upgrade prompts for reboot.

Configuration backup: saveconfig writes the current config to a file; loadconfig restores it. Backups are version-specific - restoring a config to a different AsyncOS major version can fail.

Commit model: GUI changes stage in memory until you click Commit Changes; uncommitted changes are lost on reboot. CLI requires commit after config commands. commitdetail shows pending diffs.

Cluster architecture: a cluster contains groups; a group contains appliances. Settings can be cluster-wide, group-wide, or machine-specific. The Centralized Management appliance (SMA) is separate from ESA clustering.

Feature keys are per-appliance and tied to the serial number. featurekey (CLI) or System Administration > Feature Keys shows installed keys; missing keys disable features like DLP, IronPort Anti-Spam, or Sophos/AMP.

Log subscriptions: logconfig creates a subscription (e.g., mail_logs, gui_logs) delivered to syslog, file, or FTP. tail and grep filter live logs; showlogs lists available log files.

High availability uses a pair of appliances with a shared IP; failover occurs when the primary loses network or the Group fails. HA requires identical AsyncOS versions and matching listener configs.

SPF: the sending domain publishes a TXT record listing authorized sending IPs. ESA validates inbound SPF only if the listener's mail flow policy has SPF verification enabled; result appears in spf-pass, spf-fail, etc. Received headers.

DKIM signing: ESA signs outbound mail with a private key; the public key is published as a TXT record at <selector>._domainkey.<domain>. Signing profile is configured under Mail Policies > Signing Profiles.

DKIM verification: inbound messages are verified against the sender's DNS record. A dkim=fail or dkim=pass result is added to the Authentication-Results header. Verification requires the DKIM feature key.

DMARC: policy published at _dmarc.<domain> tells receivers what to do when SPF and DKIM both fail (none/quarantine/reject). ESA can enforce DMARC via a content filter or the DMARC verification feature; alignment matters, not just pass.

Inbound authentication order: SPF is checked at connection/mail flow policy level; DKIM and DMARC are checked during message processing. Results are stamped in Authentication-Results and can drive content filters.

TLS encryption: configure a certificate (Mail Policies > Certificate Management) and enable TLS on the listener. tls CLI command manages certificates; certconfig sets the listener certificate.

Opportunistic TLS vs. required TLS: opportunistic attempts TLS and falls back to cleartext; required TLS rejects the connection if TLS cannot be negotiated. Configure per destination domain under Mail Policies > Destination Controls.

Message encryption options: TLS (transport), S/MIME (end-to-end, requires certificates), and Cisco Secure Email Encryption (CRES) for message-level encryption with a hosted key service.

Outbound DKIM signing requires the signing key pair generated on the ESA (dkimconfig) and the public key published in DNS. The selector must match the DNS record name exactly.

IronPort Anti-Spam (IPAS) assigns a spam score to each message. Thresholds are set per mail flow policy (e.g., POSITIVE, SUSPECT, NEGATIVE). SUSPECT messages can be quarantined; POSITIVE are typically dropped or tagged.

Sophos Anti-Virus scans attachments and message bodies. Virus-infected messages can be dropped, quarantined, or cleaned. Scanning is enabled per mail flow policy under the Virus policy.

Outbreak Filters (OF) use Cisco Talos threat data to catch zero-day and targeted attacks before signatures exist. Outbreak quarantine holds suspicious messages for a configurable time; outbreakconfig sets thresholds.

Outbreak Filters use a threat level (0-5) and per-policy settings. Higher threat levels lower the threshold, quarantining more messages. Quarantine retention is set by outbreakconfig (default often 1 hour).

Grapevine: the ESA can publish and subscribe to reputation/host data across appliances. grapevineconfig manages it; useful for sharing spam and outbreak intelligence in a cluster.

Reputation Filtering (SenderBase) scores the sending IP. A low reputation score can cause connection throttling or rejection at the listener. Configured via mail flow policy > Reputation.

Quarantine types: Spam, Virus, Outbreak, Policy, and Message (DLP) quarantines. Each has its own retention and release rules; quarantineconfig manages them.

Content filters and message filters can invoke anti-spam/anti-virus actions. antispamconfig and antivirusconfig set global defaults; per-policy overrides live in the mail flow policy.

False positive handling: released messages from quarantine can be used to train the anti-spam engine. quarantine release actions include deliver, delete, and forward.

Content filters match on message attributes (subject, body, attachment, sender, recipient) and apply actions (drop, quarantine, add header, notify, BCC). Filters are ordered; the first matching filter's action runs unless the filter continues.

Message filters are CLI-created (filters command) and use a different syntax than GUI content filters. They run at the message level and can call quarantine, drop, bounce, notify, and bcc.

Mail flow policies apply per listener and per sender/receiver group. They control TLS, SPF, anti-spam/anti-virus, and connection limits. Default policy applies when no other policy matches.

DLP: Data Loss Prevention policies use classifiers (predefined patterns for credit cards, SSNs, etc.) and custom classifiers. A DLP policy has a severity and an action (quarantine, drop, encrypt, notify).

DLP policy order matters: the first matching policy with the highest severity wins. DLP can be applied inbound and outbound; outbound DLP is the typical use case for data exfiltration prevention.

DLP classifiers: predefined (e.g., credit card numbers, U.S. SSNs) and custom (regex or content match). Custom classifiers are created under Data Loss Prevention > Classifiers.

Content filter actions include: drop(), quarantine(), add-header(), notify(), bcc(), encrypt(), deliver(). Actions can chain with and in message filters.

Policy quarantine: messages matching a DLP or content filter can be held in the Policy quarantine for admin review. Release requires an admin action; retention is configurable.

Bypass rules: DLP and content filters can be bypassed by trusted senders or specific domains. Bypass lists are configured per policy and evaluated before matching.

SMTP routing: use smtproutes to send mail for a domain to a specific host. Default route handles all other domains. Useful for hybrid deployments (e.g., route to Exchange or O365).

LDAP integration: configure an LDAP server profile under System Administration > LDAP. Used for recipient validation, authentication (SMTP AUTH), and directory-based policies. ldapconfig manages profiles.

Recipient validation: the ESA can query LDAP or use call-ahead verification to reject unknown recipients at SMTP time, reducing backscatter. Configured per listener/mail flow policy.

Troubleshooting tools: tail mail_logs, grep, hoststatus, nslookup, ping, traceroute, telnet (SMTP test), and topin for connection inspection. showstatus gives system health.

Message tracking: the Message Tracking feature (trackingconfig) records message events (received, delivered, bounced). Search by sender, recipient, or message ID in the GUI under Message Tracking.

Common failure: TLS negotiation fails - check certificate validity, expiration, and cipher support. tls CLI shows certificate status; logs show tls errors in mail_logs.

Common failure: mail stuck in queue - check hoststatus for destination reachability, DNS resolution, and smtproutes. queue and workqueue commands inspect and manage queued messages.

Integration with Cisco Secure Email and Web Manager (SMA): centralizes quarantine and reporting. The ESA registers with the SMA via a shared secret; sma CLI configures the connection.

SNMP and syslog: snmpconfig sets traps/community strings; logconfig forwards logs to a syslog server. Verify connectivity with telnet <syslog-host> 514.