Skip to content

Radware DefensePro

Overview

Radware is a leading provider of cybersecurity and application-delivery solutions that keep enterprise applications fast, available and secure across on-premises, cloud and hybrid environments. The platform offers real-time DDoS protection, a web application firewall, application delivery controllers, bot management and API security, all unified under centralized management with advanced analytics and automation. By combining multi-layered defenses with performance optimization, Radware enables organizations to mitigate attacks, accelerate traffic and ensure continuous service availability.

Warning

Important note - This format is currently in beta. We highly value your feedback to improve its performance.

  • Vendor: Radware
  • Supported environment: On-premises
  • Detection based on: Telemetry
  • Supported application or feature: DDoS Attack Detection, Attack Mitigation, Traffic Analysis

Specification

Prerequisites

  • Resource:
    • Self-managed syslog forwarder (e.g., Rsyslog, Syslog-ng)
  • Network:
    • Outbound traffic from DefensePro to syslog server on TCP/UDP 514 (or custom port)
    • Outbound traffic from syslog server to Sekoia.io on TCP 10514
  • Permissions:
    • Administrator rights on Radware DefensePro to configure syslog forwarding
    • Root access to the Linux server hosting the syslog forwarder

Transport Protocol/Method

  • Indirect Syslog (via syslog concentrator)

Step-by-Step Configuration Procedure

Instructions on the 3rd Party Solution

Forward Radware DefensePro Logs to Sekoia.io

This setup guide will show you how to forward your Radware DefensePro logs to Sekoia.io by means of a syslog transport channel through a concentrator.

Prerequisites

Before you start:

  • Connect to Sekoia.io SOC Platform with a Defend Plan
  • Add an Intake to the relevant Entity
  • Keep track of the automatically generated Intake key
  • Have a syslog concentrator (Rsyslog or Syslog-ng) already running and configured to forward logs to Sekoia.io

Detailed Procedure

Configure Syslog on Radware DefensePro

There are two ways to configure syslog on Radware DefensePro: through the Web UI or via the APSolute Vision management portal. Choose the method that best suits your environment and preferences.

Web UI Configuration
  1. Log in to the Radware DefensePro management portal
  2. Navigate to Services > Syslog Reporting
  3. Choose Enable under the Syslog Operation menu
  4. Click on Create to add a new syslog destination server
  5. Fill in the required fields based on your syslog server configuration ( Syslog server, Syslog server Source Port, Syslog server destination Port and Protocol)
  6. Click Set to confirm the configuration
APSolute Vision Configuration
  1. Log in to the APSolute Vision management portal
  2. Navigate to Configuration > Setup > Reporting Settings > Syslog
  3. Enable syslog and enter the syslog server address and ports
  4. Select your preferred protocol (TCP or UDP)
  5. Click Submit to apply the configuration

Instruction on Sekoia

Configure Your Intake

This section will guide you through creating the intake object in Sekoia, which provides a unique identifier called the "Intake key." The Intake key is essential for later configuration, as it references the Community, Entity, and Parser (Intake Format) used when receiving raw events on Sekoia.

  1. Go to the Sekoia Intake page.
  2. Click on the + New Intake button at the top right of the page.
  3. Search for your Intake by the product name in the search bar.
  4. Give it a Name and associate it with an Entity (and a Community if using multi-tenant mode).
  5. Click on Create.

Note

For more details on how to use the Intake page and to find the Intake key you just created, refer to this documentation.

Configure a forwarder

To forward events using syslog to Sekoia.io, you need to update the syslog header with the intake key you previously created. Here is an example of your message before the forwarder 

<%pri%>1 %timestamp:::date-rfc3339% %hostname% %app-name% %procid% LOG RAW_MESSAGE
and after 
<%pri%>1 %timestamp:::date-rfc3339% %hostname% %app-name% %procid% LOG [SEKOIA@53288 intake_key=\"YOUR_INTAKE_KEY\"] RAW_MESSAGE

To achieve this you can:

  • Use the Sekoia.io forwarder which is the official supported way to collect data using the syslog protocol in Sekoia.io. In charge of centralizing data coming from many equipments/sources and forwarding them to Sekoia.io with the apporpriated format, it is a prepackaged option. You only have to provide your intake key as parameter.
  • Use your own Syslog service instance. Maybe you already have an intance of one of these components on your side and want to reuse it in order to centralize data before forwarding them to Sekoia.io. When using this mode, you have to configure and maintain your component in order to respect the expected Sekoia.io format.

Warning

Only the Sekoia.io forwarder is officially supported. Other options are documented for reference purposes but do not have official support.

Raw Events Samples

In this section, you will find examples of raw logs as generated natively by the source. These examples are provided to help integrators understand the data format before ingestion into Sekoia.io. It is crucial for setting up the correct parsing stages and ensuring that all relevant information is captured.

20-03-2025 07:49:10 WARNING 1282 ErtFeed "ERT Active Attacker: ERT;SCN" TCP 1.2.3.4 56789 5.6.7.8 8080 1 Regular "test4" occur 1 0 2605 0 N/A high drop FFFFFFFF-0000-4567-8989-012345678901

01-08-2025 12:55:01 INFO BDoS baseline learning is being suppressed now on inbound IPv4 traffic for policy "test".

01-07-2025 10:49:12 INFO User jdoe logged in via ssh 1.2.3.4

Detection section

The following section provides information for those who wish to learn more about the detection capabilities enabled by collecting this intake. It includes details about the built-in rule catalog, event categories, and ECS fields extracted from raw events. This is essential for users aiming to create custom detection rules, perform hunting activities, or pivot in the events page.

Event Categories

The following table lists the data source offered by this integration.

Data Source Description
Network Device Logs Logs generated by Radware DefensePro that provide detailed information on detected network threats, attacker behaviors, and mitigation actions taken to protect the infrastructure

In details, the following table denotes the type of events produced by this integration.

Name Values
Kind alert, event
Category authentication, intrusion_detection, network
Type denied, info, start

Transformed Events Samples after Ingestion

This section demonstrates how the raw logs will be transformed by our parsers. It shows the extracted fields that will be available for use in the built-in detection rules and hunting activities in the events page. Understanding these transformations is essential for analysts to create effective detection mechanisms with custom detection rules and to leverage the full potential of the collected data.

{
    "message": "20-03-2025 07:49:10 WARNING 1282 ErtFeed \"ERT Active Attacker: ERT;SCN\" TCP 1.2.3.4 56789 5.6.7.8 8080 1 Regular \"test4\" occur 1 0 2605 0 N/A high drop FFFFFFFF-0000-4567-8989-012345678901",
    "event": {
        "action": "drop",
        "category": [
            "intrusion_detection",
            "network"
        ],
        "code": "1282",
        "kind": "alert",
        "type": "denied"
    },
    "@timestamp": "2025-03-20T07:49:10Z",
    "destination": {
        "address": "5.6.7.8",
        "ip": "5.6.7.8",
        "port": 8080
    },
    "log": {
        "level": "WARNING"
    },
    "network": {
        "packets": 1,
        "protocol": "tcp"
    },
    "observer": {
        "product": "DefensePro",
        "vendor": "Radware"
    },
    "radware": {
        "defensepro": {
            "attack": {
                "status": "occur"
            },
            "context": "Regular",
            "mpls": {
                "rd": "0",
                "tag": "N/A"
            },
            "physical": {
                "port": 1
            },
            "risk": "high",
            "unique_id": "FFFFFFFF-0000-4567-8989-012345678901",
            "vlan": {
                "tag": "2605"
            },
            "volume": 0
        }
    },
    "related": {
        "ip": [
            "1.2.3.4",
            "5.6.7.8"
        ]
    },
    "rule": {
        "ruleset": "test4"
    },
    "source": {
        "address": "1.2.3.4",
        "ip": "1.2.3.4",
        "port": 56789
    },
    "threat": {
        "feed": {
            "name": "ErtFeed"
        },
        "technique": {
            "name": "ERT Active Attacker: ERT;SCN"
        }
    }
}

{
    "message": "01-08-2025 12:55:01 INFO BDoS baseline learning is being suppressed now on inbound IPv4 traffic for policy \"test\".",
    "event": {
        "category": [
            "network"
        ],
        "kind": "event",
        "reason": "BDoS baseline learning is being suppressed now on inbound IPv4 traffic for policy \"test\".",
        "type": "start"
    },
    "@timestamp": "2025-08-01T12:55:01Z",
    "log": {
        "level": "INFO"
    },
    "observer": {
        "product": "DefensePro",
        "vendor": "Radware"
    },
    "radware": {
        "defensepro": {
            "baseline": {
                "status": "suppressed"
            }
        }
    },
    "rule": {
        "ruleset": "test"
    }
}

{
    "message": "01-07-2025 10:49:12 INFO User jdoe logged in via ssh 1.2.3.4",
    "event": {
        "category": [
            "authentication"
        ],
        "kind": "event",
        "type": "info"
    },
    "@timestamp": "2025-07-01T10:49:12Z",
    "log": {
        "level": "INFO"
    },
    "network": {
        "protocol": "ssh"
    },
    "observer": {
        "product": "DefensePro",
        "vendor": "Radware"
    },
    "related": {
        "ip": [
            "1.2.3.4"
        ],
        "user": [
            "jdoe"
        ]
    },
    "source": {
        "address": "1.2.3.4",
        "ip": "1.2.3.4"
    },
    "user": {
        "name": "jdoe"
    }
}

Extracted Fields

The following table lists the fields that are extracted, normalized under the ECS format, analyzed and indexed by the parser. It should be noted that infered fields are not listed.

Name Type Description
@timestamp date Date/time when the event originated.
destination.ip ip IP address of the destination.
destination.port long Port of the destination.
event.action keyword The action captured by the event.
event.category keyword Event category. The second categorization field in the hierarchy.
event.code keyword Identification code for this event.
event.kind keyword The kind of the event. The highest categorization field in the hierarchy.
event.reason keyword Reason why this event happened, according to the source
event.type keyword Event type. The third categorization field in the hierarchy.
log.level keyword Log level of the log event.
network.packets long Total packets transferred in both directions.
network.protocol keyword Application protocol name.
observer.product keyword The product name of the observer.
observer.vendor keyword Vendor name of the observer.
radware.defensepro.attack.status keyword Attack status values indicate whether an event is per packet (occur), marks the start or end of a continuous event (start/term), is an ongoing report for continuous events (ongoing), or is a sampled report for continuous events (sampled).
radware.defensepro.baseline.status keyword Baseline status (e.g., active, suppressed)
radware.defensepro.context keyword Context, relevant only when SSL/TLS is used. Values: Reassembly, Regular, Decrypted HTTPS and Regular-and-Decrypted-HTTPS
radware.defensepro.mpls.rd keyword MPLS Route Distinguisher value associated with the reported event
radware.defensepro.mpls.tag keyword MPLS label/tag associated with the reported event
radware.defensepro.physical.port number Identified DefensePro physical port
radware.defensepro.risk keyword Risk level of the attack, as calculated by DefensePro
radware.defensepro.unique_id keyword Unique ID, identifying the specific security event, and added to all messages that relate to it. The unique ID is presented in GUID format
radware.defensepro.vlan.tag keyword VLAN tag associated with the reported event
radware.defensepro.volume number Total kilobits used by the attack, rounded down
rule.ruleset keyword Rule ruleset
source.ip ip IP address of the source.
source.port long Port of the source.
threat.technique.name keyword Threat technique name.
user.name keyword Short name or login of the user.

For more information on the Intake Format, please find the code of the Parser, Smart Descriptions, and Supported Events here.

Further readings