[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PF Filter rules & NAT

On Tue, Dec 10, 2002 at 01:02:21AM +1100, Benjamin M.A. Robson wrote:
> > no filtering on dc1 at all.
> Not filtering on any interface is a -very- bad idea.  As if the scenario 
> was that I had 3
> interfaces, and I only filtered on the Internet interface, I now have no 
> access control between the
> 2nd and 3rd interfaces.
it depends on the "level" of control you want to have on each interface.
since I started using PF, I adopted the "Cisco" filtering philosophy.
That is, give a "virtual" level to each interface:
  - internal interface is trusted
  - external interface is untrusted
  - the other ifs somewhere in between
here is how it is implemented on one of my gws:
  # allow anything in/out from the internal interface
  pass in quick on $internal_if all  
  pass out quick on $internal_if all  
  # block attempted access from the dmz to the internal network
  # but let answers go back to the internal net
  pass out quick on $dmz_if proto tcp from $internal_net to $dmz_net \ 
  flags S keep state 
  pass out quick on $dmz_if proto { udp, icmp } from $internal_net to \
  $dmz_net keep state
  block in log quick on $dmz_if from $dmz_net to $internal_net
  # let anything in/out to/of the dmz interface
  pass in quick on $dmz_if all
  pass out quick on $dmz_if all
in this example, the dmz interface is  denied  access  to  the  internal
network _and_ there is no "filtering" on the internal  interface.  maybe
you can use this concept on your PF web interface.
Saad Kadhi -- [[email protected]] [[email protected]]
[pgp keyid: 35592A6D http://pgp.mit.edu]
[pgp fingerprint: BF7D D73E 1FCF 4B4F AF63  65EB 34F1 DBBF 3559 2A6D]
Can't fight the Systemagic
Uber tragic