Jeremy Chadwick wrote:
On Mon, Oct 06, 2008 at 08:19:09AM +0100, Matthew Seaman wrote:
Jeremy Chadwick wrote:

If you want a "magic solution", see blackhole(4).

block drop all

looks fairly magical to me.  Stick that at the top of your ruleset as
your default policy, add more specific rules beneath it to allow
the traffic you do want to pass, and Robert is your Mother's Brother.
No more floods of RST packets.

This is incredibly draconian.  :-)  I was trying my best to remain

It's no such thing.  This is the recommended standard practice when designing
firewalls: always start from the premise that all traffic will be dropped by
default and add specific exceptions to allow the traffic you want.  Trying to
work the other way round is a recipe for disaster: 'allow everything, but block
what is then shown to be deleterious' means that you're always playing catch-up
as changes on your servers expose new attack vectors and as attackers discover
and try to exploit those holes.  Not recommended, unless you actually /like/
being paged in the wee small hours.

(Actually, I'd recommend always adding a 'log' clause to any rules that
drop packets like so: 'block log drop all'.  Makes running 'tcpdump -i pflog0'
an invaluable debugging aid.)

I cannot advocate use of "log" on such "vague" rules, and my attitude is
based on experience:

We had "log" set on some of our deny rules, specifically on an entry
which blocked any traffic to an IP to any ports other than 53 (DNS).
Someone initiated an attack against that IP, to a destination port of
something other than 53, which caused pflog to go crazy with logging.

What inadvertently resulted was a local system DoS -- the system began
sporting a load average between 40 and 50, and was sluggish.

The root cause?  /var/log/pflog was growing at such a tremendous rate
that newsyslog (trying to rotate and compress the logs) could not keep
up.  When I got to it, I found 8 or 9 gzip/newsyslog processes running
trying to deal with the chaos.

Bottom line: be very, very cautious what rules you use "log" on, and be
sure to remove it once the system is in production.

You have a point here, I will certainly admit that.  In my experience, I've not
yet run into that scenario.  I've tended to see systems more easily DoSed by
running out of pf states due to excessive DoS traffic to allowed ports than to
any extra load from pflogd and newsyslog from logging denied traffic.  The
machines in question already log so much legitimate traffic from Squid and 
that pflog is trivial by comparison.  Of course, now I've said 'it never 
I'm expecting half our firewalls to explode any minute now...



Dr Matthew J Seaman MA, D.Phil.                   7 Priory Courtyard
                                                 Flat 3
PGP:     Ramsgate
                                                 Kent, CT11 9PW

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to