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

    Rate limit inbound connections

    Scheduled Pinned Locked Moved Firewalling
    2 Posts 2 Posters 2.9k 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.
    • T
      td_miles
      last edited by

      Apologies if this has been asked before. I've done some searching and can't really find an answer to my question.

      The problem I have is a large number of incoming PPTP connections trying to brute force passwords. This is evident in the RADIUS logs (RADIUS is on another server) showing the usernames being attempted (ie. dictionary type attack). This has been happening for a number of hours and the RADIUS logs shows many thousands of attempts.

      Ignoring the use of PPTP at this point (it is something I am unable to change), what is the best way to prevent/limit this activity. I could block the source IP address in question, but that only fixes the problem temporarily until it starts to come from a difference source.

      I was looking at setting some options for inbound connections on port 1723, but don't want to inadvertently cause a DoS on myself.

      If I look at the "Advanced Options" section of a firewall rule it has options for:

      • Maximum state entries this rule can create

      • Maximum number of unique source hosts

      • Maximum number of established connections per host

      • Maximum state entries per host

      • Maximum new connections / per second(s)

      • State Timeout in seconds

      Setting the first option might cause a DoS as the hacker would continually use up all the "allowed" entries and legitimate clients would be unable to connect ?
      The second one would be of no real benefit, except again perhaps causing a DoS against myself ?
      The third option is interesting, but not sure if it would be of any benefit unless the connections were happening multiple at a time from the hacker. I'm also not sure if the "per host" referred to is the source host ?
      Fourth one I'm not sure about, again is this per source host ? Again assuming TCP connections are closed properly, I don't think this would slow down hacking attempt ?
      Maximum number of connections per second holds some promise, but I'm unsure of the values. There is a text entry field and also a drop-down box that allows me to select a value 1-254. Does this means if I put 1 in the text box and then select 60 from the drop down, this is 1 new connection per 60 seconds ? I would also ask whether this is per host or just in general as I might again DoS myself if I limit things to 1 new connection per second and the hacking host takes all of the available new connections.
      Don't know if "State Timeout" is relevant at all as I would assume that the PPTP password cracker being used is tearing down TCP session properly and so this timeout won't have any effect ?

      So I guess the question is, are any of the "Advanced Options" going to help me out here ? Some combination of them that might do what I want ? Is there a way of saying "limit inbound connections to this port to 1 every 10 seconds, per source host" ?  Is there any more documentation I can read on what the above Advanced Options do and examples of how to use them ?

      I'm open to other suggestions too (apart from saying "don't use PPTP"). I note that for SSH there is a package called "denyhosts" which would seem to do the sort of thing I need, but it is specific for SSH. I looked at "Strikeback", but doesn't seem to do what I want.

      On a quick side note, I saw a post somewhere else about having to disable auto generation of VPN rules to be able to add a customer rule for TCP/1723, but could I just leave the auto rules in place and add my custom rule above the auto rules ? Does pfsense do a "first rule that matches" type lookup behaviour and then skip the rest of the rules for a packet ?

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

        answering to very last question from you questions: top-to-down and ingress is used => first matching packet win

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