Re: pf vs. RST attack question

[Matthew Seaman]

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 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.

What I mean by 'draconian': "block drop all" includes both incoming
*and* outgoing traffic.

block drop all
pass out all

Well, yeah. But 'block drop in all' is pretty much just an optimised variant of even if you never write it out that way. You're just starting two steps into the process I was talking about.

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.).

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


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,


        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

of the firewalls we manage the policy is 'all outgoing is allowed', 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, HTTP, NTP, HTTPS, RSYNC, CVSUP and frequently that's allowing outgoing to any unless there's a requirement to restrict things further. 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 than having to traverse the whole rule set. At least, it is when using pf.

signature.asc
Description: OpenPGP digital signature