Threat Protection

Overview

Threat protection is comprised of the Snort intrusion detection engine and AMP anti-malware technology.

Threat Protection is available only with Advanced Security Edition licensing.

Learn more with these free online training courses on the Meraki Learning Hub:

Enabling Threat Protection on a Security Appliance

Sign in with your Cisco SSO or create a free account to start training.

Advanced Malware Prevention (AMP)

Advanced malware prevention (AMP) inspects HTTP file downloads through an MX security appliance and blocks or allows file downloads based on threat intelligence retrieved from the AMP cloud. For more information about AMP, see this article.

You can enable AMP by setting the Mode option to Enabled in the Security & SD-WAN > Configure > Threat protection page.

When traffic is filtered, the URL or ID and the action taken are logged under Security & SD-WAN > Monitor > Security center.

Malware protection is powered by the Advanced Malware Protection engine in MX 12.20 and higher. Previous releases leverage Kaspersky Lab as the malware protection engine.

To review the firmware versions of MX appliances in your organization and to schedule firmware upgrades, see the Organization > Monitor > Firmware upgrades page.

Dealing with False Positives

Occasionally the MX appliance may block a file or URL that is deemed safe by the administrator. In that case, you can tell MX to allow the download of the content or web page by allowing the content.

Allow List URLs

Find the URL that was blocked in the Event log page and enter it in the Allow list URLs section to allow that URL in the future. All values entered into this field will be treated as URLs, including IP addresses.

A request to an IP address in the allow list will be allowed, but a request to a domain that resolves to that IP address will not be allowed.

Allow list URLs entries support trailing wildcards (e.g., http://meraki.cisco.com/*).

Allow List files

For files, JavaScript, and other objects that are not URLs, the MX appliance assigns a unique ID. You can see the blocked items in the Event log page. By entering the ID of the object you want to allow in the Allow list files section you can instruct the appliance to allow the detected signature, even if the URL is different.

Intrusion Detection and Prevention

The MX’s Intrusion Detection and Prevention System (IDS/IPS) is powered by Snort. Snort is an open-source intrusion prevention system designed to detect and prevent cyber attacks by monitoring network traffic for malicious activity. It uses rulesets to analyze network packets and match them against known and emerging threats, such as viruses, worms, and other forms of malware. These rules are curated by Cisco's threat intelligence research group, Talos Intelligence, and the Meraki Cloud will automatically keep the MX up-to-date to ensure networks are safeguarded.

The rules are categorized as follows:

Connectivity: focuses on maintaining network performance and minimal security controls
Balanced: offers a compromise between security and performance
Security: prioritizes security even if it may impact network speed

Versions

The version of Snort operating on the MX appliance varies based on the specific firmware release currently installed on the device.

Snort 2

MX firmware releases earlier than 17.6
MX64/65

Snort 3

MX firmware releases later than 17.6
MX64/65 will continue to run Snort 2

Capability	Snort 2	Snort 3
Multi-Threaded Architecture	✅	✅
Daily threat signature updates from the cloud	✅	✅
Cloud-delivered engine swap in runtime, as a service	❌	✅
Capable of running multiple Snort processes	❌	✅
Port independent protocol inspection	❌	✅
IPS Accelerators / Hyperscan Support	❌	✅
Modularity	❌	✅
Scalable Memory Allocation	❌	✅
Next Gen Talos rules - e.g., Regex/Rule Options/Sticky Buffers	❌	✅
New and Improved HTTP Inspector - HTTP/2 Support	❌	✅

Traffic Inspection

In both IDS and IPS modes the following is inspected:

all traffic between LAN and the Internet
all traffic between VLANs

In both IDS and IPS modes the following is not inspected:

Intra-VLAN traffic (where Client 1 and Client 2 are both in the same VLAN)

The latest enhancement to our Snort 3 deployment incorporates zero-trust principles meaning we inspect internal traffic with the same rigor with which we inspect internet-bound traffic (since we should not assume internal traffic is any more trusted than internet traffic) resulting in higher efficacy and protection when compared to earlier Snort deployments on the MX. A higher volume of alerts may be seen in some instances. If the alert is determined to be a false positive, the signature may be allow listed, or the client/server can be trusted using Trusted Traffic Exclusions.

Configuring Intrusion Detection and Prevention

Intrusion Detection

You can enable intrusion detection by setting the Mode to Detection under Security & SD-WAN > Configure > Threat protection > Intrusion detection and prevention. When enabling intrusion detection, there are three distinct detection rulesets to choose from using the Ruleset selector:

Connectivity: Contains rules from the current year and the previous two years for vulnerabilities with a CVSS score of 10.
Balanced: Contains rules that are from the current year and the previous two years, are for vulnerabilities with a CVSS score of nine (9) or greater, and are in one of the following categories:
- Malware-CNC: Rules for known malicious command and control activity for identified botnet traffic. This includes call home, downloading of dropped files, and exfiltration of data.
- Blocklist: Rules for URIs, user agents, DNS hostnames, and IP addresses that have been determined to be indicators of malicious activity.
- SQL Injection: Rules that are designed to detect SQL Injection attempts.
- Exploit kit: Rules that are designed to detect exploit kit activity.
Security: Contains rules that are from the current year and the previous three years, are for vulnerabilities with a CVSS score of eight (8) or greater, and are in one of the following categories:
- Malware-CNC: Rules for known malicious command and control activity for identified botnet traffic. This includes call home, downloading of dropped files, and exfiltration of data.
- Blocklist: Rules for URIs, user agents, DNS hostnames, and IP addresses that have been determined to be indicators of malicious activity.
- SQL Injection: Rules that are designed to detect SQL Injection attempts.
- Exploit kits: Rules that are designed to detect exploit-kit activity.
- App-detect: Rules that look for and control the traffic of certain applications that generate network activity.

The Balanced ruleset will be selected by default.

Intrusion Prevention

You can enable intrusion prevention by setting the Mode drop-down to Prevention under Security & SD-WAN > Configure > Threat protection > Intrusion detection and prevention. Traffic will be automatically blocked by best effort if it is detected as malicious based on the detection ruleset specified above.

Protected Network section is used to controls the IP addresses or subnets of the systems protectied. Entries should be separated by commas or blank space(s). This will narrow down the subnets protected, it will protect only the subnets listed.

Note: The Protected Network section is only available for Security Appliances in Passthrough mode.

Allow List rules

You can allow specific Snort signatures by clicking Add an IDS rule to Allow list. Any signatures for which matching traffic has been seen by the appliance will appear in the Select an Option drop-down so you can select which signature(s) you wish to allow. This setting is shared among all networks in your organization.

Note: Allow list rules are only visible to Full Organization Administrators. Read-only Organization admins and network admins are not able to view or modify these rules.

Logging

Once AMP or IPS/IDS are enabled the events related to packet and file inspection will be available in the Security Center (Security & SD-WAN > Monitor > Security Center). For a detailed overview of the Security Center, please refer to this KB article. Security Events can be exported via Syslog on a network-by-network basis. For configuration details on enabling event export via Syslog, please see this KB article.