Operate the normalized DNN-aware WAF, block mapped and behaviorally suspicious DNN requests, and correlate attack activity without relying only on static CVE signatures.
Not rated yet
Version 03.03.00 normalizes DNN requests before applying policy. The WAF evaluates the effective
route, query and form inputs, upload metadata, trusted client address, authentication/role context,
and DNN-specific surfaces. It then correlates related signals and deduplicates repeated rule noise
so an investigation row explains the event rather than printing a raw signature fragment.
Actual module screen: the WAF Dashboard makes the current operating mode visible. Detection records matching traffic; Prevention blocks only the requests that meet an enabled control.
Core protection families
- SQL injection variants relevant to Microsoft SQL Server and DNN query patterns;
- reflected/stored XSS and unsafe executable markup;
- path traversal and attempts to read sensitive files such as
web.config;
- dangerous upload extensions, double extensions, SVG policy, and Unicode path obfuscation;
- ASP.NET ViewState and deserialization abuse indicators where visible at the request boundary;
- anonymous or unauthorized access to sensitive DNN handlers and services;
- DNN advisory-specific routes, ownership checks, SSRF/private-network targets, and write actions;
- reconnaissance, credential pressure, repeated completed HTTP requests, and crawler claims.
The in-process WAF cannot stop a connection-level Slowloris attack or volumetric DDoS before IIS
receives the request. IIS limits and an upstream proxy/CDN handle those layers. Request fingerprints
and crawler claims are risk signals; a declared Google/Bing/Meta user agent never bypasses
authentication or blocking rules.
Protection before a CVE exists
The normalized WAF does not require a published CVE name to recognize dangerous behavior. It can
score and prevent unsafe combinations of route, verb, role, upload metadata, destination, input,
request rate, and DNN object ownership. Advisory Shield adds exact fail-closed checks as soon as a
DNN advisory is mapped, while the generic policy continues to cover related variations.
This matters for zero-day pressure: even when the initial application bug is unknown, an attacker
still has to deliver input, reach a sensitive DNN surface, write or invoke code, and establish
persistence. WAF, scanner, Realtime Monitor, FIM, quarantine, and audit correlation cover those
different stages. In Prevention/Strict mode, a matched event is denied; in Detection/Audit mode it
is evidence and must never be described as blocked.
Event anatomy
A useful WAF event includes UTC time, effective client, method and route, sanitized query context,
the normalized signal/family, risk/severity, action, control mode, and correlation information.
Duplicate sub-signals for one request are grouped so the operator can see the primary reason and
the contributing evidence.
Choosing the mode
- Start in Detection on a production site and observe normal authenticated workflows.
- Investigate high scores and tune only with bounded route/role evidence; do not create broad
allowlists for an entire DNN subsystem.
- Move to Prevention after regression testing login, Persona Bar, module editing, uploads,
scheduled operations, and site-specific APIs.
- Keep the targeted Advisory Shield enabled; its strict checks run independently of the generic
WAF bypasses documented for exact Host-authenticated DNN Defender requests.
If the log says Observed or Logged, report it as detection evidence—not as a blocked attack.