Using Suricata SID Mgmt

bmeeks

@newUser2pfSense said in Using Suricata SID Mgmt:

I actually did the Rebuild on the interface thinking that Suricata would update/reload the rules. However, I didn't go to the interfaces tab and physically restart Suricata on the interface. I'll give that a try.

One other thing to do is to check the actual active rules file to see if the SID MGMT regex is actually finding and modifying the rule or rules you want changed. You can find the file by going to the RULES tab and then choosing "Active Rules" in the drop-down there for viewing. If you have a ton of selected rules, it can take a long time for the page to load after selecting "Active Rules". You would be looking for the specific SIDs you changed and verifying the action was changed to DROP.

You can also go to the LOGS VIEW tab and select the SID Mgmt log for viewing. You will see entries in there detailing whether or not your regex identified rules for changing and how many it changed.

newUser2pfSense

I'm currently running pfSense 2.4.5-RELEASE-p1 (amd64) and Suricata 5.0.4.

The manual action to Drop the rules are currently like this -
ET COMPROMISED Known Compromised or Hostile Host Traffic group 1
thru
ET COMPROMISED Known Compromised or Hostile Host Traffic group 217
[this if from when I was manually setting the action to Drop]

The SID Mgmt entry in the dropRules.conf file are collectively -
ET COMPROMISED Known Compromised or Hostile Host Traffic group 1
thru
ET COMPROMISED Known Compromised or Hostile Host Traffic group 247
[1:2500000-1:2500492]

So, ET COMPROMISED Known Compromised or Hostile Host Traffic group 218
thru
ET COMPROMISED Known Compromised or Hostile Host Traffic group 247
the action is not shown to Drop in the Active Rules. They are still shown to Alert.

In the Logs View tab, the Log File to View dropdown doesn't show a SID Mgmt log to view. The closest is a sid_changes.log which dispalys - Log file does not exist or that logging feature is not enabled.

bmeeks

sid_changes.log is the correct file. I was working from a faulty memory ... .

You must also select the proper interface in the Interface drop-down on that LOGS VIEW tab when viewing logs. It will default to the WAN when initially opened. Perhaps you were trying to find a sid_changes.log file for an interface which does not have any SID MGMT changes configured.

If you had the correct interface selected and it says no sid_changes.log file exists, then you have not saved something correctly and run a rules rebuild. That log file is only created when SID MGMT changes are enabled, a valid configuration file is created and assigned to an interface, and then the interface is cycled to load the change. That's when the log file is written.

newUser2pfSense

Hmmmmm...my WAN and LAN Logs View tab look like this -

I'm not sure what I've done wrong. In SID Mgmt, I checked the Rebuild boxes and clicked Save for the interfaces and then restarted the interfaces before I checked the Logs View tab above.

bmeeks

At the very top of the SID MGMT tab is a checkbox to "Enable" that feature. I assume you placed a check there and saved it?

If no log file is available, that strongly indicates SID MGMT is not enabled for the interface. That log file is written when the rules file for an interface is created. Part of the creation of the rules file is processing SID management changes (when enabled and when rules match the regex) and any user-forced rule changes to action or state. Even if no regex matches are detected, the sig_changes.log is still created showing zero matches when SID Managment is enabled on an interface.

Trust me the process works. I have a standard test that is part of my testing suite for every new Suricata package release. It changes the ET-Scan rules to DROP via SIG MGMT.

newUser2pfSense

Doh...Again, no one has ever accused me of being smart .

I checked the box at the top of SID Mgmt, chose the interfaces to Rebuild and Save, restarted the interfaces and then checked the Active Rules. All are now set on the action to Drop. As well, I can now view the sid_changes.log file.

Nice!!! Whew. I'm so glad this works.

newUser2pfSense

Ok, so now the Suricata Updates are displaying "Not Downloaded".
Installed Rule Set MD5 Signatures.png

So I chose to Force update and a half hour later, the updates are still not downloaded. In the Status > System Logs > System > General, I'm seeing -

[Suricata] There is a new set of Emerging Threats Open rules posted. Downloading emerging.rules.tar.gz...
[Suricata] Emerging Threats Open rules file update downloaded successfully.
[Suricata] There is a new set of Snort rules posted. Downloading snortrules-snapshot-29151.tar.gz...

The Snort rules is where it looks to have stopped.

Interestingly though, more than a half hour later, the updates still appear to be downloading -
Rules Update Task.png

Not sure if this is normal or not.

newUser2pfSense

So a hard restart of pfSense resolved the update issue. I think I'm out of the weeds now.

Thanks Bill.

bmeeks

@newUser2pfSense said in Using Suricata SID Mgmt:

So a hard restart of pfSense resolved the update issue. I think I'm out of the weeds now.

Thanks Bill.

You're not 100% out of the woods. You need to change your configuration to pull down the most current Snort 2.9.x rule set. That 2.9.15.1 version is now outdated. Read the information in this thread to understand why and how you must manually configure Suricata to obtain the most current Snort rules: https://forum.netgate.com/topic/110325/using-snort-vrt-rules-with-suricata-and-keeping-them-updated.

newUser2pfSense

Thanks for the link Bill. Read it all and will keep in mind to check every 30 days for any Snort rule updates. I changed the 2.9.15.1 version of the Snort rules to snortrules-snapshot-29170.tar.gz. Suricata updated with no issues.