Some rules action not changing to drop even though the full category is set to drop

Rules
1

Hello

I am using Suricata package version 6.0.3-0ubuntu1. I am using the ET-OPEN rule set and using suricata-update to generate the suricata.rules file. It works pretty well except for some issues that we are seeing…

I have set all the ET-Open (https://rules.emergingthreats.net/open/suricata-5.0.0/emerging.rules.tar.gz ) categories to drop in the drop.conf with the following format. We are seeing that in some categories the rules are not getting changed to drop.

suricata-update

/usr/bin/python3 /usr/bin/suricata-update --suricata-conf /var/lib/suricata/ips.yaml --no-test --output /var/lib/suricata/ --enable-conf=/var/lib/suricata/amz_enable.conf --disable-conf=/var/lib/suricata/disable.conf --drop-conf=/var/lib/suricata/drop.conf --modify-conf=/var/lib/suricata/modify.conf --url https://rules.emergingthreats.net/open/suricata-5.0.0/emerging.rules.tar.gz --ignore files.rules --ignore deleted.rules

drop.conf entries

group:3coresec.rules
group:botcc.portgrouped.rules
group:botcc.rules
group:ciarmy.rules
group:compromised.rules
group:drop.rules
group:dshield.rules
group:emerging-activex.rules
group:emerging-adware_pup.rules
group:emerging-attack_response.rules
group:emerging-chat.rules
group:emerging-coinminer.rules
group:emerging-current_events.rules
group:emerging-dns.rules
group:emerging-dos.rules
group:emerging-exploit.rules
group:emerging-exploit_kit.rules
group:emerging-ftp.rules
group:emerging-hunting.rules
group:emerging-icmp.rules
group:emerging-icmp_info.rules
group:emerging-imap.rules
group:emerging-inappropriate.rules
group:emerging-info.rules
group:emerging-ja3.rules
group:emerging-malware.rules
group:emerging-misc.rules
group:emerging-mobile_malware.rules
group:emerging-netbios.rules
group:emerging-p2p.rules
group:emerging-phishing.rules
group:emerging-policy.rules
group:emerging-pop3.rules
group:emerging-rpc.rules
group:emerging-scada.rules
group:emerging-scan.rules
group:emerging-shellcode.rules
group:emerging-smtp.rules
group:emerging-snmp.rules
group:emerging-sql.rules
group:emerging-telnet.rules
group:emerging-tftp.rules
group:emerging-user_agents.rules
group:emerging-voip.rules
group:emerging-web_client.rules
group:emerging-web_server.rules
group:emerging-web_specific_apps.rules
group:emerging-worm.rules
group:threatview_CS_c2.rules
group:tor.rules
group:app-layer-events.rules
group:decoder-events.rules
group:dhcp-events.rules
group:dnp3-events.rules
group:dns-events.rules
group:http-events.rules
group:ipsec-events.rules
group:kerberos-events.rules
group:modbus-events.rules
group:nfs-events.rules
group:ntp-events.rules
group:smb-events.rules
group:smtp-events.rules
group:stream-events.rules
group:tls-events.rules

I even tried to select that particular SID and add a drop rule with the format of just specifying sid alone in the drop.conf file
2034631

Some of the rule SID where the actions are not getting set to DROP are as follows

ACTIVEX :2001622
ADWARE-PUP : 2010500, 2010501, 2018050
CHAT : 2003031, 2003032
CURRENT-EVENTS: 2019343, 2020993, 2026461, 2026462
DOS : 2014385, 2014386, 2034095
EXPLOIT : 2002914,2002915,2002918,2002919, 2034520, 2034519, 2033751 …
EXPLOIT-KIT : 2014096, 2014097, 2019668 …
MALWARE : 2022882, 2021976, … (about 104 rules here are still in alert)
and multiple other categories have rules still as alert

The same happens if I try to disable these rules which are set to enabled… They do not get disabled.

Total number of rules
root@ZKVM:/home/router# cat /var/lib/suricata/suricata.rules | wc -l
35662

Total number of rules which had they action set to drop
root@ZKVM:/home/router# cat /var/lib/suricata/suricata.rules | grep ^drop | wc -l
24752
root@ZKVM:/home/router# cat /var/lib/suricata/suricata.rules | grep ^"# drop" | wc -l
9692

Total number of rules which is still set to alert
root@ZKVM:/home/router# cat /var/lib/suricata/suricata.rules | grep ^alert | wc -l
419
root@ZKVM:/home/router# cat /var/lib/suricata/suricata.rules | grep ^"# alert" | wc -l
799

I was wondering if there is any special about these rules that they just need to only alert and not drop? I don’t think its a regex matching problem since when I specify the SID it should be a direct match and change action to drop… but that did not happen…

Any explanation on the above would be helpful

1 Like
2

After adding some debug prints in the suricata-update code, what I am seeing is that any rule which is set to flowbits:noalert is not changing their action to drop…

The DropRuleFilter is always returning false if it detects the the noalert flag…

class DropRuleFilter(object):
    """ Filter to modify an idstools rule object to a drop rule. """
    def __init__(self, matcher):
        self.matcher = matcher

    def match(self, rule):
        if rule["noalert"]:
            return False
        return self.matcher.match(rule)

        for fltr in drop_filters:
            if fltr.match(rule):
                rule = fltr.run(rule)
                dropped = True

I understand that noalert is not to alert but should it not still allow the drop operation? I see that its been that way from the beginning… Is there any reason for it?

There are about 402 rules of this nature spread across ET-Open

cat suricata.rules | grep ^alert | grep flowbits:noalert | wc -l
402

1 Like
3

I think I got it now… After carefully looking at the rules, these are also having flowbit dependencies… noalert is used in all the cases where the flowbits are set… and these rules cannot be set to action drop… as only the dependent rule which checks these bits can set the action to drop…

1 Like