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 realistic.
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
Apache
that pflog is trivial by comparison. Of course, now I've said 'it never
happens'
I'm expecting half our firewalls to explode any minute now...
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
Kent, CT11 9PW
signature.asc
Description: OpenPGP digital signature
