
Enable and Configure IPS Signatures on a SonicWall (SonicOS 7)
Before you run this
This guide turns on Intrusion Prevention Service (IPS) on a SonicWall firewall running SonicOS 7 and sets what the firewall does when traffic matches a signature: log it (Detect) or drop it (Prevent). The purpose is to catch known exploit and attack traffic passing through the firewall.
A few things to be clear about before you touch anything:
- This is a GUI procedure done as a firewall administrator. You need to log in to the SonicOS web management interface with an account that has full administrator rights. There is no bash or PowerShell here — the "script" is SonicWall's own configuration screens.
- Setting a signature group to Prevent can drop legitimate traffic. IPS false positives are real. If you set high-volume categories to Prevent without observing them first, you can break applications and get calls. That is why the standard approach below is Detect first, Prevent second.
- IPS requires an active subscription. Without a valid Intrusion Prevention (or Gateway/Comprehensive Security Suite) license and an up-to-date signature database, enabling IPS does nothing useful. Confirm the licence before you start.
- Keep an out-of-band path open. Have a physical console cable on the appliance's console port, or a management session on a separate interface, before you change anything. A wrong setting that drops traffic should not also lock you out of the box.
- Back up the running configuration first (steps below). SonicOS has no timed auto-rollback like some platforms — your rollback path is restoring the settings file you exported, or booting the previous settings image from SafeMode. Make sure you have that backup in hand.
- Do this in a maintenance window, and if you have a spare or lab appliance, walk through it there first.
I'm assuming a single firewall on SonicOS 7.0/7.1, managed through the local web UI, with LAN, WAN and (optionally) DMZ zones already configured. Menu labels moved slightly between 7.0 and 7.1 point releases; where I'm not certain of the exact wording I say so and point you to the admin guide rather than guess.
Step 1: Confirm the licence and signature database
Go to DEVICE | Settings > Licenses and confirm Intrusion Prevention shows as licensed. If it isn't, synchronise licences (the same page has a manual synchronise/refresh action) or activate the service through your MySonicWall account first — IPS will not enforce anything unlicensed.
Then open POLICY | Security Services > Intrusion Prevention. The page header shows the IPS signature database version and timestamp. With a valid licence, signatures update automatically; if the timestamp is stale, the general security-services update is triggered from POLICY | Security Services > Summary (SonicWall's automatic signature update). Don't proceed against an empty or badly outdated database.
Step 2: Back up the configuration
Before any change:
- Go to DEVICE | Settings > Firmware and Settings.
- Use Create Backup to store a local backup on the appliance.
- Also Export Configuration to download a settings file (
.exp) to your workstation.
Keep both. The exported file is your off-box copy if the appliance itself becomes unreachable.
Step 3: Enable IPS globally
On POLICY | Security Services > Intrusion Prevention:
- In the IPS Global Settings area, tick Enable IPS.
- Leave the per-priority signature actions at their defaults for now — you'll set them deliberately in the next step.
- Accept / Apply the change.
Enabling IPS globally arms the engine, but on SonicOS traffic is only inspected on zones where IPS is switched on. That's Step 5.
Step 4: Set signature actions — Detect first
The Intrusion Prevention page groups signatures by severity into three signature groups: High Priority Attacks, Medium Priority Attacks, and Low Priority Attacks. Each group has independent Prevent All and Detect All controls, plus a log-redundancy filter.
The safe, standard rollout is to observe before you block:
- High Priority Attacks — enable Detect All now. These are the ones you'll most likely want to Prevent, but log them first for a day or two to confirm you don't see false positives on legitimate traffic.
- Medium Priority Attacks — enable Detect All.
- Low Priority Attacks — enable Detect All. Low-priority signatures are the noisiest and the most likely to fire on benign traffic, so these usually stay in Detect long-term.
Apply, then let it run and watch the logs (Step 6). Once you've confirmed the High (and Medium) groups aren't flagging traffic you depend on, come back and tick Prevent All on High Priority Attacks first, then Medium. This staged move from Detect to Prevent is the whole point of doing it in a maintenance window with logging on.
I'm describing the group-level controls, which are the mainstream way to configure IPS on SonicOS. There is also per-category and per-signature tuning available on the same screen (drill into a category to override an individual signature's action or exclude it). If you need that granularity, follow the per-signature workflow in the SonicWall SonicOS 7 Security Services administration guide under Intrusion Prevention rather than assuming a menu label from memory.
Step 5: Enable IPS on the zones you want inspected
Global enablement plus signature actions still won't inspect anything until IPS is turned on per zone.
- Go to OBJECT | Match Objects > Zones.
- Edit the zone you want protected (for example your LAN zone, and typically WAN and any DMZ).
- In the zone's settings, tick the option to Enable Intrusion Prevention Service for that zone.
- Save, and repeat for each zone.
Enable it on the zones where the traffic you care about actually flows. Inspecting LAN and DMZ is the common baseline; inspecting WAN is common too but generates more noise.
Step 6: Verify it's working
- Signature status: back on POLICY | Security Services > Intrusion Prevention, confirm Enable IPS is ticked and your chosen groups show the actions you set.
- Live events: go to MONITOR | Logs > System Logs (the event log) and filter for IPS/Intrusion Prevention events. In Detect mode you'll see "detected" entries; in Prevent mode you'll see traffic being dropped. If you see nothing at all after a reasonable period, re-check that IPS is enabled on the correct zone and that the signature groups have Detect enabled.
- Generate a controlled test if you can do so safely — for example an EICAR-style or a known benign IDS test pattern from a lab host — and confirm it appears in the log. Do not run a real exploit against production.
- App Flow / Dashboard: the MONITOR dashboards summarise threat/IPS activity and are a quick way to confirm the engine is seeing traffic.
Undo and rollback
- To relax a single group: untick Prevent All on that group and leave Detect All on — traffic flows, you still get the logs. This is the quick, targeted reversal if Prevent starts blocking something legitimate.
- To disable IPS entirely: untick Enable IPS in the global settings, and/or untick Intrusion Prevention on the zone in OBJECT | Match Objects > Zones.
- Full rollback: if a change caused wider problems, restore the backup from DEVICE | Settings > Firmware and Settings (the local backup you created in Step 2), or import the exported
.expfile. If the appliance is unreachable, use the console port and, if needed, boot the previous settings from SafeMode as described in the SonicOS 7 upgrade/maintenance documentation.
Once High and Medium priority groups have run in Detect long enough to trust, moving them to Prevent is where IPS starts earning its keep — just make that move deliberately, with logging on and a backup in your pocket.
Runs enterprise networks and security for a living, and writes Shore Up to turn two decades of hands-on Linux, Windows and mail-server work into guides you can actually use.
More about the author →Was this article helpful?
Tap a star — no sign-in needed.
Be the first to rate this article.
Related guides
Configure Port Forwarding to an Internal Server on a SonicWall
This guide publishes one internal server on one port to the internet through a SonicWall. You will create an address object for the server, pick or create a service (port) object, add an inbound NAT policy that rewrites the destination to the internal host, and add a WAN→LAN access rule that permits the traffic. Both pieces are required: the NAT policy alone forwards nothing without the matching access rule.
Factory Reset and Recover a SonicWall with SafeMode
SafeMode is SonicWall's out-of-band recovery boot. You enter it with the physical reset button, and from a small web page on the appliance you can reboot the current firmware, boot a backup image, upload firmware, export settings, or boot with factory default settings — which wipes the running configuration back to out-of-the-box defaults. This guide covers using SafeMode to factory reset and recover a firewall you're locked out of, or one whose config or firmware is corrupt.
Set Up Content Filtering (CFS) on a SonicWall
This guide turns on SonicWall's Content Filtering Service (CFS): the firewall inspects outbound HTTP/HTTPS requests, looks the destination category up against SonicWall's cloud database, and blocks or allows the request based on a profile you define. The purpose is category-based web filtering for a specific zone (typically your LAN).
Configure High Availability on a SonicWall Pair
This guide pairs two identical SonicWall appliances into an Active/Standby High Availability cluster: the Primary handles all traffic, the Secondary sits synchronized and idle, and if the Primary fails the Secondary takes over the firewall's identity and keeps traffic flowing. That is the whole purpose — surviving a hardware failure without hand-rebuilding a box.




