OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: Adrian Buxton (adrian.buxtonteam.ozemail.com.au)
Date: Fri Jun 21 2002 - 22:18:05 CDT

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    > -----Original Message-----
    > From: Robert Schwartz [mailto:robertmrsquirrel.com]
    > Sent: Saturday, 22 June 2002 1:19 AM
    > To: 'Adrian Buxton'; 'Daniel Hartmeier'
    > Cc: miscopenbsd.org
    > Subject: Re: PF gateway problems.. return traffic blocked
    > (but not if in N AT m ode!)
    >
    >
    > > -----Original Message-----
    > > From: owner-miscopenbsd.org [mailto:owner-miscopenbsd.org]
    > > On Behalf Of Adrian Buxton
    > > Sent: Friday, June 21, 2002 1:35 AM
    > > To: 'Daniel Hartmeier'
    > > Cc: 'miscopenbsd.org'
    > > Subject: Re: PF gateway problems.. return traffic blocked
    > > (but not if in N AT m ode!)
    > >
    > [snip]
    > > This also means that the HOWTO document has a bogus
    > > demonstration ruleset.
    > [snip]
    >
    > The problem was your "default block" rule as Daniel pointed
    > out, not the
    > FAQ:

    I was not referring to the FAQ on the OpenBSD site. I was referring to
    the HOWTO document linked off the pf homepage.
    http://www.inebriated.demon.nl/pf-howto/html/node3.html#SECTION000310000
    000000000000

    > (from your first email)
    > # block anything not matching
    > block in log quick from any to any
    > block out log quick from any to any
    >
    > (from one of Daniel's responses)
    > "> So, this means I have to keep state on the external interface else
    > the
    > > return traffic is dropped?
    > If you have a default block on both interfaces, yes.
    > Daniel"
    >
    > So yes, you'll have to create state on all interfaces you
    > want to create
    > default block filters on. The default ruleset clearly states:
    >
    > (from the PF FAQ "putting it all together as per your email)
    > "# by default, block all incoming packets, except those explicitly
    > # allowed by further rules
    > block in on $ExtIF all"
    >
    > So the example ruleset has a much more conventional block in
    > on $ExtIF,
    > requiring state to be kept on only one interface, which is a "germain"
    > example, not a "bogus" example.
    >

    Again this refers to a differing document.

    > In your example to get the kind of fine-grain control that
    > lets you have
    > "egress and ingress" filtering, you can block in on $ext and block out
    > on $ext. In a 2 nic setup this should work the same as block
    > in on $ext
    > and block out on $int.
    >

    Yes. The bit I was missing was that states are interface specific. The
    reason it was working for NAT is because of a rule I had to permit
    traffic from $ext_if on $ext_it to any keep state, which originally I
    setup to allow the f/w gateway to go anywhere.

    > If you have more then 2 nics and you have three different security
    > policies to enforce then you'll need these bigger state
    > tables you were
    > talking about, but with only 2 nic's it's fine to move the
    > egree filter
    > to the external nic as well as the ingress filter.
    >

    The system will have about 4 nics. I'll have to try and determine what
    ruleset will allow me to maintain strict control over what enters the
    firewall system, as well allow traffic between all networks. Hopefully
    without multiple keep state rules.

    Cheers,
    Adrian.