2. Creating a DMZ
● Project News
● What is a DMZ?
● DMZ Diagram
● Designing the DMZ
● Protecting Servers
● Preparing for the DMZ
● Creating the DMZ
Interface
● Services for the DMZ
● Firewall Aliases
● NAT Considerations
● Firewall Rules for the
DMZ
● Firewall Rules for LANs
● VPN Concerns
● Q&A
3. Project News
● 2.2.6 is out
● 2.3 is now BETA!
– Release timeline will roughly parallel FreeBSD
10.3-RELEASE
– Snapshots at https://snapshots.pfsense.org/
– Most popular packages have been
converted/updated for Bootstrap
– Less than 50 open new bugs to go
● Keep an eye on the blog
4. What is a DMZ?
● Co-opted military term meaning Demilitarized Zone
● Used to house public services, away from sensitive internal systems
● It is considered LESS secure than LANs or internal networks
● It is considered MORE secure than the Internet at-large
● DMZ is protected from the LAN(s), LAN(s) protected from DMZ
● Must be on a separate layer 2, not just a separate subnet
● If a server is compromised in a properly isolated DMZ, the LAN is not at significant
risk
● Examples of items in the DMZ: Web, E-Mail, PBX, Proxy, etc
● Can utilize separate firewalls, but more often is an additional interface
● SOHO gear uses the term “DMZ” incorrectly, typically they mean 1:1 NAT on the
WAN IP address to an internal host, that is not an actual DMZ in the correct sense
and it is not secure
6. Designing the DMZ
●
Public IP addresses or private IP addresses?
– Neither is inherently more secure, both can be made insecure by rules
– Public:
●
Less overhead and headaches!
●
Easier routing and DNS
●
No need for port forwards, 1:1 NAT, or NAT reflection
●
No need for outbound NAT for the subnet
●
Firewall rules only
●
Requires a routed subnet from ISP, different from the WAN subnet
●
Some services such as a PBX do better without NAT involved
– Private:
●
Will still need outbound NAT
●
Will need port forwards, 1:1 NAT, or other means of forwarding in traffic (e.g. proxy or load balancer)
●
More complicated when allowing traffic between LAN and DMZ (NAT reflection or split DNS)
●
Will need to pick a private non-overlapping subnet, preferably one that summarizes w/LAN
●
Can work using VIPs in the WAN subnet, or depending on the services, just the WAN IP address
●
Separate VLAN or switch?
– Separate physical switches are more secure
– VLAN on the switches, vmware vswitch, etc
●
How many separate DMZ interfaces will there be?
7. Protecting Servers
● The firewall can only protect traffic between networks
● Servers also need protection from other servers
● A few tactics are possible:
– Host-based firewalls on the servers themselves
– Multiple DMZ interfaces (web, client proxy, mail, VoIP, etc)
● DB servers should be in an even more secure style DMZ and
monitored, or isolated behind another system
– Service config, limit # of listening daemons
– Switch port isolation
● Only viable if the servers do not need to reach each other
8. Preparing for the DMZ
● Create isolated L2 (switch or VLAN)
● Prepare the physical NIC or interface for use by pfSense
– Install a NIC if possible or necessary
– Add VLAN tag if VLANs are required
● Do not multi-home servers in DMZ and LAN!
– Servers should not have NICs in both networks
– Weakens security
– Defeats the point of the DMZ, if the server is compromised it
has access to both networks
– Creates asymmetric routing problems
9. Creating the DMZ Interface
● In pfSense...
● Interfaces > (assign)
● Choose the interface
● Click + to add it as an OPT interface
● It will show in the list, note its name
● Interfaces > OPTx
● Check Enable
● Give it a name (e.g. DMZ or DMZ_Web)
● Select and configure IPv4 and IPv6 addresses chosen earlier
● Save, Apply
10. Services for the DMZ
● Optionally enable DHCP Server
– Servers are usually static, but you could use static
mappings or use DHCP for temporary access while
bringing up new systems
– Services > DHCP Server, DMZ tab
– Enable, set a range, save, etc.
● If other local services had strict bindings (e.g.
DNS Resolver, NTP), adjust accordingly
11. Aliases to Make Things Easier
● Firewall > Aliases
● Make aliases for servers and groups of ports for
services
– Example: web_servers alias with IP addresses of servers
– Example: web_ports alias with 80 and 443
– Similar for mail, db, whatever is needed and requires
public exposure.
● Make an RFC1918 alias with private networks
(10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
12. NAT Considerations
● Private IP Addresses on DMZ:
– Add port forwards or 1:1 NAT as needed to direct traffic inbound
– Port forwards get rules automatically
– 1:1 NAT needs manual firewall rules, use the private IP address as target
– If LAN clients must contact servers by NAME, consider split DNS (local DNS
resolves to local IP address of the server)
– If split DNS is not possible and LAN must reach the DMZ, enable NAT reflection
(System > Advanced, Networking tab)
● Public IP Addresses on DMZ:
– Switch to Hybrid Outbound NAT and add a rule to “not” NAT the public subnet
source
– OR –
– Switch to Manual Outbound NAT and remove rules referencing the subnet
13. Firewall Rules for the DMZ
● Rules on WAN to allow access to public services inbound
● DMZ hosts should NOT have access to the LAN unless
absolutely necessary
– If unavoidable, it should be heavily restricted
● It is usually OK to allow access from the DMZ to the
Internet, but it could also be restricted
– Example: To allow OS/software updates, remote queries, active
FTP from remote clients, etc
● Utilize the RFC1918 alias to prevent the servers from
reaching local private networks and VPN networks
14. Firewall Rules for LANs
● The LAN should not have unrestricted access to the DMZ either, but
it is not as important as restrictions in the other direction
– Ideally, only allow access to the same IP addresses and ports accessible
from the WAN, though managing rules for that case can be complex
– Consider rougue or compromised clients on the LAN and what they could do
to servers in the DMZ (e.g. virus infected clients)
● Unsecure LANs, such as guest networks, should be more strictly
isolated from the DMZ
● With Multi-WAN, add rules to pass traffic to DMZ without a gateway
set
● Don't rely on policy routing to isolate, it can be OK at times but not a
perfect means of security.
15. VPN Concerns
● Consider what systems must communicate across the VPN
● If the servers must reach remote VPN systems, be strict
with rules passing the traffic out that direction
– Could be DR replication, backups, etc
● If remote VPN systems must reach servers in the DMZ, use
rules on the VPN interface tab(s) appropriate for the role of
the VPN
– Example: A remote access admin VPN for ops employees should
have more access than a site-to-site VPN with untrusted clients
16. Expand from here...
● Add more servers, ports, additional DMZs,
additional LANs, and so on
● Keep the rule styles similar, isolating each
segment from all the others
● Interface groups can help with rules, but be
careful of rule ordering when using them.
● Consider monitoring DMZ traffic with an IDS
(Suricata, Snort, etc)