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

    Suricata 4.1.4_2 not blocking hosts

    Scheduled Pinned Locked Moved IDS/IPS
    49 Posts 7 Posters 8.3k 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

      To be sure blocking is working, I just installed the latest 4.1.4_2 version of Suricata on a virtual machine and then scanned the WAN IP address of that virtual machine from a Kali Linux host using nmap. I enabled the emerging-scan rules in Suricata.

      Here are some of the alerts from the nmap scan:

      ExampleAlerts.png

      And here is the BLOCKS tab showing the Kalin Linux host getting blocked. The Kali Linux IP address is 192.168.10.21:

      ExampleBlock.png

      So Suricata appears to be working fine. You have something quite out of shape in your firewall. Those warning messages about receiving an invalid IP are not normal!

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

        Hi bmeeks,

        I reinstalled pfsense and configured it from scratch. Then I installed Suricata, and I no longer have errors. Thanks for the info and feedback!

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

          @StephenAmazen said in Suricata 4.1.4_2 not blocking hosts:

          Hi bmeeks,

          I reinstalled pfsense and configured it from scratch. Then I installed Suricata, and I no longer have errors. Thanks for the info and feedback!

          Good deal! Glad you got is sorted out.

          1 Reply Last reply Reply Quote 0
          • B
            bose301s
            last edited by bose301s

            Same Issue, I updated to the new release and changed nothing else and since doing so nothing is being added to black list even though I have Legacy Mode blocking enabled.

            12/6/2019 -- 13:13:44 - <Notice> -- This is Suricata version 4.1.4 RELEASE
            12/6/2019 -- 13:13:44 - <Info> -- CPUs/cores online: 4
            12/6/2019 -- 13:13:44 - <Info> -- HTTP memcap: 67108864
            12/6/2019 -- 13:13:44 - <Notice> -- using flow hash instead of active packets
            12/6/2019 -- 13:13:44 - <Info> -- alert-pf -> Creating automatic firewall interface IP address Pass List.
            12/6/2019 -- 13:13:44 - <Info> -- alert-pf -> adding firewall interface igb0 IPv6 address fe80:0000:0000:0000:02e0:67ff:fe13:c174 to automatic interface IP Pass List.
            12/6/2019 -- 13:13:44 - <Info> -- alert-pf -> adding firewall interface igb0 IPv4 address 68.20.12.27 to automatic interface IP Pass List.
            12/6/2019 -- 13:13:44 - <Info> -- alert-pf -> adding firewall interface igb0 IPv6 address 2600:1700:0bab:6d00:02e0:67ff:fe13:c174 to automatic interface IP Pass List.
            12/6/2019 -- 13:13:44 - <Info> -- alert-pf -> adding firewall interface igb0 IPv6 address 2600:1700:0bab:6d00:0000:0000:0000:0044 to automatic interface IP Pass List.
            12/6/2019 -- 13:13:44 - <Info> -- alert-pf -> adding firewall interface igb1 IPv4 address 192.168.1.1 to automatic interface IP Pass List.
            12/6/2019 -- 13:13:44 - <Info> -- alert-pf -> adding firewall interface igb1 IPv6 address 2600:1700:0bab:6d0f:02e0:67ff:fe13:c175 to automatic interface IP Pass List.
            12/6/2019 -- 13:13:44 - <Info> -- alert-pf -> adding firewall interface igb1 IPv6 address fe80:0000:0000:0000:0000:0000:0001:0001 to automatic interface IP Pass List.
            12/6/2019 -- 13:13:44 - <Info> -- alert-pf -> adding firewall interface lo0 IPv6 address 0000:0000:0000:0000:0000:0000:0000:0001 to automatic interface IP Pass List.
            12/6/2019 -- 13:13:44 - <Info> -- alert-pf -> adding firewall interface lo0 IPv6 address fe80:0000:0000:0000:0000:0000:0000:0001 to automatic interface IP Pass List.
            12/6/2019 -- 13:13:44 - <Info> -- alert-pf -> adding firewall interface lo0 IPv4 address 127.0.0.1 to automatic interface IP Pass List.
            12/6/2019 -- 13:13:44 - <Info> -- alert-pf output device (regular) initialized: block.log
            12/6/2019 -- 13:13:44 - <Info> -- alert-pf -> Pass List /usr/local/etc/suricata/suricata_63062_igb0/passlist parsed: 14 IP addresses loaded.
            12/6/2019 -- 13:13:44 - <Info> -- alert-pf -> Created firewall interface IP change monitor thread for auto-whitelisting of firewall interface IP addresses.
            12/6/2019 -- 13:13:44 - <Info> -- alert-pf output initialized, pf-table=snort2c block-ip=both kill-state=on block-drops-only=off
            12/6/2019 -- 13:13:44 - <Info> -- alert-pf -> Firewall interface IP address change notification monitoring thread started.
            12/6/2019 -- 13:13:44 - <Info> -- fast output device (regular) initialized: alerts.log
            12/6/2019 -- 13:13:44 - <Info> -- http-log output device (regular) initialized: http.log
            12/6/2019 -- 13:13:44 - <Info> -- tls-log output device (regular) initialized: tls.log
            12/6/2019 -- 13:13:44 - <Info> -- stats output device (regular) initialized: stats.log
            12/6/2019 -- 13:13:52 - <Info> -- 2 rule files processed. 8028 rules successfully loaded, 0 rules failed
            12/6/2019 -- 13:13:52 - <Info> -- Threshold config parsed: 0 rule(s) found
            12/6/2019 -- 13:13:52 - <Info> -- 8028 signatures processed. 429 are IP-only rules, 3450 are inspecting packet payload, 5213 inspect application layer, 0 are decoder event only
            12/6/2019 -- 13:13:52 - <Warning> -- [ERRCODE: SC_WARN_FLOWBIT(306)] - flowbit 'et.http.PK' is checked but not set. Checked in 2019835 and 1 other sigs
            12/6/2019 -- 13:14:20 - <Info> -- Using 1 live device(s).
            12/6/2019 -- 13:14:20 - <Info> -- using interface igb0
            12/6/2019 -- 13:14:20 - <Info> -- Running in 'auto' checksum mode. Detection of interface state will require 1000 packets.
            12/6/2019 -- 13:14:20 - <Info> -- Set snaplen to 1518 for 'igb0'
            12/6/2019 -- 13:14:20 - <Info> -- RunModeIdsPcapAutoFp initialised
            12/6/2019 -- 13:14:20 - <Notice> -- all 5 packet processing threads, 2 management threads initialized, engine started.
            12/6/2019 -- 13:14:21 - <Info> -- alert-pf -> Received notification of IP address change on interface igb1.
            12/6/2019 -- 13:14:21 - <Info> -- alert-pf -> deleted address 192.168.1.1 from automatic firewall interface IP Pass List.
            12/6/2019 -- 13:14:22 - <Info> -- alert-pf -> Received notification of IP address change on interface igb0.
            12/6/2019 -- 13:14:22 - <Info> -- alert-pf -> deleted address 68.20.12.27 from automatic firewall interface IP Pass List.
            12/6/2019 -- 13:14:26 - <Info> -- alert-pf -> Received notification of IP address change on interface igb1.
            12/6/2019 -- 13:14:26 - <Info> -- alert-pf -> added address 192.168.1.1 to automatic firewall interface IP Pass List.
            12/6/2019 -- 13:14:31 - <Warning> -- [ERRCODE: SC_WARN_UNCOMMON(230)] - alert-pf -> Firewall interface IP change notification thread received an invalid IP address via kernel routing message socket.
            12/6/2019 -- 13:14:32 - <Warning> -- [ERRCODE: SC_WARN_UNCOMMON(230)] - alert-pf -> Firewall interface IP change notification thread received an invalid IP address via kernel routing message socket.
            12/6/2019 -- 13:14:32 - <Info> -- alert-pf -> Received notification of IP address change on interface igb0.
            12/6/2019 -- 13:14:32 - <Error> -- [ERRCODE: SC_ERR_INVALID_ARGUMENT(13)] - Argument "tree" NULL
            12/6/2019 -- 13:14:32 - <Info> -- alert-pf -> added address 68.20.12.27 to automatic firewall interface IP Pass List.
            12/6/2019 -- 13:14:35 - <Info> -- alert-pf -> Received notification of IP address change on interface igb1.
            12/6/2019 -- 13:14:35 - <Info> -- alert-pf -> Received notification of IP address change on interface igb1.
            12/6/2019 -- 13:14:35 - <Error> -- [ERRCODE: SC_ERR_INVALID_ARGUMENT(13)] - Argument "tree" NULL
            12/6/2019 -- 13:14:35 - <Info> -- alert-pf -> added address 192.168.1.1 to automatic firewall interface IP Pass List.
            12/6/2019 -- 13:14:36 - <Info> -- No packets with invalid checksum, assuming checksum offloading is NOT used
            12/6/2019 -- 13:14:40 - <Info> -- alert-pf -> Received notification of IP address change on interface igb0.
            12/6/2019 -- 13:14:44 - <Warning> -- [ERRCODE: SC_WARN_UNCOMMON(230)] - alert-pf -> Firewall interface IP change notification thread received an invalid IP address via kernel routing message socket.
            12/6/2019 -- 13:14:45 - <Warning> -- [ERRCODE: SC_WARN_UNCOMMON(230)] - alert-pf -> Firewall interface IP change notification thread received an invalid IP address via kernel routing message socket.
            12/6/2019 -- 13:14:45 - <Info> -- alert-pf -> Received notification of IP address change on interface igb0.
            12/6/2019 -- 13:14:45 - <Error> -- [ERRCODE: SC_ERR_INVALID_ARGUMENT(13)] - Argument "tree" NULL
            12/6/2019 -- 13:14:45 - <Info> -- alert-pf -> added address 68.20.12.27 to automatic firewall interface IP Pass List.
            12/6/2019 -- 14:24:10 - <Notice> -- rule reload starting
            12/6/2019 -- 14:24:17 - <Info> -- 2 rule files processed. 8028 rules successfully loaded, 0 rules failed
            12/6/2019 -- 14:24:17 - <Info> -- Threshold config parsed: 0 rule(s) found
            12/6/2019 -- 14:24:17 - <Info> -- 8028 signatures processed. 429 are IP-only rules, 3450 are inspecting packet payload, 5213 inspect application layer, 0 are decoder event only
            12/6/2019 -- 14:24:17 - <Warning> -- [ERRCODE: SC_WARN_FLOWBIT(306)] - flowbit 'et.http.PK' is checked but not set. Checked in 2019835 and 1 other sigs
            12/6/2019 -- 14:24:25 - <Info> -- cleaning up signature grouping structure... complete
            12/6/2019 -- 14:24:25 - <Notice> -- rule reload complete

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

              @bose301s said in Suricata 4.1.4_2 not blocking hosts:

              Same Issue, I updated to the new release and changed nothing else and since doing so nothing is being added to black list even though I have Legacy Mode blocking enabled.

              12/6/2019 -- 13:13:44 - <Notice> -- This is Suricata version 4.1.4 RELEASE
              12/6/2019 -- 13:13:44 - <Info> -- CPUs/cores online: 4
              12/6/2019 -- 13:13:44 - <Info> -- HTTP memcap: 67108864
              12/6/2019 -- 13:13:44 - <Notice> -- using flow hash instead of active packets
              12/6/2019 -- 13:13:44 - <Info> -- alert-pf -> Creating automatic firewall interface IP address Pass List.
              12/6/2019 -- 13:13:44 - <Info> -- alert-pf -> adding firewall interface igb0 IPv6 address fe80:0000:0000:0000:02e0:67ff:fe13:c174 to automatic interface IP Pass List.
              12/6/2019 -- 13:13:44 - <Info> -- alert-pf -> adding firewall interface igb0 IPv4 address 68.20.12.27 to automatic interface IP Pass List.
              12/6/2019 -- 13:13:44 - <Info> -- alert-pf -> adding firewall interface igb0 IPv6 address 2600:1700:0bab:6d00:02e0:67ff:fe13:c174 to automatic interface IP Pass List.
              12/6/2019 -- 13:13:44 - <Info> -- alert-pf -> adding firewall interface igb0 IPv6 address 2600:1700:0bab:6d00:0000:0000:0000:0044 to automatic interface IP Pass List.
              12/6/2019 -- 13:13:44 - <Info> -- alert-pf -> adding firewall interface igb1 IPv4 address 192.168.1.1 to automatic interface IP Pass List.
              12/6/2019 -- 13:13:44 - <Info> -- alert-pf -> adding firewall interface igb1 IPv6 address 2600:1700:0bab:6d0f:02e0:67ff:fe13:c175 to automatic interface IP Pass List.
              12/6/2019 -- 13:13:44 - <Info> -- alert-pf -> adding firewall interface igb1 IPv6 address fe80:0000:0000:0000:0000:0000:0001:0001 to automatic interface IP Pass List.
              12/6/2019 -- 13:13:44 - <Info> -- alert-pf -> adding firewall interface lo0 IPv6 address 0000:0000:0000:0000:0000:0000:0000:0001 to automatic interface IP Pass List.
              12/6/2019 -- 13:13:44 - <Info> -- alert-pf -> adding firewall interface lo0 IPv6 address fe80:0000:0000:0000:0000:0000:0000:0001 to automatic interface IP Pass List.
              12/6/2019 -- 13:13:44 - <Info> -- alert-pf -> adding firewall interface lo0 IPv4 address 127.0.0.1 to automatic interface IP Pass List.
              12/6/2019 -- 13:13:44 - <Info> -- alert-pf output device (regular) initialized: block.log
              12/6/2019 -- 13:13:44 - <Info> -- alert-pf -> Pass List /usr/local/etc/suricata/suricata_63062_igb0/passlist parsed: 14 IP addresses loaded.
              12/6/2019 -- 13:13:44 - <Info> -- alert-pf -> Created firewall interface IP change monitor thread for auto-whitelisting of firewall interface IP addresses.
              12/6/2019 -- 13:13:44 - <Info> -- alert-pf output initialized, pf-table=snort2c block-ip=both kill-state=on block-drops-only=off
              12/6/2019 -- 13:13:44 - <Info> -- alert-pf -> Firewall interface IP address change notification monitoring thread started.
              12/6/2019 -- 13:13:44 - <Info> -- fast output device (regular) initialized: alerts.log
              12/6/2019 -- 13:13:44 - <Info> -- http-log output device (regular) initialized: http.log
              12/6/2019 -- 13:13:44 - <Info> -- tls-log output device (regular) initialized: tls.log
              12/6/2019 -- 13:13:44 - <Info> -- stats output device (regular) initialized: stats.log
              12/6/2019 -- 13:13:52 - <Info> -- 2 rule files processed. 8028 rules successfully loaded, 0 rules failed
              12/6/2019 -- 13:13:52 - <Info> -- Threshold config parsed: 0 rule(s) found
              12/6/2019 -- 13:13:52 - <Info> -- 8028 signatures processed. 429 are IP-only rules, 3450 are inspecting packet payload, 5213 inspect application layer, 0 are decoder event only
              12/6/2019 -- 13:13:52 - <Warning> -- [ERRCODE: SC_WARN_FLOWBIT(306)] - flowbit 'et.http.PK' is checked but not set. Checked in 2019835 and 1 other sigs
              12/6/2019 -- 13:14:20 - <Info> -- Using 1 live device(s).
              12/6/2019 -- 13:14:20 - <Info> -- using interface igb0
              12/6/2019 -- 13:14:20 - <Info> -- Running in 'auto' checksum mode. Detection of interface state will require 1000 packets.
              12/6/2019 -- 13:14:20 - <Info> -- Set snaplen to 1518 for 'igb0'
              12/6/2019 -- 13:14:20 - <Info> -- RunModeIdsPcapAutoFp initialised
              12/6/2019 -- 13:14:20 - <Notice> -- all 5 packet processing threads, 2 management threads initialized, engine started.
              12/6/2019 -- 13:14:21 - <Info> -- alert-pf -> Received notification of IP address change on interface igb1.
              12/6/2019 -- 13:14:21 - <Info> -- alert-pf -> deleted address 192.168.1.1 from automatic firewall interface IP Pass List.
              12/6/2019 -- 13:14:22 - <Info> -- alert-pf -> Received notification of IP address change on interface igb0.
              12/6/2019 -- 13:14:22 - <Info> -- alert-pf -> deleted address 68.20.12.27 from automatic firewall interface IP Pass List.
              12/6/2019 -- 13:14:26 - <Info> -- alert-pf -> Received notification of IP address change on interface igb1.
              12/6/2019 -- 13:14:26 - <Info> -- alert-pf -> added address 192.168.1.1 to automatic firewall interface IP Pass List.
              12/6/2019 -- 13:14:31 - <Warning> -- [ERRCODE: SC_WARN_UNCOMMON(230)] - alert-pf -> Firewall interface IP change notification thread received an invalid IP address via kernel routing message socket.
              12/6/2019 -- 13:14:32 - <Warning> -- [ERRCODE: SC_WARN_UNCOMMON(230)] - alert-pf -> Firewall interface IP change notification thread received an invalid IP address via kernel routing message socket.
              12/6/2019 -- 13:14:32 - <Info> -- alert-pf -> Received notification of IP address change on interface igb0.
              12/6/2019 -- 13:14:32 - <Error> -- [ERRCODE: SC_ERR_INVALID_ARGUMENT(13)] - Argument "tree" NULL
              12/6/2019 -- 13:14:32 - <Info> -- alert-pf -> added address 68.20.12.27 to automatic firewall interface IP Pass List.
              12/6/2019 -- 13:14:35 - <Info> -- alert-pf -> Received notification of IP address change on interface igb1.
              12/6/2019 -- 13:14:35 - <Info> -- alert-pf -> Received notification of IP address change on interface igb1.
              12/6/2019 -- 13:14:35 - <Error> -- [ERRCODE: SC_ERR_INVALID_ARGUMENT(13)] - Argument "tree" NULL
              12/6/2019 -- 13:14:35 - <Info> -- alert-pf -> added address 192.168.1.1 to automatic firewall interface IP Pass List.
              12/6/2019 -- 13:14:36 - <Info> -- No packets with invalid checksum, assuming checksum offloading is NOT used
              12/6/2019 -- 13:14:40 - <Info> -- alert-pf -> Received notification of IP address change on interface igb0.
              12/6/2019 -- 13:14:44 - <Warning> -- [ERRCODE: SC_WARN_UNCOMMON(230)] - alert-pf -> Firewall interface IP change notification thread received an invalid IP address via kernel routing message socket.
              12/6/2019 -- 13:14:45 - <Warning> -- [ERRCODE: SC_WARN_UNCOMMON(230)] - alert-pf -> Firewall interface IP change notification thread received an invalid IP address via kernel routing message socket.
              12/6/2019 -- 13:14:45 - <Info> -- alert-pf -> Received notification of IP address change on interface igb0.
              12/6/2019 -- 13:14:45 - <Error> -- [ERRCODE: SC_ERR_INVALID_ARGUMENT(13)] - Argument "tree" NULL
              12/6/2019 -- 13:14:45 - <Info> -- alert-pf -> added address 68.20.12.27 to automatic firewall interface IP Pass List.
              12/6/2019 -- 14:24:10 - <Notice> -- rule reload starting
              12/6/2019 -- 14:24:17 - <Info> -- 2 rule files processed. 8028 rules successfully loaded, 0 rules failed
              12/6/2019 -- 14:24:17 - <Info> -- Threshold config parsed: 0 rule(s) found
              12/6/2019 -- 14:24:17 - <Info> -- 8028 signatures processed. 429 are IP-only rules, 3450 are inspecting packet payload, 5213 inspect application layer, 0 are decoder event only
              12/6/2019 -- 14:24:17 - <Warning> -- [ERRCODE: SC_WARN_FLOWBIT(306)] - flowbit 'et.http.PK' is checked but not set. Checked in 2019835 and 1 other sigs
              12/6/2019 -- 14:24:25 - <Info> -- cleaning up signature grouping structure... complete
              12/6/2019 -- 14:24:25 - <Notice> -- rule reload complete

              Just to be clear, are you seeing alerts on the ALERTS tab that correspond with IP addresses that should be blocked? I need to be sure you are getting the proper alerts first. I tried to reproduce this behavior for the previous poster but was unable to do so. He wiped and reloaded pfSense and his error went away (according to his last post).

              B 2 Replies Last reply Reply Quote 0
              • B
                bose301s @bmeeks
                last edited by

                This post is deleted!
                1 Reply Last reply Reply Quote 0
                • B
                  bose301s @bmeeks
                  last edited by

                  @bmeeks Here is my Alert list which I would think should cause at least one block:

                  ccb252e5-a905-4a86-8748-b53a90cb519e-image.png

                  Here is my Block list with no blocks:

                  df0843fd-8ea6-4bc9-ada3-866b6390d1dd-image.png

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

                    @bose301s: and one last question, is the "Which IP to Block" setting on the INTERFACE SETTINGS tab set to BOTH, or DST or SRC? BOTH is the default.

                    Edit: Oh, and you do not have Block on Drops only set do you? If so, have you changed your rule actions to DROP from their default of ALERT?

                    Just checking all the obvious things first.

                    B 1 Reply Last reply Reply Quote 0
                    • B
                      bose301s @bmeeks
                      last edited by bose301s

                      @bmeeks said in Suricata 4.1.4_2 not blocking hosts:

                      @bose301s: and one last question, is the "Which IP to Block" setting on the INTERFACE SETTINGS tab set to BOTH, or DST or SRC? BOTH is the default.

                      Edit: Oh, and you do not have Block on Drops only set do you? If so, have you changed your rule actions to DROP from their default of ALERT?

                      Just checking all the obvious things first.

                      The which IP to block is set to BOTH and I did not change it to Block on Drops.

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

                        @bose301s:
                        Okay. I will look into this again. It very well may be related to a bug fix I did to correct a problem with Suricata failing to start on interfaces with a /31 subnet mask.

                        So that I can test with the exact same IP configuration, will you PM me the IP address and subnet mask for your WAN link? If it is what I suspect, then certain types of IP subnets may trigger the problem, and using yours can help me locate it. You can do that using the Chat icon at the top right corner of this page.

                        B 1 Reply Last reply Reply Quote 0
                        • R
                          ryan_g
                          last edited by

                          I am having the identical problem with 4.1.4_3 after updating. I have not tried rebuilding the entire router but wiping Suricata and reinstalling/re-configuring has not made a difference. Alerts are showing properly, just no blocks. I will message my IP if that helps.

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

                            @bmeeks said in Suricata 4.1.4_2 not blocking hosts:

                            @bose301s:
                            Okay. I will look into this again. It very well may be related to a bug fix I did to correct a problem with Suricata failing to start on interfaces with a /31 subnet mask.

                            So that I can test with the exact same IP configuration, will you PM me the IP address and subnet mask for your WAN link? If it is what I suspect, then certain types of IP subnets may trigger the problem, and using yours can help me locate it. You can do that using the Chat icon at the top right corner of this page.

                            I am really new to pfSense, do you need my public IP and the Subnet?

                            bmeeksB 1 Reply Last reply Reply Quote 0
                            • J
                              jchud
                              last edited by

                              I recently upgrade to 4.1.4_3 and am having the same issue where it is alerting but not blocking. And when I tried rebooting my pfsense box this morning it failed to properly come back up, displaying a ton of errors to the console. Just got done rebuilding me entire pfsense box and still having the same issue.

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

                                @ryan_g : I received your info. Thanks. Will look into this problem. I am pretty sure I introduced it by fixing another issue reported on Redmine with /31 point-to-point subnets.

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

                                  @jchud said in Suricata 4.1.4_2 not blocking hosts:

                                  I recently upgrade to 4.1.4_3 and am having the same issue where it is alerting but not blocking. And when I tried rebooting my pfsense box this morning it failed to properly come back up, displaying a ton of errors to the console. Just got done rebuilding me entire pfsense box and still having the same issue.

                                  I suspect this is a common problem, and likely one I inadvertenly introduced while fixing another reported bug. I will get this one fixed.

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

                                    @bose301s said in Suricata 4.1.4_2 not blocking hosts:

                                    @bmeeks said in Suricata 4.1.4_2 not blocking hosts:

                                    @bose301s:
                                    Okay. I will look into this again. It very well may be related to a bug fix I did to correct a problem with Suricata failing to start on interfaces with a /31 subnet mask.

                                    So that I can test with the exact same IP configuration, will you PM me the IP address and subnet mask for your WAN link? If it is what I suspect, then certain types of IP subnets may trigger the problem, and using yours can help me locate it. You can do that using the Chat icon at the top right corner of this page.

                                    I am really new to pfSense, do you need my public IP and the Subnet?

                                    See my PM reply to you. Was away for a while and replied to your post after it was 5 hours old.

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

                                      To anyone else experiencing this issue of the latest Suricata package not blocking hosts when Legacy Mode blocking is enabled, I am aware and looking into the fix. Pretty sure this is a side effect from fixing another different bug. The issue is within the custom blocking plugin I wrote for Suricata, so I will have to patch and then submit an updated Suricata binary to correct the problem.

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

                                        The fix for this bug is posted for the pfSense team to review and merge. I've asked them to expedite this one, so keep checking for a new Suricata package to show up in PACKAGE MANAGER either later today or early tomorrow.

                                        The pull request for the fix is here: https://github.com/pfsense/FreeBSD-ports/pull/652.

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

                                          Just got the update installed, so thanks for fixing things. I do want to mention though that just like when I rebuilt everything from scratch it did not automatically start on my WAN interface but did on my LAN and when I go look up the rules it tells me the app-layer-event.rules can not be found or something. On the bright side at least its blocking again.

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

                                            @jchud said in Suricata 4.1.4_2 not blocking hosts:

                                            Just got the update installed, so thanks for fixing things. I do want to mention though that just like when I rebuilt everything from scratch it did not automatically start on my WAN interface but did on my LAN and when I go look up the rules it tells me the app-layer-event.rules can not be found or something. On the bright side at least its blocking again.

                                            There is a fix for that in the update, but unfortunately you don't get the fixed file in effect until after you install the update. By that point the old file has already messed up your install. You can fix your problem by doing what I just wrote in the Release Notes here. Delete the Suricata package and then install it again. That will restore the missing app-layer-events.rules and other events rules files.

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