Is there a reason max-src limits are linked to virusprot by default and always?

Started by bb-mitch, July 02, 2020, 10:19:37 PM

Previous topic - Next topic
I was trying to test out something I've tried before... hoping it had changed. And locked myself out again  ::) :P

I'm wondering if there's a reason things are the way they are, or if any of the powers that be can see a reason NOT to support a simple change I'm requesting. I can find ways to work around it. I just think it might make the feature more widely useful if there was some flexibility in the way the feature is coded.

I'm making this thorough so it's a helpful reference to any who read it later even if nothing changes.

When you want to set maximum limits for TCP connections you have the following field options (from the pf man page (https://www.freebsd.org/cgi/man.cgi?query=pf.conf&sektion=5&n=1) :

Quotemax-src-nodes <number>
Limits the maximum number of source addresses which can simultaneously have state table entries.

max-src-states <number>
Limits the maximum number of simultaneous state entries that   a single source address can create with this rule.

For stateful TCP connections, limits on established connections (connections 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 connection rate is an approximation calculated as a moving average.
There is a section in the docs:
https://docs.opnsense.org/manual/firewall.html#connection-limits

However, I think it's missing some information / explanation including a section / reference to Firewall -> Diagnostics -> pfTables

IF you enable any of those options you need to know triggering them results in black listing.
To manage it:


  • Navigate to: Firewall -> Diagnostics -> pfTables
  • Select the virusprot table
  • Remove any IP you need to unblock


From the posts I've seen, it seems like that keeps catching people and it's not hard to understand why...

At the beginning of the firewall rules there are a couple of important lines:

table <virusprot>
This sets up the table.

block in log quick from {<virusprot>} to {any} label "8e36..." # virusprot overload table
This results in anything listed in that table being blocked in spite of later rules.

When you add some state limits, the rule gets tagged with them like this:
max-src-conn 1 max-src-states 10 tcp.established 120 max-src-conn-rate 1 /1, overload <virusprot> flush global


The tricky part (and what I'm wondering about changing / making allowance for customization) is the part at the end:
overload <virusprot> flush global

If we review the manual for pf again:
QuoteBecause 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 table. 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> table 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)[/code]

What I'm suggesting is under the advanced settings could there be a list of tables so you could optionally select one? If you wanted to, the default could still be virusprot which would preserve the default behavior?

The flush and global options could be default checked, but allowed to be unchecked.

WHY AM I ASKING?

Consider if I added a rule to rate limit access to a webserver... maybe used for provisioning. A large site with a power failure COULD trip the max https requests at once, but the ability to change the table name, and to not include flush and global could allow the working phones to continue to work. The existing connections to continue to download their payload.

The way it is, the tripwire is all or nothing - and prevents many people from using the connection rate limiting function unless they are prepared to lose all connectivity with any host that exceeds the limit.

limiting connections (i.e. to an SMTP service might be desirable (resulting in a timeout on the sender) instead of black listing the IP like currently happens.

In short one suggestion and one suggestion for a change (improvement?).
1) Update the doc with a reference to how to fix it when you enable those features?
2) Make the table name selectable, and the flush and global options optional.

What do you think? Happy to make a donation to the effort!  ;D

Thanks in advance for your consideration and feedback.

m