Navigation

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

    Suricata 4.1.4_2 not blocking hosts

    IDS/IPS
    7
    49
    852
    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.
    • S
      StephenAmazen last edited by StephenAmazen

      Hi,

      Just upgraded to the latest version and Suricata stopped blocking hosts. I reinstalled pfsense and Suricata to no avail. I'm new and not a power user, so I'm not sure what I did wrong, and I don't know what the error messages mean. If anyone can help fix this issue and the error messages, that would great! Here is my log. Thanks.

      8/6/2019 -- 13:42:35 - <Info> -- 2 rule files processed. 10981 rules successfully loaded, 18 rules failed
      8/6/2019 -- 13:42:35 - <Info> -- Threshold config parsed: 0 rule(s) found
      8/6/2019 -- 13:42:35 - <Info> -- 10982 signatures processed. 385 are IP-only rules, 4076 are inspecting packet payload, 7599 inspect application layer, 103 are decoder event only
      8/6/2019 -- 13:42:35 - <Warning> -- [ERRCODE: SC_WARN_FLOWBIT(306)] - flowbit 'OLE.CompoundFile' is checked but not set. Checked in 2016395 and 0 other sigs
      8/6/2019 -- 13:42:43 - <Info> -- alert-pf -> Received notification of IP address change on interface em1.
      8/6/2019 -- 13:42:43 - <Info> -- alert-pf -> deleted address 192.168.1.1 from automatic firewall interface IP Pass List.
      8/6/2019 -- 13:42:43 - <Info> -- Using 1 live device(s).
      8/6/2019 -- 13:42:43 - <Info> -- using interface em0
      8/6/2019 -- 13:42:43 - <Info> -- Running in 'auto' checksum mode. Detection of interface state will require 1000 packets.
      8/6/2019 -- 13:42:43 - <Info> -- Set snaplen to 1518 for 'em0'
      8/6/2019 -- 13:42:43 - <Info> -- RunModeIdsPcapAutoFp initialised
      8/6/2019 -- 13:42:43 - <Notice> -- all 5 packet processing threads, 2 management threads initialized, engine started.
      8/6/2019 -- 13:42:45 - <Info> -- alert-pf -> Received notification of IP address change on interface em0.
      8/6/2019 -- 13:42:45 - <Info> -- alert-pf -> deleted address 76.xxx.xxx.xxx from automatic firewall interface IP Pass List.
      8/6/2019 -- 13:42:46 - <Info> -- alert-pf -> Received notification of IP address change on interface em1.
      8/6/2019 -- 13:42:46 - <Info> -- alert-pf -> added address 192.168.1.1 to automatic firewall interface IP Pass List.
      8/6/2019 -- 13:42:52 - <Warning> -- [ERRCODE: SC_WARN_UNCOMMON(230)] - alert-pf -> Firewall interface IP change notification thread received an invalid IP address via kernel routing message socket.
      8/6/2019 -- 13:42:53 - <Warning> -- [ERRCODE: SC_WARN_UNCOMMON(230)] - alert-pf -> Firewall interface IP change notification thread received an invalid IP address via kernel routing message socket.
      8/6/2019 -- 13:42:53 - <Info> -- alert-pf -> Received notification of IP address change on interface em0.
      8/6/2019 -- 13:42:53 - <Error> -- [ERRCODE: SC_ERR_INVALID_ARGUMENT(13)] - Argument "tree" NULL
      8/6/2019 -- 13:42:53 - <Info> -- alert-pf -> added address 76.xxx.xxx.xxx to automatic firewall interface IP Pass List.
      8/6/2019 -- 13:42:53 - <Info> -- No packets with invalid checksum, assuming checksum offloading is NOT used
      8/6/2019 -- 13:42:57 - <Info> -- alert-pf -> Received notification of IP address change on interface em1.
      8/6/2019 -- 13:42:57 - <Info> -- alert-pf -> Received notification of IP address change on interface em1.
      8/6/2019 -- 13:42:57 - <Error> -- [ERRCODE: SC_ERR_INVALID_ARGUMENT(13)] - Argument "tree" NULL
      8/6/2019 -- 13:42:57 - <Info> -- alert-pf -> added address 192.168.1.1 to automatic firewall interface IP Pass List.
      8/6/2019 -- 13:43:02 - <Info> -- alert-pf -> Received notification of IP address change on interface em0.
      8/6/2019 -- 13:43:07 - <Warning> -- [ERRCODE: SC_WARN_UNCOMMON(230)] - alert-pf -> Firewall interface IP change notification thread received an invalid IP address via kernel routing message socket.
      8/6/2019 -- 13:43:07 - <Warning> -- [ERRCODE: SC_WARN_UNCOMMON(230)] - alert-pf -> Firewall interface IP change notification thread received an invalid IP address via kernel routing message socket.
      8/6/2019 -- 13:43:07 - <Info> -- alert-pf -> Received notification of IP address change on interface em0.
      8/6/2019 -- 13:43:07 - <Error> -- [ERRCODE: SC_ERR_INVALID_ARGUMENT(13)] - Argument "tree" NULL
      8/6/2019 -- 13:43:07 - <Info> -- alert-pf -> added address 76.xxx.xxx.xxx to automatic firewall interface IP Pass List.

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

        @StephenAmazen said in Suricata 4.1.4_2 not blocking hosts:

        8/6/2019 -- 13:42:52 - <Warning> -- [ERRCODE: SC_WARN_UNCOMMON(230)] - alert-pf -> Firewall interface IP change notification thread received an invalid IP address via kernel routing message socket.
        8/6/2019 -- 13:42:53 - <Warning> -- [ERRCODE: SC_WARN_UNCOMMON(230)] - alert-pf -> Firewall interface IP change notification thread received an invalid IP address via kernel routing message socket.

        These warning messages are most unusual. Something is strange with one of your interfaces in pfSense. The kernel routing messages are subscribed to by the Suricata blocking module to keep track of firewall interface IP addresses. Something is strange on your firewall. I have never seen that message returned before by Suricata.

        1 Reply Last reply Reply Quote 0
        • bmeeks
          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!

            bmeeks 1 Reply Last reply Reply Quote 0
            • bmeeks
              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

                bmeeks 1 Reply Last reply Reply Quote 1
                • bmeeks
                  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

                      bmeeks 1 Reply Last reply Reply Quote 1
                      • bmeeks
                        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.

                          bmeeks 1 Reply Last reply Reply Quote 0
                          • bmeeks
                            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.

                              bmeeks 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?

                                bmeeks 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.

                                  bmeeks 1 Reply Last reply Reply Quote 1
                                  • bmeeks
                                    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
                                    • bmeeks
                                      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
                                      • bmeeks
                                        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
                                        • bmeeks
                                          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
                                          • bmeeks
                                            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.

                                              bmeeks 1 Reply Last reply Reply Quote 0
                                              • bmeeks
                                                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
                                                • J
                                                  jchud @bmeeks last edited by

                                                  @bmeeks Alright did an uninstall followed by a reinstall and it got rid of the app-layer-event.rule thing. The only thing that it still did was not autostart on my WAN interface like it did on my LAN, any idea how to correct that?

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

                                                    @jchud said in Suricata 4.1.4_2 not blocking hosts:

                                                    @bmeeks Alright did an uninstall followed by a reinstall and it got rid of the app-layer-event.rule thing. The only thing that it still did was not autostart on my WAN interface like it did on my LAN, any idea how to correct that?

                                                    There should be a message in the suricata.log file for the interface. It can also take Suricata a little time to start on an interface if you have lots of rules enabled. That little icon on the INTERFACES tab will show a spinning gear if Suricata is still starting for an interface. If you see just the red X (for stopped), then check the log file to see what's up. And just one more thing: don't use the Service Watchdog package with Suricata or Snort. You haven't said you are, but I just mention it because several folks have done that and it leads to issues.

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

                                                      @bmeeks Well unfortunately I do not have a copy of the log prior to me starting it manually, but I will check next I reboot or something. Though speaking about that log I did notice that while it is blocking I still get a few entries (like when it wasn't) saying "<Warning> -- [ERRCODE: SC_WARN_UNCOMMON(230)] - alert-pf -> Firewall interface IP change notification thread received an invalid IP address via kernel routing message socket.", "<Error> -- [ERRCODE: SC_ERR_INVALID_ARGUMENT(13)] - Argument "tree" NULL", and some about IP address on the interface being changed. Also as far as I know I am not using the Service Watchdog package.

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

                                                        @jchud said in Suricata 4.1.4_2 not blocking hosts:

                                                        @bmeeks Well unfortunately I do not have a copy of the log prior to me starting it manually, but I will check next I reboot or something. Though speaking about that log I did notice that while it is blocking I still get a few entries (like when it wasn't) saying "<Warning> -- [ERRCODE: SC_WARN_UNCOMMON(230)] - alert-pf -> Firewall interface IP change notification thread received an invalid IP address via kernel routing message socket.", "<Error> -- [ERRCODE: SC_ERR_INVALID_ARGUMENT(13)] - Argument "tree" NULL", and some about IP address on the interface being changed. Also as far as I know I am not using the Service Watchdog package.

                                                        Are you sure you got the updated binary? Those errors were the old bug manifesting itself. That can't happen in the fixed binary. Did you delete the Suricata package entirely and then install it again? If not, do it this way ---

                                                        1. Go to the PACKAGE MANAGER tab, and on the Installed Packages tab click the trash icon beside the Suricata package to remove it from the firewall. It will take serveral seconds to uninstall. Let it finished and DO NOT leave the page until you get a green status bar saying removal succeeded.

                                                        2. Click the Available Packages tab, locate Suricata in the list, and install it again. Pay careful attention to the dependency packages listed underneath the Suricata entry. You should a line that says suricata-4.1.4_2. If you see suricata-4.1.4_1 or older, then the new binary is not yet posted. This might be the case if you have a Netgate appliance as firmware and package updates for those may be delayed a day or so.

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

                                                          @bmeeks At first I just did an in place upgrade, then I did a uninstall and reinstall to get rid of that app-layer-event.rule thing. As things stand right now it says I have version 4.1.4_4 installed and it lists 4.1.4_2 as a dependency. I am happy to do another uninstall/reinstall if you think it will make a difference?

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

                                                            @jchud said in Suricata 4.1.4_2 not blocking hosts:

                                                            @bmeeks At first I just did an in place upgrade, then I did a uninstall and reinstall to get rid of that app-layer-event.rule thing. As things stand right now it says I have version 4.1.4_4 installed and it lists 4.1.4_2 as a dependency. I am happy to do another uninstall/reinstall if you think it will make a difference?

                                                            You should not be getting those error messages in your suricata.log, especially the one about "Argument 'tree' NULL". Are you sure those are in the current log? Stop and restart Suricata again and see if the message reappears.

                                                            If they do, then open a CLI session on the firewall and run this command at a shell prompt:

                                                            suricata -V

                                                            That will print the current Suricata binary version. See what it says.

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

                                                              @bmeeks The only thing I noted when I stopped the service from the homepage is that it still showed as if it were running even though it had stopped on both the interface. When I restarted the service again the WAN didn't automatically start but the LAN did. And the log for the when did not contain any of those errors after the I started it back up again. Lastly when running the command you mention it tells me I am running version 4.1.4.

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

                                                                @jchud: the "still running" indication would be a symptom of a zombie process or a crashed process where the PID file did not get cleaned up. The GUI senses the presence of the PID file with a valid process ID within it to determine what icon to show for Suricatat status.

                                                                It sounds much better that you no longer are seeing those errors in the suricata.log file.

                                                                In the future, when upgrading the package, it is always safer to first delete it and then install it again instead of just clicking the "Reinstall" icon. The way PHP and the pkg utility work on the system can lead to a mixup of new and old files if you just do the reinstall option. While reinstall will work for some simple updates, other updates need to change files that are sometimes cached and held open by the system during a reinstall. That can prevent some migration actions for the new version from happening.

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

                                                                  @bmeeks I killed the zombie process and got everything to start back up again normally. In the suricata.log I still get the change of IP address thing along with the [ERRCODE: SC_WARN_UNCOMMON(230)], which I am guessing has something to do with the fact that when this is restarted on the WAN side "/rc.newwanip" starts doing some stuff like claiming the IP has changed even though its exactly the same as it was before.

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

                                                                    @jchud said in Suricata 4.1.4_2 not blocking hosts:

                                                                    @bmeeks I killed the zombie process and got everything to start back up again normally. In the suricata.log I still get the change of IP address thing along with the [ERRCODE: SC_WARN_UNCOMMON(230)], which I am guessing has something to do with the fact that when this is restarted on the WAN side "/rc.newwanip" starts doing some stuff like claiming the IP has changed even though its exactly the same as it was before.

                                                                    No, that SC_WARN_UNCOMMON error is definitely not supposed to be there. What kind of interface is your WAN? Is it configured for DHCP or is it a PPPoE connection?

                                                                    It really sounds like your binary is not the patched one. Look at the file date and time for this file:

                                                                    /usr/local/bin/suricata

                                                                    and let me know what it says. Giving the me size in bytes will help as well. The latest file should show a date of June 13, 2019 and have a file size of 4,340,864 bytes.

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

                                                                      @bmeeks Yes my WAN is configure for DHCP and the date/time for that file is June 13 17:49 and the size in bytes is 4499944.

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

                                                                        @jchud said in Suricata 4.1.4_2 not blocking hosts:

                                                                        @bmeeks Yes my WAN is configure for DHCP and the date/time for that file is June 13 17:49 and the size in bytes is 4499944.

                                                                        I'm working the same issue with another user in a different thread, and he is reporting the same file size. That is certainly different from what is on my machine. Is your hardware an Intel-base AMD64 CPU, or is it an ARM-based Netgate appliance? Trying to figure out why the binary is different.

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

                                                                          @bmeeks Intel based, built the computer its running on myself

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

                                                                            @jchud : Good, that means we are on the same CPU. My virtual machine box that works is running on VMware Workstation on a Windows host with an Intel i7 CPU.

                                                                            Let's compare MD5 hashes to see if your binary is the same as mine. Run this command from a shell prompt on the firewall:

                                                                            md5 -q /usr/local/bin/suricata

                                                                            The output should be:

                                                                            cc5200e8369def9268b9e30c0c3f41c6

                                                                            Let me know what you get.

                                                                            1 Reply Last reply Reply Quote 0
                                                                            • W
                                                                              wangel last edited by wangel

                                                                              @bmeeks

                                                                              I just found this thread from a google search. I'm having the exact same issue.

                                                                              It started yesterday, I noticed Suricata would run, and then just crash. I could restart it and it would work fine for a few hours, crash again.

                                                                              I am getting the same error messages; [ERRCODE: SC_ERR_INVALID_ARGUMENT(13)] - Argument "tree" NULL

                                                                              Last night, I found the thread with you talking about the bug. I uninstalled and reinstalled suricata, and it ran all night and most of today w/ no issues, but it just crashed again.

                                                                              So, again, I uninstalled Suricata ... waited for it to finish. Made sure it was gone, and then reinstalled it. Once I started Suricata, the error messages showed up again. Here's the output from what you where asking @jchud about.

                                                                              Also, I hadn't noticed, but yes, it is not blocking hosts now either. It will Alert.

                                                                              [2.4.4-RELEASE][admin@fw.alteredreality.cc]/root: suricata -V
This is Suricata version 4.1.4 RELEASE
[2.4.4-RELEASE][admin@fw.alteredreality.cc]/root: ls -l /usr/local/bin/suricata
-rwxr-xr-x  1 root  wheel  4499944 Jun 13 17:49 /usr/local/bin/suricata
[2.4.4-RELEASE][admin@fw.alteredreality.cc]/root: md5 -q /usr/local/bin/suricata
c962d5d995867c5baf3136035a34fac7
[2.4.4-RELEASE][admin@fw.alteredreality.cc]/root:

                                                                              Thanks

                                                                              1 Reply Last reply Reply Quote 0
                                                                              • kiokoman
                                                                                kiokoman LAYER 8 last edited by

                                                                                when exactly have you reinstalled it? in the last 30 min ? because the new update with the right crc appeared on my pf sense 2.5 only 30 min ago max 1 hour ago

                                                                                ̿' ̿'\̵͇̿̿\з=(◕_◕)=ε/̵͇̿̿/'̿'̿ ̿
                                                                                Please do not use chat/PM to ask for help
                                                                                we must focus on silencing this @guest character. we must make up lies and alter the copyrights !
                                                                                Don't forget to Upvote with the 👍 button for any post you find to be helpful.

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

                                                                                  Make sure you have the correct MD5 hash showing for your Suricata binary as per my post above. Apparently something went south with the posting of the updated package and the binary got a new timestamp but did not actually get updated with my bug fix. I think that is the root of all these issues.

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

                                                                                    @bmeeks said in Suricata 4.1.4_2 not blocking hosts:

                                                                                    md5 -q /usr/local/bin/suricata

                                                                                    My alerts and blocks have starting working again. The result of that command gets me - c962d5d995867c5baf3136035a34fac7

                                                                                    bmeeks 1 Reply Last reply Reply Quote 0
                                                                                    • First post
                                                                                      Last post

                                                                                    Products

                                                                                    • Platform Overview
                                                                                    • TNSR
                                                                                    • pfSense
                                                                                    • Appliances

                                                                                    Services

                                                                                    • Training
                                                                                    • Professional Services

                                                                                    Support

                                                                                    • Subscription Plans
                                                                                    • Contact Support
                                                                                    • Product Lifecycle
                                                                                    • Documentation

                                                                                    News

                                                                                    • Media Coverage
                                                                                    • Press
                                                                                    • Events

                                                                                    Resources

                                                                                    • Blog
                                                                                    • FAQ
                                                                                    • Find a Partner
                                                                                    • Resource Library
                                                                                    • Security Information

                                                                                    Company

                                                                                    • About Us
                                                                                    • Careers
                                                                                    • Partners
                                                                                    • Contact Us
                                                                                    • Legal
                                                                                    Our Mission

                                                                                    We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

                                                                                    Subscribe to our Newsletter

                                                                                    Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

                                                                                    © 2021 Rubicon Communications, LLC | Privacy Policy