TTechclick All lessons
Cisco Meraki · Security (MX) · Threat ProtectionInteractive · L1 / L2

Meraki Layer-7 Security — Content Filtering, AMP & Snort IDS/IPS

Three checkboxes on one dashboard page protect a whole branch — but flip the wrong one and you take down Microsoft 365 for the office. Skip the docs wall: pick a layer below, watch a real download get inspected live, ask the in-page AI tutor anything, and you're done.

📅 2026-05-31 · ⏱ 11 min · 3 interactive demos · 🏷 10-Q assessment + AI Tutor inline

By the end, you can

⚡ Quick Answer

Cisco Meraki Layer-7 security explained the AI-era way — turn on Content Filtering, AMP and the Snort IDS/IPS engine, pick Connectivity vs Balanced vs Security, watch a packet get inspected live, and learn the Detection-vs-Prevention + false-positive traps in 11 minutes instead of an afternoon.

Pick a layer — jump straight to it

1

Content Filtering

Block whole website categories using the URL or the TLS SNI field + Cisco Talos.

 2

AMP Anti-Malware

Inspect HTTP file downloads against the AMP cloud — plus retrospective detection.

 3

Snort IDS/IPS

Talos-curated signatures. Detection vs Prevention. Connectivity / Balanced / Security.

 4

False Positives

"It blocked M365!" → Security Center + allow-list playbook + throughput fix.

The branch-office analogy that makes this click

Read as:

Picture a mall with one main entrance. The Content Filter is the guard who turns away anyone heading to shops you've banned — he reads the sign above the shop, not what's inside the bag. AMP is the X-ray scanner that opens parcels and checks them against a "known-bad" list updated every minute. IDS/IPS (Snort) is the trained sniffer dog that recognises the behaviour of an attacker even when the parcel looks normal. One Meraki MX runs all three at the front door of your branch.

The Meraki MX runs three Layer-7 inspection engines on the same data path: a URL/SNI content classifier (queries Cisco Talos categories), AMP (HTTP file-download disposition lookups against the AMP cloud), and a Snort engine for signature-based IDS/IPS. All three live on one page — Security & SD-WAN > Threat protection — and all need the Advanced Security licence. Inspection runs on traffic between LAN↔Internet and between VLANs, but not intra-VLAN.

Architecturally these are three independent control points stacked on a single packet-processing pipeline, each with its own oracle: Talos category cloud (content), AMP/Secure Malware Analytics cloud (file disposition + retrospection), and Talos-curated Snort rulesets (signatures). The design tradeoff is throughput vs efficacy: every engine adds latency and CPU, so model sizing (MX67 vs MX85 vs MX250) and ruleset choice are capacity-planning decisions, not just security ones. Cloud-managed means signatures auto-update — no maintenance window — but also means you trust the cloud's classification calls.

One sentence to memorise: "Content filtering reads the address, AMP scans the box, IDS/IPS watches the behaviour." Each sees a different slice of the same flow. Mix them up in an interview and you'll lose the question — this is a top-asked ECMS 500-220 area.

A branch LAN passes traffic through one Meraki MX that runs Content Filtering, AMP and Snort IDS/IPS engines, each consulting a different Cisco cloud, before reaching the internet. Branch LAN 10.20.10.0/24 laptops · phones printers · IoT Cisco Meraki MX Advanced Security licence ① Content Filtering reads URL + TLS SNI → category ② AMP anti-malware HTTP file download → disposition ③ Snort IDS/IPS packet behaviour → signature match Internet + Cisco clouds Talos categories ↑ content AMP cloud ↑ files + retro Talos Snort rules ↑ auto-update
Big picture: one Meraki MX, three Layer-7 engines, three different Cisco clouds. Content reads the address, AMP scans the file, Snort watches the behaviour — all on the same flow.
🏷
Content Filter
tap to flip

Reads the URL or the TLS SNI field, asks Talos "what category?", then allow/block. Sees the destination, not the payload.

📦
AMP
tap to flip

Inspects HTTP file downloads, asks the AMP cloud for a disposition (clean / malicious / unknown), and can re-flag a file later — retrospective detection.

🐷
Snort
tap to flip

The open-source engine behind Meraki IDS/IPS. Matches packets against Talos-curated signatures. Detection = alert only; Prevention = block inline.

🔑
The licence
tap to flip

All three require the Advanced Security edition licence. On the Essentials/Enterprise licence, the Threat protection page is greyed out.

Warm-up · Q1 of 10 · Remember

Which Meraki MX licence edition is required before Content Filtering, AMP and IDS/IPS can be turned on?

Correct: a. Threat protection (Content Filtering, AMP, IDS/IPS) is available only with the Advanced Security edition licence. On Essentials/Enterprise the page is disabled. They are NOT separate per-feature add-ons (c) and definitely not free (b). SM (d) manages endpoints, not MX threat protection.

① Content Filtering — block the address, not the box

Sneha runs the IT desk at a TCS branch. Management wants gambling, adult and known-malware sites blocked across all 200 laptops. She doesn't write 200 firewall rules — she ticks a few categories under Security & SD-WAN > Content filtering, and the MX does the rest using Cisco Talos categories.

S
Sneha @ TCS branch: she blocks the "Gambling" category. A user visits https://bet365example.com. Because it's HTTPS, the MX can only read the domain from the TLS SNI — it can't see the full path — but the domain alone is enough to block. The user sees a browser TLS error page, not the friendly Meraki block page. Sneha now knows why HTTPS blocks "look broken" to users.

Here's the key mechanic students miss. The MX inspects either the URL in an HTTP payload, or the Server Name Indication field of outbound TLS traffic. It queries Talos, then keeps the answer in a local cache — up to 100,000 records, for up to 20 minutes. So the first user to hit a new domain pays the lookup cost; the next 200 ride the cache.

Pause & predict

A user complains "the block page is broken — I just get a certificate error". The site was HTTPS. Why no Meraki block page?

HTTPS can't be intercepted cleanly. Content Filtering can only classify and block on the domain (from SNI), not the full URL, when TLS is in use. Because the MX never decrypts the session, it can't inject an HTML block page — the browser just shows a TLS handshake error. That's expected behaviour, not a bug. If you want a friendly block page on HTTPS, you'd need full SSL decryption (a separate, heavier feature).
A request enters the MX, the MX reads the URL or TLS SNI, checks its 20-minute Talos cache, queries Talos on a miss, then allows or blocks based on category and the allow-list over block-list precedence. Request HTTP URL / TLS SNI In cache? 100K records · 20 min HIT → instant MISS Query Talos → category + cache it Match category? allow-list > block-list BLOCK block page / TLS error ALLOW to internet Content Filtering: cache-first, Talos-on-miss
Flow: the MX checks its local 20-minute cache first; on a miss it asks Talos, caches the answer, then applies the category rule — and the allow list always wins over the block list.
Dashboard intent — Content filtering page 
Security & SD-WAN > Configure > Content filtering
  Category filtering: Block  → Gambling, Adult, Illegal Downloads
  Blocked URL patterns: bet365example.com
  Allowed URL patterns: intranet.tcs.local   # always wins over block list
  URL category list size: Top sites  (vs Full list)
Expected result (Security Center event) 
2026-05-31 14:02  client 10.20.10.55  → bet365example.com:443
  action: blocked   reason: content-filtering (Gambling)
  note: HTTPS — classified via SNI, no block page rendered
Quick check · Q2 of 10 · Apply

Sneha adds intranet.tcs.local to the Allowed URL patterns, but the same domain is also matched by a blocked category. What happens?

Correct: b. In Meraki Content Filtering the allow list always takes precedence over the block list and over category blocks. That's exactly how you carve out a single trusted site inside an otherwise-blocked category. It is never random (c), and your explicit lists are not ignored in favour of Talos (d).

② AMP — scan the file, then keep watching it

Content Filtering blocks where you're going. AMP checks what you're downloading. When a user pulls a file over HTTP, the MX computes its fingerprint and asks the AMP cloud for a disposition: clean, malicious, or unknown. Malicious files are blocked at the wire.

R
Rahul @ Infosys: a user downloads invoice.exe over HTTP. AMP returns "unknown" — so it's allowed through. Two hours later the AMP cloud learns it's a dropper. Rahul gets a retrospective email alert: "a file you allowed has changed disposition to malicious." Now he can isolate that one laptop instead of finding out from a ransom note.

Two facts that win interview points. First, AMP inspects HTTP file downloads — not HTTPS, not FTP, not SMB. Second, it needs Traffic Analysis enabled under Network-wide > Configure > General to function at all. Turn AMP on, forget Traffic Analysis, and it silently does nothing.

Pause & predict

A file was downloaded yesterday and allowed. Today AMP emails you "this file is now malicious." Did AMP fail?

No — that's retrospective detection working as designed. At download time the AMP cloud had no intelligence on that fingerprint, so the disposition was "unknown" (allowed). When new intelligence arrives, AMP revisits earlier events and re-classifies the file, firing a retrospective alert. It turns a blind spot into a same-day incident ticket. Enable the alert at Network-wide > Configure > Alerts > "Malware is downloaded".

▶ Watch a file get AMP-inspected

Click Play. Watch where the disposition lookup happens — and where retrospection bites later.

① DOWNLOAD 10.20.10.55 pulls http://files.example.com/invoice.exe
User clicks a link in zone LAN. HTTP, so AMP can inspect it.
▼
② FINGERPRINT MX computes the file fingerprint as bytes stream through
▼
③ CLOUD LOOKUP Fingerprint → AMP cloud → disposition = unknown
▼
④ DECISION Unknown ≠ malicious → file is allowed. Event logged to Security Center.
▼
⑤ +2 HOURS AMP cloud gains new intel → fingerprint now = malicious
▼
⑥ RETROSPECTION MX re-flags the earlier event → email alert "Malware is downloaded" fires to Rahul.
Press Play to step through an AMP inspection — including the retrospective re-flag two hours later. Each Next advances one stage.
The #1 AMP blind spot

Symptom you'll see: AMP is "Enabled", yet malware still lands on endpoints. Cause: the download came over HTTPS (or FTP/SMB) — AMP only inspects HTTP file downloads. Most of the web is HTTPS now, so AMP on the MX is a backstop, not your only malware defence. Pair it with endpoint protection (Cisco Secure Endpoint / Defender). Also confirm Traffic Analysis is enabled, or AMP does nothing at all.

Quick check · Q3 of 10 · Apply

Rahul enables AMP but malware keeps reaching laptops. The downloads are all from https:// sites. What's the most accurate explanation?

Correct: c. AMP on the MX inspects HTTP file downloads only — not HTTPS, FTP or SMB. With most traffic now HTTPS, AMP is a useful backstop but cannot be your only malware control; pair it with endpoint protection. It is not a hardware fault (a), it does not scan every protocol (b), and signatures auto-update with no reboot (d).

③ Snort IDS/IPS — Detection, Prevention & the ruleset dial

Now the smart layer. Meraki's IDS/IPS is powered by Snort, with signatures curated by Cisco Talos and pushed automatically. Two dials decide its behaviour: the mode and the ruleset.

Dial 1 — Detection vs Prevention

Dial 2 — Connectivity / Balanced / Security

Three Snort rulesets compared on a slider from speed to security: Connectivity is fastest with fewest rules, Balanced is the default middle ground, Security is the most thorough with highest CPU cost. Pick the dial: more speed ⟷ more security ◀ faster / less CPU deeper inspection ▶ Connectivity Lightweight & fast CVSS 10, last 2 yrs fewest rules USE WHEN perf-sensitive site, small MX model, saturated uplink DEFAULT Balanced Selected by default C2, exploit kits, SQLi, blocklists moderate impact USE WHEN typical branch, you're unsure — start here Security Maximum detection broadest signatures highest CPU cost USE WHEN regulated site, headroom on a larger MX model
Decision: Balanced is the default and the right answer for most branches. Drop to Connectivity only when a small MX is choking; move to Security when a regulated site has CPU headroom to spare.
P
Priya @ HCL: she flips IPS to Prevention + Security ruleset on an MX67 at a small site. Speed-tests crater from ~800 Mbps to ~350 Mbps and users complain video calls stutter. Her fix isn't to disable security — it's to drop to Balanced (or move that site to a larger MX). Inline deep inspection is CPU-bound; ruleset choice is a capacity decision.
Snort 2 is sunsetting — know the cutoff

Snort 2 runs on MX firmware below 17.6 and on MX64/MX65. Snort 2 stopped receiving rule updates after 18 December 2025. Snort 3 ships on firmware 17.6+ (most current MX models) and is the engine you should be on. In an interview: "are you on Snort 2 or 3?" is a real maturity question — Snort 2 = stale signatures.

Dashboard intent — Threat protection page 
Security & SD-WAN > Configure > Threat protection
  Intrusion detection and prevention:
    Mode:     Prevention            # IDS=Detection, IPS=Prevention
    Ruleset:  Balanced              # default; Connectivity / Security alt
  Advanced Malware Protection (AMP):
    Mode:     Enabled               # needs Traffic Analysis ON
  Snort engine: Snort 3  (fw 19.1.x)
Expected output (Security Center → Events) 
blocked  src 172.16.30.9  dst 203.0.113.44:80
  signature 1:2024897  "ET MALWARE Cobalt Strike beacon"
  ruleset Balanced · action Prevention · disposition malicious
Quick check · Q4 of 10 · Apply

Priya wants Snort to alert on threats during a two-week evaluation, without ever dropping a legitimate user's traffic. Which mode does she choose?

Correct: d. Detection mode generates alerts/logs but never blocks traffic automatically — exactly right for a non-disruptive evaluation of what Prevention would drop. Both Prevention options (a, b) actively block inline, which is what she's trying to avoid. Disabling entirely (c) gives her no IDS visibility at all.

④ When it goes wrong — false positives & the allow-list playbook

Here's the war story every Meraki admin eventually lives. A Talos signature mis-fires and the MX, in Prevention mode, starts blocking legitimate traffic. In one widely-reported case, a Meraki IPS rule flagged normal Microsoft 365 connections as a "Microsoft Windows IIS denial-of-service attempt" — and offices lost M365 until admins allow-listed the signature.

A
Aditya @ Wipro: Outlook and Teams die across the branch right after a Talos rule push. The Security Center shows a flood of blocks on rule ID 1-60381 against M365 IPs. Aditya doesn't disable IPS — he allow-lists that one rule ID under Security & SD-WAN > Threat protection > Allow list rules and service returns in minutes.

▶ False-positive triage — 4-step playbook

Legit traffic is being blocked. Walk the ladder instead of panic-disabling IPS.

① SYMPTOM Users report M365 / an app suddenly broke after a rule push
▼
② SECURITY CENTER Monitor → Security Center → find the spiking signature / rule ID (e.g. 1-60381)
▼
③ CONFIRM FALSE + Destination is a trusted service (M365 IP range) → it's a false positive, not a real attack
▼
④ ALLOW-LIST RULE Threat protection → Allow list rules → add the rule ID. IPS keeps running for everything else.
▼
⑤ TRUSTED TRAFFIC For chronic noise from a trusted host: Trusted Traffic Exclusions → accelerated path (bypasses IDS/IPS, AMP, Threat Grid)
▼
⑥ VERIFY Re-test the app · watch Security Center → blocks stop · service restored
Press Play to walk the false-positive ladder. The discipline: scope the fix to one rule, never disable the whole engine.
Pause & predict

An "Allow list rule" only lets you whitelist an entire signature, not a specific source→destination pair. What risk does that create, and what's the safer alternative for one trusted host?

Risk: allow-listing a whole rule ID disables that signature network-wide — if a real attack later matches it, you're blind to it. Safer for one host: use Trusted Traffic Exclusions to trust that specific source/destination/app onto the accelerated path. Caveat — trusted traffic bypasses IDS/IPS, AMP and Secure Malware Analytics (Threat Grid) for that flow, so only trust hosts you genuinely control. It's a scalpel where the rule-ID allow-list is a hammer.
The "allowed" log that isn't an attack

Symptom: Security Center shows a malicious signature with action "allowed" and you panic. Cause: the MX saw a single packet match the signature, but the flow was already reset by the remote end, so it couldn't take a block action — it logs the event as "allowed" even though no malicious flow actually completed. Don't auto-escalate every "allowed" line; correlate with whether a session really established.

Throughput & sizing — three pro tips
Quick check · Q5 of 10 · Analyze

Aditya needs M365 working again in 5 minutes after a false-positive IPS block, while keeping IPS protecting everything else. Best action?

Correct: a. The surgical fix is to identify the false-positive rule ID in Security Center and allow-list just that signature — IPS keeps protecting against every other threat. Switching to Detection (b) or disabling IDS/IPS (c) drops protection network-wide. Downgrading firmware (d) is slow, risky and unnecessary for a single bad signature.
A decision tree: if legit traffic is blocked, scope to a rule ID and allow-list it; if a trusted host is chronically noisy, use Trusted Traffic Exclusions; if throughput drops, lower the ruleset or resize the MX. "It broke" → which lever do I pull? What's the symptom? Legit app blocked (e.g. M365 after rule push) Allow-list the rule ID Threat protection → Allow list rules Trusted host, chronic noise backup server, scanner Trusted Traffic Exclusion accelerated path — bypasses IPS+AMP, beware Slow / throughput drop video stutters, ~350 Mbps Lower ruleset / resize MX Security→Balanced, or MX67 → larger model Golden rule: scope the fix as narrowly as the symptom — never disable the whole engine.
Decision ladder: three symptoms, three scoped levers. A blocked app → allow-list one rule; a noisy trusted host → Trusted Traffic Exclusion; a throughput drop → lower the ruleset or right-size the MX.

🤖 Ask the AI Tutor

Tap any question — instant context-aware answer. No login, no waiting.

Pre-curated answers from Meraki docs + community Q&A. For live prod issues, paste your Security Center event + Threat protection config into chat.techclick.in.

Explain it back (R6)

In your own words: a colleague turned AMP "Enabled" but malware still lands. Give the two-line diagnosis you'd send them.

Model: "AMP only inspects HTTP file downloads — your malware came over HTTPS, so it bypassed AMP. AMP is a backstop; you also need endpoint protection. And double-check Traffic Analysis is ON under Network-wide → General, or AMP isn't actually inspecting anything."

📝 Wrap-up — five more

You've already answered 5 inline. Five left. 70% (7 of 10) total marks the lesson complete on your profile. Tap Submit all answers at the end.

Q6 · Analyze

An MX65 on firmware 17.2 is still using Snort 2. After 18 December 2025, what is the practical consequence the team must plan for?

Correct: b. Snort 2 stopped receiving rule updates after 18 Dec 2025, so its signatures gradually go stale — leaving the MX blind to newer threats. The fix is a path to Snort 3 (firmware 17.6+ on a supported model). The feeds are not shared (a), the MX doesn't auto-disable IPS (c), and Content Filtering/AMP are independent engines (d).
Q7 · Analyze

Two laptops sit in the SAME VLAN. Laptop A scans laptop B with malware-laden traffic. The MX has IPS in Prevention + Security ruleset. Why does the MX NOT block it?

Correct: c. Inspection covers LAN-to-Internet and inter-VLAN traffic, but intra-VLAN (client-to-client in the same VLAN) never traverses the MX, so no engine sees it. To inspect east-west traffic, segment hosts into different VLANs. The ruleset does include scan signatures (a), Prevention isn't inbound-only (b), and AMP only inspects HTTP downloads, not lateral scans (d).
Q8 · Analyze

A user reports a HTTPS site "won't load — certificate error" right after you blocked its category. A colleague insists Content Filtering is broken. What's actually happening?

Correct: d. Content Filtering classifies HTTPS by the SNI domain without decrypting the session, so it can't inject an HTML block page — the browser just fails the handshake and shows a TLS error. That's the documented, expected behaviour, not a fault. The MX is not decrypting (a), nothing is broken (b), and the 20-min cache doesn't need manual flushing (c).
Q9 · Evaluate

A nightly backup server triggers the same IPS signature every night against an internal target, flooding Security Center. An engineer proposes allow-listing that rule ID network-wide. Evaluate the best approach.

Correct: b. Allow-listing the rule ID network-wide (a) disables that signature everywhere — a real attack matching it later goes unseen. A Trusted Traffic Exclusion scoped to the known backup host removes the noise while every other host keeps that signature, accepting that the trusted flow bypasses IPS/AMP/Threat Grid. Detection mode (c) and dropping to Connectivity (d) weaken protection far more broadly than the problem requires.
Q10 · Evaluate

A CISO says "we have a Meraki MX with AMP and IPS on Security ruleset — we're fully protected against malware." As the engineer, what's the most defensible correction?

Correct: a. The honest assessment: AMP inspects only HTTP file downloads (HTTPS bypasses it), IDS/IPS can't see intra-VLAN traffic, and nothing on the MX decrypts payloads — so the MX is a strong network-edge backstop, not a complete malware solution. Defence-in-depth needs endpoint protection plus VLAN segmentation. Agreeing (b) is wrong; Connectivity is the lightest ruleset, not "better coverage" (c), and Content Filtering and AMP solve different problems (d).
Lesson complete — saved to your profile.
Almost! You need 70% (7 of 10) — re-read the section that tripped you up and tap "Try again".

👥 Teach a friend (you learn 2× by teaching)

In one WhatsApp message to a junior, explain the difference between Content Filtering, AMP and IDS/IPS using the mall analogy — guard at the door, X-ray scanner, sniffer dog. If you can send it in three lines, you own this lesson.

🔁 Lock it in — spaced recall

We'll email you 3 quick recall questions on this lesson in 3 days, then again in 10. Spaced repetition is how this sticks past the interview.

Saved — we'll nudge you in 3 days. (Stored locally on this device.)

📒 Glossary — the 8 terms that matter

Content Filtering
Blocks websites by category using the URL or TLS SNI, classified by Cisco Talos. Sees the destination, not the payload.
SNI (Server Name Indication)
The unencrypted domain field in a TLS handshake. Lets the MX classify HTTPS by domain without decrypting.
AMP (Advanced Malware Protection)
Inspects HTTP file downloads, asks the AMP cloud for a disposition, can re-flag files later (retrospection).
Disposition
The AMP verdict on a file: clean, malicious, or unknown. Unknown is allowed but watched.
Retrospective detection
AMP re-classifies a previously-allowed file when new intelligence arrives, firing a delayed alert.
Snort
The open-source IDS/IPS engine behind Meraki threat protection, fed Talos-curated signatures.
Ruleset (Connectivity / Balanced / Security)
The signature breadth dial. Balanced is default; trade speed against detection depth.
Trusted Traffic Exclusion
Puts a trusted source/dest/app on an accelerated path that bypasses IDS/IPS, AMP and Threat Grid.

📚 Sources

  1. Cisco Meraki Documentation — Threat Protection (MX). documentation.meraki.com
  2. Cisco Meraki Documentation — Advanced Malware Protection (AMP) + Content Filtering. documentation.meraki.com
  3. Cisco Meraki Documentation — Trusted Traffic Exclusions & Security Center. documentation.meraki.com
  4. The Meraki Community — "IPS Snort Microsoft Windows IIS DoS attempt — false positive" thread (allow-list rule ID 1-60381).
  5. BleepingComputer — "Microsoft 365 outage triggered by Meraki firewall false positive" (2025).
  6. The Meraki Community — Intrusion detection and prevention throughput thread (~800→350 Mbps with IDP on).
  7. Stratus Information Systems — "New Threat Protection in Meraki MX: Snort 3 and Beyond"; Snort 2 EOL 18 Dec 2025.
  8. Cisco Security Advisory — CVE-2025-20271 / CVE-2025-20212 Meraki MX & Z Series AnyConnect VPN DoS.
  9. Cisco — Engineering Cisco Meraki Solutions (ECMS 500-220) exam blueprint.

What's next?

You've secured one branch. Now scale it to 200 — without clicking every box on every MX by hand. Next we cover config templates, network tags and change management: how to push one policy fleet-wide and not break a site.

Next · Meraki at Scale — Templates, Tags & Change Management → ← Recap MX & AutoVPN

— Techclick Team