Creating a DMZ - pfSense Hangout January 2016
2 likes14,840 views
This document provides guidance on creating a DMZ (demilitarized zone) network on a pfSense firewall. It discusses what a DMZ is, considerations for designing a DMZ like whether to use public or private IP addresses. It also covers steps to set up a DMZ interface on pfSense, configure services and firewall rules to isolate and protect the DMZ network, and considerations for VPN and other network traffic. The overall goal is to add an additional layer of security by housing public servers in a separate DMZ network, isolated from internal private networks.
Creating a DMZ - pfSense Hangout January 2016
- 1. Creating a DMZ January 2016 Hangout Jim Pingle
- 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)
- 17. Conclusion ● Questions? ● Ideas for hangout topics? Post on forum, comment on the blog posts, Reddit, etc