Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Does supression in suricata mean blocking or hiding the alert?

    Scheduled Pinned Locked Moved IDS/IPS
    15 Posts 3 Posters 6.9k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • bmeeksB
      bmeeks
      last edited by bmeeks

      A rule on a Suppression List is still evaluated, but it will not log an alert and will not cause a block. However, CPU cycles are still expended evaluating packets against the suppressed rule.

      A disabled rule is not even loaded into memory by the Suricata engine. Thus disabled rules do not consume CPU cycles and, since they are not even loaded, can't produce either alerts or blocks.

      A Pass List is a different animal entirely and is a pfSense-specific customization in Suricata. Legacy Mode blocking uses a custom output plugin compiled into the Suricata binary. That plugin receives a copy of every single alert generated by the Suricata traffic inspection engine. The custom plugin examines the IP addresses in the alerting packet and checks if they are on a configured Pass List for the interface. If they are, then no block is generated for that rule BUT the alert from the rule will still print to the log and show up on the ALERTS tab. It just does not result in blocked traffic. However, if an IP address in the alerting rule is not covered by a configured Pass List, then a block for that IP is inserted into the firewall's pf packet filter table called snort2c.

      So how do suppressed rules fit into the block logic? A suppressed rule can't generate an alert, and with no alert generated to be passed over to the custom blocking plugin, suppressed rules can't generate blocks.

      S Bob.DigB 2 Replies Last reply Reply Quote 3
      • S
        strongthany @bmeeks
        last edited by

        @bmeeks Thank you for the very informative response. I want to ask once more, however, only for clarification sake to me:

        1. When you say a block, that is referring to the action of suricata blocking a connection.
        2. When a rule is processed from the suppression list against a connection, that takes a cycle and, provided that the connection fits what's in the suppression list, will allow it through.

        Am I correct in my statements and understanding of how these functions and nomenclature work?

        Thank you again for the help!

        bmeeksB 1 Reply Last reply Reply Quote 0
        • Bob.DigB
          Bob.Dig LAYER 8 @bmeeks
          last edited by

          @bmeeks Can it generate drops though?

          bmeeksB 1 Reply Last reply Reply Quote 0
          • bmeeksB
            bmeeks @strongthany
            last edited by bmeeks

            @strongthany said in Does supression in suricata mean blocking or hiding the alert?:

            @bmeeks Thank you for the very informative response. I want to ask once more, however, only for clarification sake to me:

            1. When you say a block, that is referring to the action of suricata blocking a connection.
            2. When a rule is processed from the suppression list against a connection, that takes a cycle and, provided that the connection fits what's in the suppression list, will allow it through.

            Am I correct in my statements and understanding of how these functions and nomenclature work?

            Thank you again for the help!

            Yes, that is correct. Suricata on pfSense "blocks" by way of the custom output plugin I mentioned, That plugin implements a block by making a system ioctl() call to the kernel to add an IP address to a pre-existing pf table called snort2c.

            Suppression Lists prevent alerts, and because of the way the custom blocking plugin works, when there is no alert there can be no block either. The plugin works only by looking at alerts.

            1 Reply Last reply Reply Quote 1
            • bmeeksB
              bmeeks @Bob.Dig
              last edited by bmeeks

              @Bob-Dig said in Does supression in suricata mean blocking or hiding the alert?:

              @bmeeks Can it generate drops though?

              No, a suppressed rule cannot generate a drop. Suppressed rules don't "fire", and thus they can't produce the action contained in their "action" verb keyword (be it ALERT, REJECT, PASS or DROP).

              Think of a suppressed rule as being the same as a disabled rule, but suppressed rules use CPU cycles while disabled rules do not. The purpose of Suppress Lists in an IDS/IPS is so you can create certain situations where problematic or false-positive prone rules in your environment can be, in effect, bypassed when certain conditions are met (the suppression criteria).

              Bob.DigB 1 Reply Last reply Reply Quote 2
              • S
                strongthany
                last edited by

                Thank you for the reply, that all made it very clear.

                1 Reply Last reply Reply Quote 0
                • Bob.DigB
                  Bob.Dig LAYER 8 @bmeeks
                  last edited by

                  @bmeeks Thanks, that I didn't understand till now, have to clear the suppression list.
                  🖖

                  Bob.DigB 1 Reply Last reply Reply Quote 0
                  • Bob.DigB
                    Bob.Dig LAYER 8 @Bob.Dig
                    last edited by

                    @Bob-Dig I kinda wish we had a alert-hiding-function as well. For example my logs always shows

                    ET USER_AGENTS Microsoft Device Metadata Retrieval Client User-Agent
                    ET INFO Windows OS Submitting USB Metadata to Microsoft
                    

                    which I always want to be blocked or dropped but not show up anymore or maybe show up but very small or half hidden or something.

                    bmeeksB 2 Replies Last reply Reply Quote 0
                    • bmeeksB
                      bmeeks @Bob.Dig
                      last edited by

                      @Bob-Dig said in Does supression in suricata mean blocking or hiding the alert?:

                      @Bob-Dig I kinda wish we had a alert-hiding-function as well. For example my logs always shows

                      ET USER_AGENTS Microsoft Device Metadata Retrieval Client User-Agent
                      ET INFO Windows OS Submitting USB Metadata to Microsoft
                      

                      which I always want to be blocked or dropped but not show up anymore or maybe show up but very small or half hidden or something.

                      Unfortunately that's just not how Suricata (or any IDS/IPS that I am familiar with) works. And think about the puzzling issues that would be caused by a rule whose action fired (drop or reject, for instance), but nothing was logged about the action.

                      1 Reply Last reply Reply Quote 2
                      • bmeeksB
                        bmeeks @Bob.Dig
                        last edited by bmeeks

                        @Bob-Dig said in Does supression in suricata mean blocking or hiding the alert?:

                        @Bob-Dig I kinda wish we had a alert-hiding-function as well. For example my logs always shows

                        ET USER_AGENTS Microsoft Device Metadata Retrieval Client User-Agent
                        ET INFO Windows OS Submitting USB Metadata to Microsoft
                        

                        which I always want to be blocked or dropped but not show up anymore or maybe show up but very small or half hidden or something.

                        One other point -- if you are using Inline IPS Mode I suggest changing the action of these types of rules to REJECT instead of DROP. Since it is your clients initiating the transfer to Microsoft, they will attempt the connection. If it is dropped, the client gets nothing back and will probably sit and wait for a timeout. If the action is REJECT, the client is immediately sent back a notification by Suricata that the destination is not accepting connections and thus your LAN clients will not wait for a timeout.

                        Drops are good on the WAN or for external connections coming in where you want the attacker to think nothing is even there. Rejects work better when trying to block LAN-initiated traffic (or in many cases such as blocking routine telemetry). For malware type rules, a drop is perferred.

                        Bob.DigB 1 Reply Last reply Reply Quote 2
                        • Bob.DigB
                          Bob.Dig LAYER 8 @bmeeks
                          last edited by

                          @bmeeks Thanks again. I have to use the Legacy Mode, because the virtual NICs in Hyper-V are not supported for inline mode.

                          1 Reply Last reply Reply Quote 0
                          • S
                            strongthany
                            last edited by

                            On the note of that, how would one check if their interface supports netmap/inline?

                            Bob.DigB bmeeksB 2 Replies Last reply Reply Quote 0
                            • Bob.DigB
                              Bob.Dig LAYER 8 @strongthany
                              last edited by

                              @strongthany Test it. ☺

                              1 Reply Last reply Reply Quote 0
                              • bmeeksB
                                bmeeks @strongthany
                                last edited by bmeeks

                                @strongthany said in Does supression in suricata mean blocking or hiding the alert?:

                                On the note of that, how would one check if their interface supports netmap/inline?

                                These NIC drivers currently support the netmap device in FreeBSD: em(4), igb(4), ixbge(4), lem(4), re(4).

                                Features such as limiters and alternate queing algorithms do not work with netmap. So if your NIC is using one of the drivers listed above, and you are not doing using limiters, then inline mode with netmap should work for you.

                                Information on configuring the supported Intel NICs can be found in this forum sticky post: https://forum.netgate.com/topic/138613/configuring-pfsense-netmap-for-suricata-inline-ips-mode-on-em-igb-interfaces.

                                1 Reply Last reply Reply Quote 0
                                • D darkphox referenced this topic on
                                • First post
                                  Last post
                                Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.