pf vs. RST attack question

[Giorgos Keramidas]

On Mon, 6 Oct 2008 00:26:11 -0700, Jeremy Chadwick <koitsu at freebsd.org> wrote:
> On Mon, Oct 06, 2008 at 08:19:09AM +0100, Matthew Seaman wrote:
>> 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.

Yes this is a bit draconian, but it is also pretty ``realistic'', as in
``it works fine if all you need is a very basic, but strict firewall''.

I run my laptop with a `pf.conf' that (putting most of the comments and
other disabled rules for one-off tests aside) looks pretty much like:

  set	 block-policy drop
  set	 require-order yes
  set	 skip on lo0
  scrub	 in  all
  block	 in  all
  block	 out all
  pass	 in  quick proto icmp all
  pass	 out quick proto icmp all
  pass	 out proto { tcp, udp } all keep state

Depending on the network I am connected to, I may leave DHCP replies
open too, i.e.:

  pass	 in  quick proto udp from 192.168.1.1/24 to 255.255.255.255 port = 68

This seems to have worked pretty well so far, but this is, as I wrote,
merely a laptop.  For production servers, there are probably going to be
quite a few other rules to allow incoming connections.

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

Heh, that's indeed a possibility.   Hence the lack of 'log' in my
default ruleset shown above.