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

    Suricata custom rule alerts but won't block

    Scheduled Pinned Locked Moved Firewalling
    71 Posts 3 Posters 12.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.
    • kiokomanK
      kiokoman LAYER 8
      last edited by kiokoman

      you can check your passlist from console, i don't know where in the gui is this options but anyway it's inside
      /usr/local/etc/suricata/suricata_PIDOFSURICATA_INTERFACE/passlist
      just noticed now that i have ip like 8.8.8.8 inside it that i don't remember i ever put ..
      edit .. ok could be that one time was a DNS configured for pfsense but it was removed long time 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.

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

        @RedDelPaPa said in Suricata custom rule alerts but won't block:

        Here's an example of a rule that both alerts and blocks the offending remote IP:
        alert tcp $EXTERNAL_NET any -> any 25 (msg:"SMTP AUTH LOGON brute force attempt"; content:"AUTH LOGIN"; nocase; threshold:type threshold, track by_src, count 3, seconds 60; classtype:suspicious-login; sid:1000002; rev:1;)

        Your rule above that alerts and blocks is basically proving my point about a Pass List. Suricata (and Snort) generates a default Pass List that includes all of the IP subnets defined on the firewall interfaces with the exception of the WAN. For the WAN, the default Pass List only includes the actual WAN IP address. The default Pass List also includes your DNS Server(s), your default gateway and any defined Virtual IPs. You can see the contents of the default Pass List by going to the INTERFACE SETTTINGS tab for the interface you are running Suricata on and then scrolling down to click the View List button beside the Pass List drop-down selector. The content (IP addresses and subnet) of the default Pass List will display in a modal dialog.

        Your SMTP server will most definitely be defined in that default Pass List (by the inclusion of the firewall locally-attached network where it resides). So that presence on the Pass List will prevent the the mail server from being blocked. Also, depending on exactly how the remote client's traffic comes back to the firewall (over a VPN, for example), it might also wind up being included on a Pass List as VPN addresses are also added to the default Pass List.

        RedDelPaPaR 2 Replies Last reply Reply Quote 0
        • bmeeksB
          bmeeks @kiokoman
          last edited by

          @kiokoman said in Suricata custom rule alerts but won't block:

          you can check your passlist from console, i don't know where in the gui is this options but anyway it's inside
          /usr/local/etc/suricata/suricata_PIDOFSURICATA_INTERFACE/passlist
          just noticed now that i have ip like 8.8.8.8 inside it that i don't remember i ever put ..
          edit .. ok could be that one time was a DNS configured for pfsense but it was removed long time ago..

          The passlist file is only updated when Suricata is stopped and restarted or when a ccnfiguration change is made in the Suricata GUI and saved. If you were to edit the DNS servers listed under the SETUP > GENERAL screen in pfSense, but then did nothing to Suricata's configuration, then your DNS server change would not be reflected until you restarted Suricata.

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

            @bmeeks Yes I thought of that one already. I disabled his vpn connection to me before testing. And his public IP is definitely not on any pass lists.

            I'm confused as to why the last rule I posted works, but the first one I posted does not.

            If the last rule works, then clearly his public IP is not on a pass list?

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

              @bmeeks just followed your directions and checked the suricata default pass list. His public IP is not on it.

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

                @RedDelPaPa said in Suricata custom rule alerts but won't block:

                @bmeeks Yes I thought of that one already. I disabled his vpn connection to me before testing. And his public IP is definitely not on any pass lists.

                I'm confused as to why the last rule I posted works, but the first one I posted does not.

                If the last rule works, then clearly his public IP is not on a pass list?

                Are you sure that previous rule you posted is actually firing properly? For example, I would not expect your mail server to be responding on port 25 necessarily. The client should have initiated the TCP connection by having port 25 as the destination but having a random high port in the message for the SMTP server to reply back on. But to be honest I've never done a packet analysis is an email server's conversations with a client.

                RedDelPaPaR 2 Replies Last reply Reply Quote 0
                • RedDelPaPaR
                  RedDelPaPa @bmeeks
                  last edited by

                  @bmeeks yes that last one i posted works on LOGIN AUTH being sent from the client to the server.

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

                    @RedDelPaPa said in Suricata custom rule alerts but won't block:

                    @bmeeks yes that last one i posted works on LOGIN AUTH being sent from the client to the server.

                    I'm talking about the original rule you posted in your first message. This one:

                    alert tcp $SMTP_SERVERS 25 -> $EXTERNAL_NET any (msg:"Custom SMTP AUTH LOGON brute force attempt"; flow:from_server,established; content:"Authentication failed"; offset:54; nocase; threshold:type threshold, track by_dst, count 3, seconds 60; classtype:suspicious-login; sid:1000001; rev:3;)
                    

                    Have you tried the rule above with "any" for the source port instead of "25"?

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

                      @bmeeks 13ca073b-7d24-4b16-a6cb-c4d8dfaa2df6-image.png

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

                        @RedDelPaPa said in Suricata custom rule alerts but won't block:

                        @bmeeks 13ca073b-7d24-4b16-a6cb-c4d8dfaa2df6-image.png

                        There is no context to the rule in this image. Is this your custom rule? If so, it is not matching what you originally posted at the start of this thread.

                        If the rule above is meant to be what I just suggested a few seconds ago, I meant chaning the port to "any" not the IP address. So like this:

                        alert tcp $SMTP_SERVERS any -> $EXTERNAL_NET any (msg:"Custom SMTP AUTH LOGON brute force attempt"; flow:from_server,established; content:"Authentication failed"; offset:54; nocase; threshold:type threshold, track by_dst, count 3, seconds 60; classtype:suspicious-login; sid:1000001; rev:3;)
                        

                        And one other point, unless you have specifically populated the SMTP_SERVERS variable on the VARIABLES tab, it will default to $HOME_NET which will be the entirety of all the locally-attached firewall subnets (as explained previously for the default pass list).

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

                          @bmeeks no i have not.. doesn't the email server respond back on the port the client is connected to? I always thought it did.. Keep in mind that rule is the same as the default rule with a slight mod to the content.

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

                            @bmeeks ca6948b8-2c0d-40ba-8cdd-51d0c32a7f49-image.png

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

                              You need to be sure the relevant variables are properly populated for your servers. In this case, that means your SMTP server. The package just uses defaults for all variables that resolve to be the same as HOME_NET. HOME_NET is the sum total of all the protected networks, so that means every single subnet defined on your firewall interfaces, plus the WAN IP, the default gateway, configured DNS servers, Virtual IPs and VPN addresses.

                              If you want a more restrictive setup, then create a firewall alias containing your mail server and then assign that alias to SMTP_SERVERS on the VARIABLES tab, save the change and then restart Suricata on the interface so it will pick up the change.

                              You also need to be sure that you are not duplicating a rule SID. You can't have two SIDs the same, and I don't think Suricata will warn you about that in the current version.

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

                                The fact your bottom rule works tells you that blocking is working fine. You have a rule content issue and/or a pass list content issue. It might be time for you to do a packet capture to see what is actually going back and forth on the wire.

                                Blocking is totally unaware of the content of a rule. It simply looks at the IP addresses in the packet, and if the IP address is not on a pass list (or covered by the default pass list), then it is blocked.

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

                                  @bmeeks I don't understand what you mean by populating variables.

                                  Would being configured wrong cause it to still alert but not block?

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

                                    @RedDelPaPa said in Suricata custom rule alerts but won't block:

                                    @bmeeks I don't understand what you mean by populating variables.

                                    Would being configured wrong cause it to still alert but not block?

                                    No, it won't impact blocking or not blocking. It can impact when the rule triggers, though. The default value for SMTP_SERVERS would be a ton of network space defined on your firewall.

                                    You appear to have a case where traffic you think should get a block is actually covered in the pass list defined for the interface. If you have not changed the pass list from the value of "default", then I'm telling you that pass list is rather large as it will encompass all the locally-attached networks plus VPNs. It might be that during your testing responses that you think would be your client's public IP might actually be showing up to Suricata as being wrapped with a locally-attached network (the VPN tunnel, for example). That's why you might want to capture the traffic to examine the IP headers.

                                    The default pass list is more than just individual IP addresses. It includes entire subnets as defined on the pfSense local interfaces.

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

                                      @bmeeks But I told you that the rule that doesn't work alerts, and writes to the log. But it won't block.

                                      As stated earlier, VPN is down and disabled for testing.

                                      The suricata log file logs his public IP when it alerts. It just won't block it.

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

                                        @RedDelPaPa said in Suricata custom rule alerts but won't block:

                                        @bmeeks But I told you that the rule that doesn't work alerts, and writes to the log. But it won't block.

                                        As stated earlier, VPN is down and disabled for testing.

                                        The suricata log file logs his public IP when it alerts. It just won't block it.

                                        Okay. I'm looking at something now in the custom blocking plugin source code that might be at play. If you want to help troubleshoot, do these steps:

                                        Use the rule that you said is alerting but not blocking, and try it using two different settings for "Which IP to Block" on the INTERFACE SETTINGS tab. Each time you change this parameter, you will need to restart Suricata on the interface so it picks up the change.

                                        Change that option to block just the DST IP address (change the setting from BOTH to DST). Save the change and restart Suricata. Then test your rule. It should alert and block the remote client (the one with the public IP of your customer).

                                        If the above test works, that validates what I think I see in the source code of the blocking module.

                                        RedDelPaPaR 3 Replies Last reply Reply Quote 0
                                        • RedDelPaPaR
                                          RedDelPaPa @bmeeks
                                          last edited by

                                          @bmeeks One more question for you if you don't mind that's off topic.

                                          How does the suppress list work? Obviously if I click suppress and add IP in the log, it will suppress and whitelist that IP to do whatever activity that IP was doing. But If I just click suppress, say, I get a ton of different IP's attacking voip and SIP which I don't use. If I just click to suppress that action without adding the IP, will suricata continue to block that activity without logging it?

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

                                            do you think that if one ip is on the passlist and the "Which IP to Block" is set to both it will ignore both ip instead of only the one in the passlist?

                                            ̿' ̿'\̵͇̿̿\з=(◕_◕)=ε/̵͇̿̿/'̿'̿ ̿
                                            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.

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