Cisco IronPort ESA Web User Interface

WUI Tour

The ESA WUI is intended to be straightforward and intuitive. All the menus and menu items should be fairly self-explanatory if you are familiar with email security, MTAs, and general servers. I give you a brief tour and then provide more details for configuration sections that are unique to the Cisco IronPort security appliances.

Monitor Menu

The monitor menu includes all of the pages that provide reports for the ESA. It includes the live, drill-down reporting pages for incoming and outgoing mail, security engines, user statistics, and system monitoring pages. It also includes system quarantines and, if enabled locally, the message tracking page. The monitor menu is shown in Figure 4-1.

Most of the reporting pages are arranged similarly. Each report has a top-level Overview report, with graphs displaying relevant data for the selected time range. The time range drop-down box gives you a choice of past hour, day, week, 30 days, 90 days, previous day, previous month, or a custom time range. If you are using an SMA with its centralized reporting feature, the ESA is limited to past hour, day, and week, because the month, quarter, and year views are only on the SMA. When you choose a time range for reports, all the report and status pages will reflect the time range choice until you change it again.

Almost every report page provides two common elements. Near the upper right is a link called Printable (PDF) that exports the current report view into a PDF document, including all graphs. In many reports, there’s also a link called Export... that can give you a comma-separated values (CSV) file containing the data included in the report. There’s more on this reporting export in Chapter 9, “Automating Tasks.”

Reporting pages do not have a CLI equivalent, with a few noted exceptions.

Overview

As its name suggests, the Overview page provides a summary of all email operations on this ESA. At the top, you’ll see a brief system status, a snapshot of up to three system quarantines ordered by disk usage, and an outbreak status. Below that is a graph and table for Incoming Mail and then below that is Outgoing Mail. Incoming and outgoing follow the general ESA rule for determining email direction: incoming are messages that are accepted; outgoing are messages that are relayed.

Incoming Mail

Incoming mail is the launch point for a variety of pages that cover all the mail accepted by the ESA. The first page you’re brought to from this menu covers mail received by the ESA, sorted by the domain of the connecting hosts. There are also IP address and network owner views of the data.

This page, like most of the reports in the ESA WUI, offers a considerable amount of detail in drill-down. For example, if you click a domain in the chart or table, you’ll see a report on email statistics and global sender information for this specific sending domain. If you click the IP address in a domain report, you’ll see the stats for that particular IP. All these reports offer an Add to Sender Group... link, which allows you to quickly add the sender to a whitelist, blacklist, or other Host Access Table (HAT) sender group.

One of the hidden gems of the WUI is only available through the default Incoming Mail page: At the bottom is a link for the Sender Groups report, which shows how the ESA has categorized the connections made to the ESA. If you can’t find it, it’s also available through the URL on your ESA:

https://<hostname>/monitor/reports/sender_groups

The sender groups report shows you how the ESA is classifying incoming connections into the sender groups, and the relative percentages and absolute connection count for each group. It won’t show an entry for groups that have no matches, so it can show you when sender conditions aren’t being matched or when your HAT ordering is incorrect. It’s also a great way to report on different senders without necessarily taking specific action. For example, you could use DNS mismatches to categorize senders into a group called DNSMISMATCH that uses the standard ACCEPTED policy. This report will show you the number of connections that meet the conditions for that group.

There’s no drill-down to individual users or messages. For this level of detail, you can look at the Internal Users report or go to Message Tracking.

Outgoing Destinations

Outgoing destinations is the opposite of incoming mail, focusing on destinations of delivered messages rather than their source. The graphs and tables show you where your users are sending messages.

You can sort the columns and choose the number of items displayed, but there’s no further drill-down in this report. For details on messages delivered to a specific destination, go to the Message Tracking page.

Note that this page is historical: It shows messages that have reach a final disposition, either delivered or bounced. For details on messages that are in the process of being delivered or are queued for delivery, see the Delivery Status report.

Outgoing Senders

Outgoing senders provides you with a view of the domains and IP addresses that are responsible for your outgoing mail. This should show you all the groupware and application servers that are using your ESA relay mail flow policies. It can also show you unexpected sources: Hosts in your network that shouldn’t be sending messages directly. Because the table provides statistics on virus and spam filtering, this report is useful for tracking down infected hosts or users.

There is no drill-down available here for more detail. For information on messages sent out by users and hosts in your organization, use the Message Tracking feature.

Delivery Status

Delivery Status provides an ordered list of active destinations in the ESA. Active refers to a destination domain that the ESA has recently or currently queued messages. If there are active recipients for a particular destination, you can Retry All Delivery with a button at the top right.

Drill-down on each destination domain provides a summary of that domain, including the delivery details, time of oldest message, and a historical summary of delivery and bounces. You can force the ESA to make a delivery attempt with the Retry All Delivery button. If the remote destination is rejecting connections with an SMTP 5yz error code, the most recent such error will be displayed here.

The same information is available in the CLI with the commands tophosts and hoststatus. Chapter 6, “Additional Management Services,” has a detailed example of delivery troubleshooting with these commands.

Internal Users

The Internal Users report summarizes both incoming and outgoing mail based on the statistics for your local users. Local user addresses are the senders of email on relay HAT connections, and the recipients of email on accepted HAT connections.

The graphs provide a view of top senders and recipients of email in your organization, and the table below total statistics for individual users by email address. Want to see who receives the most spam? Who sends the most virus-laden messages? Sort the columns in the table here for the view that you want.

You can also drill-down on specific users by clicking their email address. The detail report for a user shows security filtering and content filtering results. The content filter results for a user allow drill-down to a content filter report for that filter.

DLP Incidents

If you have a feature key for the RSA DLP engine and are scanning outgoing email for data loss prevention policy violations, any matches will be recorded here.

DLP match results are similar to content filter matches, with the addition of a severity score that roughly correlates with the number of entity matches in the message. You can drill-down on the policy names to get to a detailed DLP report, which lists local email addresses causing policy matches.

Chapter 15, “Advanced Topics,” covers DLP.

Content Filters

The Content Filters report summarizes content filter matches for incoming and outgoing mail. This report shows the totals for your content filters by name—a good reason to use descriptive names when you create content filters. A content filter match means that either one or all conditions matched, depending on the logic you used in the filter. Any message that matches the filter conditions is considered a match, even if no permanent action is taken.

This feature makes the content filters report wonderfully flexible, allowing you to gather statistics on a wide variety of message conditions that don’t have dedicated reports. If you want to know how many messages are sent out with ZIP file attachments, or those larger than a specific size, or almost any other message condition, simply create a filter with that condition and a low impact action, like Add Header. Matches are recorded for every message where the filter is applied and the condition clause matches.

Drill-down on any filter name shows a graph of match results over time, and a list of internal users whose messages have matched the filter. Clicking the user email address brings you to the Internal Users report for that user.

Outbreak Filters

Outbreak Filters (OF) reports details the type of threat messages acted on by the outbreak filters engine. In versions prior to 7.5, this report is known as Virus Outbreak Filters (VOF). The entries in this report describe the classification of threat messages and the count of messages in each category.

The use of OFs to scan for and stop zero-day viruses, phishing, and malware messages are covered in Chapter 8, “Security Filtering.”

Virus Types

The Virus Types report is a detail of all email attachment viruses that have been sent or received in the current timeframe. It displays the name provided by the AV vendor, and some virus names will vary across different vendors.

The outgoing virus types graph should ideally be empty. If there are hits for outgoing viruses, use the Internal Users or Outgoing Senders reports, or the Message Tracking feature to find the source of these viruses in your organization.

TLS Connections

The TLS Connections report is similar to the Incoming Mail report, but focused on message statistics received over connections that used Transport Layer Security (TLS) to encrypt the SMTP conversation. If you’re not using TLS, the report will be empty.

The goal of this report is to give you a snapshot for how much TLS is being used, and with which senders and recipients. It’s the first place to look if you’re receiving alerts about TLS being required but not available, and a good place to look for senders that you can move from Preferred to Required TLS.

You can drill-down on incoming TLS domains to get a domain-specific TLS report that includes individual sending IP addresses.

System Capacity

System Capacity collects all the operational conditions of the ESA into one place. There are separate pages for the work queue, incoming mail, outgoing mail, and system load, or you can just click the All link to see everything in one page.

These reports are an easy way to zero in on capacity issues, queue backups, and corresponding events. Work queue backups can usually be correlated with a spike in connections, message count, or message size.

System Status

The System Status page collects the current running statistics for the ESA and displays them all in one page. The results are collected at the time the page is requested, so the statistics here will change each time you reload the page.

Most of the gauges are self-explanatory, but the rates and counters warrant a bit of explanation. The rates refer to events per hour, but measured over the last 1, 5, or 15 minutes. The ESA measures the rate at which these events occur and extrapolates the per-hour rate from that measurement period. For example, if the page displays 600 in the 1-minute column for messages received, that means the ESA received 10 messages in 1 minute and extrapolated from that a rate of 600 per hour. You can think of this as somewhat like speed in a car: On the highway, you might say that you’ve been driving at 60 mph for the last minute. Because they measure a longer interval, the 15-minute samples are the most accurate.

The counters are straightforward enough, but have three measures by which they count: reset, uptime, and lifetime. Lifetime is a count from the time when the system was first imaged and shipped, and it can never be reset. Uptime counts events from the last reboot of the system. Reset refers to events since the last time counters were reset, either with the Reset Counters button on this page or the resetcounters command.

You can obtain the same information in the CLI with the command status detail or with the XML status pages. There is more detail on these approaches in Chapter 5, “Command-Line Interface,” and Chapter 9, respectively.

Scheduled Reports

Scheduled Reports is where you schedule any of the previously mentioned reports to be generated on a regular cycle. There are even some scheduled report types, like the domain-based executive summary, that aren’t available anywhere else.

Note that if you are using an SMA for centralized reporting, you should generate scheduled reports there, as they are disabled on the individual ESAs. Because the SMA can generate reports for individual appliances, it’s not necessary to have this on the ESA.

Archived Reports

This page is the historical collection of all the results of the scheduled reports that archive their results. Reports are stored in either PDF or CSV, and the report title link allows you to download it directly to your local computer. You can delete old reports to save space, but the appliance will also do this for you, deleting the oldest reports first when space is limited.

If you aren’t already receiving a copy of reports every day, suggest that, as a minimum, you schedule an Executive Summary and System Capacity report generated on a daily basis for the previous calendar day. You might not examine these reports every day, but having them available will give you some insight into long-term trends. If you’re using the DLP feature, the DLP Incident Summary report is another good daily report to archive.

Quarantines

Quarantines are storage space on the appliance for messages of interest. There are two basic kinds of quarantines. The IronPort Spam Quarantine (ISQ) provides storage for spam or suspected spam messages and optionally allows for direct end user access and management. The other type are system quarantines, which are intended to hold messages for administrator review; there are no end-user access capabilities for system quarantines. Within system quarantines, there is some space reserved for Outbreak Filters quarantining and two quarantines (called Policy and Virus) that are created by default.

This page in the WUI gives you access to the quarantines for message management or, if you have administrator or operator rights, the ability to manage the quarantine settings for space, retention time, and expiration action.

Administrators and operators have the rights to release or delete messages in any quarantine. Guest and Help Desk users do not, but can be granted privileges on a per-quarantine basis. For example, if you create a quarantine called PCI for the purposes of storing messages that contain credit-card numbers, you can grant access to that quarantine to a guest user in your legal department who is responsible for investigations. This type of task delegation allows that person to perform policy review without having other administrative rights.

Many of the quarantine settings are available in the CLI with quarantineconfig, but managing messages in quarantine for release or delete is best done through the WUI.

Message Tracking

Message Tracking is a single, simple interface for searching the ESA history for message events. The search fields allow you to query the history for messages based on sender, recipient, subject, or attachment name, and to restrict the search to specific date and time range. The interface also allows you to search by message event so that you can search for all DLP violations or virus positive messages in the past day, for example.

The results of a search are a summary of all matching messages that can be exported to a CSV file. Every message in the match list has a Show Details link that provides a complete summary of that particular message. This cradle-to-grave report of the message shows the source IP, message sender and recipient, and all the processing details, including the verdicts of the security filtering engines.

If you have an SMA in your environment configured for centralized message tracking, this feature will be disabled on the ESA. The SMA will have message tracking history for all ESAs in the environment.

There’s nothing quite like message tracking in the CLI; however, you can search the text mail logs with CLI commands, like grep, tail, and findevent.

Mail Policies Menu

The Mail Policies menu is where almost all of the controls related to email filtering happens. All the security and content filtering policies are set here, so it’s likely that, as an ESA administrator, the pages on this menu are where you are likely to spend most of your time. The Mail Policies menu is shown in Figure 4-2.

Mail Policies also provides WUI pages for creating and managing the resources, such as DLP policies, notifications, and dictionaries that you will use elsewhere in constructing policies.

Incoming Mail Policies

Incoming Mail Policies graphically displays the filtering steps of the email security pipeline starting with anti-spam.

The ESA pipeline, including incoming and outgoing policies, is covered in Chapter 3, “ESA Email Pipeline.”

The CLI equivalent is policyconfig.

Incoming Content Filters

Content filters are the ESA Swiss army knife with flexible conditions and Boolean logic to identify messages of interest. Content filters must be managed separately for incoming and outgoing traffic.

This WUI page allows you to create and manage a library of filters that you then apply by editing the Content Filters column in Incoming Mail Policies.

The CLI equivalent is buried under policyconfig; after you choose incoming or outgoing policies, you see the filters menu item.

Outgoing Mail Policies

Outgoing mail policies are the inverse of incoming and are similar in function and appearance. There are two key differences. First, the default settings for the outgoing policies are different from those on incoming. This is sensible, because you typically won’t be spam-scanning your outgoing traffic. Second, Outgoing Mail Policies has a column for DLP if you have a license key for that security filtering engine.

The CLI equivalent is also under policyconfig, just like incoming policies.

Outgoing Content Filters

This is the outgoing equivalent of incoming content filters. It uses the same interface and provides the same conditions and actions as incoming content filters.

The CLI equivalent is buried under policyconfig; after you choose incoming or outgoing policies, you see the filters menu item.

Host Access Table (HAT) Overview

The next three menu items are all related and are grouped under the heading HAT. As discussed in Chapter 3, the HAT controls the parameters the ESA uses in the first part of the SMTP server pipeline: connection management, SMTP conversation, and related tasks, like recipient validation.

The HAT is a table composed of two portions: the sender groups and the mail flow policies. Sender groups do just what it sounds like: lumps email senders into groups based on criteria that you specify. Every sender group has a name and one or more entries that define which senders are members of that group. You can do this manually by entering IPs, CIDR ranges, or hostnames, or you can use dynamic categorization like SenderBase Reputation Scores (SBRS), DNS blocklists, or other DNS parameters. For the vast majority of customers, SBRS is the primary means of sender sorting, and sensible defaults are established by the System Setup Wizard or whenever you create a new public listener.

Once a connecting IP is categorized, the mail flow policy associated with the sender groups is applied. Mail flow policies control basic connection behavior as well as rate limits, SMTP responses, TLS, security, authentication, and verification. The mail flow policy has effects on the pipeline deeper than the immediate SMTP connection behavior it dictates.

The HAT offers a good deal of depth, and because it’s such an integral part of the pipeline its features are covered in Chapter 3. The security nature of SBRS and Reputation Filters is covered in Chapter 8.

Each listener on your ESA has its own HAT and, for that reason, the command-line equivalent is in the hostaccess item under the edit menu in listenerconfig.

Mail Flow Policies

Mail flow policies collects all the parameters associated with accepting and handling SMTP connections that are applied to sender groups. It also affects a number of other pipeline components, such as anti-spam and antivirus, by deciding whether such scanning will be performed on messages accepted under this policy.

The HAT and its corresponding mail flow policies are described in Chapter 3.

Exception Table

The exception table is used only for overriding the results of the Sender Verification features in HAT mail flow policies. To use it, you must turn on the Use Sender Verification Exception Table option in one or more mail flow policies.

This table is here because DNS Sender Verification can be problematic. Sender Verification attempts to look up the domain of the email sender of messages in DNS. The logic of this lookup is that you may want to reject messages whose senders don’t exist in DNS and whose messages you can’t reply to. Years ago, before spam and fraud senders got wise, this could be used to discard junk email. Today, these sophisticated senders use legitimate return addresses stolen from other sources, so most junk messages will pass the sender verification step.

The problems with sender verification are that DNS can occasionally return indecisive results, like temporary lookup failures, and queries can timeout. Further, some legitimate senders don’t have their DNS house in order and can fail this test, resulting in your ESA rejecting legitimate messages.

It’s this last problem that the exception table is designed to solve.

Recipient Access Table (RAT)

The Recipient Access Table (RAT) is simple: It controls whether the ESA will accept email for a given recipient, or recipient domain, or not. The default is to reject all recipients at all domains to avoid the ESA being configured as an open relay. During the system setup wizard, you normally specify your local domains for the ESA to accept on incoming mail connections.

If the RAT specifies that a domain or address is to be accepted, you can also specify that LDAP queries be bypassed. The RAT is discussed in more detail in Chapter 3.

An ESA may have more than one RAT, because each listener has one RAT table. As a result, the CLI command equivalent is in the listenerconfig command in the rcptaccess option within the edit command for each listener.

Destination Controls

You can think of destination controls as the opposite of the HAT. This table is where you specify connection and SMTP parameters at the end of the pipeline for delivery. You can modify settings for delivery on a per-domain basis for attributes such as TLS, concurrent connections, messages per hour, and recipients in a unit of time. You can also decide which bounce profile to assign to messages queued for delivery to each destination.

The equivalent CLI command is destconfig. I cover different components of this table in other chapters. Bounce profiles are in Chapter 3, and TLS (encrypted SMTP delivery) is covered in Chapter 12, “Advanced Networking.”

Bounce Verification

Bounce verification is an interesting feature, one that most customers likely won’t need, but a lifesaver for some environments. The purpose is to stop bounce storms, a type of SMTP application layer attack roughly akin to a distributed denial of service (DDOS) attack. Such attacks can be intentional or just a side effect of the spam and fraud messages that traverse the Internet daily.

These attacks take advantage of the fact that SMTP sender address specified in the MAIL FROM command can be forged. If the fraudulent sender uses an address from your organization in their message, you will sometimes get non-delivery records (NDR, or bounces) sent back to your organization. This happens every day, and the occasional bounce message might be confusing to users, but ultimately not terribly harmful. The anti-spam engine on the ESA can often filter these messages.

The harm comes when a fraudulent sender composes tens of millions of these messages, all using the same address in your organization. The result can be millions of bounced messages, sent by many organizations across the globe, all during the same time period. This traffic can swamp even the largest email systems.

Bounce verification can solve this by marking up messages that leave your environment. If these messages bounce, the markup is recognized, and the bounce is accepted by your ESA and delivered. If a bounce arrives at the gateway without the markup, it can be assumed that the original message was not from one of your users and can be rejected. The markup used by bounce verification is actually a modification of the SMTP envelope sender and includes a timestamp and a secret key so that attackers can’t forge the return addresses.

There are a number of potential problems to consider with bounce verification, and I cover it in detail in Chapter 14, “Recommended Configurations.” The CLI command equivalent is bvconfig.

DLP Policy Manager

If you have a license key for the DLP scanning engine, configuration of policies is done here. Like content filters, policies are created in a library and then applied to individual outgoing mail policies.

Prebuilt policies are available for many U.S. Federal and State regulations and some industry-specific ones; others are available for common intellectual property and confidentiality protection needs. In addition, built-in and blank policies are customizable, and you have access to the dictionaries, classifiers, and entities that the RSA DLP engine provides. These entities include content-matching patterns for identifiers from many countries that go beyond regular expressions, such as for payment card numbers, bank routing numbers, social insurance, and drivers’ licenses.

DLP is covered in Chapter 15. There’s no CLI equivalent.

Domain Profiles

Domain Profiles is for managing Domain Keys Identified Mail (DKIM) policies. DKIM is a form of sender authentication that cryptographically signs email messages to prove their provenance. This page allows you to specify which messages are signed, what DKIM options are used, and what signing key is used.

You can also create profiles that use the older Domain Keys (DK) standard, but unless you have a need to support legacy signatures, you should use DKIM.

Chapter 15 covers DKIM and other sender authentication standards. You can manage DKIM keys and profiles in the CLI with domainkeysconfig.

Signing Keys

DKIM signing requires cryptographic public key pairs using the RSA algorithm, and the ESA gives you this page to create and manage your key pairs. Keys can be generated locally or pasted in if you’ve generated them with another tool.

Chapter 15 covers DKIM and other sender authentication standards.

Text Resources

Text Resources is a single place to manage templates for all kinds of administrative and user-facing text. Notifications, disclaimers (footers and headers), encryption text, and even bounce message text can be managed here.

Text messages are created in a library here and then used in other places, like filters, bounce profiles, and antivirus policies. You can create notifications in any language, provided that your browser supports Unicode or other character sets.

Text resources can also make use of a number of action variables that include information from the ESA or from the message being acted on. These include data like message size, senders, recipients, attachment names, filter name, ESA hostname, timestamp, and so on. An action variable is a string beginning with a dollar sign character, such as $bodysize.

The equivalent CLI command is textconfig.

Dictionaries

Dictionaries are lists of words, phrases, and regular expressions that are used for matching content in message or content filters. You can use dictionaries to test simple Boolean logic, such as “does this message match any single entry in this dictionary?” and weighted logic by assigning a score to each dictionary entry and building a filter whose conditions trigger only when the total score match reaches a threshold you specify.

Chapter 11, “Message and Content Filters,” discusses dictionaries in the context of message and content filters. The equivalent CLI for managing dictionaries is dictionaryconfig.

Security Services Menu

The Security Services menu provides global settings and status for all of the optional filtering engines on the ESA. Some menu items only appear here if the corresponding license key is available and active on the system. For example, you won’t see a license for McAfee Antivirus if the key is expired. The Security Services menu is shown in Figure 4-3.

Anti-Spam

The global settings for each engine generally cover size thresholds, timeouts, and other options that apply to the engine as a whole. Specific policy actions are handled in Incoming and Outgoing Mail Policies pages in the Mail Policies menu and, as a result, most configuration for the security and content engines is handled there, not in the Security Services menu.

The Security Services menu does provide a status for each engine, where relevant. This includes the individual engine version, rules database versions, and the timestamp of last update. For anti-spam, the rules are in a number of different databases that are updated independently. You can also manually force an update of rules downloads.

The CLI equivalent is antispamconfig.

Antivirus

There are two possible menu items for antivirus: Sophos and McAfee, depending on which engine technology is licensed on the ESA. It is possible to show both if there is an active license key for each.

The global options are similar for the two antivirus engines. The menu item for each engine also shows the status of latest rules downloads, including the version number and timestamp. You can also manually force an update of rules.

The CLI equivalent is antivirusconfig. Both engines configuration is available under this single command.

RSA Email DLP

If you have a feature key for the RSA DLP engine, you can enable it here. There is also an option to enable or disable Matched Content Logging, which records an excerpt of text that causes a DLP match, and makes it available during message tracking searches.

Matched content logging is extremely useful, but it does expose message content to any user with message tracking privileges.

IronPort Email Encryption

Here, email encryption refers to the message-based envelope encryption that Cisco offers as an optional license key and service. When used as a content filter or DLP action, message contents are encrypted using strong symmetric encryption, and sent to the recipients with that encrypted bundle attached. The recipient can open the message using only a web browser.

The encryption options that are used when a particular message is encrypted are selected by an encryption profile. An encryption profile encapsulates settings such as encryption strength and algorithm, envelope branding logos, notification text, and reply options. You can have multiple encryption profiles on one ESA, for multiple notification types or for multiple brands. If you send encrypted messages from separate divisions within your organization, you may want to have separate brands for each division’s encrypted mail.

Once an encryption profile is created and provisioned, the Encrypt action is available in incoming and outgoing content filters.

IronPort Image Analysis

Image analysis is another optional engine that will only appear here if you have a valid license key. The purpose of this engine is singular: to open and examine image attachments to messages and make a determination of whether the image is business inappropriate. In other words, it determines if a still image is pornographic.

You have a number of configurable options for sensitivity. Image attachments are scored from 0 to 100, with 100 being most likely to contain adult content. This range is broken up into three verdicts: clean, suspected, and inappropriate. You can modify the thresholds here.

The other option is for minimum size threshold, and this is important for two reasons: First, small images, such as icons and logos, are not likely to have adult content, and skipping them avoids any false positives. Second, these icons and logos are common attachments, such as those in email signatures, and skipping them saves a huge amount of work. The default threshold is 100 pixels in either width or height, but I recommend increasing this to 150 or 200, if you plan to use this feature.

Once this engine is enabled, the Image Analysis verdict is available in incoming and outgoing content filters. Because such machine image recognition has an inherent false positive rate, quarantining is the preferred action to take on positive verdicts.

Outbreak Filters

One of the primary functions of the ESA is to keep dangerous messages that contain virus attachments or URL links to virus or malware laden websites out of your environment. The anti-spam and antivirus engines provide most of the filtering, but Cisco created Outbreak Filters (OF) to incorporate one more layer of protection. This type of filtering is usually known as “zero-day” protection, because it can effectively stop newly released malware before antivirus signatures are published.

The global options for OFs are configured on this page, and it also provides a snapshot of the current outbreak rules that the ESA has in place. This list of rules is constantly changing, updated by the ESA automatically every 5 minutes.

As with all the security engines, the configuration provided here is fairly minimal. Most of the configuration options are in the Incoming and Outgoing Mail Policies.

Chapter 8 covers outbreak filters and its interaction with antivirus features. The CLI equivalent is outbreakconfig.

SenderBase

This page provides configuration and status for two separate components lumped together under the name SenderBase. The first is SenderBase Network Participation (SBNP), which allows your ESA to share a limited amount of anonymized data with Cisco, to help improve the security services. For the most part, this data consists of security engine verdicts for Internet IPs, and hashed filenames of message attachments. Not only does this help to improve scores globally, it can provide a boost in capture rates for your environment.

The bottom part of the page shows the connectivity for both SBNP and SBRS lookups. Any problem with a status check here should be investigated.

The CLI equivalents are senderbaseconfig and sbstatus.

Reporting

ESA Reporting (in the Monitor menu) is configured here, and it’s a simple single option: whether to use local or centralized reporting. Centralized reporting provides a single place to look at reports across all of your ESAs and provides more storage for longer-term reports, but it requires that you have a separate Security Management Appliance (SMA), in the Cisco M-series of IronPort appliances.

Unlike with message tracking, using centralized reporting does not completely disable reporting on your ESA. Reporting is still available for past hour, day, and week durations. Longer durations, for past month and year, are only available on the SMA.

The CLI equivalent is reportingconfig.

Message Tracking

As its name implies, message tracking is configured here. The main choice is whether to use local or centralized message tracking. Centralized message tracking provides a single place to look up message history and provides more storage, but it requires that you have a separate SMA. You have the choice of whether to track rejected IP addresses, which allows for more detail, but requires more storage space, which reduces the duration of message history you can track.

The CLI equivalent is trackingconfig.

External Spam Quarantine

This page allows you to enable and define an external end-user IronPort Spam Quarantine (ISQ) host on a separate SMA appliance. If you’re using the ISQ locally on the EUQ, you won’t need this page. You don’t have to quarantine spam messages at all, in fact, and so you may not need this page.

There’s no CLI equivalent.

Service Updates

All the services that dynamically update their rules and engines honor the settings in the Service Updates page of the Security Services menu. This page is also where you would specify a proxy server if the ESA cannot reach Internet destinations on port 80 and 443 directly. The Service Updates are globally set to a 5-minute update interval, and I recommend that this value not be changed. Updates longer than 5 minutes, especially for anti-spam rules, will cause the ESA to miss spam messages. In the ever-changing world of email threats, having timely updates dramatically improves filtering results.

This is also why I do not recommend using a proxy server for downloading updates, preferring instead to allow the ESA direct access on port 80 and 443 to all Internet destinations. In some environments, this may not be preferable from a security perspective, but using a proxy adds one more layer that can potentially fail, reducing effectiveness of filtering and lowering the level of security that the ESA provides to your environment.

Network Menu

The Network menu provides pages for all of the TCP and SMTP network settings. Most of the options here are settings you would establish at the initial installation of the ESA and then rarely configure again, but if you are changing deployments or taking advantage of additional ESA features, you’ll find them useful. Note that there are several networking related areas that are not available in the WUI: physical Ethernet port settings, VLANs, and loopback addresses are in the CLI command etherconfig. Figure 4-4 shows the WUI Network menu.

IP Interfaces

This is where you create and manage the IP addresses and hostnames that your ESA occupies on the network. You can configure multiple IP interfaces on each physical port and even multiple interfaces on a single port.

If you reconfigure or delete an interface that you’re currently using to log into the WUI or CLI, you’ll get a warning about losing access to the appliance. If you delete an interface that has an associated listener or is being used in delivery as a virtual gateway, you’ll get a warning. If you remove all the administrative interfaces on an ESA, you’ll have to resort to access through the console on the serial port.

There are a lot of capabilities related to IP interfaces, and the topic is more thoroughly covered in Chapter 12.

The CLI equivalent is interfaceconfig or, for those with a preference for UNIX commands, ifconfig.

Listeners

Listeners are an SMTP daemon that accepts inbound SMTP connections on an IP interface and port combination. As such, they cover a huge amount of the ESA SMTP server functionality. Each listener has its own HAT and RAT whose settings are covered elsewhere in the WUI, as are LDAP queries that can be tied to a listener.

Because the settings that the listener provides cover a wide range of topics, I address them in different chapters: HAT and RAT in Chapter 3, LDAP in Chapter 7, and multiple interfaces and listeners in Chapter 12.

The CLI equivalent is listenerconfig.

SMTP Routes

SMTP routes controls delivery destinations for email domains. It’s a simple table specifying one or more destinations for an email domain or subdomain. Destinations can be IP addresses or other domains or hosts, and each destination for a given domain has a weight or cost associated with it. If you use weighted routes, the ESA will attempt delivery in order from highest priority (lowest weight) to lowest, failing over only when connection attempts to a host fail. For equally weighted hosts, the ESA load-balances its connections.

Don’t confuse this with IP routing, which is two menu items below. This is only for the purposes of directing messages to their next hop. When delivering email to a destination domain that does not appear explicitly in the SMTP routes table, it drops to the default route, which is usually empty. An empty default route means to use DNS for delivery, and that’s the default for an ESA.

SMTP routes are covered in Chapter 3 as part of the last stage of the pipeline.

The equivalent CLI command is smtproutes.

DNS

DNS is a critical network service for the operation of any MTA, including ESA. Aside from providing the MX record lookups that email delivery requires, DNS queries are also used by reputation filters, sender groups, DNSBLs, and sender verification and authentication features. In short, good DNS is a requirement, and it’s configured here in the WUI. The ESA can act as its own DNS server or you can configure it to make queries to your local DNS servers. For redundancy, you can configure multiple DNS hosts.

More on DNS, especially on more complex split-DNS, is included in Chapter 12. The equivalent CLI command is dnsconfig. The Clear DNS Cache button on the WUI page has an equivalent in the CLI command dnsflush.

Routing

Routing here refers to IP static routing. Because the ESA is not a packet router and does not support dynamic routing protocols, all network destinations that cannot be reached through adjacency will be sent to the default router. To override that behavior, you must provide a static route for any destination network that uses a different gateway.

Because most ESA deployments only have interfaces on one network, it’s not common to need a static route other than the default. Static routing is covered in Chapter 12. The equivalent CLI command is routeconfig. The default gateway for an ESA is configured using setgateway.

SMTP Call-Ahead

SMTP Call-Ahead is an alternative to LDAP for recipient validation, added in AsyncOS 7.5. Instead of querying a directory for valid recipients, it uses an independent SMTP connection to the delivery host or to a specified static host. The ESA makes an SMTP connection and uses the RCPT TO command to test each recipient. A 2yz response code indicates a valid recipient, while a 5yz indicates a non-existent recipient.

If LDAP is not available or complete in your environment, you may be able to use SMTP Call-Ahead instead. You must have a mail server that’s capable of replying appropriately to the RCPT TO command, and you must disable any kind of harvesting protection or rate limiting on the call-ahead server.

SMTP Call-Ahead provides the same features to the ESA as LDAP Accept queries: listener assignment, conversational rejection, and directory harvest attack prevention. The CLI equivalent is callaheadconfig.

Bounce Profiles

Bounce profiles would be better described as retry profiles, because that’s the configuration they cover. At message delivery, the bounce profile assigned to a message determines whether, and how often, a message or host is retried before the ESA gives up. When a message can’t be delivered, the profile also controls if and when a user should be notified and whether to generate a bounce.

Bounce profiles are covered in depth in Chapter 3. The equivalent CLI command is bounceconfig.

SMTP Authentication

One of the services you can offer with your ESA is the ability to authenticate remote senders using the ESMTP AUTH extension. Control over this service is given here. The ESA acts only as a bridge for credentials and does not authenticate the sender against local accounts. To authorize senders, you must have either an LDAP server or another SMTP server that supports AUTH for the ESA to make connections to using the supplied credentials. Another use of SMTP AUTH is when the ESA is acting as a client and must provide authentication credentials to another MTA. The CLI equivalent is smtpauthconfig.

Incoming Relays

ESAs depend heavily on information about connecting IP addresses to arrive at a verdict in the security engines. If the ESA is not receiving connections directly from the public Internet from senders, but is instead behind another MTA, the security engines will be hampered. Incoming relays can help by looking through the messages received from another server for the original source IP.

This feature allows you to specify the MTAs where the ESA will receive its incoming mail and which headers to search for the original IP. Luckily, the SMTP-standard received header is written by most MTAs in a standard format with this information.

This isn’t a perfect solution, because it prevents the ESA from using any of the HAT-based connection controls. Therefore, it’s not a recommended configuration except in some cases; for example, in evaluation prior to a production deployment or where only a small fraction of incoming messages are coming from another server.

The CLI equivalent is incomingrelayconfig.

Certificates

X.509 certificates are used for a number of different features on the ESA related to encryption: HTTPS for WUI access, for secure LDAP connections to servers that require it, and for encrypted SMTP connections using TLS. This page is where you create and manage your certificates. You can also manage the list of root certificates that your ESA trusts when verifying TLS connections.

Most environments require that a certificate be purchased from a well-known root certificate authority (CA). In some cases, the certificate provider has tools to allow you to request certificates. For others, you may need to provide a certificate signing request (CSR), and you can generate that on the ESA.

If you don’t need a certificate signed by a public root CA, you can also generate and use a self-signed certificate. I recommend that you take at least this step, because the self-signed certificate that Cisco provides on each ESA is identical across all new ESAs and is not secure.

Chapter 12 provides more information on TLS, including what information you need to provide to acquire an appropriate certificate.

The CLI equivalent is certconfig, but there are some important differences. The WUI allows you to import certificates in PKCS format, while certconfig requires separate key and certificate files in PEM format.

System Administration Menu

The System Administration menu fits in all the miscellaneous WUI tasks for the appliance as a whole. Figure 4-5 shows this menu.

Trace Tool

The trace tool is an extremely useful page for troubleshooting and configuration planning. Trace allows you to simulate an email message injected into the ESA. You can specify the attributes: sending IP and host, sender’s SBRS, the listener on the ESA, and all the message attributes, such as sender, recipients, and even the entire message body. Clicking Start Trace runs the message through all the appropriate tables and filters, providing a verdict for each stage of processing. The final disposition of the message is provided, allowing you to determine whether the message would be delivered or if it would be bounced, dropped, or quarantined. It does not actually inject a message or make any attempt to deliver it. Trace acts on uncommitted changes, so it’s extremely useful for testing new policy before you commit them.

Trace is especially useful for troubleshooting content filters, because it shows in detail which conditions matched on the supplied message. It’s easy to uncover logic issues in filters this way.

In the CLI, the equivalent command is trace.

Alerts

Alerts are email messages generated by the appliance about events occurring on the system that warrant a notification. Most of these alerts require some action from an administrator.

Alerts are grouped into categories, and then into severities within each category. By default, ESA sends all alerts to the email address specified during the System Setup Wizard, but you can create additional recipients and limit the messages sent to specific categories or severities.

Because some alerts can be repeated many times, the system has the ability to suppress and summarize duplicates instead of sending individual alerts thousands of times. The repeat interval is something you can modify, but the default settings are recommended.

The equivalent CLI command is alertconfig.

LDAP

Directory integration via LDAP is one of the most common ESA configuration tasks. ESA is known to work with a wide variety of commercial and open source LDAP servers. LDAP integration is important for security, policy, and remote access features. This page in the WUI allows you to create and test LDAP server profiles and their associated queries.

Because of the number of options for LDAP configuration, and the relationship between LDAP and policy, Chapter 7 is dedicated to the topic.

Related CLI commands include ldapconfig, ldaptest, and ldapflush.

Log Subscriptions

For any network security appliance, logging is critical for troubleshooting and post mortem, and ESA is no different. The appliances provide many different types of logs in various formats and a number of options on storage and rollover. There are logs for each major subsystem of the ESA pipeline, and a global text mail log format that records all message events for all messages and connections.

Logs on the ESA are arranged into subscriptions, where each subscription defines the log type, the size of the log files, the number of files, and what to do when the subscription reaches the limit. The logs can be stored locally and retrieved via FTP or SCP, or the ESA can push these files to a remote server using FTP or SCP or send log lines via syslog. This WUI page also gives you a button to force a log rollover.

You can have multiple log subscriptions of the same type. For example, you may want the text mail logs sent to a central log server via syslog for long-term archiving, but it’s always convenient to have logs stored locally on the appliance for troubleshooting using grep and tail. You can easily do this with a new log subscription of the same type as the on-box subscription.

Most of the log formats support various levels of detail, from Error (reports errors only) to Warning, Information, Debug, and Trace, with more information recorded at each level. There are also log types that are specifically for debugging, such as LDAP debug or injection debug logs. Chapter 7 discusses logging in detail.

The equivalent CLI commands are logconfig and rollovernow.

Return Addresses

Every email message generated by the ESA has a return address in the From: header, and these can be specified here. By default, the ESA uses “Mail Delivery System” <MAILER-DAEMON@hostname> as the sending address.

The ESA generates messages like alerts and notifications that go to administrative users, but also some messages, like bounces and quarantine notifications, that your end users will see. If you want your users to be able to reply to these, you’ll need to set valid addresses for your environment. Each type of notification can be configured separately. Return addresses for administrative alerts are not configured here, but under the Alerts menu.

The equivalent CLI command is addressconfig.

Users

The Users page provides settings for local or remotely authenticated user accounts for ESA administration. This is strictly for administrative users with a variety of privilege levels and not for end users. End user authentication for such features as ISQ is strictly performed through LDAP.

The user accounts that you create here can have one of five available fixed roles. Administrator is a super-user account with the ability to make changes in almost every configuration area. In AsyncOS versions prior to 7.5, certain tasks, like system upgrades, were limited to the “admin” account, but with 7.5 and later, the Administrator level includes all configuration options. Operators have access to most configuration areas with some important exceptions, like user-account creation. A read-only operator is just that: An account that can see all settings but not make configuration changes. A Guest has minimal access, only to reporting, and cannot make configuration changes. Helpdesk User has minimal reporting access and message tracking ability, making it ideal for a group that services end users’ queries about message delivery. The privileges that each user has can also be individually specified in some cases, such as access to quarantines.

Administrative users do not need to have local accounts. You can also allow for authentication to an external LDAP directory or a RADIUS server. RADIUS server settings are configured on the External Authentication settings page, but LDAP authentication requires that you already have an LDAP server profile and query created.

The equivalent CLI command is userconfig.

User Roles

User Roles is a new features in AsyncOS 7.5 that allows an administrator to create named roles to assign to other administrative users. It expands upon the earlier role-based access control by allowing roles to be assigned and limited to specific policies, reports, filters, and quarantines.

Creating roles for specific configuration areas allows you to delegate a portion of the configuration to specific users. For example, you can delegate configuration of DLP policies to a regulatory compliance officer, allow departments to manage their own anti-spam settings, or even have a separate administrator for specific domains.

You can manage user roles in the CLI command userconfig.

Network Access

Network access allows you to limit the network address sources that can use the ESA’s administrative interfaces. You can think of it as a simple firewall rule that specifies who can connect to the administrative ports on the appliance. By default, the ESA allows any source to connect, but you can change this to only allow certain sources to connect either directly or through a proxy. Another option on this page is the WUI inactivity timeout.

Valid source ranges can be specified as individual IP addresses, IP ranges, or CIDR blocks. The equivalent CLI command is adminaccessconfig, although that command also allows you to create a login banner that is displayed to anyone that connects to the ESA via SSH or HTTP before login. This banner is a typical place to display warnings about unauthorized access.

Time Zone and Time Settings

These two related pages in the WUI allow you to set your local time zone and either manually or automatically set your current date and time. Time zones can be set by geography or to a specific GMT offset. Automatic time settings use Network Time Protocol (NTP) and require that the ESA can reach the specified NTP servers on port 123 UDP. Time zone information is updated automatically and you can force a request for updates here.

Accurate time is required for proper functioning of any MTA, including the ESA. Aside from logging and header timestamps, many anti-spam rules depend on time accuracy.

The equivalent CLI commands are settz, settime, ntpconfig, and tzupdate.

Configuration File

The configuration file page allows you to import and export the entire ESA configuration file in XML format. You can save the file to your local computer or to the ESA’s disk storage, or have it sent via email. You can restore configurations from a local or uploaded XML file. You can also separately manage the database file for the end user safelist/blocklist spam filter feature.

Chapter 10, “Configuration Files,” covers managing the XML configuration.

The equivalent CLI commands are saveconfig, mailconfig, and loadconfig.

Feature Keys and Feature Key Settings

Feature keys control the availability and expiration of features on the ESA. There are two types of keys: perpetual (which never expire) and duration (which expires at the end of your contract). When you purchase an ESA, you’ll typically receive a perpetual key for incoming mail handling and duration keys for the length of the support contract you purchased. Some features will not appear in the WUI unless you have an active feature key for them. New ESAs ship with a 30-day evaluation key for all individual features.

Feature keys are typically downloaded by each ESA automatically after they become available. Some keys are applied automatically, but others require that you accept the EULA before the key becomes active. The Feature Key Settings page allows you to specify how, and whether, new keys are automatically downloaded and applied. The default is to allow both to happen automatically, and I recommend leaving this default setting. Feature key downloads use the interval and method that’s specified in the Service Updates page on the Security Services menu.

The Feature Keys Settings page also allows you to paste in a feature key string manually if that becomes necessary.

The equivalent CLI commands are featurekey and featurekeyconfig.

Shutdown/Suspend

As the name suggests, this page allows you to shut down or reboot the ESA, but also suspend and resume some email services.

Shutdown, reboot, and suspend don’t abruptly halt all services and connections, instead using a friendlier method. New connections are refused, but the system waits for existing open connections to finish, waiting as long as the time limit that you specify here. At that point, existing open connections are reset and the restart or shutdown proceeds.

You can independently suspend individual listeners, or email delivery, with the check boxes in the Mail Operations section. Suspending a listener stops it from accepting new connections and is extremely useful for taking an ESA out of production for upgrade, replacement, or major configuration changes. Suspending delivery allows the ESA to continue accepting and filtering messages, but prevents it from delivering them; this can be useful if you are performing maintenance on other servers in your email environment, because the ESA can easily hold several hours worth of mail in most environments without ill effect. This page allows you to resume these operations if they are currently suspended. Suspended delivery or receiving is a state that is preserved when you restart the system, so you must resume operations after a restart to let mail flow again.

The related CLI commands for mail operations are suspend, suspenddel, suspendlistener, resumedel, resumelistener, and resume. The commands for shutting down or restarting are shutdown and reboot.

System Upgrade

The System Upgrade page is only available to administrators. An upgrade in this context refers to a new version of AsyncOS—a complete replacement of the software running on the ESA. The Available Upgrades... button checks the Cisco servers for any available new version, and then lets you select an upgrade from the list and start the process.

There may be multiple upgrade versions available in the list, especially if you haven’t upgraded for an extended period. It’s safe to upgrade to any version in the list. You do not need to upgrade sequentially across version numbers. If an upgrade version appears in the list, it means that the upgrade path from your current version to that target version has been tested and approved. If an upgrade path has not been tested and approved, the version simply won’t appear in the list.

If your ESA is running older software, you may have to upgrade more than once to get to the latest version. Only certain upgrade paths are tested and approved. When you complete an upgrade, it’s worthwhile to check again for upgrades, because new versions may be available that weren’t on the upgrade path from the version you started with.

The upgrade process requires several confirmations at the start and a confirmation at the end before a mandatory reboot. Until you click Reboot, the ESA continues to operate as normal. WUI upgrades are resumable—that is, you can close your browser session or go out to lunch, and the upgrade will continue. You may be required to log back in to the WUI, and the system will send you back to the upgrade in progress.

Although you can perform an upgrade while the ESA is in production, it’s recommended to suspend incoming email traffic while you’re doing the upgrade. If nothing else, the upgrade proceeds faster if the ESA is not busy processing messages.

The CLI equivalent is upgrade, but be aware that the upgrade here is not resumable. If your CLI session is interrupted, the upgrade halts and you have to run the command again.

System Setup Wizard

This page offers to let you run the initial System Setup Wizard again, just as with a factory-new configuration. Be aware, however, that this is destructive: All of your current configuration, including network settings, is restored to factory default. The WUI page warns you of this. It’s likely you’ll be disconnected from the WUI and not able to reconnect.

Because of its destructiveness, there’s little reason to use this on a production ESA. Email messages on the system can be lost and unrecoverable.

The CLI equivalent is systemsetup. The command resetconfig will restore the system to its factory state, which will prompt you to run the systemsetup command.

Next Steps

The Next Steps page is normally only displayed after you complete the System Setup Wizard, and it gives you points to common configuration steps that are useful on a newly setup system. You can reach all the tools listed here through other WUI pages, so there’s not much reason to come to this page.

Options Menu

The Options menu collects a couple of important items for your interaction with the ESA WUI. This drop-down menu is in the upper right-most portion of the WUI page. ESAs running AsyncOS versions before 7.5 will have only two options: Change Password and Log Out. However, if you have a key for WUI localization, this is where you’ll see the selection box for the 11 languages that the WUI is available in. With AsyncOS 7.5, a localization key is no longer required. A menu item called Active Sessions has also been added in 7.5. Figure 4-6 shows the Options menu.

Active Sessions

Active Sessions shows all currently active sessions by administrative users for both the WUI and the CLI. The output on this page shows the username, role, login time, and duration, and the IP address of the remote host that opened the session. You can’t forcibly close another session.

In AsyncOS 7.5, the who or w command in the CLI has been enhanced to show both CLI and WUI sessions.

Change Password

The Change Password page allows you to change the password on the account currently logged into the WUI. If you are logged in with an administrator account, you can change the password for any user account in the Users page of the System Administration menu.

The CLI equivalent is password.

Log Out

This is self-explanatory. Log Out literally logs you out of your WUI session and returns you to the login page of the ESA. There’s no confirmation page, unless you have uncommitted changes pending. In that case, you will get an error and the Uncommitted Changes page that requires you to commit or abandon your change.

The CLI equivalents are the quit or exit command. Like in the WUI, these warn you if you have changes pending.

Help and Support Menu

The Help and Support menu gathers a couple of important tools: documentation, online support, and some troubleshooting tools. Figure 4-7 shows the Help and Support menu in the upper right-most portion of the WUI.

Online Help

The online help provides you with a searchable HTML version of the entire documentation suite for the ESA. This includes the Configuration Guide, Advanced Configuration Guide, and the Daily Management Guide. The help is context sensitive and will open to the section of the help for the WUI page you’re currently on. There’s no equivalent documentation in the CLI, but the help command can give you syntax and command descriptions.

Support Portal

This entry provides a link to the IronPort customer support portion of the Cisco website. The support portal provides documentation and tools for download, and a page to submit a support request. You need a cisco.com login to access the tools.

New in This Release

This pops up another browser window or tab with an HTML version of the release notes. Release notes cover notable new features, bugs fixed, and outstanding known issues in the current release.

Open a Support Case

Choosing this option brings you to a page that prompts you for information about a question or problem you might have with the ESA. Clicking Send creates an email message and sends it to support along with the provided information. This opens a Cisco IronPort support request.

This is a great way to get support, from minor issues to serious problems. It provides the support engineer with a serial number and configuration of the system where the request is generated and includes additional logging and debugging information. This means issues are resolved quickly because the request includes commonly needed information from the appliance configuration.

Because it depends on email, you shouldn’t use this method of contacting support if email operations on the ESA are severely impacted.

You can send yourself a copy of the support request if you’re interested in knowing what it is composed of. The equivalent CLI command is supportrequest, which prompts you for the issue description and contact information.

Remote Access

Remote access is a support tool that you might be asked to use during a support issue. This tool allows remote access to an authorized customer care engineer using an SSH reverse tunnel. A reverse tunnel uses SSH to connect from your ESA to the Cisco IronPort support portal, and then allows an engineer to use SSH to connect from Cisco to your ESA. This remote access can help Cisco identify and troubleshoot issues more quickly than any other way or monitor for situations that only occur occasionally.

This access method is extremely valuable and will help you get issues resolved more quickly. However, many ESA owners are naturally wary of opening a back door into their environments.

To ease these concerns, the remote access tool has been designed with a few important features:

1. The remote-access tunnel cannot be enabled from anywhere other than the CLI or WUI, is not turned on by default, and not turned on automatically under any circumstances. You or a delegated administrator must enable it.
2. Using the remote-access tunnel requires a session password, which is different from the ESA admin password, that you share with a support engineer. No Cisco engineer can access your appliance without this password.
3. The WUI and CLI indicate when an engineer is remotely logged into your appliance.
4. You control when the tunnel is closed. When you disable the tunnel session, it cannot be re-enabled remotely.

The CLI equivalent is techsupport.

Packet Capture

The last tool in the Support menu is a packet-capture tool for recording network traffic on one or more ESA IP interfaces. Like the tcpdump application that it’s based on, it provides a variety of filtering expressions to allow you to narrow your packet capture to the traffic you’re interested in. It records the selected traffic until a maximum size is reached or you manually stop the capture, and the resulting data is stored on disk in a file that you can download from this page.

Using packet captures and troubleshooting IP and TCP packets is beyond the scope of this guide. If you’re familiar with captures and with tools to analyze them, you’ll have no trouble with this tool. Even if you’re not, it’s a simple interface, if a packet capture is necessary for support to troubleshoot an issue.

The CLI equivalent is packetcapture.

4. WUI with Centralized Management | Next Section Previous Section