Messages

[Content match Service Suricata_alert Date: Sat, 30 Aug 2025 14:41:04 Action: alert Host: opnsfwpr01.petrillo.home Description: content match:{"timestamp":"2025-08-30T14:39:03.101552-0400","flow_id":2125015740515061,"in_iface":"igb3^","event_type":"alert","src_ip":"172.16.2.2","src_port":31511,"dest_ip":"185.136.96.98","dest_port":53,"proto":"UDP","pkt_src":"wire/pcap","tx_id":0,"alert":{"action":"allowed","gid":1,"signature_id":2027758,"rev":5,"signature":"ET DNS Query for .cc TLD","category":"Potentially Bad Traffic","severity":2,"metadata":{"affected_product":["Any"],"attack_target":["Client_Endpoint"],"confidence":["High"],"created_at":["201...]

Suricata is throwing up some alerts that I think are ok but I am not sure. Is this ok??

Content match Service Suricata_alert

        Date:        Sat, 30 Aug 2025 14:41:04
        Action:      alert
        Host:        opnsfwpr01.petrillo.home
        Description: content match:
{"timestamp":"2025-08-30T14:39:03.101552-0400","flow_id":2125015740515061,"in_iface":"igb3^","event_type":"alert","src_ip":"172.16.2.2","src_port":31511,"dest_ip":"185.136.96.98","dest_port":53,"proto":"UDP","pkt_src":"wire/pcap","tx_id":0,"alert":{"action":"allowed","gid":1,"signature_id":2027758,"rev":5,"signature":"ET DNS Query for .cc TLD","category":"Potentially Bad Traffic","severity":2,"metadata":{"affected_product":["Any"],"attack_target":["Client_Endpoint"],"confidence":["High"],"created_at":["201
...

The Suricata alert indicates a network event captured on August 30, 2025, at 14:39:03 EDT, with the following details:

Timestamp: 2025-08-30T14:39:03.101552-0400
Flow ID: 2125015740515061 (unique identifier for the network flow)
Interface: igb3^ (network interface where traffic was captured)
Event Type: Alert (triggered by Suricata's intrusion detection system)
Source IP/Port: 172.16.2.2:31511 (private IP, likely internal network device)
Destination IP/Port: 185.136.96.98:53 (public IP, port 53 used for DNS)
Protocol: UDP (typical for DNS queries)
Packet Source: wire/pcap (captured from live network traffic or pcap file)
Transaction ID: 0 (tx_id for the specific transaction in the flow)

Alert Details:

Action: Allowed (traffic was not blocked)
GID: 1 (group ID for the rule)
Signature ID: 2027758 (unique ID for the rule triggered)
Revision: 5 (rule version)
Signature: ET DNS Query for .cc TLD (Emerging Threats rule for DNS query to .cc top-level domain)
Category: Potentially Bad Traffic (indicates suspicious but not necessarily malicious activity)
Severity: 2 (moderate severity, on a scale where 1 is critical, 3 is low)

Metadata:

Affected Product: Any (applies to any system)
Attack Target: Client_Endpoint (likely targeting a client device)
Confidence: High (high confidence in the rule's accuracy)
Created At: 2013 (rule creation date)

Summary: The alert was triggered by a DNS query from 172.16.2.2 to 185.136.96.98 for a .cc domain, flagged as potentially suspicious by Suricata's Emerging Threats ruleset. The .cc TLD is sometimes associated with malicious activity, but the traffic was allowed. Further investigation into the destination IP and domain context is recommended to assess risk. If you check out what this host has been reported for causing it to be flagged, you can look here. I like to use AbuseIPDB for further IP/host investigation.

[Like I said:]

Rules are copyright

I'm talking about creating your own rules such as the ones I created. They do not have copyrights.

Also then you know how to edit them

Yes

What 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.

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

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.

This works, "advanced mode" in the upper left corner.

[Summary]

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, #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), 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.

[interface LAN/WAN]

So the Floating rule should be:

Source: Any
Destination: (alias) Blocklist

This would be any (source) network on my LAN blocking traffic to that IP address. I thought by selecting interface LAN/WAN would block this IP going in and out with any protocol.

I just want to make sure no traffic in or out is going to or coming from the IP in the alias. Is there more I need to add to this rule for that?

[UPDATED THIS POST TO SHOW THE CORRECT ANSWER]

UPDATED THIS POST TO SHOW THE CORRECT ANSWER
OPNsense 24.7.12_2-amd64

Set up an alias: Firewall-> Alias
Named it: blocklist
** Type: Host(s)
Content: 34.107.243.93 (single IP example)

Created Firewall Floating Rule: Firewall-> Rules-> Floating
Action: Block
Apply the action immediatly on match: checked
Interface: LAN & WAN
Direction: any
TCP/IP Version: IPv4
Protocol: any
Source: any
Destination: (alias) blocklist

PLACES TO CHECK

If not blocking, Try: Firewall-> Diagnostic-> States-> Actions-> Reset state table

Firewall-> Diagnostics-> Aliases-> (alias name) blocklist
Should show the IP address to be blocked

** ALIAS TYPES

Host(s): This type allows you to define individual IP addresses or subnets (CIDR blocks).
Usage: It's useful when you want to create an alias that contains a list of specific IP addresses
Example: 192.168.1.100, 10.0.0.0/24, 203.0.113.0/32.

URL (IPs): This type allows you to specify a URL that contains a list of IP addresses (the URL will return a plain list of IPs, typically in a text format).
Usage: It's useful for dynamically pulling a list of IP addresses from a URL (such as a publicly available threat intelligence feed).
Example: You could enter a URL that points to an IP blocklist file, and OPNsense will download and parse that list to use it in the alias.
Example URL: https://lists.blocklist.de/lists/all.txt

URL Table (IPs): This type allows you to define an alias based on a list of IP addresses that is fetched from a URL, similar to the URL (IPs) type. However, in this case, OPNsense treats the list as a "table" and will update the list periodically (according to the refresh interval you specify) and maintain it in memory for use in firewall rules.

This fixed the issue. Thank you.

I keep getting "Error 200" when trying to view the Zenarmor logs or Live Sessions in the GUI. I cant see the logs at all. Also the database will not start, even after reboot. I tried to reinstall the zenarmor packages. That didnt help.

Is there a way to upload custom Suricata rulesets using the GUI? At one point we use to be able to do this but it doesn't look like its availaible any longer. Here was an old way:

Step 1: Navigate to the Suricata Settings

    - In the OPNsense dashboard, go to Services > Intrusion Detection.
    - Click on the "Signatures" tab.

Step 2: Add Custom Suricata Rules

    - Scroll down to the "Local Rules" section.

Here, you can add custom rules directly into the Suricata rule configuration:
You can paste the contents of your custom rules into the box.
Alternatively, you can specify a custom rule file location (more advanced).

I have this same problem. It immediatly pops up with a new schedule creation. When clicking Cancel, it take you out of the schedule tab.

[Firewall -> Nat -> Port Forward]

TO get your Plex server Fully accessible outside your network

Firewall -> Nat -> Port Forward
From this page click + (add)
No RDR: unchecked
Interface: WAN
TCP/IP Version: IPv4
Protocol: TCP
Source: Any
Source Port Range: any/any
Destination: WAN Address
Destination port range: (other) 32400/32400
Redirect target IP (Single host or Network): Plex server internal IP
Redirect target port: (other) 32400
Pool Options: Default
Description: Plex Media Server
NAT Reflection: Enable
Filter Rule Association: Pass

Services-> Unbound DNS-> Advanced-> Private Domains-> plex.direct (optional)

Firewall-> Settings -> Advanced
Reflection for port forwards: checked
Reflection for 1:1: checked
Automatic outbound NAT for Reflection: checked
Firewall Optimization: normal

[Dell DP/N: 0MX846]

Every time I follow these instructions to bridge my LAN & WIFI card I get this error:

Bridging a wireless interface is only possible in hostap mode.

How do I bridge Lan & Wifi?

Trying this: https://forum.opnsense.org/index.php?topic=5066.0
and this: https://www.cyberciti.biz/faq/howto-configure-wireless-bridge-access-point-in-pfsense/

Wifi card is a Dell DP/N: 0MX846.
https://www.pchub.com/uph/laptop/279-79033-1500/Dell-Common-Item-Dell-Wireless-LAN-Card.html

Also tried a Realtek RTL81878 MOW 11b/g and got the same error.

I'm using Suricata IPS. It keeps blocking a single specific IP address with a rule. I would like to keep the rule in place just not block the single IP. What is the correct way to whitelist the IP address so it is not blocked with the Suricata IPS rule?

[Services]

Go to:  Services>Intrusion Detection>Administration>Rules

Browse past page 6 of rules, for the example.
Then click a box to enable any rule (furthest box on the right of rule).
This bring you back to page 1 automatically.

This is very annoying while browsing each page and trying to enable individual rules. You have to remember which page you are on to go back and continue where you left off. Enabling a rule should keep you on the same page you enabled the rule from.

I have tried several WiFi cards And they all had issues. Instead of using the internal cards I flashed an old Linksys router with DDWRT firmware and used that as an access point. Since then I do not have wireless issues.