Managing Suricata Rules in Suri Oculus 4.0

Suri Oculus 4.0 provides a web interface for viewing and managing Suricata rules. Users can work with both the main Suricata ruleset and their own local rules, search for rules by SID, enable or disable rules, change rule actions, add custom rules, and validate them before use.

Rule management is divided into several logical areas:

• the main Suricata ruleset;

• user-defined local rules;

• additional rules;

• rule state configuration files;

• validation of new rules;

• applying modified rulesets to Suricata.

1. Rule Files #

Paths to the rule files used by Suri Oculus are defined in the backend configuration.

Main rules file:

/var/lib/suricata/rules/suricata.rules

Local rules:

/var/lib/suricata/rules/local.rules

Additional rules:

/var/lib/suricata/rules/additional.rules

Rule state management files are also used:

/etc/suricata/disable.conf
/etc/suricata/enable.conf
/etc/suricata/drop.conf

This separation makes it possible to keep the main Suricata ruleset separate from rules created directly by the user.

2. Main Suricata Rules #

The main ruleset contains the rules used by Suricata to analyze network traffic.

The Suri Oculus interface allows users to view these rules, search for a specific rule, and change its state.

For each rule, Suri Oculus can display information extracted from its content, including SID, revision, message, action, protocol, classtype, and current state.

Searching for a Rule by SID #

Every Suricata rule has a unique identifier called a SID.

To find a specific rule, enter its SID in the corresponding field and perform the search.

For example:

22600011

Searching by SID is particularly useful when working with large rulesets containing tens of thousands of rules.

Enabling and Disabling Rules #

A rule can have one of two states:

Enabled
Disabled

Disabling a rule removes it from the active ruleset without deleting the rule itself.

This is useful, for example, when a particular rule generates a large number of false positives but should be preserved for further analysis or later reactivation.

When changing the state, Suri Oculus uses the rule SID to identify the rule.

Changing the Rule Action #

Suri Oculus allows the action associated with a rule to be changed.

In particular, a rule can use the action:

alert

or:

drop

alert instructs Suricata to generate an event when the rule matches.

drop is used to block matching traffic when Suricata operates in a mode that supports IPS functionality.

Changing a rule action to drop should be done only after the rule behavior has been verified, because it can directly affect network traffic.

3. Local Rules #

The Local Rules tab is intended for managing custom user-defined rules.

These rules are stored separately from the main ruleset:

/var/lib/suricata/rules/local.rules

This approach allows users to create their own rules without modifying the main Suricata ruleset.

Local Rules supports:

• viewing local rules;

• searching by SID;

• adding new rules;

• deleting rules;

• enabling and disabling rules;

• switching the rule action between alert and drop.

4. Viewing Local Rules #

To display all local rules, use the:

Show Rules

button.

The rules are displayed in a table.

The following information can be shown for each rule:

To select a rule, click the corresponding row in the table.

Detailed information about the selected rule is then displayed.

The selected rule can subsequently be used for deletion, state changes, or action changes.

5. Navigating Local Rules #

When the number of rules is large, the list is divided into pages.

Use:

Previous — to move to the previous page.

Next — to move to the next page.

The number of rules displayed per page can be selected from:

10
20
30

By default, Suri Oculus displays:

20

rules per page.

6. Searching for a Local Rule by SID #

To find a local rule, enter its SID in the:

Enter SID

field and click:

Search by SID

For example:

1000001

If a rule with the specified SID exists, it will be displayed in the search results.

7. Adding a New Rule #

To create a custom rule, click:

Add Rule

A rule input dialog will open.

For example:

alert tcp any any -> any 22 (msg:"LOCAL SSH connection detected"; sid:1000001; rev:1;)

Before the rule is added, Suri Oculus validates it.

Validation is performed by Suricata itself in test mode using:

suricata -T

The new rule is written to a temporary file and validated together with the existing Suricata configuration.

The temporary rule file is loaded using the -s option, which adds it to the ruleset defined in suricata.yaml.

This is important because it allows the new rule to be tested in the context of the existing ruleset and, in particular, makes it possible to detect SID conflicts.

If the rule passes validation, it can be added to:

/var/lib/suricata/rules/local.rules

After successful addition, Suri Oculus reports:

Rule added successfully

8. SID Validation #

The SID identifies a rule and must be unique.

Before adding a new Local Rule, Suri Oculus extracts the SID from the rule and checks whether that SID is already in use.

If the SID already exists, the new rule is rejected.

For example, the server may return:

SID already in use

Therefore, it is not sufficient for the text of the new rule to differ from existing rules. Its SID must also be unique.

For custom rules, it is recommended to define a dedicated SID range in advance and use it consistently when creating Local Rules.

9. Rule Validation #

Validation is performed using the current Suricata configuration file.

The general process is:

New Local Rule
      |
      v
Temporary rule file
      |
      v
suricata -T
      |
      v
Validation
   /       \
  OK       Error
  |          |
  v          v
Add Rule   Reject Rule

If Suricata accepts the rule, Suri Oculus reports successful validation.

If an error is detected, the rule should not be added, and the interface displays information returned during validation.

This makes it possible to detect syntax and configuration errors before a rule is included in the working ruleset.

10. Why Validation Uses -s #

When testing a new rule, Suri Oculus loads the temporary rule file using:

-s

rather than:

-S

This distinction is important.

-s adds the temporary rule file to the ruleset defined by the Suricata configuration.

As a result, the new rule is checked not only by itself but also in the context of the existing ruleset.

Using -S would replace the configured ruleset with the temporary rule file. That would not represent the actual production configuration and could, among other things, hide SID conflicts.

11. Deleting a Local Rule #

To delete a rule:

1. Find the required rule.

2. Select it in the table.

3. Verify the SID and content of the selected rule.

4. Click Delete Rule.

5. Confirm the operation.

Before deleting the rule, Suri Oculus asks for confirmation.

After a successful operation, the rule is removed from the local ruleset.

Rule deletion should be performed carefully, especially when the local ruleset is used on a production system.

12. Enabling and Disabling a Local Rule #

A local rule can be temporarily disabled without deleting it.

To change its state:

1. Select the rule.

2. Click Toggle Local Rule Status.

3. Confirm the operation.

If the rule is enabled, it will be disabled.

If the rule is disabled, it will be enabled.

The current state is displayed as:

Yes

or:

No

in the Enabled field.

When changing the state, Suri Oculus identifies the rule by SID.

This means the operation does not depend on an exact match of the complete rule text.

If multiple rules with the same SID are found in local.rules, Suri Oculus treats this as a conflict and does not perform an ambiguous modification.

13. How a Disabled Local Rule Is Stored #

For local rules, the state is reflected directly in the local.rules file.

An enabled rule may look like this:

alert tcp any any -> any 22 (msg:"LOCAL SSH"; sid:1000001; rev:1;)

A disabled rule is stored as a commented line:

# alert tcp any any -> any 22 (msg:"LOCAL SSH"; sid:1000001; rev:1;)

When the rule is enabled again, the comment marker is removed.

Suri Oculus handles different formatting variants, including whitespace before the rule or after the comment marker.

14. Changing a Local Rule Action #

The:

Change Local Rule Action

button switches the action of the selected local rule:

alert -> drop

or:

drop -> alert

To change the action:

1. Select the rule.

2. Verify its SID and current Action value.

3. Click Change Local Rule Action.

4. Confirm the operation.

Suri Oculus identifies the rule by SID and determines its actual current action from local.rules.

The operation supports only:

alert
drop

If the rule uses another action, the switch is not performed.

15. Changing the Action of a Disabled Rule #

Changing alert/drop does not automatically enable a disabled rule.

For example:

# alert tcp any any -> any 22 (...)

becomes:

# drop tcp any any -> any 22 (...)

The Disabled state is preserved.

Suri Oculus therefore manages two rule properties independently:

Rule status: Enabled / Disabled
Rule action: alert / drop

This makes it possible, for example, to prepare a drop rule in advance while keeping it disabled until it is required.

16. Safe Modification of local.rules #

When changing the state or action of a local rule, Suri Oculus avoids partially overwriting the active local.rules file.

The modified ruleset is written using a temporary file, after which the working rules file is replaced atomically.

This approach reduces the risk of corrupting local.rules, for example if a write operation fails.

17. Additional Rules #

In addition to the main and local rulesets, Suri Oculus uses:

/var/lib/suricata/rules/additional.rules

The current implementation provides management of additional rule categories, including:

universal
fakenews
porno
gambling
social

This mechanism is separate from user-defined Local Rules and is used to manage additional Suri Oculus rule groups.

18. Modifying Rule Files vs. the Active Suricata Ruleset #

It is important to distinguish between:

modifying rule files

and:

applying rules to the running Suricata process

Adding, deleting, enabling, disabling, or changing a rule action modifies the corresponding rule configuration files.

This does not by itself mean that the already running Suricata process immediately starts using the modified ruleset.

The rules must be loaded by Suricata before the changes become active.

19. Reloading Rules #

Suri Oculus 4.0 includes mechanisms for reloading the Suricata ruleset.

A blocking reload is supported:

suricatasc -c reload-rules

as well as a non-blocking reload:

suricatasc -c ruleset-reload-nonblocking

Both methods allow the modified ruleset to be applied without manually editing the Suricata configuration.

The non-blocking reload requests a ruleset reload without waiting for the complete reload operation to finish before returning control.

20. Restarting Suricata #

Suri Oculus also provides a full Suricata service restart:

systemctl restart suricata

This is different from reloading the rules.

A rules reload updates the ruleset used by the running Suricata instance.

A restart completely stops and starts the Suricata process.

A full restart is a more disruptive operation and is generally not required solely for an ordinary rule modification when the ruleset can be reloaded using Suricata’s rule reload mechanism.

21. Recommended Workflow for Creating a Custom Rule #

When creating a new Local Rule, the following workflow is recommended:

1. Create the rule with the alert action.

2. Assign a unique SID.

3. Validate the rule.

4. Add the rule to Local Rules.

5. Apply the updated ruleset.

6. Test the rule against test or production traffic.

7. Analyze the generated events.

8. Adjust the rule if necessary.

9. Verify that the rule does not generate unwanted matches.

10. Only after testing, consider changing the action from alert to drop.

For example, initially:

alert tcp any any -> any 22 (msg:"LOCAL SSH connection detected"; sid:1000001; rev:1;)

After testing, the action can be changed if necessary:

drop tcp any any -> any 22 (msg:"LOCAL SSH connection detected"; sid:1000001; rev:1;)

This approach is particularly important when Suricata is operating in IPS mode, because an incorrect drop rule can block legitimate network traffic.

22. Practical Recommendations #

Use a dedicated and consistent SID range for custom rules, and do not reuse the same SID for multiple rules.

New rules should normally be introduced with the alert action first.

Before adding a rule, use the built-in Suri Oculus validation mechanism. Validation is performed by Suricata itself and therefore provides a more realistic check than simple textual syntax validation.

Before deleting, disabling, or changing the action of a rule, verify the SID of the selected rule.

When changing alert to drop, consider the current Suricata operating mode and the potential effect on network traffic.

After modifying rule files, make sure that the updated ruleset has been applied to the running Suricata instance.

23. Summary #

Suri Oculus 4.0 provides a unified interface for the main Suricata rule management operations.

The main ruleset is used to manage existing Suricata rules, while Local Rules provides a separate mechanism for user-defined rules.

Local Rules supports the complete set of essential operations:

Create
  |
Validate
  |
Add
  |
Enable / Disable
  |
alert / drop
  |
Delete

Before a new rule is added, it is validated directly by Suricata. SIDs are checked for uniqueness, and local rule modification operations identify rules by SID.

After the rule configuration has been changed, the ruleset can be reloaded by Suricata without manually editing the rule files.

This separation allows Suri Oculus to serve as a centralized rule management interface while keeping custom rules separate from the main Suricata ruleset.