Suricata rules files specified but not loaded error

[HaydenB0101]

Version

2.4.201

Installation Method

Security Onion ISO image

Description

configuration

Installation Type

Standalone

Location

on-prem with Internet access

Hardware Specs

Exceeds minimum requirements

CPU

12

RAM

32

Storage for /

200

Storage for /nsm

400

Network Traffic Collection

tap

Network Traffic Speeds

1Gbps to 10Gbps

Status

Yes, all services on all nodes are running OK

Salt Status

Yes, there are salt failures (please provide detail below)

Logs

Yes, there are additional clues in /opt/so/log/ (please provide detail below)

Detail

My forward nodes are reporting they are unable to find a rules file in /etc/suricata/rules. This path doesn't exist on my nodes. but I do have rules files under /opt/so/conf/suricata/rules. I have recently run Soup and ran salt-call state.highstate on the forward nodes and on the manager but calling it doesn't create the path the config wants. The docker for Suricata only has PLACEHOLDER in the /etc/suricata/rules file path. Is there a config i should change, or is something misconfigured elsewhere?

Guidelines

• I have read the discussion guidelines at Read before posting! #1720 and assert that I have followed the guidelines.

[HaydenB0101]

Looking at the fixes page, specifically #15396 , would I need to change my Suricata config to look for all.rules in /opt/so/conf, and would I need to change how my nodes are getting those rule files from updates? Also following along to #15429

[HaydenB0101]

It was already set to all-rules.rules and didn't change how it was syncing, but i was able to get the origional syncblock file and the text in it

Suricata ruleset sync is blocked until this file is removed. **CRITICAL** Make sure that you have manually added any custom Suricata rulesets via SOC config before removing this file - review the documentation for more details: https://docs.securityonion.net/en/2.4/nids.html#sync-block
Custom so-rule-update detected (hash: 69e567075e969d403a897ffaa392d8d2cd359d7ba5796a5bed2323dedaff12cc)

i have versions of this under:

/nsm/backup/detections-migration/2-4-200/so-rule-update
/root/SecurityOnion/salt/idstools/tools/sbin_jinja/so-rule-update
/var/cache/salt/minion/files/base/idstools/tools/sbin_jinja/so-rule-update
/usr/sbin/so-rule-update

[cm-ops]

If you cat /usr/sbin/so-rule-update what does it show?

[HaydenB0101]

cat /usr/sbin/so-rule-update
#!/bin/bash

# if this script isn't already running
if [[ ! "`pidof -x $(basename $0) -o %PPID`" ]]; then

    . /usr/sbin/so-common
# Download the rules from the internet
    export http_proxy=http://webproxy:8080
    export https_proxy=http://webproxy:8080
    export no_proxy="localhost, 127.#.#.#, 127.#.#.#, manager, manager.com"

    mkdir -p /nsm/rules/suricata
    chown -R socore:socore /nsm/rules/suricata
# Download the rules from the internet
    docker exec so-idstools idstools-rulecat -v --suricata-version 7.0.3 -o /nsm/rules/suricata/ --merged=/nsm/rules/suricata/emerging-all.rules --force

    argstr=""
    for arg in "$@"; do
        argstr="${argstr} \"${arg}\""
    done

    docker exec so-idstools /bin/bash -c "cd /opt/so/idstools/etc && idstools-rulecat --force ${argstr}"

fi

[HaydenB0101]

Well, turns out what I was missing was adding the proxy into each ruleset source. I used my http proxy in each rule, synced SOC, and ran a full update on Suricata. Still not sure if anything needs to be done with so-rule-update since idstools is gone now, but I'm getting Suricata logs now.