When should I worry about performance tuning?

[Chris H]

On Wed, 29 Mar 2017 22:19:58 +0200 "Kristof Provost" <kristof at sigsegv.be> wrote

> On 29 Mar 2017, at 22:06, Chris H wrote:
> > OK. My association with FreeBSD has made me a prime
> > target for every male hormone distributor on the net.
> > Fact is; I can guarantee ~89 SPAM attempts in under 5
> > minutes, after creating a pr on bugzilla. At first I
> > was angry, and frustrated. But decided to make it a
> > challenge/contest, and see my way to thwarting their
> > attacks. Long story short; I think I'm on the right
> > track; In just over a month, I've managed to trap
> > just under 3 million (2,961,264) *bonafide* SPAM sources.
> > I've been honing, and tuning my approach to insure that
> > there are zero false positives, and at the same time,
> > make it more, and more efficient.
> > So now that I'm dropping packets from *so* many IP's
> > I'm wondering if it's not time to better tune pf(4).
> > I've never worked pf hard enough to do any more than
> > create a table, and a few simple rules. But I think I
> > need to do more.
> > Here's the bulk of what I'm using now:
> >
> > ###################################
> > set loginterface re0
> > set block-policy drop
> > set fingerprints "/etc/pf.os"
> > scrub in all
> > set skip on lo0
> > antispoof quick for lo0
> > antispoof for re0 inet
> >
> > table <spammers> persist file "/etc/SPAMMERS"
> > block in log quick on re0 proto tcp from <spammers> to port {smtp, 
> > submission,
> > pop3, imap, imaps}
> > ###################################
> >
> > Would set optimization be warranted?
> > Any thoughts, or advice greatly appreciated!
> >
> If I’m reading the code right the table lookup already uses a radix 
> table
> internally, so I would already expect this to perform as well as it’s 
> going to.
> 
> Arguably you could just drop all traffic from them on all interfaces, 
> but I
> doubt that’ll make a huge difference.
> 
Thanks for the reply, Kristof!

If it makes any difference. All the IP's in the table are in CIDR
notation, and are of either www.xxx.yyy.0/24, or www.xxx.yyy.zzz/32
It seemed that would be the most efficient approach -- to me, anyway. :-)

Thanks again!

--Chris