Date: Mon, 06 Oct 2008 12:04:24 +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: <48E9F0B8.6070708@infracaninophile.co.uk> In-Reply-To: <20081006090704.GB13975@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> <48E9CDA6.80508@infracaninophile.co.uk> <20081006090704.GB13975@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)
--------------enig35BF2940C2F165010B6ACDC7
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Jeremy Chadwick wrote:
> On Mon, Oct 06, 2008 at 09:34:46AM +0100, Matthew Seaman wrote:
>> 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 a=
s
>>>> 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=
=2E
>>>> 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 de=
signing
>> firewalls: always start from the premise that all traffic will be drop=
ped by
>> default and add specific exceptions to allow the traffic you want. Tr=
ying 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.
>=20
> What I mean by 'draconian': "block drop all" includes both incoming
> *and* outgoing traffic.
Well, yeah. But 'block drop in all' is pretty much just an optimised=20
variant of
block drop all
pass out all
even if you never write it out that way. You're just starting two=20
steps into the process I was talking about.=20
> I have absolutely no qualms with "block in all", but "block out all" is=
> too unrealistic, depending greatly on what the purpose of the machine
> is. Any outbound sockets are going to be allocated dynamically (e.g.
> non-static port number), so there's no effective way to add pass rules
> for outbound traffic. Using uid/gid is not sufficient.
> I often advocate using "block in all", "pass out all", and then adding
> specific "pass" rules for incoming traffic (e.g. an Internet request
> wishing to speak to BIND on port 53, Apache on 80/443, etc.).
>=20
> Like I said: I'm being realistic.
One man's realism is another's open proxy or information disclosure
and having to deal with abuse complaints. Yes, in practice for some
of the firewalls we manage the policy is 'all outgoing is allowed',=20
but by no means the majority. Most of the time we do permit outgoing for=
some or all of these protocols: FTP(passive), SSH, SMTP, DNS,=20
HTTP, NTP, HTTPS, RSYNC, CVSUP and frequently that's allowing=20
outgoing to any unless there's a requirement to restrict things=20
further.
We aren't concerned with writing filter rules that operate on the
local port numbers here, but with the port numbers on the remote sites
we're connecting to. As you say, local port numbers are unpredictable,
but stateful firewall rules handle all that sort of thing easily,
even for stateless (UDP) protocols like DNS. Not only that, but looking =
up a packet in the state table is generally quite a bit faster=20
than having to traverse the whole rule set. At least, it is when using=20
pf.
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
--------------enig35BF2940C2F165010B6ACDC7
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
iEYEAREIAAYFAkjp8MMACgkQ8Mjk52CukIz5cQCeNxS9/HmpjFqICplsOkU+o8Rz
BDwAn0fCcq5jWDyuW6Sk82RJlt18HXr0
=SJ0k
-----END PGP SIGNATURE-----
--------------enig35BF2940C2F165010B6ACDC7--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48E9F0B8.6070708>