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

    Snort - IPS mode

    Scheduled Pinned Locked Moved IDS/IPS
    4 Posts 4 Posters 2.8k 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.
    • E
      Emill
      last edited by

      Hello all,

      When creating Snort rules to drop/block, it is not functioning. It works as IDS well and does alert, but for example when the below Snort rule is used, it is not blocking.

      block tcp any any -> any any (msg:"reddit is blocked"; appid:reddit; sid:1000001; classtype:misc-activity; rev:1;)
      
      

      I tried drop, sdrop, reject instead of block, but none of them is blocking access to applications that OpenAppID has detectors for (reeddit in this case).

      Using alert works well, and I can see Snort alerts logged.

      And in snort.conf there is:

      preprocessor normalize_ip4
      preprocessor normalize_tcp: ips ecn stream
      preprocessor normalize_icmp4
      preprocessor normalize_ip6
      preprocessor normalize_icmp6
      
      

      so it is running inline mode.

      Could anyone let me know why it is not blocking? Any help is appreciated.

      1 Reply Last reply Reply Quote 0
      • P
        padpn
        last edited by

        Hello!

        I have the same issue with suricata and can not find any way to solve it (((

        1 Reply Last reply Reply Quote 0
        • J
          jeffhammett
          last edited by

          I may be wrong, but I don't think Snort on pfSense supports anything other than alert in rules (no drop, reject, block, etc.).

          To enable blocking, you leave the rules as they are (alert …) and tick the "Block Offenders" box in the settings for the specific Snort interface.

          This will then add the IP (or IPs, source, destination or both depending on "Which IP to Block" settings) to the Snort2c table which adds a firewall block for that IP. If the "Kill States" box is ticked it will also kill states for that IP immediately as well as blocking new connections. The amount of time the IP is blocked is configurable in the Global Settings tab in Snort.

          This does allow some amount of data leakage as Snort is allowing the traffic, processing it and then blocking (and optionally killing states) once an alert has been generated.

          The other thing about Snort and blocking is that there is no ability (as far as I am aware) to run a mixed mode where some rules block and others only alert.

          All of the above applies to Suricata in Legacy IPS mode as well.

          Recently an Inline mode was introduced in Suricata on pfSense that does allow for inline filtering and the drop rule functionality. This prevents data leakage and allows for running both alert and drop signatures in one instance of Suricata. This is fairly new and some people have had issues with it, so YMMV if you decide to try it.

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

            @jeffh is correct.  Snort can only block when block offenders is enabled.  This is because the custom plugin that does blocking simply uses every alert to generate a block.  So any alert that is fired will result in a block of the offending host or hosts when "block offenders" is enabled.  Which host is blocked (source, destination or both) is configurable in the GUI.  Of course alerts that are suppressed, or rules that are disabled, will not generate corresponding blocks.  Right now the plumbing used internally in Snort does not lend itself well to inline IPS mode on pfSense.  That may change in the future.

            Suricata leverages the somewhat new Netmap functionality introduced in FreeBSD (in version 9 I think, but I'm not sure off the top of my head) to provide a true inline IPS mode that honors "alert", "drop", "reject" or "pass" as rule actions.  Netmap allows very high speed pipes to be established between the NIC driver and user-land software (in this case, Suricata).  However (and it's a big "however"), Netmap is only fully supported by a tiny handful of NIC drivers on FreeBSD.  Some drivers sort of support it but are still quite buggy.  Also, in pfSense, Netmap is currently incompatible with the traffic shaper and VLANs.  So if you have a traffic shaper enabled or use VLANs, then Netmap will kill connectivity on any interface it is enabled on.  This in turn means Suricata can't work with inline mode on such an interface.

            Bill

            1 Reply Last reply Reply Quote 0
            • First post
              Last post
            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.