Best Practice question - DMZ vs port redirection?
-
I'm looking for some general advice on firewall configuration - more along the lines of "Do it this way" rather than a detailed "how to" list.
I have pfSense running with the WAN side connected to the ISP and some reasonably strict inbound rules restricting inbound access to the LAN - outbound is also filtered but with a "pass and log" rule at the bottom of the rule list.
I also have a mail server, DNS server and FTP running on OPT1 and physically separate from the LAN side (a DMZ configuration). This setup has worked well for some years without problems but the inbound access to these OPT1 machines is "permit all" which I'm not happy about.
I'm about to change ISPs (moving from cable to DSL) which is going to mean rewriting a lot of the pfSense rules. Would this be a good time to change my network configuration and move the mail server inside the firewall with the required WAN side ports redirected to the mail server and get rid of the OPT1 interface?
I'm thinking is that this would mean all internal IMAP traffic will be LAN side and never have to go through the firewall - thus internal mail server access speed should improve. The FTP and DNS services would be outsourced.
Or should I stick with the OPT1 DMZ, maintain physical isolation and tighten up the DMZ access policy?
Thanks in advance.
-
Having a separate "DMZ" where you put externally accessible servers is still considered good practice. However, you could (should) have strict outbound rules for your OPT1 / DMZ segment as well (e.g. should your mail-server be allowed to open a connection port 6667 to some IRC server?), in fact stricter fw rules than your LAN segment does.
BTW I think a lot of confusion about DMZ in recent years is due to that fact that many consumer-level routers have hijacked the term DMZ to actually mean "exposed host".
You don't mention numbers of users, but generally speaking IMAP & DNS services shouldn't put a prohibitively high traffic load on your firewall. Had it been a NAS however, I'd try to put it inside the LAN instead of the DMZ.
-
The way I was taught and understand it is as follows. Services that have no business talking to the internal lan must sit on the dmz. Services that have need to have access to the internal net, but also need outside net access should be restricted at a by host basis on an isolated segment. Services that require unrestricted access to both internal and external nets should be treated as untrusted, and heavily monitored, audited, and patched. Strictly internal services must never have a route to outside nets.
In your case. If your mailserver is strictly internal, it should live on your internal net with no gateway that routes externaly, FTP and Web should be on a strictly outward facing segment. If your mailserver needs to connect to the external net, then you need to have a strict rule so that the only traffic allowed is the external MTA.
This is as far as I know the setup you need to follow best practice. -
Having a separate "DMZ" where you put externally accessible servers is still considered good practice. However, you could (should) have strict outbound rules for your OPT1 / DMZ segment as well (e.g. should your mail-server be allowed to open a connection port 6667 to some IRC server?), in fact stricter fw rules than your LAN segment does.
Thanks, that's helpful. I agree, "Kill them all, the rules know their own" is how I have the LAN rules set. That's been a bit of a problem on the OPT1 segment because the mail server (Alt-N MDaemon) supports some anti-spam services that don't document their port usage - I spent a few weeks with deny all rules in place and adding new exceptions everyday based on the logs before I decided to just wing it. But that needs to change.
I don't have a lot of users (~20 tops) and we're recently moved all our web hosting outside. The IMAP load can hit 30Mb/s from a single user when a new folder is opened on the mail server and we have a lot of archived folders - so IMAP seems to be the bottleneck on the LAN.