Feature request: Improve suricata configuration options

[lordraiden]

[X] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md

[X] I have searched the existing issues and I'm convinced that mine is new.

Is your feature request related to a problem? Please describe. The configuration options for Suricata IDS in OPNsense are pretty simple, and they don't allow to enjoy all the benefits of the IDS.

Describe the solution you'd like 1) Bring all the configuration options available on the pfsense suricata pluging. Then add: 2) The ability to filter the IDS rules at least by Client/server rules and by OS 3) Add the ability to create IDS policies based on the IDS rules selected. 4) The ability to assign an IDS policy to a firewall rule so the IDS will only work for the traffic manage by the firewall rule and with the IDS rules that were selected in the IDS policy. So you can create a firewall rule for a server and assing a IDS policy with IDS rules related with the technologies behind the firewall rule.

Screenshost sample (2016 old): https://elatov.github.io/2016/11/setup-suricata-on-pfsense/ PFsense package: https://github.com/pfsense/FreeBSD-ports/tree/6a961dfaa609ede3dbb7c38b3ca441ee066918fb/security/pfSense-pkg-suricata

Describe alternatives you've considered Explained above

Additional context One of the strenghs of opnsense is that the IDS is fully integrated but right now it is a quite simple implementation and I think it would be interesting to work more on it. Nobodody choose anymore a firewall for its "firewall" capabilities but for its cybersecurity capabilities. It would be interesting to bring other security capabilities to the opnsense "core" and not just leave them as plugings, things like the ones below should be a default in a firewall and are the things why people choose to use it. https://github.com/stamparm/maltrail https://www.sunnyvalley.io/sensei

[AdSchellevis]

There is a good reason why the number of options are limited, although I don't mind adding some advanced options, it would be good to create separate tickets for the options to add and the reason why they should exist. Our implementation is easy to use for the general audience, which is something we value a lot.

[lordraiden]

I don't think keeping it simple really helps a lot because at the end pleople choose other alternatives because things can't be done. Maybe you can take a look to the pfsense suricata interface and select those you think might be helpful. In any case what doesn't do pfsense suricata and I think is crucial are the points 2, 3, and 4. Basically any corporate firewall even having simple configuration options as you like allow you to create IDS policies and apply them to a firewall rule. So basically you don't enable the IDS for all the traffic, but only for the traffic affected by the firewall rules on which you apply a IDS policy.

This is how a IDS policy is created in Sophos XG

At least suricata in pfsense allows you to create different policies for each network or vlan I miss as well a lot of reporting capabilities The ability to supress rules

[AdSchellevis]

You can't combine filter rules with ids rules, since both act independently (netmap vs pf). Just saying, try to create tickets for features that can be developed within the scope of a ticket...

A view of the rules which can be filtered/enabled/disabled is already available (and could be improved), but we always depend on the metadata available in the rules (in case of et-open/pro, topics are easily split per file).

[lordraiden]

Other firewalls using snort can do this, relate an IDS politcy to a firewall rule, so only the traffic affected by that firewall rule is affected as well by the IDS policy assigned. If you say this is not possible in opnsense I will have to belive you.

I shouldn't be planning the roadmap of a core component of opnsense I will leave that to dev team. But basically this, and the traffic shapping that is quite basic https://github.com/opnsense/core/issues/2191 are the kind of things that keep me using other firewall instead opnsense, anyway I follow the news of opnsense very closely. Maybe with Sensei I will give it another chance.

[lordraiden]

You can't combine filter rules with ids rules, since both act independently (netmap vs pf). Just saying, try to create tickets for features that can be developed within the scope of a ticket...

A view of the rules which can be filtered/enabled/disabled is already available (and could be improved), but we always depend on the metadata available in the rules (in case of et-open/pro, topics are easily split per file).

Pfsense can apply differnet suricata configurations to different networks. Is a basic stuff in any firewall, you don't want to inspect all the WAN traffic, only the ports or IP where you have exposed services. You have to understand this to properly design a way to configure the IDS in any firewall. Currently opnsense doens't allow any fine tuning of the IDS so is a no go for anyone with a little bit of knowledge. I can max out my connection with pfsense, sophos XG, but not with opnsense.

[AdSchellevis]

From a performance point of view I can understand that you might want different suricata processes with different rulesets if the policies differ a lot between interfaces, although it likely causes a degradation in performance (memory/cpu) when all interfaces use the same policy (which we usually see, when home_nets are properly configured). We always have to seek a balance between specialised setups and easy to setup general crowd for that matter. Not saying that you can't open a feature request for it, but its not this request (the scope of this request looks like another product)

About combining firewall rules with IDS rules is only possible with other technologies (like nfqueue under linux or divert under FreeBSD), which usually is quite a lot slower than the netmap option we choose.

We prefer to use our forum (https://forum.opnsense.org) for discussions about future feature requests.

[AdSchellevis]

this might be of interest at some point in the future https://suricata.readthedocs.io/en/suricata-4.1.2/configuration/multi-tenant.html , doesn't support IPS yet according to the docs, but maybe it will later.

[aeeaan]

Wasn't sure if I should open a separate ticket for this one, but I would love to see this in the GUI. I was hoping to use opnsense behind a reverse proxy as an IDS device.

  # HTTP X-Forwarded-For support by adding the unified2 extra header that
  # will contain the actual client IP address or by overwriting the source
  # IP address (helpful when inspecting traffic that is being reversed
  # proxied).
  xff:
    enabled: no
    # Two operation modes are available, "extra-data" and "overwrite". Note
    # that in the "overwrite" mode, if the reported IP address in the HTTP
    # X-Forwarded-For header is of a different version of the packet
    # received, it will fall-back to "extra-data" mode.
    mode: extra-data
    # Header name were the actual IP address will be reported, if more than
    # one IP address is present, the last IP address will be the one taken
    # into consideration.
    header: X-Forwarded-For

[labor4]

I think better separation of WAN (SSL, Fingerprints, IP Blacklists) against behind-proxy (deeper inspection) would make a lot of sense, also in a performance manner since ie "deep rules" need not be loaded for SSL.

I also second the xff post since i cannot put it in the custom.yaml (?) and with each update the mainconfic.yaml needs to be patched.

Also suricata has more variables like for webservers, special ports, that i'd love to see in the gui.

could multi-tenant become a strategy for dealing with special interests (separate advanced/handwritten stuff)? a major benefit would also be persisting config files. maybe the gui could generate all up to an empty tenant-1.yaml file, and from there on it's custom. just a wild guess though.

cheers, and thanks

[lordraiden]

I think better separation of WAN (SSL, Fingerprints, IP Blacklists) against behind-proxy (deeper inspection) would make a lot of sense, also in a performance manner since ie "deep rules" need not be loaded for SSL.

I also second the xff post since i cannot put it in the custom.yaml (?) and with each update the mainconfic.yaml needs to be patched.

Also suricata has more variables like for webservers, special ports, that i'd love to see in the gui.

could multi-tenant become a strategy for dealing with special interests (separate advanced/handwritten stuff)? a major benefit would also be persisting config files. maybe the gui could generate all up to an empty tenant-1.yaml file, and from there on it's custom. just a wild guess though.

cheers, and thanks

All this is what is holding me, an I guess anyone using IDS from moving to opnsense. O hope some effort is put into this in the future. Maybe doesn't have to be as advanced as pfsense.

[fichtner]

I also second the xff post since i cannot put it in the custom.yaml (?) and with each update the mainconfic.yaml needs to be patched.

@labor4 this makes no sense to me, can you elaborate?

[labor4]

I also second the xff post since i cannot put it in the custom.yaml (?) and with each update the mainconfic.yaml needs to be patched.

@labor4 this makes no sense to me, can you elaborate?

i tried to do custom edits in the included custom.yaml file. but order seems important in the syntax (wont start, errors). so i needed to edit the main template. after an opnsense update, the main template gets overwritten. so i will have to correct it again.

[fichtner]

Is this a known limitation in Suricata yaml or a bug that upstream could fix?

[labor4]

Is this a known limitation in Suricata yaml or a bug that upstream could fix?

i think expected behaviour for suricata.yaml. it's just getting replaced with an update.

but my point is: custom.yaml is for special wishes, but how should one use custom.yaml? i tried to verify the problems the last hour, and it seems it's not possible to "merge" subcategories using the custom.yaml.

probably inherent to basic yaml. (There exist multiple flavours)

[fichtner]

To be honest this is a question for upstream, hence my surprise for the issue. I know from Unbound that includes get merged into the global scope and the last include wins (keypath+value).

PS: Which custom.yaml are you editing?

[labor4]

To be honest this is a question for upstream, hence my surprise for the issue. I know from Unbound that includes get merged into the global scope and the last include wins (keypath+value).

maybe an example/use case..? i'm a newbie to yaml world after all. in some cases out there includes can lead to indent problems.

PS: Which custom.yaml are you editing?

the one side along suricata.yaml that gets included by default. (templates folder)

[labor4]

could multi-tenant become a strategy for dealing with special interests (separate advanced/handwritten stuff)? a major benefit would also be persisting config files. maybe the gui could generate all up to an empty tenant-1.yaml file, and from there on it's custom.

actually if you would open that pandora box, i'd open the discussion for "auto vs. manual", with "manual" being a text editor in the gui (taking pressure from advanced new-features requests), stored via DB. sort of. because the backup'ability would be beautiful. i like that about the haproxy plugin.

but maybe someone with pfsense experience can tell better what to learn from their solution.

[tpcr]

I would like to see the option of Reject Action be added. With REJECT, the packet is still dropped, but the sender is notified that the packet was rejected by the recipient. This is helpful when used with rules associated with internal hosts. It can prevent applications from experiencing long timeout periods waiting for feedback about a packet that was actually dropped. With REJECT rules, the sender gets immediate notification that the recipient refused to accept the packet.

[AdSchellevis]

This issue has been automatically timed-out (after 180 days of inactivity).

For more information about the policies for this repository, please read https://github.com/opnsense/core/blob/master/CONTRIBUTING.md for further details.

If someone wants to step up and work on this issue, just let us know, so we can reopen the issue and assign an owner to it.