change action for all ruleset categories except one (via regex?) in dropsid.conf

[tinfoilmatt]

if "emerging" is specificed in dropsid.conf, all ET rules from all categories have their action changed from ALERT to DROP. now how can emerging-info.rules be excluded? is it possible using regex?

replacing "emerging" with any of the following expressions fails (but the rest of dropsid.conf succeeds):

emerging-
emerging-(?!inf).+
emerging-(?!inf)\w+
emerging-(?!inf)\w+.+
emerging-(?!inf)\w+.rules

emerging\-
emerging\-(?!inf).+
emerging\-(?!inf)\w+
emerging\-(?!inf)\w+.+
emerging\-(?!inf)\w+.rules

prefixing "emerging" with the keyword "pcre:" behaves the same as "emerging": all ET rules from all categories have their action changed from ALERT to DROP. but prefixing any of the above expressions with "pcre:" fails (and still the rest of dropsid.conf succeeds).

[bmeeks]

No, the dropsid.conf logic is not expecting regex in the names. It is looking for a complete category name, a specific SID, or a SID range.

Just enter the specific Emerging Threats files you want in the list by name. It will take a few minutes to type or paste in, but then your done.

[tinfoilmatt]

hey @bmeeks, thanks for the quick reply. thought that might be the case after seeing this thread. would have to agree with @Gblenn however that there is a legitimate use case to change rule action to DROP selectively by category via dropsid.conf, given the package's ruleset and SID MGMT processing 'order of operations'.

in this case working with the ET ruleset—and the goal is to change action for all rule categories to DROP while excluding only a few such as Deleted, Info, Hunting, and JA3 for example. you maintain the most effective way to accomplish that is to type out all 53 categories save for the ones to be excluded? ditto for the 68 current Snort categories?

[bmeeks]

@cyberconsultants said in change action for all ruleset categories except one (via regex?) in dropsid.conf:

you maintain the most effective way to accomplish that is to type out all 53 categories save for the ones to be excluded? ditto for the 68 current Snort categories?

No, not saying it is the most effective way -- just that currently it is the only way the PHP code as currently written in the package works.

I am a volunteer maintainer for the package and receive no compensation for my efforts. However, it is completely open source and pull requests are accepted for improvements. The Netgate GitHub project for the PHP GUI portion of the package can be found here: https://github.com/pfsense/FreeBSD-ports/tree/devel/security/pfSense-pkg-snort.

I should also mention that the Snort package on pfSense is currently based on Snort 2.9.x and not the more recent and current 3.x branch. There is currently no effort that I am aware of to create a Snort3 package. Thus, unless someone takes up that mantle to create a Snort3 package, once Talos/Cisco upstream drops support of Snort 2.9.x, then the pfSense Snort package will disappear. I've been concentrating most of my efforts on Suricata.

[tinfoilmatt]

@bmeeks your efforts are well known and appreciated by a wide range of communities across both softwares and their respective pfSense packages, Bill! didn't mean to come across as ungrateful. was more so continuing what seemed like the discussion from the other thread i linked. my apologies.

just realizing it hasn't yet been mentioned that this has all been within the Suricata package.

and we did have a look at what we think is the dropsid.conf parser function while trying to determine if the regex efforts were futile, but frankly lack the skill to decipher it.

would you consider this a legitimate Suricata feature request? a regex subparser included in both the modifysid.conf and dropsid.conf files? it would greatly enhance the functionality of both, advanced 'find and replace' with the former, and action management by rule category (etc.) with the latter, as just two examples.

[bmeeks]

It might be useful, but trying to incorporate regex parsing where you accept others' regex arguments has proven to be "prickly" in PHP. It seems hard to handle the escape codes properly.

You will note that the current code uses regex parsing itself, but those expressions are built into the code. They are not being supplied by the user. That's the part that has proven hard to get right (at least for me). I've had to modify the code around modify.sid at least twice as I recall in both packages because users complained about the implementation. It centered around properly detecting escape delimiters and the behavior of them when the regex was evaluated within PHP.

So, long story shortened a bit, I'm not enough of a regex expert (far, far from one, actually) to have confidence I would get such code working correctly in all situations.