Support #5369
closedsuricata-update generated classificiation.config leaves whitespace after the comma before severity
Description
Greetings,
I have my suricata configured to drop traffic in ips mode by severity level in classification.config.
While checking the alert dashboard I noticed that some traffic that was classified as severity 2 was passing through with an allow event for wordpress admin urls.
I checked into this and found that classification.config had the following 2 lines:
config classification: bad-unknown,Potentially Bad Traffic, 2
config classification: trojan-activity,A Network Trojan was detected, 1
The other lines with no white-space work as expected.
I can fix it manually and reload-rules but each time my system runs suricata-update update it regenerates the file with the aforementioned white space and causes the severity not to be picked up correctly and the traffic is allowed through.
Other lines which work look like the following:
config classification: successful-user,Successful User Privilege Gain,1
Updated by Jason Ish almost 2 years ago
This whitespace is actually coming from the classification.config provided by Suricata. Suricata-Update reads it in, but passes it through unmodified. See https://github.com/OISF/suricata/blob/master/etc/classification.config#L7, and Suricata is able to parse it just fine.
How are you dropping traffic based on severity?
Updated by John Barfield almost 2 years ago
Jason Ish wrote in #note-1:
This whitespace is actually coming from the
classification.configprovided by Suricata. Suricata-Update reads it in, but passes it through unmodified. See https://github.com/OISF/suricata/blob/master/etc/classification.config#L7, and Suricata is able to parse it just fine.How are you dropping traffic based on severity?
You know what? /me palm-in-face, I jumped the gun opening this bug report and apologize. I simply forgot that I was placing the "re:classtype:<types>" into "drop.conf" based off of any line that ended with '(,2|,1)' in "classification.conf", I will modify my "drop.conf" generation bash script like so: '^,.*(1|2)$'. I think that something close to that will solve the issue for me. I run this script after "suricata-update" in cron, just in case the classification config is modified at all after an update and then reload the rules 1 final time. This can be closed I'm sorry I wasted everyones time here.
- update
confirming that this:
`awk -F '\ |,' '/(1|2)$/ {print "re:classtype:"$3}' <PATH_TO>/classification.config >> <PATH_TO>/drop.conf`
Works perfectly!
Updated by John Barfield almost 2 years ago
One final note though, the only aspect that I can say is true about my report, is the following:
If I edit classification.config and remove the whitespace, and then run suricata-update update, the whitespace does come back everytime.
I wonder if that is just suricata reloading the rules and regenerating the file...I guess I was thinking that it was a static file that was read by suricata...I didn't realize that suricata would output that file if it were edited.
I suppose I wonder then, should there be a classification.local in the event that someone writes their own rules with special classifications?
I was considering whitelisting based off of a "safe to ignore" classification type. But if this isn't supported I'll scratch that idea.
Updated by Jason Ish almost 2 years ago
- Tracker changed from Bug to Support
- Status changed from New to Closed