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.

Well, yeah.  But 'block drop in all' is pretty much just an optimised 
variant of

block drop all
pass out all

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

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 
than having to traverse the whole rule set.  At least, it is when using 
pf.

	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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 258 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20081006/d93c6e33/signature.pgp