Feature Request: GUI-Based Editor for Full Suricata Rule Syntax in OPNsense
Date: August 23, 2025
To: OPNsense Development Team
Subject: Request for Enhanced GUI Support for Adding and Editing Custom Suricata Rules
Summary
I respectfully request the addition of a GUI-based editor in OPNsense to allow users to manually add and edit full Suricata rules with complete syntax support, including advanced keywords such as fileext, http.method, and pcre. This feature would enhance the usability of the Suricata IDS/IPS plugin by eliminating the need for SSH-based file editing, which is currently required for complex rule definitions.
Current Limitation
The Services > Intrusion Detection > User Defined tab in OPNsense 25.7.2 provides a form for adding custom rules, but it is limited to basic fields: Enabled, Source IP, Destination IP, SSL/Fingerprint, and Action. These fields support simple IP-based or SSL fingerprint rules but do not allow users to specify advanced Suricata keywords or protocol-specific conditions. For example, to detect .dat file exfiltration via HTTP uploads, a rule like the following is needed:
drop http $HOME_NET any -> $EXTERNAL_NET any (msg:"Blocked .dat File Exfiltration via HTTP Upload"; http.method; content:"POST"; nocase; fileext:"dat"; filestore; sid:1000010; rev:2;)
OR
drop http $HOME_NET any -> $EXTERNAL_NET any (msg:"Blocked .dat File Exfiltration via HTTP Upload"; http.method; content:"POST"; nocase; fileext:"dat"; filestore; sid:1000010; rev:2;) drop ftp $HOME_NET any -> $EXTERNAL_NET any (msg:"Blocked .dat File Exfiltration via FTP"; fileext:"dat"; filestore; sid:1000011; rev:2;) drop smtp $HOME_NET any -> $EXTERNAL_NET any (msg:"Blocked .dat File Exfiltration via SMTP"; fileext:"dat"; filestore; sid:1000012; rev:2;) drop smb $HOME_NET any -> $EXTERNAL_NET any (msg:"Blocked .dat File Exfiltration via SMB"; fileext:"dat"; filestore; sid:1000013; rev:2;) drop nfs $HOME_NET any -> $EXTERNAL_NET any (msg:"Blocked .dat File Exfiltration via NFS"; fileext:"dat"; filestore; sid:1000014; rev:2;) drop dns $HOME_NET any -> $EXTERNAL_NET any (msg:"Blocked .dat File Exfiltration via DNS Tunneling"; dns.query; content:".dat"; nocase; pcre:"/^[a-f0-9]{32,}.dat$/"; sid:1000015; rev:2;)
This requires editing /usr/local/etc/suricata/rules/custom.rules via SSH, which is inaccessible to users without CLI experience or those in restricted environments where SSH is disabled for security reasons. Additionally, the absence of a GUI-based file editor under System > Diagnostics in some installations (e.g., 25.7.2) further complicates manual rule management.
Impact
Accessibility: Users without SSH access or CLI expertise cannot implement advanced Suricata rules, limiting the IDS/IPS functionality for non-technical administrators.
Security Risks: Enabling SSH to edit configuration files introduces potential security vulnerabilities, especially in production environments where SSH is disabled.
Use Case Example: Detecting file exfiltration (e.g., .dat or .pdf files via HTTP, FTP, SMTP, SMB, NFS, or DNS) requires complex rules with fileext and protocol-specific keywords. Without GUI support, users must resort to manual file edits, increasing the risk of errors and configuration issues.
Efficiency: Manual SSH-based edits are time-consuming and error-prone, requiring validation steps (e.g., suricata -T) that are not integrated into the GUI workflow.
Proposed Solution
I propose adding a Custom Rule Editor to the OPNsense GUI, either within Services > Intrusion Detection > User Defined or as a new tab (e.g., Custom Rules).
The editor should include:
Text-Based Rule Input:
A text area for entering full Suricata rule syntax, supporting all keywords (e.g., fileext, http.method, dns.query, pcre).
Syntax highlighting or validation to catch errors (e.g., invalid SIDs, missing semicolons).
Rule Management:
Options to add, edit, delete, enable/disable, and assign SIDs to custom rules.
Ability to group rules into categories (e.g., "File Exfiltration") for organization.
Integration with Suricata:
Automatic addition of rules to /usr/local/etc/suricata/rules/custom.rules (or a similar file).
Validation button to run suricata -T and display errors within the GUI.
Option to reload Suricata after changes (equivalent to service suricata restart).
Configuration Checks:
Automatic verification of prerequisites (e.g., file-store and fileinfo enabled in suricata.yaml for fileext rules).
Warnings for undefined variables (e.g., $HOME_NET) with suggestions to configure them in Global Settings.
Benefits
User Accessibility: Enables non-technical users to leverage Suricata's full capabilities without CLI knowledge, broadening OPNsense's audience.
Security: Reduces reliance on SSH, aligning with secure configurations where SSH is disabled.
Efficiency: Streamlines rule creation and management within the familiar GUI, reducing errors and configuration time.
Flexibility: Supports advanced use cases (e.g., file exfiltration detection, custom protocol monitoring) not possible with the current User Defined form.
Consistency: Aligns with other OPNsense features (e.g., firewall rule editor) that offer robust GUI controls.
Use Case Example
To detect and block .dat file exfiltration, users need to implement rules like I posted above.
Currently, this requires SSH access to edit /usr/local/etc/suricata/rules/custom.rules and verify /usr/local/etc/suricata/suricata.yaml, which is cumbersome and inaccessible in some environments. A GUI editor would allow users to input this rule directly, validate it, and apply it without leaving the web interface.
Additional Notes
Community Support: OPNsense forum threads and GitHub issues (e.g., #8232 (https://github.com/opnsense/core/issues/8232), #3472 (https://github.com/opnsense/core/issues/3472)) highlight user demand for enhanced Suricata rule management, suggesting this feature would be well-received.
Implementation Feasibility: Similar GUI-based rule editors exist in competing platforms (e.g., pfSense's Snort/Suricata interfaces (https://iritt.medium.com/configuring-custom-rules-in-snort-for-network-monitoring-on-pfsence-interface-for-your-d536798b27e3)), providing a model for development.
Fallback: If a full editor is resource-intensive, consider adding a System > Diagnostics > Edit File option for suricata.yaml and custom.rules to all OPNsense versions, as it's missing in some 25.7.2 installations.
Conclusion
Adding a GUI-based editor for full Suricata rule syntax would significantly enhance the usability and security of OPNsense's IDS/IPS functionality. It would empower users to implement advanced rules for scenarios like file exfiltration detection without requiring CLI access, aligning with OPNsense's user-friendly design. We appreciate the development team's efforts and look forward to your consideration of this feature.
Thank you.
Rules are copyright
Also then you know how to edit them
What difference does it make where
Also security considerations, reloads, updates
They are in two places for a reason
If you want, you can write your own rules and put them in the rules
Security is a top priority
Anyone who knows that much, can easily customize and do there own thing, its not for everyone
Example, if you can change them, so can I from somewhere else
QuoteRules are copyright
I'm talking about creating your own rules such as the ones I created. They do not have copyrights.
QuoteAlso then you know how to edit them
Yes
QuoteWhat difference does it make where?
Like I said: "Accessibility: Users without SSH access or CLI expertise cannot implement advanced Suricata rules, limiting the IDS/IPS functionality for non-technical administrators."
And benefits of: User Accessibility: Enables non-technical users to leverage Suricata's full capabilities without CLI knowledge, broadening OPNsense's audience.
And in my conclusion:Adding a GUI-based editor for full Suricata rule syntax would significantly enhance the usability and security of OPNsense's IDS/IPS functionality. It would empower users to implement advanced rules for scenarios like file exfiltration detection without requiring CLI access, aligning with OPNsense's user-friendly design. We appreciate the development team's efforts and look forward to your consideration of this feature.
QuoteAlso security considerations, reloads, updates
They are in two places for a reason. If you want, you can write your own rules and put them in the rules. Security is a top priority
Anyone who knows that much, can easily customize and do there own thing, its not for everyone. Example, if you can change them, so can I from somewhere else
A GUI-based Suricata rule editor can be designed with strict access controls, such as role-based permissions, to prevent unauthorized changes, mitigating the risk of external tampering. Separating rule management into two places (GUI and CLI) creates inconsistency and complexity, which a unified GUI solution would streamline without sacrificing security. Custom rules via CLI require technical expertise, excluding non-technical users, whereas a GUI editor democratizes access while maintaining validation checks (e.g., suricata -T) to ensure rule integrity. Reloads and updates can be handled securely within the GUI, similar to existing OPNsense firewall rule workflows, ensuring stability and alignment with user-friendly design.
Please read this - the way everyone else does it with Suricata is 'suricata-update', so, to do 'suricata-update' on OPNSense you will have to change some things...
https://www.nova-labs.net/using-suricata-update-on-opnsense/
We dont use suricata-update in opnsense
And what your asking is, for us to do away with the security measures that have been put in place
Understood, but no I am not "asking us to do away with security measures". It is the original (and hails from the pulled-pork/oinkmaster days with Snort if you have used IDS that long) way.
You do not have to use it, OPNSense has designed their own way to enable/disable rules and the policy system works. It does not let you 'edit' the rules - and yes, if you know what you are doing, you can increase your security with a few useful rule edits.
Here's a git repo I made with some 'suricata-update' config examples to help people get started.
https://github.com/j0nny55555/noiseless-suricata-update (https://github.com/j0nny55555/noiseless-suricata-update)
The 'suricata-update' method is the way that ships with Suricata by default (and is already present on the OPNSense, it gets installed w/suricata) but OPNSense does not use it. IMHO, the GUI that should be made for the OPNSense should use 'suricata-update' in the background and then we can disable/enable/modify/drop rules very quickly as it works quite fast.
If you are like me and have an aging box running your OPNSense, the 'suricata-update' method will put a decent tax on the system resources... so now I have a docker container run the same suricata version on my OPNSense and build my rules file that I have the OPNSense download. It is pretty clever, fast, and resource light on the router as another beefy box does all the rule building heavy lifting (regex mods can get heavy on 200k+ rules).