An example:
table <abusive_hosts> persist
block in quick from <abusive_hosts>
pass in on $ext_if proto tcp to $web_server \
port www flags S/SA keep state \
(max-src-conn 100, max-src-conn-rate 15/5, overload <abusive_hosts> flush)
This does the following:
* Limits the maximum number of connections per source to 100
* Rate limits the number of connections to 15 in a 5 second span
* Puts the IP address of any host that breaks these limits into the <abusive_hosts> table
* For any offending IP addresses, flush any states created by this rule.

So I understand this
For example if some user with this IP
192.168.0.52
connect to my web server , he or she can only open 15 pages in 5 second ,if he or she open new pages , pf block him.

and I understand this
user with 192.168.0.53 can not open than 15 pages or can not connect more than 15 connection in 5 second .

Am I right ?
Do I understand good this?,
with this rule I each IP can have 15 connection in 5 second .
please someone explain this section better for me

...I understand this
user with 192.168.0.53 can not open than 15 pages or can not connect more than 15 connection in 5 second .

Am I right ?
Do I understand good this?,

Yes, you are right, but .... only because each web page request from a browser uses a separate HTTP session.

(PF does not know anything about applications. All it knows is TCP/IP. Other application abuse may or may not be manageable with PF.)

In this example you reference, abusers get their IP address added to the "abusive_hosts" table, they get blocked, and their existing sessions get killed.

The "abusive_hosts" table is in kernel memory, and not stored in a file, so a restart of the OS will start with an empty table. To make it permanent, you can add pfctl commands to /etc/rc.shutdown to store the table in a file, and use the "file" option of the table command in pf.conf, to load the table from the file at start up. These are described in pfctl(8) and pf.conf(5).

One -can- restrict the total number of simultaneous states allowed, to keep access manageable in the event a website gets "slashdotted" -- overwhelmed because of sudden increased transaction rates.

In the example mfaridi quoted, max-src-conn 100 limits the number of simultaneous transactions to 100. Users beyond that number do not get a connection, which -might- or -might not- be a problem, depending on the application. But it does allow the 100 sessions that are connected to function without overwhelming resources.

That "100" is of course not meaningful without understanding the webserver's capacity, and the capacity of adjunct application and database servers that might be involved.

this is more useful to restrict ssh access...
For a webserver, it is quite annoying.

Some webservers such as the Hiawatha webserver actually have these options builtin, (ConnectionsTotal, ConnectionsPerIP, BanOnFlooding, BanOnMaxPerIP options).

In the pf.conf for this forums I have:

Quote:

source-track max-src-conn 50 max-src-conn-rate 200/10

For a time I monitored the overload table I used to see how often this limit was reached: Almost never, and when it was reached it was almost always by a bot, either a legitimate bot (i.e. google) or a bot of unclear origin and doubtful legitimacy.
I solved the problem by making a table with known bot addresses (Taken from iplists.com) which are exempted from this rule.

Why use max-src-conn and max-src-conn-rate? It prevent (D)DoS attacks.

__________________
UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things.

Can we find another solution to control access web server , we use this rule but in some place like school with ADSL internet sharing , our PF block them , for example we have 200 computer in one school and all of them one ADSL internet connection .

Some webservers such as the Hiawatha webserver actually have these options builtin, (ConnectionsTotal, ConnectionsPerIP, BanOnFlooding, BanOnMaxPerIP options).

In the pf.conf for this forums I have:

For a time I monitored the overload table I used to see how often this limit was reached: Almost never, and when it was reached it was almost always by a bot, either a legitimate bot (i.e. google) or a bot of unclear origin and doubtful legitimacy.
I solved the problem by making a table with known bot addresses (Taken from iplists.com) which are exempted from this rule.

Why use max-src-conn and max-src-conn-rate? It prevent (D)DoS attacks.

if I understand good you advise me I make new table about bot , and I say to pf do not block this IP (bot IP)
Am I right ?
if I understand good , I have abuse table too , in abuse rule I define PF block max connection , I think this rule will block BOT IP too.
So I say PF dose not use abuse rule for BOT IP and use abuse rule for other function ?