Practicing Proper DMZ and Firewall Hygiene

Author: Sai Kiran Uppu, Operational Security Researcher

Introduction

The “demilitarized zone” (DMZ) refers to a logical network section through which internal resources are selectively exposed to the open Internet while keeping the most sensitive systems behind a firewall, helping to reduce overall attack surface. A properly protected DMZ is essential to enabling secure access to business applications and services by your employees, partners, and customers.

While modern public cloud infrastructure providers offer granular security controls such as Security Groups in AWS, network security groups (NSG) in Azure, and VPC Firewall rules in Google Cloud, enterprise networks mostly rely upon traditional “Allow or Deny” policies.

The main objective of my research is to develop practices that can improve the overall security posture of DMZ configurations and general firewall hygiene. The results of this research can help reduce technical IT debt, identify higher risk rules in a DMZ network, and properly formulate a risk matrix and automated risk remediation strategy.

What to Look For

You can use tools like the Secure Track API to help you understand all current firewall rules so you can look for issues that could increase risk. So, what exactly are you looking to find? Common issues include:

• Unsecured access to Internet over non-SSL protocols like HTTP, FTP and SMTP
• Inconsistent data flow across trust zones
• Access to internal resources from outside world across broad number of IP ranges and ports
• Firewall rules with an “ANY” tag on “Destination,” which opens up that resource completely without any protections
• Connections made to domains that no longer exist, increasing the risk of subdomain takeover
• Static IP addresses in “Destination” fields
• Rules that enable “World” access over SSH
• Old firewall tags
• Improper logging
• Open access to DMZ services from within an internal network

With cloud services, there are additional issues that can present problems. For example, consider an AWS service that was made available to the open internet via the DMZ. In this example, each EC2 instance with a public IP is assigned a CNAME through which one can connect to the EC2 instance. However, a common mistake is configuring static EC2 instance names in the destination tag of firewall rules. This can cause issues if, for example, the EC2 instance was marked for termination and the public IP will be reused. In this case the CNAME would remain the same — possibly exposing resources from unintended EC2 instances.

Determining Risk

As part of our research, I developed the “Risk Factor Classification” table below. Several possible firewall rule violations are shown classified according to high, medium or low severity.

Figure 1 — Risk Factor Classifications

Recommended Best Practices

Based upon my research, here are some recommended best practices for helping to enable proper hygiene for your firewalls and DMZ environment.

Network Configuration:

• Limit internet facing port exposure​ on critical resources in the DMZ networks.
• Limit exposed ports to only required IP addresses and avoid placing wildcards in destination port or host entries.
• Regularly update any public IP ranges in active use.
• Ensure unsecured protocols like FTP and HTTP are limited in use and restricted to specific IP ranges.

Monitoring

• Review static IP entries which are no longer in use regularly and remove the firewall rules associated with them.
• Set up a process for automated/semi-automated firewall rule deletion based on host deletion.
• Regularly review the firewall rule policy with large subnets​ exposed either internally or externally.
• All firewall rules must be enforced with proper logging capabilities.

General Hygiene of the Environment:

• If data flows from untrusted zone to trusted zone, it should be always done over a secure protocol like HTTPS with mandatory 2FA​.
• Old firewall tags should be deleted from the system and corresponding rules should be retired periodically.

Automating Detection of Issues

One of the primary project goals was to develop an automated way to detect security issues in a DMZ on an ongoing basis. Based on this risk classification chart, we implemented an automated pipeline tool leveraging the Secure Track API and other tools which can help us intelligently identify high and medium risk firewall rules matching violation criteria described in our own security policies. This tool is a set of scripts to help with this detection that are currently run on a manual, as-requested basis. We use the output of this tool to help our network security teams get a better view of our current DMZ security posture and fix any issues that are detected. As a next step from this research we will be looking at further automation of these techniques to provide more continuous monitoring.

Conclusion

Practicing good firewall and DMZ hygiene are essential to help protect your critical business applications as usage of cloud services continues to expand. Keeping up with the changes that are often necessary to firewall configurations to support your business requires diligence — and is also a prime candidate for automation, as we attempted to do as part of our research. I hope this guidance is beneficial as a starting blueprint for improving your firewall hygiene.