Repository navigation
Conversation
github-actions
Bot
added
the
documentation
✅ Deploy Preview will be available once build job completes!
|
JTorreG
left a comment
JTorreG
left a comment
There was a problem hiding this comment.
remove all the --- section separators.
|
@JTorreG Incorporated your suggestions. However, when I run "make watch" on this branch, it doesn't render anything in the directory "content/nginxaas/overview/app-protect/waf-security-dashboard". Any idea why? |
edarzins
changed the title
| url: /f5ads/platform/app-protect/waf-security-dashboard | ||
| --- | ||
|
|
||
| Use the security monitoring module in the F5 ADS Console to collect, visualize, and query security events from F5 WAF for NGINX running on NGINX Plus instances. Review attacks, violations, and triggered signatures to assess threats. |
There was a problem hiding this comment.
I can't find it in these changes in the docs preview pages. Where does the content in this file show up?
There was a problem hiding this comment.
Consolidated redundant overview and security-monitoring overview.
| f5-content-type: concept | ||
| f5-docs: DOCS-000 | ||
| f5-product: F5 Application Delivery Service | ||
| title: Security monitoring overview |
There was a problem hiding this comment.
It looks a but odd to see Overview and Security monitoring overview sections in the navbar. Can we move the contents of this file so they show up in Overview?
There was a problem hiding this comment.
The "overview" section was redundant, so I removed it. It was a carryover from the N1 docs.
| - **Deployment**: Each event records the F5 ADS deployment ID that produced it. Use this to scope by deployment. | ||
| - **Instance**: Each event records the NGINX instance hostname that produced it. Use this to scope by data plane. | ||
| - **Policy**: Each event records the F5 WAF for NGINX policy that produced it, so you can compare activity across policy versions or rollouts — useful for measuring the impact of a policy change before promoting it. | ||
| - **Destination hostname**: Each event records the HTTP `Host` header sent by the client — the *application* being attacked, not the instance hostname (which identifies the data plane). Use this when one data plane fronts multiple applications and you need to scope by app rather than by infrastructure. |
There was a problem hiding this comment.
Sent by the client, or set by the NGINX dataplane?
This sounds like it is discussing the client of F5ADS (eg. the Host header used in the request to NGINX), while also discussing the backend/upstream application workloads that NGINX proxies to. Could use some clarity.
There was a problem hiding this comment.
Removed unnecessary stuff to make it more clear.
| - **Destination hostname**: Each event records the HTTP `Host` header sent by the client — the *application* being attacked, not the instance hostname (which identifies the data plane). Use this when one data plane fronts multiple applications and you need to scope by app rather than by infrastructure. | ||
| ## Retention | ||
|
|
||
| Security events are retained for **90 days**. Queries that reach further back than 90 days return no results. If you need long-term retention, forward events to an external Security Information and Event Management (SIEM) system with a [custom log profile]({{< ref "/nginx-one-console/waf-integration/log-profiles/_index.md" >}}) in addition to the `secops_dashboard` log profile. |
There was a problem hiding this comment.
Do we really want to tell users to go do this themselves? I could see suggesting they reach out to us (maybe we can work with them to retain their data for longer as a premium option if there is enough interest).
There was a problem hiding this comment.
Retention for 90 days is the current configuration in AIDF. Extending that is beyond the scope of this epic. Please open a ticket if you think the data-retention period should be configurable.
| toc: true | ||
| f5-keywords: "security monitoring, security dashboard, F5 WAF for NGINX, security events, analytics, F5 ADS Console" | ||
| f5-summary: > | ||
| Security monitoring in the F5 ADS Console centralizes security events from F5 WAF for NGINX instances and exposes them through dashboards. |
There was a problem hiding this comment.
| Security monitoring in the F5 ADS Console centralizes security events from F5 WAF for NGINX instances and exposes them through dashboards. | |
| Security monitoring in the F5 ADS Console centralizes security events from F5 WAF for your deployments and exposes them through dashboards. |
| f5-audience: operator | ||
| --- | ||
|
|
||
| Security monitoring brings F5 WAF for NGINX events from every connected instance into a single place in the F5 ADS Console. This page explains what data the system collects, how it flows, and how it is organized. |
There was a problem hiding this comment.
| Security monitoring brings F5 WAF for NGINX events from every connected instance into a single place in the F5 ADS Console. This page explains what data the system collects, how it flows, and how it is organized. | |
| Security monitoring brings F5 WAF for NGINX events from every deployment into a single place in the F5 ADS Console. This page explains what data the system collects, how it flows, and how it is organized. |
|
|
||
| ## What is security monitoring? | ||
|
|
||
| Security monitoring is the F5 ADS Console module that ingests F5 WAF for NGINX security events from your data planes, stores them centrally, and exposes them through a security dashboard. It gives you a single view of attacks, violations, and triggered signatures across every NGINX Plus instance you have connected to the F5 ADS Console. |
There was a problem hiding this comment.
| Security monitoring is the F5 ADS Console module that ingests F5 WAF for NGINX security events from your data planes, stores them centrally, and exposes them through a security dashboard. It gives you a single view of attacks, violations, and triggered signatures across every NGINX Plus instance you have connected to the F5 ADS Console. | |
| Security monitoring is the F5 ADS Console module that ingests F5 WAF for NGINX security events from your data planes, stores them centrally, and exposes them through a security dashboard. It gives you a single view of attacks, violations, and triggered signatures across every deployment you have created in the F5 ADS Console. |
| app_protect_security_log /etc/nginx/secops_dashboard.tgz syslog:server=127.0.0.1:1514; | ||
| ``` | ||
|
|
||
| `app_protect_enable on;` and `app_protect_policy_file` must be present in the same context. These are covered in [Before you begin](#before-you-begin). |
There was a problem hiding this comment.
All I see in before you begin is "- Deployment: A deployment that has been created with the F5 ADS Console."
There was a problem hiding this comment.
Also added that the user needs a WAF policy to be referenced in their config.
|
|
||
| ```nginx | ||
| app_protect_security_log_enable on; | ||
| app_protect_security_log /etc/nginx/secops_dashboard.tgz syslog:server=127.0.0.1:1514; |
There was a problem hiding this comment.
elsewhere I see the path is /etc/app_protect/conf/secops_dashboard.tgz (which would make more sense since this is pre-packaged and shouldn't be in a user-managed directory, right?)
There was a problem hiding this comment.
Yes -- the correct path is "/etc/app-protect/conf/ecops_dashboard.tgz"
| Every security event carries enough context to attribute it to a specific data plane, a specific policy, and the application it targeted. | ||
|
|
||
| - **Deployment**: Each event records the F5 ADS deployment ID that produced it. Use this to scope by deployment. | ||
| - **Instance**: Each event records the NGINX instance hostname that produced it. Use this to scope by data plane. |
There was a problem hiding this comment.
Do we have these events for us given that we don't expose the underlying deployment instance details to our customers?
There was a problem hiding this comment.
That was leftover from the N1 docs, "Instance" is not applicable here.
| - **Deployment**: Each event records the F5 ADS deployment ID that produced it. Use this to scope by deployment. | ||
| - **Instance**: Each event records the NGINX instance hostname that produced it. Use this to scope by data plane. | ||
| - **Policy**: Each event records the F5 WAF for NGINX policy that produced it, so you can compare activity across policy versions or rollouts — useful for measuring the impact of a policy change before promoting it. | ||
| - **Destination hostname**: Each event records the HTTP `Host` header sent by the client — the *application* being attacked, not the instance hostname (which identifies the data plane). Use this when one data plane fronts multiple applications and you need to scope by app rather than by infrastructure. |
There was a problem hiding this comment.
not the instance hostname (which identifies the data plane) - should this be the deployment name (or identifier)?
There was a problem hiding this comment.
Clarified this. Removed discussion of the instance.
|
|
||
| The security monitoring dashboard depends on a consistent set of fields being present on every security event. The `secops_dashboard` log profile is the guarantee of that consistency: it ensures every data plane forwards the same set of fields, so the dashboard can render every event correctly. | ||
|
|
||
| ## What is the `secops_dashboard` log profile? |
There was a problem hiding this comment.
Should this content include the filepath to this log profile?
| 2. **Forwarding.** F5 WAF for NGINX writes the entry over syslog (port `1514` on localhost) using the [`secops_dashboard` log profile]({{< ref "/f5ads/platform/app-protect/waf-security-dashboard/default-log-profile.md" >}}). NGINX Agent's OpenTelemetry collector receives it through the `tcplog/nginx_app_protect` receiver. | ||
| 3. **Transport.** The collector batches events and exports them to the F5 ADS Console through the `otlp/default` exporter. Batching keeps the upstream call rate low while keeping per-event delivery latency under a minute. |
There was a problem hiding this comment.
This is a lot of internal technical detail that I don't think we should share in public docs. The use of NGINX Agent and otel are not important to how users interact with the F5ADS service and utilize our WAF capabilities.
There was a problem hiding this comment.
Agree. This was leftover from the N1 docs. Removed.
| The data pipeline has four stages: | ||
|
|
||
| 1. **Detection.** F5 WAF for NGINX inspects requests on the data plane and produces a security log entry whenever a request matches a violation, signature, or threat campaign. | ||
| 2. **Forwarding.** F5 WAF for NGINX writes the entry over syslog (port `1514` on localhost) using the [`secops_dashboard` log profile]({{< ref "/f5ads/platform/app-protect/waf-security-dashboard/default-log-profile.md" >}}). NGINX Agent's OpenTelemetry collector receives it through the `tcplog/nginx_app_protect` receiver. |
There was a problem hiding this comment.
There is a user-facing component to writing over the syslog port so it makes sense to reference that here but I'm wondering if we need to go into the internal details of our collector and receiver (unless there is a user-facing portion to it). Perhaps we can mention the collector generically, without the internal receiver name - something like:
| 2. **Forwarding.** F5 WAF for NGINX writes the entry over syslog (port `1514` on localhost) using the [`secops_dashboard` log profile]({{< ref "/f5ads/platform/app-protect/waf-security-dashboard/default-log-profile.md" >}}). NGINX Agent's OpenTelemetry collector receives it through the `tcplog/nginx_app_protect` receiver. | |
| 2. **Forwarding.** F5 WAF for NGINX writes the entry over syslog (port `1514` on localhost) using the [`secops_dashboard` log profile]({{< ref "/f5ads/platform/app-protect/waf-security-dashboard/default-log-profile.md" >}}). A collector on the data plane receives the entry and forwards it on. |
There was a problem hiding this comment.
Agree. This was leftover from the N1 docs. Removed.
| A security engineer suspects a policy is producing false positives. The engineer opens the security dashboard, filters by policy and blocked requests, and reviews the breakdown of triggered signatures. The high-volume signatures with low risk and accuracy stand out as candidates for tuning. The engineer cross-checks a few events against the raw requests to confirm the signature is firing on legitimate traffic before changing the policy. | ||
| ## What security monitoring does not cover | ||
|
|
||
| - **Access logs and performance metrics** — security monitoring only ingests F5 WAF for NGINX security events. NGINX access logs and performance telemetry are handled by other parts of the F5 ADS Console. |
There was a problem hiding this comment.
handled by other parts of the F5 ADS Console
Better to just link to the monitoring docs?
|
|
||
| 1. **Detection.** F5 WAF for NGINX inspects requests on the data plane and produces a security log entry whenever a request matches a violation, signature, or threat campaign. | ||
| 2. **Forwarding.** F5 WAF for NGINX writes the entry over syslog (port `1514` on localhost) using the [`secops_dashboard` log profile]({{< ref "/f5ads/platform/app-protect/waf-security-dashboard/default-log-profile.md" >}}). NGINX Agent's OpenTelemetry collector receives it through the `tcplog/nginx_app_protect` receiver. | ||
| 3. **Transport.** The collector batches events and exports them to the F5 ADS Console through the `otlp/default` exporter. Batching keeps the upstream call rate low while keeping per-event delivery latency under a minute. |
There was a problem hiding this comment.
I'm less concerned about this one but specifying the otlp/default exporter seems like an internal detail. Perhaps we can omit that.
There was a problem hiding this comment.
Agree. This was leftover from the N1 docs. Removed.
|
|
||
| For more information, see: | ||
|
|
||
| - [Set up security monitoring]({{< ref "/f5ads/platform/app-protect/waf-security-dashboard/set-up-security-monitoring.md" >}}) |
There was a problem hiding this comment.
The ordering here for the first 2 items is reversed from the assigned weights - (navbar shows secops_dashboard first and set up security monitoring next).
|
|
||
| --- | ||
|
|
||
| ## Deploy the `secops_dashboard` log profile |
There was a problem hiding this comment.
I'm thinking the contents of the secops_dashboard log profile page can be added here as a note instead of having those separately called out in it's own page.
There was a problem hiding this comment.
Agree. Combined them.
|
|
||
| When you select **Save Changes** in the previous step, F5 ADS Console pushes the configuration change to the deployment and displays a confirmation message. At that point, the F5 WAF for NGINX policy and the `secops_dashboard` log profile are in place on the deployment, and the security log directive is wired to NGINX Agent. | ||
|
|
||
| Any request that F5 WAF for NGINX inspects on the instance produces a security event that flows to the F5 ADS Console. Use the following checks to confirm the pipeline end to end: |
There was a problem hiding this comment.
| Any request that F5 WAF for NGINX inspects on the instance produces a security event that flows to the F5 ADS Console. Use the following checks to confirm the pipeline end to end: | |
| Any request that F5 WAF for NGINX inspects on the deployment produces a security event that flows to the F5 ADS Console. Use the following checks to confirm the pipeline end to end: |
|
|
||
| Any request that F5 WAF for NGINX inspects on the instance produces a security event that flows to the F5 ADS Console. Use the following checks to confirm the pipeline end to end: | ||
|
|
||
| 1. Send one or more requests through the protected application path on the instance you just configured. If you have a staging policy or a known test case that triggers a violation, use it so the event is easy to identify. Otherwise, normal inspected traffic is enough to confirm the pipeline. |
There was a problem hiding this comment.
| 1. Send one or more requests through the protected application path on the instance you just configured. If you have a staging policy or a known test case that triggers a violation, use it so the event is easy to identify. Otherwise, normal inspected traffic is enough to confirm the pipeline. | |
| 1. Send one or more requests through the protected application path on the deployment you just configured. If you have a staging policy or a known test case that triggers a violation, use it so the event is easy to identify. Otherwise, normal inspected traffic is enough to confirm the pipeline. |
|
|
||
| | Filter | Description | | ||
| |:--- |:--- | | ||
| | **Config Sync Group** | Events from instances in a specific Config Sync Group. | |
There was a problem hiding this comment.
Do we have this? If so, what does it mean in the context of our service where users interact with deployments?
There was a problem hiding this comment.
Nope, leftover from N1 docs. Removed.
| | **Country** | A two-letter country code derived from the client IP address. | | ||
| | **Destination Hostname** | The HTTP `Host` header that the client sent, which identifies the application being attacked. | | ||
| | **Hostname** | The NGINX instance hostname (the data plane host), which identifies the data plane that produced the events. | | ||
| | **Instance** | A specific NGINX instance, identified by object identity rather than hostname. | |
There was a problem hiding this comment.
Do we have this? If so, what does it mean in the context of our service where users interact with deployments?
There was a problem hiding this comment.
Nope, leftover from N1 docs. Removed.
| | **Violation Context Value** | The field value where the violation occurred. | | ||
| | **Violation Rating** | The numeric severity rating (0–5) that F5 WAF for NGINX assigned to the violation. | | ||
|
|
||
| Use filters to scope the dashboard to a specific policy, instance, hostname, country, IP, signature, violation, or any combination. To go from a metric on the dashboard to the underlying events, apply the relevant filter and switch to the **Event Logs** tab. |
There was a problem hiding this comment.
Similar comment as previous re: instance, and hostname?
There was a problem hiding this comment.
Nope, leftover from N1 docs. Removed.
| | **Top Signatures** | Signature (the same as the **Top Signatures** widget on the Main tab) | URIs, IP addresses, violations, and policies | | ||
| | **Top Signature CVEs** | CVE referenced by one or more signatures | URIs, IP addresses, violations, and policies | | ||
| | **Top Threat Campaigns** | Threat campaign | URIs, IP addresses, violations, and policies | | ||
| | **Top Attacked Instances** | NGINX instance hostname (not the HTTP `Host` header) | URIs, IP addresses, violations, and policies | |
There was a problem hiding this comment.
Similar comment as previous re: instance hostname
There was a problem hiding this comment.
Replaced with "Top Attacked Deployments".
amudukutore
left a comment
amudukutore
left a comment
There was a problem hiding this comment.
@edarzins - thanks for making these changes. Overall, this looks good to me.
I made a few suggestions and had a few questions (most of them related to instance and hostnames). Am approving this pending satisfactory resolution of those comments.
Documentation for configuring and operating Security Monitoring in NGINXaaS.
Consolidated it with setup-security-monitoring
Documentation for configuring and operating Security Monitoring in F5 ADS.
Proposed changes
Checklist
Before sharing this pull request, I completed the following checklist:
Footnotes
Potentially sensitive information includes personally identify information (PII), authentication credentials, and live URLs. Refer to the style guide for guidance about placeholder content. ↩