DDoS dynamic signatures¶

Overview¶

F5 BIG-IP Next Cloud-Native Network Functions (CNF) includes DDoS protection that lets you mitigate traffic matching a specific class or vector, such as TCP-SYN or Bad-TTL, based on thresholds you configure. However, some attack scenarios need more granular detection that goes beyond pre-defined vectors.

Behavioral DoS (BDOS) dynamic signatures address this gap. The feature has three main goals:

Identify anomalies dynamically. Detect anomalies in Layer 3 and Layer 4 packet metrics (predicates), in addition to the static vector classes already supported.
Generate signatures automatically. Create dynamic signatures based on the anomalies the system identifies.
Isolate bad traffic from good traffic. Use these signatures for detection and mitigation, the same way the system handles static DoS vectors today.

How dynamic signatures work¶

The BDOS system operates in two phases: a learning phase and a detection phase.

Learning phase¶

During the learning phase, the BDOS engine:

Reads and processes traffic statistics streamed.
Builds the baseline to identify legitimate vs anomalous traffic.

Detection phase¶

After the system completes the learning period, it transitions to the detection phase. During detection:

The learning algorithm continues to update baselines.
The anomaly detection algorithm runs periodically.
The system identifies anomalies using the generated baselines and creates signatures.

Signature correlation phase¶

Once the signatures are generated, BDOSD transitions to the correlation phase. During the correlation:

Generated signatures are initially placed in the current signature list and correlated with each other. Signatures that meet the merge criteria are combined into a single signature.
Once the attack has ended and the minimum merge period has been satisfied, the resulting signatures are moved to the past signature list, where they are retained in the system until the BDOS configuration is disabled or removed.

Architecture¶

BDOS pod¶

The BDOS engine runs as a dedicated pod (BDOSD) within your CNF deployment. The pod has four main functions:

Receive configuration: Handle configuration messages from the ingress controller and configure the BDOS engine.
Process TMM statistics: Reads and processes traffic statistics to establish behavioral baselines.
Run detection logic: Execute the core BDOS algorithms to generate dynamic signatures.
Distribute signatures: Send signature create, update, and delete messages to Traffic Management Microkernel (TMM) pods.

Statistics collection¶

BDOSD receives aggregate statistics from TMM pods via the Observer infrastructure to enable accurate learning and signature generation.

Multi-TMM scaling support¶

A single BDOSD pod reads aggregated statistics from all TMM pods through the Observer infrastructure, create baselines, identify anomalies and generates a common set of signatures, and distributes them to every TMM pod. It supports both TMM scale-up and scale-down scenarios.

Configure DDoS dynamic signatures¶

Before you begin¶

You have a working F5 BIG-IP Next CNF deployment.
Observer infrastructure pods are deployed and running, as BDOSD depends on them to collect TMM statistics.
You have access to modify Custom Resource Definitions (CRDs) in your cluster.

Enable the BDOSD pod¶

To enable the BDOSD pod and its sidecar container, add the following parameters to your cnf-values.yaml override file:

global:
  bdosd:
    enabled: true
f5-bdosd:
  enabled: true
  bdosd:
    image:
      repository: <your-registry>/f5-bdosd
      name: f5-bdosd
      tag: <version>
    enabled: true
  fluentbit_sidecar:
    image:
      repository: <your-registry>/fluentbit
    enabled: false

Note

By default, Fluent Bit log forwarding is disabled. You can enable it by setting the enabled option to true.

Configure global BDOS options¶

Use the f5-dos-global CRD to set global tuning parameters for the BDOS engine.

Set advanced options¶

The following advanced options control how the BDOS engine detects anomalies. Modify these values with careful consideration.

Parameter	Description
`anomalyDetectFreq`	How often the system runs anomaly detection, in seconds
`learningPeriod`	How long the system learns network traffic patterns, in minutes.

Example configuration:

bdosGlobalOptions:
  advancedOptions:
    anomalyDetectFreq: <value in seconds>
    learningPeriod: <value in minutes>

Enable dynamic signature detection¶

You can enable dynamic signature detection at the global level or on a per-virtual-server basis using the behavioralDos section of the CRD.

Detection modes¶

Mode	Description
`disabled`	No dynamic signature detection or action. This is the default.
`enabled`	Traffic patterns are analyzed, baselines are established, anomalies are detected, dynamic signatures are generated, and attacks are logged and mitigated.
`learn-only`	Traffic patterns are analyzed, baselines are established, and anomalies are detected. Attacks are neither logged nor mitigated, and dynamic signatures are not generated.

Mitigation sensitivity¶

When detection is set to enabled, you can control how aggressively the system drops packets during mitigation.

Level	Description
`none`	Detection only; no mitigation. This is the default
`low`	Conservative packet dropping
`medium`	Moderate packet dropping
`high`	Aggressive packet dropping

Protocol families¶

You can choose which protocol predicates the system uses for dynamic signature generation:

networkFamily: Uses Layer 3 and Layer 4 network predicates only. Set to true to enable. Default is false.
dnsFamily: Uses DNS predicates along with Layer 3 and Layer 4 predicates. Set to true to enable. Default is false.

Both options can be enabled simultaneously and are valid only when dynSigDetection is set to enabled or learn-only.

Example: Enable dynamic signatures at the global level¶

Add the below behavioralDos section to the spec of your F5BigDdosGlobal CRD and apply the CRD to your cluster.

behavioralDos:
  dynamicSignatures:
    dynSigDetection: enabled
    mitigationSensitivity: medium
    networkFamily: true
    dnsFamily: false

For example, to enable dynamic signatures globally with mitigation sensitivity and network family, your F5BigDdosGlobal CRD would look like this:

apiVersion: "k8s.f5net.com/v1"
kind: F5BigDdosGlobal
metadata:
  name: ddos-global-config
spec:
  bdosGlobalOptions:
     advancedOptions:
        anomalyDetectFreq: 10
        learningPeriod: 15
     logLevel: debug
  behavioralDos:
      dynamicSignatures:
        dynSigDetection: enabled
        mitigationSensitivity: low
        networkFamily: true

Example: Enable dynamic signatures per virtual-server¶

For per-virtual-server configuration, add the behavioralDos section to the spec of your F5BigDdosProfile CRD and apply the CRD to your cluster. For example, to enable dynamic signatures per virtual server, your F5BigDdosProfile CRD would look like this:

apiVersion: appdelivery.f5.com/v1
kind: F5BigDdosProfile
metadata:
  name: dynamic-sig-profile
  namespace: default
spec:
  behavioralDos:
    dynamicSignatures:
      dynSigDetection: enabled
      mitigationSensitivity: medium
      networkFamily: true
      dnsFamily: false

Reference the F5BigDdosProfile from your virtual server CR:

apiVersion: appdelivery.f5.com/v1
kind: VirtualServer
metadata:
  name: secure-vs
  namespace: default
spec:
  host: example.com
  pools:
    - name: web-pool
      service: web-service
      servicePort: 80
  virtualServerAddress: 10.0.0.1
  ddosProfile: dynamic-sig-profile
  http:
    - port: 443
      tls:
        termination: edge

Verify the configuration¶

You can verify the configuration using the following commands:

kubectl logs -n <namespace> <bdosd-pod-name> -c bdosd

kubectl logs -n <namespace> <tmm-pod-name> -c f5-tmm

Performance considerations¶

This feature supports up to 50 virtual servers with dynamic signatures enabled.
The system supports up to 16 TMM pods.
The Observer infrastructure streams BDOS statistics from TMM pods to BDOSD every three seconds. Any delay in this statistics collection interval can impact BDOS learning and reduce signature generation accuracy. Ensure the system remains stable during the learning phase to maintain accurate signature generation.
The BDOSD pod consists of:
- BDOSD main container: One CPU and a maximum of one GB memory.
- Fluent Bit sidecar container: 0.5 CPU and a maximum of 500 MB memory for limits; 0.3 CPU and 300 MB memory for requests.
- Stats collector: 0.5 CPU and a maximum of 500 MB memory.

Previous Next