On Tue, Feb 21, 2012 at 9:51 PM, Joachim Schipper
<joac...@joachimschipper.nl> wrote:
> Just the most obvious idea, since you mention that this sort-of-works if
> you put "block drop in quick from !<whitelisted_users>": does it handle
> this load if you turn off pf, or only include one or two trivial rules?

Did not try to turn off pf (I need it anyway), and my pf.conf is very
simple and already optimized following the good book of pf and some
undeadly posts.

> It certainly suggests that you may be well-served by optimizing your
> pf.conf... (also, you've probably found the "synproxy" directive? If
> not, try that too.)

I already use synproxy, the problem is that I get so much SYN that
pf/state table collapses.

> Also, state tracking is apparently faster than stateless pf for normal
> firewalls. I'd double-check if this is still true in your case, though;
> if nothing else, stateless pf makes a CARP'ed setup easier.

I am not sure to understand here. I want to use synproxy to protect my
backend servers, so I need state stracking.

> I'm pretty sure you can muck with the rules without dropping existing
> connections. (pf essentially does "does this packet match a known state?
> If not, look at pf.conf".) This is almost certainly easier than your
> proposed daemon.

Sure thing, the daemon is only a workaround to provide degraded but
working service when under attack.

> A final, rather hackish, idea that probably does need a bit of
> programming: greylisting for SYNs. Legitimate users will send you a
> second SYN, so you could do something like (this has not even been
> syntax-checked!)
>  block drop log in quick from !<syn_seen> no state flags S/SA

I like the idea. This may need some programming indeed, but it seems
even better than my idea. Thanks, I'll take a look at this.

> and then add every logged IP to syn_seen. Obviously, this will slow down
> access to the service for legitimate users, which may or may not be
> acceptable.

We are speaking of a slower but working service, or no service at all.
I prefer the first alternative :)

Reply via email to