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

    Lockout incoming port

    Scheduled Pinned Locked Moved Firewalling
    6 Posts 4 Posters 1.1k 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.
    • G
      gertjan_kesel
      last edited by

      Hi,

      is there any solution for blocking someone that tries multiple times to login on our server behind a firewall?
      Something like the lockout rule, like if they try 10 time in 10 minutes we can block that wan ip for some time?

      Thanks in advance!

      1 Reply Last reply Reply Quote 0
      • M
        muswellhillbilly
        last edited by

        This is probably what you're looking for:

        https://doc.pfsense.org/index.php/Locked_out_of_the_WebGUI

        Quoting from this page:


        Attempting to login to the GUI and failing many times will cause the connecting IP address to be added to the webConfigurator lockout table. Currently the limit is 15 failures (without success) within 24 hours. Addresses are not automatically expired from the table on pfSense 2.1.x and earlier. On pfSense 2.2 and later, addresses are expired after a minimum of one hour.

        To regain access, login successfully from another IP address and then manually remove the entry as follows:

        Navigate to Diagnostics > Tables
            Select webConfiguratorlockout
            Click "x" by the entry or entries for workstations to allow again.

        The lockout table may also be cleared by the console or ssh in the shell:

        pfctl -T flush -t webConfiguratorlockout


        The othe consideration is to prevent console access from your WAN, just making it LAN-only access.

        1 Reply Last reply Reply Quote 0
        • johnpozJ
          johnpoz LAYER 8 Global Moderator
          last edited by

          mus I don't think he is talking about the web gui of pfsense… Sounds like he has rdp or something open to a box behind pfsense.. And he wants pfsense to stop that login..

          Don't open up serves to remote access in the first place - vpn into your network if you need access to servers would be my suggestion.

          An intelligent man is sometimes forced to be drunk to spend time with his fools
          If you get confused: Listen to the Music Play
          Please don't Chat/PM me for help, unless mod related
          SG-4860 24.11 | Lab VMs 2.8, 24.11

          1 Reply Last reply Reply Quote 0
          • M
            mer
            last edited by

            Doesn't pf (at the base level) have the ability to utilize number of tcp connections over a given period as a filter?  Basically x # connection attempts in y seconds from an IP can be used to block that IP?  If every login attempt resulted in the establishment of a new new connection to the server, something like this may help.

            I know that's not really what the OP is asking:  it sounds like he need feedback from the application that is rejecting the login to add a temp rule back at pfSense to block the source IP.  As for exactly how to do this, I have no idea, I suspect a lot would depend on the application that is at the server.

            1 Reply Last reply Reply Quote 0
            • johnpozJ
              johnpoz LAYER 8 Global Moderator
              last edited by

              yes it does… But depending on the system trying to login too.. Why would you think that a new connection would be created?  A new connection to pfsense would be a new SYN..  Once you opened a session to try and auth, who says that session would be killed?  One you open say a rdp connection, you could bang on that all day pretty much in the same session.

              If you have brute force attempts to your servers you have open to the public..  Lock down the rule that says what IPs can talk to that server would be another option in preventing those attempts.  Putting services out to the public net not a good idea..  If you need to login to stuff, why not just vpn.. You can lock down what source IPs can even use the IP for your vpn.  And you can require multi factor auth even to get in.  Username and Password, and Cert, etc.  And or even go above that with say a OTA, etc.

              Only upon auth to your vpn, would you be able to hit stuff that might not have real security on their auth method, like a RDP session, or a web gui to some service, etc.

              An intelligent man is sometimes forced to be drunk to spend time with his fools
              If you get confused: Listen to the Music Play
              Please don't Chat/PM me for help, unless mod related
              SG-4860 24.11 | Lab VMs 2.8, 24.11

              1 Reply Last reply Reply Quote 0
              • M
                mer
                last edited by

                @johnpoz:

                yes it does… But depending on the system trying to login too.. Why would you think that a new connection would be created?  A new connection to pfsense would be a new SYN..  Once you opened a session to try and auth, who says that session would be killed?  One you open say a rdp connection, you could bang on that all day pretty much in the same session.

                If you have brute force attempts to your servers you have open to the public..  Lock down the rule that says what IPs can talk to that server would be another option in preventing those attempts.  Putting services out to the public net not a good idea..  If you need to login to stuff, why not just vpn.. You can lock down what source IPs can even use the IP for your vpn.  And you can require multi factor auth even to get in.  Username and Password, and Cert, etc.  And or even go above that with say a OTA, etc.

                Only upon auth to your vpn, would you be able to hit stuff that might not have real security on their auth method, like a RDP session, or a web gui to some service, etc.

                Thanks John.  The first part was merely wondering "if the login attempts had these characteristics, this could be a way", but without knowing more specifics from the OP, I'm just guessing/speculating/swag-ing, in the hopes of the OP providing us more detail to work with.

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