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

    Rate limiting via virusprot takes actions too early

    Firewalling
    2
    4
    609
    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
      gabriiel
      last edited by

      Hi all,

      I have a rule, where I check number of connections from one IP coming to http(s), set to these limits:
      150 total connections in the state table
      120 new connections in 30 seconds.

      The rule in console output looks like this:

      pass in log quick on lagg0_vlan5 reply-to (lagg0_vlan5 ip.ad.dr.es) inet proto tcp from ! <grp_hosts_wl> to <grp_fw> port = https flags S/SA keep state (source-track rule, max-src-conn 150, max-src-conn-rate 120/30, overload <virusprot> flush global, src.track 30) label "ratelimit"</virusprot></grp_fw></grp_hosts_wl>
      

      The problem is, sometimes there are customers, who are blocked after having like 30 connections in like 10 minutes, which obviously didn't hit this rule at all.
      I have no other rule for rate limiting.

      I was checking if they have reached a total states limit and not at all as well.

      Seems like a bug to me.

      How can I verify, why they are blocked? In the logs I can only see the connections, but not the reason, like "blocked because this and that limit reached".

      Thanks,
      Gabriel

      1 Reply Last reply Reply Quote 0
      • G
        gabriiel
        last edited by

        Anyone any ideas?

        1 Reply Last reply Reply Quote 0
        • G
          gabriiel
          last edited by

          Still no ideas? The issue is still ongoing.

          Thanks.

          1 Reply Last reply Reply Quote 0
          • jimpJ
            jimp Rebel Alliance Developer Netgate
            last edited by

            It's working as intended, but perhaps not the way you expect:

            https://www.freebsd.org/cgi/man.cgi?query=pf.conf&apropos=0&sektion=0&manpath=FreeBSD+11.2-RELEASE&arch=default&format=html#STATEFUL_TRACKING_OPTIONS

                 For stateful TCP connections, limits on established connections (connec-
                 tions which have completed	the TCP	3-way handshake) can also be enforced
                 per source	IP.
            
                 max-src-conn <number>
            	   Limits the maximum number of	simultaneous TCP connections which
            	   have	completed the 3-way handshake that a single host can make.
                 max-src-conn-rate <number>	/ <seconds>
            	   Limit the rate of new connections over a time interval.  The	con-
            	   nection rate	is an approximation calculated as a moving average.
            
                 Because the 3-way handshake ensures that the source address is not	being
                 spoofed, more aggressive action can be taken based	on these limits.  With
                 the overload <table> state	option,	source IP addresses which hit either
                 of	the limits on established connections will be added to the named ta-
                 ble.  This	table can be used in the ruleset to block further activity
                 from the offending	host, redirect it to a tarpit process, or restrict its
                 bandwidth.
            
                 The optional flush	keyword	kills all states created by the	matching rule
                 which originate from the host which exceeds these limits.	The global
                 modifier to the flush command kills all states originating	from the
                 offending host, regardless	of which rule created the state.
            
                 For example, the following	rules will protect the webserver against hosts
                 making more than 100 connections in 10 seconds.  Any host which connects
                 faster than this rate will	have its address added to the <bad_hosts> ta-
                 ble and have all states originating from it flushed.  Any new packets
                 arriving from this	host will be dropped unconditionally by	the block
                 rule.
            
            	   block quick from <bad_hosts>
            	   pass	in on $ext_if proto tcp	to $webserver port www keep state \
            		   (max-src-conn-rate 100/10, overload <bad_hosts> flush global)
            

            You specified a rate. Not that it is not a literal count of X states in Y time, but a calculated average. If they connect at a rate faster than the one you chose, on average, they will be blocked, even if they did not explicitly exceed the stated limit over the entire time period.

            Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

            Need help fast? Netgate Global Support!

            Do not Chat/PM for help!

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