When should I worry about performance tuning?

[Chris H]

On Wed, 29 Mar 2017 22:57:48 +0200 (CEST) Martin MATO <martin.mato at orange.fr>
wrote
> > Message du 29/03/17 22:05
> > De : "Chris H" 
> > A : "FreeBSD pf" 
> > Copie à : 
> > Objet : When should I worry about performance tuning?
> > 
> > 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 persist file "/etc/SPAMMERS"
> > block in log quick on re0 proto tcp from to port {smtp, submission,
> > pop3, imap, imaps}
> > ###################################
> > 
> > Would set optimization be warranted?
> > Any thoughts, or advice greatly appreciated!
> > 
> Greetings.
> 
> I don't understand some things.
> 
> your machine is a mail relay/server, or you haved a host without any firewall
> between him and the internet? 
>
>  
> 
> In the first case, you'll should prefer setting greylisting / tarpitting at
> minimum, feeding a firewall table for blacklisting is a neverending story
> (plus, there is some real chance blocking real MX relays). 
>
>  
> 
> and in the second case a basic pf configuration blocking any incoming
> attempts like: 
>
>  
> 
> set skip lo0 # skipping any filtering on lo0
> 
> ext_iface="your_network_card_connected_to_internet"
> 
> pass out quick on $ext_iface all
> block log quick on $ext_iface all
> 
>  
> 
> should be sufficient.
> 
> for more information about optimizations,  man (5) pf.conf  should do the
> trick. 
>
>  
Thanks for the reply, Martin.
It (currently) has only one [inet] facing NIC.
It's an MX for some 60 domains. I have zero reason to think I
am, or will drop packets from an innocent/legitimate MX. I also
monitor/filter http/www. In fact, I'm now at a point that I can tell
you which computers are drones, which web software is now vulnerable,
and how to subvert that web software. It's not terribly uncommon to
get over 500 identical (subversive) requests, from over five hundred
unique IP's, in under 4 seconds. Which pretty much guarantees that
they came from drones (p0wned boxes).
To your point regarding other methods of filtering (greylisting,
etc...). I've used those, as well as RBL services, and in ALL cases
they fell short of their objective(s). They either weren't flexible
enough, or (frequently) blocked innocent senders. This is my attempt
to overcome those shortcomings. I'm filtering in ways that none of
the other methods seem to have thought of, or perhaps couldn't figure
out how. I'm also not convinced the additional overhead that an
additional NIC would add, would be beneficial (tho I could be wrong). :)
In any case. So far, my filtering has only improved. I expect in
another month. I'll be ready to either open a service, or the method
(source) itself to accomplish all this. :-)

Thanks again, for taking the time to respond, Martin!

--Chris