Rate limiting via virusprot takes actions too early
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".
Anyone any ideas?
Still no ideas? The issue is still ongoing.
It's working as intended, but perhaps not the way you expect:
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.