Guide: Integrating Radware logs into our existing Splunk workflow.

Alright, fellow workflow optimizers 👋. I've been deep in the trenches of our observability stack lately, and I kept hitting a wall: our Radware Alteon logs were living in this isolated silo, while our devs and SREs live and breathe in Splunk for everything else. The context switching was killing our incident response time. So, I embarked on a mission to pipe those crucial application delivery and security logs directly into our existing Splunk dashboards.

The goal was straightforward, but the path had a few interesting forks. I wanted to avoid any "heavy" agents if possible and leverage Radware's native capabilities. Here's the playbook I settled on, after testing a couple of approaches.

### The Core Strategy: Syslog Forwarding + Splunk Heavy Forwarder

Radware Alteon supports sending syslog messages, which is perfect. The trick is formatting them for Splunk's happiness and getting them across the network securely. We opted to not send directly to the Splunk indexers, but to use a Heavy Forwarder as a receiver and parser.

**Step 1: Configuring Radware Alteon for Syslog**

This is done via the CLI. You'll want to set the syslog server to your Splunk Heavy Forwarder's IP and specify the facility and severity. We used `local4` as our facility to make filtering easy.

```bash
/cfg/sys/log/config
target remote
server
facility local4
severity info
enable
/apply
```

**Step 2: Setting up the Splunk Heavy Forwarder (Linux)**

The Heavy Forwarder needs to listen for syslog. We used `syslog-ng` for its flexibility, but `rsyslog` works too. The key is to get the messages into a file that Splunk will monitor.

*Example `syslog-ng.conf` snippet:*
```
source s_radware {
network(ip() port(514) transport("udp"));
};
destination d_radware { file("/var/log/radware/alteon.log"); };
log { source(s_radware); destination(d_radware); };
```

**Step 3: The Splunk Input & Props Configuration**

Now, tell Splunk to monitor that log file on the Heavy Forwarder. This is in `inputs.conf` on the Heavy Forwarder:

```ini
[monitor:///var/log/radware/alteon.log]
sourcetype = radware:alteon
index = net_prod
disabled = false
```

The magic (and the headache) is in `props.conf`. Radware's syslog format isn't natively parsed by Splunk. We needed to extract key fields like virtual service name, client IP, and attack signature. A lot of trial and error with regex went down here.

*Example `props.conf` extractor for a specific log type:*
```ini
[radware:alteon]
TIME_PREFIX = ^w+s+d+s+
MAX_TIMESTAMP_LOOKAHEAD = 25
TIME_FORMAT = %b %d %H:%M:%S
EXTRACT-fields = ^S+s+S+s+(?d+.d+.d+.d+).*vss+(?S+).*attacks+(?w+)
```

### Pitfalls & Lessons Learned

* **UDP vs. TCP:** We started with UDP for simplicity, but for audit logs, you might want the reliability of TCP. Radware and your syslog daemon need to support it.
* **Log Volume:** Be mindful of the verbosity. Start with `severity info` and adjust. Flooding Splunk with debug logs is expensive and noisy.
* **Time Zones:** Ensure your Radware device, syslog forwarder, and Splunk are all synchronized on timezone (UTC preferred) to avoid timestamp confusion in dashboards.
* **Field Extraction:** This is the most iterative part. Use the Splunk web interface to test your extractions on a sample log before rolling out the `props.conf` to production.

The integration has been running solidly for a few months now. Having Radware data alongside our application logs in Splunk has been a game-changer for debugging weird client issues and correlating attack patterns with application behavior. It feels less like a separate security appliance and more like a part of the unified system.

Has anyone else taken a different route? Maybe using the Splunk HTTP Event Collector (HEC) with a script in the middle? Or found a particularly elegant regex for the WAF logs? I'm always curious about alternative setups.