NGFW: IDS/IPS and app/URL lists
USDN's NGFW feature runs the open-source Snort 3 engine on each AdWanOS device. It does two things:
- IDS/IPS. Snort checks traffic against signature rules. It can raise alerts or drop matching traffic.
- App and URL lists. You can list application names and URL categories to allow or deny.
This page explains what NGFW does, how to turn it on, and what it does not do. Read What NGFW is not before you compare it with other firewalls.
- Engine: Snort 3, running on each device.
- Feature key:
snort. The portal shows it as IDS / IPS. - Turn it on for a whole organization or for one site. Your plan must include it.
- URL categories are short, fixed lists of host names. They are not a commercial URL database.
- Not included: SSL/TLS decryption, URL cloud lookups, user identity, and app-based traffic steering.
What NGFW does
Intrusion detection and prevention (IDS/IPS)
Snort compares traffic with a set of signature rules.
- IPS mode is the default. Snort drops traffic that matches a blocking rule and raises an alert.
- IDS mode only raises alerts. Nothing is dropped.
Signatures. Snort uses the Cisco Talos rule set with its balanced IPS policy when a Talos rules key is set for your organization. Devices download new rules once a day. Without a key, Snort runs only a few basic local rules and catches very little. Ask USDN support whether your organization has a Talos key.
Which ports. By default, Snort checks traffic as it enters the device on its WAN and LAN ports. This is an organization setting. USDN support can limit it to WAN or LAN only.
If Snort stops. By default, traffic keeps flowing without inspection.
Alerts. Open Security → IDS/IPS in the portal. It shows alert counts, top signatures, top source addresses and recent alerts.
App and URL lists (NGFW policies)
Open Security → NGFW Policies in the portal. It has four tabs:
| Tab | What you set |
|---|---|
| Action Profiles | What happens to traffic on a deny list (see below). |
| App Control | Application names to allow and to deny. |
| URL Categories | URL category names to allow and to deny. |
| Policies | One action profile, app profile and URL profile, applied to a scope. |
An item cannot be on the allow list and the deny list of the same profile.
Action profiles. The default action decides what a deny-list match does:
| Default action | Deny-list matches are… |
|---|---|
| Deny | Dropped, with an alert. |
| Allow | Alerted only. Nothing is dropped. |
| Monitor | Alerted only, the same as Allow today. |
A policy without an enabled action profile acts as Deny.
There is no default deny. Traffic that is not on a list is never blocked by a policy. Allow-list entries take priority over deny-list entries.
Application names. You type application names as plain text, for example zoom or tiktok. Each name is handed to Snort's application ID option. There is no published list of supported names, and the portal does not check them. A name Snort does not recognize matches nothing.
URL categories. Each named category is a short, fixed list of host names:
| Category | Host names |
|---|---|
adult | pornhub.com, xvideos.com |
gambling | bet365.com, pokerstars.com, draftkings.com, fanduel.com, 888.com |
gaming | store.steampowered.com, epicgames.com, riotgames.com |
malware | One placeholder host. It does not protect against malware. |
social_media | facebook.com, instagram.com, tiktok.com, twitter.com, x.com |
streaming | netflix.com, youtube.com, twitch.tv, hulu.com, disneyplus.com |
Keep these limits in mind:
- Plain HTTP only. Snort reads the host name from the HTTP request headers. HTTPS hides those headers, so HTTPS visits are not matched. Most web traffic today is HTTPS.
- Text match. Snort looks for the text in the request headers. A different site whose name contains the text can match too. For example,
x.comalso matchesnetflix.com. - Other names. The portal accepts any category name today. A name that is not in the table matches any HTTP request whose headers contain that word. Use only the names in the table.
- No updates. The lists change only when USDN releases new device software. There is no reputation score and no cloud lookup.
App and URL lists are a basic control, not a full web filter. Test a policy on one site and check the result before you rely on it.
Scopes
A policy applies at one of three scopes:
| Scope | How you set it |
|---|---|
| Device | Pick a device (by its whitelist entry). |
| Site | Pick a site. |
| Organization | Pick neither. The policy is the default for every device. |
Each device uses one policy. A device policy beats a site policy, and a site policy beats an organization policy. Policies do not merge. If two enabled policies target the same device, site or organization, the one changed most recently wins. If no policy applies, the device runs IDS/IPS signatures only.
A policy only reaches devices where NGFW is turned on. When you save a policy or a profile, the change is sent to the affected devices automatically.
Policy status
The Policies tab shows a Last apply status for each policy: Applied, Rejected, Failed, Skipped (unchanged) or Never pushed.
- A device reports this status when NGFW is turned on or applied again.
- It confirms the device received the policy. It does not prove that traffic is being blocked.
- Several devices can share one policy. The status shows the most recent device report.
Turning NGFW on
Check your plan
NGFW is included in the Enterprise edition and in the Advanced Security add-on. It is not included in the Essential or Professional editions, or for organizations without an active subscription.
To check, open your organization and select the Features tab. If the IDS / IPS row says Not in your plan, contact USDN to add it.
For the whole organization
- Open your organization and select the Features tab.
- Turn on IDS / IPS.
This applies to every site, except sites that have their own setting. You need permission to manage sites.
For one site
Site-level control is available through the API today:
PUT /v1/sites/{id}/desired-features/snort/with{"enabled": true}turns NGFW on for the site.DELETE /v1/sites/{id}/desired-features/snort/returns the site to the organization setting.GET /v1/sites/{id}/desired-features/snort/status/shows the status of each device at the site.
If your plan does not include NGFW, the site request fails with 403 and "error": "not_entitled". Devices added to the site later get the site's setting automatically.
Turning NGFW off
In the current release, turning NGFW off saves the change, but a device that already runs Snort may keep running it. Contact USDN support to confirm that Snort has stopped on a device.
What NGFW is not
NGFW is Snort-based IDS/IPS plus simple app and URL lists. It does not include:
- SSL/TLS decryption. Encrypted traffic is not opened. HTTPS pages, URLs and downloads are not inspected.
- A URL categorization service. There is no commercial URL database, no reputation scoring and no cloud lookup. Categories are the fixed host lists above.
- User identity (user-ID). Policies apply to an organization, a site or a device. They cannot target users or groups. NGFW does not read user identity from a directory.
- App-based traffic steering. NGFW does not choose which path traffic takes. It only alerts on or drops traffic.
- A default-deny application firewall. There is no list of supported applications, and traffic that is not on a list is allowed.
For API users
The NGFW policy API lives under /v1/ngfw/. Reading needs permission to view sites. Changing needs permission to manage sites.
| Endpoint | Purpose |
|---|---|
/v1/ngfw/action-profiles/ | Action profiles (list, create, read, update, delete) |
/v1/ngfw/app-profiles/ | App control profiles |
/v1/ngfw/url-profiles/ | URL category profiles |
/v1/ngfw/policies/ | Policies and their scope |
/v1/ngfw/policies/form-options/ | Choices for the policy form |
/v1/organizations/{slug}/features/snort/ | Organization on/off |
/v1/sites/{id}/desired-features/snort/ | Site on/off |
/v1/security/ids-ips/ | Organization IDS/IPS settings |
/v1/security/ids-ips/stats/ | Alert statistics |
Today the IDS/IPS settings endpoint accepts changes even when your plan does not include NGFW. Devices only run NGFW when your plan includes it.