Rate limiting via virusprot takes actions too early

[gabriiel]

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

[gabriiel]

Anyone any ideas?

[gabriiel]

Still no ideas? The issue is still ongoing.

Thanks.

[jimp]

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.