View Single Post
  #2   (View Single Post)  
Old 1st November 2011
J65nko J65nko is offline
Administrator
 
Join Date: May 2008
Location: Budel - the Netherlands
Posts: 4,131
Default

In your case you have to deal with the following packet flows ( I hope I didn't miss any )
  1. EXTERNAL INTERFACE
    1. Outgoing traffic
      1. initiated by the internal LAN( entered on the internal interface)
      2. initiated by the DMZ servers (e.g. DNS requests by the mail server)
      3. initiated by the firewall box itself (e.g. troubleshooting by admin)
      4. answer packets issued by the DMZ servers to clients on the internet
    2. Incoming traffic

      1. answer packets for connections initiated by the internal LAN
      2. answer packets for the DMZ servers (e.g. DNS answers for the mail server)
      3. connections initiated by clients on the internet to the DMZ servers
  2. INTERNAL INTERFACE
    1. Outgoing traffic
      1. answer packets entering the external interfaces destined for internal LAN
      2. answer packets entering the DMZ interface, destined for connections initiated by internal LAN
    2. Incoming traffic
      1. packets initiated by internal LAN clients with destination internet,
      2. packets initiated by internal LAN clients with destination DMZ
  3. DMZ INTERFACE
    1. Outgoing traffic
      1. packets entered on external interface with destination DMZ server
        (connections initated by external clients on the Internet)
        (connections initiated by DMZ server (e.g. DNS anwers for mail server)
      2. packets entered on internal interface with destination DMZ server
        (connections initiated by clients on the internal LAN)
    2. Incoming traffic
      1. answer packets for external clients on the Internet
      2. answer packets for internal lan clients

The dangereous ones are in red, and actually should not be used in a "real DMZ" configuration.

As far as I understand the Diginotar debacle, this is how they got 'cracked". The internal administrative machine connected to the Diginotar DMZ servers was compromised, and used as base to generate the "fake" SSL certificates.

Back to your issue

I would advise to use pf's tags to make it easier to handle the flows.
An example for DNS requests, or connections initatiated by a DMZ mail server

Code:
# DMZ interface
# -- in
pass in quick on DMZ_if from DMZ-servers to !(INT_lan:network, EXT_if) tag OUT_OK

# EXTERNAL INTERFACE
# --out
pass out quick on EXT_if tagged OUT_OK
(Untested because I have to walk the dog ), but you get the idea.

In a similar way you could tag the traffic from the internal LAN to the internet with the same OUT_OK tag, and the last rule would "automagically" deal with that traffic too. A great way to simplify your ruleset.
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump

Last edited by J65nko; 1st November 2011 at 10:27 PM.
Reply With Quote