# partitioning / rate limiting in pf(4)



## Chris_H (Apr 11, 2014)

Greetings,
 I'm afraid my pf(4) foo is quite dated, as my pf.conf(5) will likely reveal. That said. As I look to a rollout of releng_9 to  all the releng_8 servers. I want to update some of the network bits, and pf(4) happens to be one of them. I'm hammered by all of the search engines 24hrs/day. Which is just fine. Google, and Ahrefs do so non-stop. Also fine. But in the case of *ahrefs*, they'll attach several bots simultaneously, and, given the chance, will suck your pipe flat. While it'd be trivial to simply drop their requests, for bad behaviour, and be done w/it. It seems it'd be a great deal smarter to simply partition the network, and attach different %rates to all the partitions. Giving higher priorities to different services/requests, than others. Effectively; rate-limiting.
Would anyone familiar with this sort of approach be willing to share some advice/examples on how best to achieve this approach, using pf(4)? Also feel free to "critique" anything in my current pf.conf(5) below. 


```
set loginterface re0
set fingerprints "/etc/pf.os"

scrub in all

set skip on lo0

antispoof for re0 inet

block in quick on re0 proto tcp from any to any port 23
block in quick on re0 proto tcp from any to any port 110

table <mailabuse> { nnn.nnn.nnn.nnn, NNN.NNN.NNN.NNN }

table <webabuse> { nnn.nnn.nnn.nnn, NNN.NNN.NNN.NNN }

block in quick from <mailabuse> to any
block in quick from <webabuse> to any

pass all
```

Thank you for all your time, and consideration.

--Chris

UPDATE: Maybe *prioritization* would have been a better way to put it. In other words; prioritizing services / requests.


----------

