On Mon, 6 Oct 2008 00:26:11 -0700, Jeremy Chadwick <[EMAIL PROTECTED]> 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 to 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.

freebsd-questions@freebsd.org mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to