Modifying existing suricata rules?

[ejgh-oe]

Version

2.4.40

Installation Method

Security Onion ISO image

Description

configuration

Installation Type

Distributed

Location

on-prem with Internet access

Hardware Specs

Exceeds minimum requirements

CPU

8

RAM

32

Storage for /

500

Storage for /nsm

500

Network Traffic Collection

span port

Network Traffic Speeds

Less than 1Gbps

Status

Yes, all services on all nodes are running OK

Salt Status

No, there are no failures

Logs

No, there are no additional clues

Detail

Since some suricata rules generate a lot of false positives I've written my own rules, basically replacing "alert" with "pass" for certain combinations of source- and destination IPs.

For example: I get lots of false positives for sid 2100366 ("GPL ICMP_INFO PING *NIX") for an internal host pinging other hosts. So I took the builtin rule for the sid

alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"GPL ICMP_INFO PING *NIX"; itype:8; content:"|10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F|"; depth:32; classtype:misc-activity; sid:2100366; rev:8; metadata:created_at 2010_09_23, updated_at 2019_07_26;)

and generated a local rule

pass icmp 192.168.4.5 any -> $HOME_NET any (msg:"My special GPL ICMP_INFO PING *NIX"; itype:8; content:"|10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F|"; depth:32; classtype:misc-activity; sid:9000005; rev:1; metadata:created_at 2024_02_14, updated_at 2024_02_14;)

(i.e. different sid)

Problem: Despite having a "pass" in my local rule, the builtin rule still fires even for the source IP of 192.168.4.5 as it seems the builtin rules are processed first.

So I tought about modifying the original rule (sid:2100366) into

alert icmp !192.168.4.5 ... ... sid:2100366 ...

so that traffic from everything but 192.168.4.5 is being alerted, but not traffic from 192.168.4.5

My questions:

• Is it possible to modify existing suricata rules using the same sid and if yes how?
• What happens when suricata-update runs and pulls in new updates? Will this overwrite my mods?

Thanks in advance for any clue.

Guidelines

• I have read the discussion guidelines at Read before posting! #1720 and assert that I have followed the guidelines.

[petiepooo]

If you don't want an alert for a specific IP, I think you want to add a threshold/suppression to the rule instead. See the suppress section here.

Also note that if your local rule has the same SID as a downloaded rule, the local rule will take precedence over the downloaded rule. However, there's a configuration section under idstools/sids/modify that works better for that. Both of those survive daily rule updates.

[ejgh-oe]

Hi,

"suppress" won't work for me since I only want to whitelist an alarm based on a combination of source- and destination-IP which is something suppress can't do.

Also note that if your local rule has the same SID as a downloaded rule, the local rule will take precedence over the downloaded rule. However, there's a configuration section under idstools/sids/modify that works better for that. Both of those survive daily rule updates.

That's fine for a simple override, but I'm looking for something different:

Disabling an alarm for a signature when it gets triggered for a certain combination of source- and destination IP while keeping the alarm active for all other combinations of source- and destination-IP; so basically the rule should behave differently dependent of the combination of source-/destination-IP.

Also thought about a BPF-filter, but that's no option either since it gets triggered based on IP-addresses so having a BPF-filter on the combination of IP-adresses to be whitelisted would result whitelisting any sort of traffic between these two hosts.

[petiepooo]

I see. Suricata does not natively support matching by both src and dst IPs The suppress option only offers track: by_either there.

You may have to use flow-bits for that. Identify the match without IPs, but instead of triggering an alert, set flowbit 1. Then, if flowbit 1 is set but the IPs don't match your specific hosts, set flowbit 2. Repeat for all your matches. After all matches, if there's a packet with the final flowbit set, alert on it.

[ejgh-oe]

You may have to use flow-bits for that. Identify the match without IPs, but instead of triggering an alert, set flowbit 1. Then, if flowbit 1 is set but the IPs don't match your specific hosts, set flowbit 2. Repeat for all your matches. After all matches, if there's a packet with the final flowbit set, alert on it.

Suppose we have two IPs, 192.168.4.1 and 192.168.5.1 and traffic between them produces a false alarm for sid=50000.
So I don't want alarms for sid 50000 for traffic between 192.168.4.1 <> 192.168.5.1 but but sid 50000 should fire for all other traffic.

How do you mean I should approach this in terms of rules / flowbits?

(Sorry, but flowbits is something completely new for me - never worked with them (until now))

[petiepooo]

I've not created rules using flowbits myself, and don't have time to outright develop it for you, but to show an example, search through your ETGPL rules for winhlp32 and see the three rules that come up.

Notice the flowbits:noalert; and flowbits:set,winhlp32; sections in the first, and flowbits:isset,winhlp32; in the othes. If the first rule fires, it doesn't trigger an alert, just sets the flowbit. Because of the isset check, the other rules will only be run on packets with that flowbit set. So my thinking was, you:

1. create a new SID matching packets that contain the two IPs you want to omit (you may need two; one for each direction) and add flowbits:noalert; and flowbits:set,ignoreping; clauses. Repeat for any other IP pairs you wich to exclude.
2. modify (or replace) the existing rule so it only triggers if the ignoreping flowbit is not set. IOW, add a flowbits:isnotset,ignoreping; clause to it.

Suricata will take care of precedence and make sure any rule(s) setting a flowbits are run before any rule(s) using them. Note that ignoreping is just a string; choose one that makes sense to you and use it consistently. More help at https://docs.suricata.io/en/latest/rules/flow-keywords.html

[petiepooo]

Note that this is a simpler method than chaining flowbits as I originally suggested. It's also easily extensible and allows for updates from upstream if the original logic were to change.

[ejgh-oe]

Thanks alot for your help - that definitely should get me going :-)