Feature Request: User Defined IDS Rules

[tpcr]

The ability to add own custom rules here would be a great help. The User defined tab should be a GeoIP tab since that is the only thing it does now.

[AdSchellevis]

It also supports ssl fingerprints.... adding some simple features could be fine, but all possible rule writing options won't be realistic (the complexity of rule writing is too large for a simple ui page to handle)

[tpcr]

For my custom rules, I just add a "custom.rules" file to rules folder. Then I edit that file with my rules. It would be better to have such an editor built into the web GUI instead of going in hacking the OS.

[AdSchellevis]

We don't support file editors for validation and security reasons.

[tpcr]

It works, and there is no other provision to add custom rules. That is why I am requesting this feature.

[sempervictus]

Validation of rules is done by the IDS engine itself, or its rule manager, so there's no real need for such heavy user input as an editor - just an upload/sync method. Folks running opnsense aren't likely to build a full CIF for rule distribution, and i'm not even sure we can configure that right now. The other reason to have this functionality is to use ignore rules, because "false positives" are context/environment specific and need to be tuned accordingly (this part CAN be done via webui pretty easily since its just a list of SIDs, unless you write full qualifying conditions, at which point, back to uploading the ignore list).

[tpcr]

Ability to 'ignore rules' would be nice, also to 'suppress' alerts. But the ability to add a few simple rules in the GUI is what I am really after. Here is an example of a simple, yet powerful, rule that works well for me. drop tcp $EXTERNAL_NET any -> $HOME_NET [1:1023,![25,80,443,465,993]] (msg:"Golden Rule TCP"; classtype:bad-unknown; sid:9900004; rev:2;) Would be nice to be able to add this to the IDS/IPS from the GUI

[sempervictus]

I wouldn't recommend that, it would mean the GUI needs complex validation logic (an attack surface in itself), or perform unvalidated writes to files in the system; which is IMO, marginally worse than uploading unvalidated files to it.

[fichtner]

If anything we should have a similar user rules approach to what firewall rules are doing now. I don't think any core dev has this on the wish list and/or can allocate time accordingly, but like always any help to get there is greatly appreciated. :)

[tpcr]

I agree with fichtner. Some sort of user rule ability is doable and makes the product more flexible. The GUI is fully protected if you set it up that way with rules and a dedicated port. Also, 99.9% of users are not concerned about attacks from within the network.

[sempervictus]

I agree with the notion of restricting this function to a confined and rational set of modular inputs which can be independently validated as opposed to expression checking/eval. @tpcr: 99.9% of users have no idea about attacks at all - what they are, how they work, and what rules they need to follow. They are also how we most commonly get in - their lack of awareness combined with their out of date browsers, plugins, and network clients permits us access past the firewall filters because its logically client egress from the L3/4 perspective of the FW's state table. However, the threat model doesnt apply to most cases of business logic here because the compromised user would need an active admin session to pivot (or use default root creds and deserve what they get), which is already sufficient to get root shells from that network vector (POST request to change password, another to enable SSH/telnet on specific port, and a TCP pivot to the proper socket). The bigger threat to something like that is people copy-pasting cleverly written shells into their web UI as strings which couldn't be properly parsed out (back to expression evaluation and syntactic checking of otherwise unvalidated input). You can write a shell in pretty bloody much any language, Check my commit logs in Metasploit - last ones were in R because we had to target a stats client... Script-based execution also bypasses a ton of binary-oriented defenses (MPROTECT and such since they need to JIT), occurs in-memory without the usual on-disk forensic print, leaving only the privilege context on-target as the concern for the attacker (unless defenders are clever). Basically, its pretty dangerous to do anything that's not strictly controlled and explicitly modular, preventing full input control by the user, because "they" will find a way around any filtering implemented.

On Fri, Dec 8, 2017 at 1:35 PM, tpcr notifications@github.com wrote:

I agree with fichtner. Some sort of user rule ability is doable and makes the product more flexible. The GUI is fully protected if you set it up that way with rules and a dedicated port. Also, 99.9% of users are not concerned about attacks from within the network.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/opnsense/core/issues/1975#issuecomment-350338201, or mute the thread https://github.com/notifications/unsubscribe-auth/ABRPjHt5nr0j7Mpq64qf2veaD_WXWSC1ks5s-YF8gaJpZM4Q5uW_ .

-- Boris Lukashev Systems Architect Semper Victus

[tpcr]

This system will never be able to protect against every threat in a real world environment nor does it have to. Most users are small and not worth super hackers time or efforts. No world bank is going to use an open-source product for its security. That is not what this system is intend for. We just want mid level protection against viruses, malware, DOS, and scanner attacks along with some routing, VPN, and proxy abilities. Having some custom IDS rules makes it easier to customize.

[sempervictus]

I can see why you may think some of these things from an outside perspective, and to a degree, you're right. However, I would have to disagree with a few points: 1: (IMO) no system with inputs and outputs can be "fully secure." Its on us all to secure every thing along the way which we can think of because our entire society depends on systems that it cannot comprehend for its entire operating semantic. 2: EVERY target is worth the effort because it amplifies your reach, gives an additional network source address, and is generally a tactical foothold. Super hackers, as you put it, automate their work and amass armies of systems designed with the mindset you describe (while having dinner with their wife and kids or playing golf because its rinse and repeat). 3: Don't assume to know what banks use. Yes there is a candy store of vendor toys at play, but much more open source in the critical path than your statement implies. 4: Finally, protection is boolean on every vector. There is no middle ground in warfare, and even if you're a humble baker on a tiny island not looking to fight, your tech is a tactical asset to some bigger party out there. Defend yourself (and encourage defensible ecosystems) or deal with the alternative. The internet is a great equalizer, for asymmetric warfare among other things. Front line are your edge and client device.

Please do not try to convince developers of open source projects to sacrifice the security of all for the convenience of some. Its the sort of decision that may have implications beyond comfort.

[tpcr]

By not adding the ability to add custom rules you are limiting the scope of protection. Also other products , such as PFsense, have these abilities. Are you stating these products are more vulnerable because they offer more options? I just don't get your point, Sorry.

[fichtner]

Please keep this discussion on point for OPNsense, because that’s the only thing we can change. As a core mission we like to deliver an easy to use IPS and access to top quality rule sets. Everything else is nice to have and sooner or later needs somebody to do the work. 😊

[tpcr]

Sorry, just trying to make a point that adding custom rules is not a security threat, rather a security enhancement. I just would like it to be considered for a future feature. Thanks

[sempervictus]

@tpcr: by no means suggesting we shouldn't improve use interface to the subsystem, sorry if thats how my statements come off. The train of thought is that such improvements should keep strict controls over user inputs such as to significantly limit the freedoms available for input, and thus restricting attacker options when attempting to gain advantage through the subsystem itnerface. I am stating that "other distributions" which utilize poorly sanitized inputs feeding into execution chains by the system are far less secure. A light google search will show what fun thing can be done by these means - xmlrpc backdoors, command injections, bad things. Add some XSS and CSRF and remote attackers can influence the inputs to these applications through the victims browser context (complex attacks are more fragile than a crystal cobweb). Most of us will discover these things and report them to the vendor, work with them to fix it. The other side tends to automate exploitation of these issues and sell the result to all comers. I am ALL for custom rules, via import or menu driven entry, just not complex expression processing in a general context.

On Sat, Dec 9, 2017 at 1:13 PM, tpcr notifications@github.com wrote:

Sorry, just trying to make a point that adding custom rules is not a security threat, rather a security enhancement. I just would like it to be considered for a future feature. Thanks

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/opnsense/core/issues/1975#issuecomment-350495242, or mute the thread https://github.com/notifications/unsubscribe-auth/ABRPjFZKG9pzu06npk9iUDGFemYcIO69ks5s-s3KgaJpZM4Q5uW_ .

-- Boris Lukashev Systems Architect Semper Victus

[AdSchellevis]

timeout (https://github.com/opnsense/core/commit/7338549ba5f295f5420e45ba74112af10d20c713)