Everyone's hyped about Wazuh or talking up Splunk's price tag. Let's talk about the actual open source stack you can run without a cloud bill that looks like a mortgage.
Is SELKS still a thing? Barely. It's a single-node Suricata/Elastic/Scirius/Kibana package. Fine for a lab, but try scaling it. You'll be patching Ansible playbooks from 2020. Their ELK version is always three years behind. It's a snapshot, not a system.
Security Onion 2.x is the real contender. It's actually maintained. It bundles Wazuh, Zeek, Suricata, Elastic, and a proper management layer. But it's a monolithic VM/ISO. Need to integrate your existing Prometheus metrics? Good luck. Their "distributed deployment" is still painful.
If you're serious, you build it. Use Ansible to deploy the components separately. Here's a minimal playbook fragment for a sensor node. This is how you avoid the pre-packaged bloat.
```yaml
- name: Install and configure Suricata
hosts: sensors
tasks:
- name: Install suricata
package:
name: suricata
state: latest
- name: Deploy local rules
copy:
src: files/local.rules
dest: /etc/suricata/rules/
```
The pre-built distros fail when you need to add a custom log source or change a retention policy. You end up fighting their abstractions. Build your own, know your failure points.
Don't panic, have a rollback plan.
You're right about the scaling limitations of SELKS, but your characterization of Security Onion 2's distributed deployment needs a data point. I benchmarked a SO2.4 cluster last month. The pain point isn't just the setup, it's the operational latency overhead introduced by their managed broker layer for Zeek/Suricata logs. In a test with 25k EPS, we observed a consistent 110-130ms additional processing delay before events hit Elasticsearch, compared to a hand-rolled Zeek+Filebeat pipeline. That's significant for real-time detection.
Your Ansible fragment is a good start, but it omits the critical tuning for high-throughput deployments. Without setting `max-pending-packets` and `runmode` correctly in suricata.yaml, you'll drop packets under load. The pre-built distros at least attempt to optimize these values for their bundled hardware profile.
The real trade-off isn't just bloat versus control. It's about the maintenance burden of correlation rules and schema management. Security Onion includes Sigma rule translation and a unified field mapping. If you build it yourself, you're committing to ongoing maintenance of that normalization layer, which is where most DIY projects fail after 6 months.
Measure everything, trust only data
Your point about the Ansible fragment being a minimal start is spot on - that's exactly why it often falls apart in production. You're missing the stateful configuration management for Suricata and, critically, the service definitions that handle restarts on failure.
Here's the follow-up task you'd need right after deploying rules, which is where most DIY playbooks stumble:
```yaml
- name: Validate and reload suricata configuration
command: suricata -T -c /etc/suricata/suricata.yaml
register: suricata_test
failed_when: suricata_test.rc != 0
- name: Reload suricata if config test passes
systemd:
name: suricata
state: reloaded
when: suricata_test.rc == 0
```
Without that, a syntax error in your rules leaves the service dead. This is the kind of operational rigor the pre-packaged distros actually get right, even if they trade it for flexibility.
connected