Date: Mon, 06 Oct 2008 09:34:46 +0100 From: Matthew Seaman <m.seaman@infracaninophile.co.uk> To: Jeremy Chadwick <koitsu@FreeBSD.org> Cc: Scott Bennett <bennett@cs.niu.edu>, freebsd-questions@FreeBSD.org Subject: Re: pf vs. RST attack question Message-ID: <48E9CDA6.80508@infracaninophile.co.uk> In-Reply-To: <20081006072611.GA13147@icarus.home.lan> References: <200810051753.m95Hr3N5014872@mp.cs.niu.edu> <20081006003601.GA5733@icarus.home.lan> <48E9BBED.7090607@infracaninophile.co.uk> <20081006072611.GA13147@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigDB0E4602F230BC04BCB244D9
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
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.
>=20
> This is incredibly draconian. :-) I was trying my best to remain
> realistic.
It's no such thing. This is the recommended standard practice when desig=
ning
firewalls: always start from the premise that all traffic will be dropped=
by
default and add specific exceptions to allow the traffic you want. Tryin=
g 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 ca=
tch-up
as changes on your servers expose new attack vectors and as attackers dis=
cover
and try to exploit those holes. Not recommended, unless you actually /li=
ke/
being paged in the wee small hours.
>> (Actually, I'd recommend always adding a 'log' clause to any rules tha=
t
>> drop packets like so: 'block log drop all'. Makes running 'tcpdump -i=
pflog0'
>> an invaluable debugging aid.)
>=20
> I cannot advocate use of "log" on such "vague" rules, and my attitude i=
s
> based on experience:
>=20
> 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.
>=20
> What inadvertently resulted was a local system DoS -- the system began
> sporting a load average between 40 and 50, and was sluggish.
>=20
> 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.
>=20
> Bottom line: be very, very cautious what rules you use "log" on, and be=
> sure to remove it once the system is in production.
>=20
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 th=
an to
any extra load from pflogd and newsyslog from logging denied traffic. Th=
e
machines in question already log so much legitimate traffic from Squid an=
d 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
--=20
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
Kent, CT11 9PW
--------------enigDB0E4602F230BC04BCB244D9
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEAREIAAYFAkjpzawACgkQ8Mjk52CukIymuACeOnFlYEUv3WQMa0ivVfp85YNf
O2QAn2P7+FJryS55FH2Fm+kgoHY0EPYJ
=SuAZ
-----END PGP SIGNATURE-----
--------------enigDB0E4602F230BC04BCB244D9--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48E9CDA6.80508>