Hardware firewalls are the cornerstone of network security for almost all TCP/IP networks. Whether it’s small business networks or large enterprise environments, a network firewall provides a primary defense against cybersecurity events targeting corporate infrastructure systems and digital information assets. Modern networks have expanded outside the firewall perimeter, making firewalls more critical than ever. Most corporate networks have an expanded design beyond an internal environment, including intranets on internal network zone, untrusted demilitarized zone (DMZ), and other optional intermediate security zones.
A security zone is a network segment that hosts a group of systems with similar functionality for information protection. In other words, a security zone is usually a layer3 network subnet where several hosts (e.g., servers and workstations) are connected. A layer 3 firewall then controls traffic to and from this specific network by analyzing and allowing traffic using an IP address and port.
Some firewalls work on layer 7 of the OSI model. Layer 7 firewalls control authorized traffic on the application layer, evaluating input sent to various internal services such as a database or a web server. For example, suppose you have an application firewall that protects the database from a public-facing web server. When users send input to the web server, the web server then sends the input to the database. An application firewall analyzes information for malformed input such as cross-site scripting (XSS) or SQL injection (SQLi) and rejects input if malicious activity is detected.
Perimeter Security Zone Segmentation for Enterprise Networks
Every enterprise network has its unique environment, so a security zone network segment will look different from business to business. Each perimeter network topology will only fit some enterprise network environments. In addition, each network has its unique requirements and functionalities so that IT teams can create security infrastructure designs based on your business model, employee activity (e.g., remote employees and on-site employees), and any public-facing applications.
Even with unique requirements, organizations should still follow best practices. A “best practice” approach to implementing a network perimeter offers enhanced security and data protection from common cybersecurity attacks. A general best practice approach is illustrated in the diagram below. Again, the defined network topology is just an example shared in enterprise networks. Still, every organization will have variations from the example design, such as using two firewall devices instead of one or only one DMZ zone instead of two. However, a firewall protects the internal corporate environments from the public internet. In some designs, two firewalls protect the DMZ and internal network from the public internet.
The suggested perimeter network above includes two DMZ (Demilitarized Zones), DMZ1 and DMZ2, and an Internal Zone for authorized users only. The red line arrows indicate the authorized traffic flow from the firewall. Notice that the public internet can only access one DMZ, which is common when corporations host their servers and internal applications available to the public. A DMZ zone is commonly open to the public internet and internally authorized employees, so it’s considered partially secure. However, traffic should never flow directly from the DMZ to the internal network without additional firewalls and security protocols.
Why Have a DMZ Zone?
A DMZ zone is an isolated layer3 subnet on which connected hosts are usually exposed to the public internet to provide services to users such as web applications, email communications, and DNS services. DMZ environments are the most vulnerable to cybersecurity attacks, as these zones take input from the public internet and allow access to services from internet users. Because of the increased cyber risks associated with a DMZ’s infrastructure and services, DMZ security is maximized to limit damage to the internally protected network should one of these servers suffer from a cybersecurity event resulting in a compromise. The strategy contains a compromised server within the DMZ, so internal applications are protected from data exfiltration, malware, ransomware, and eavesdropping.
A DMZ is necessary if an organization hosts any application available on the public-facing internet. Usually, they are reserved for organizations using on-premises services, but a security engineer might set up DMZ in a hybrid cloud environment. Organizations with cloud-hosted services must also set up a protected zone when private cloud applications are hosted on the same network. It often requires professional help and penetration testing for an organization to set up a DMZ and correctly configure the environment with the proper security controls.
Enhance your network security with WebTitan DNS filtering solution. Book a free demo
Book Free Demo
DMZ1 – Publicly Available Applications
This zone hosts the public-facing servers which must be accessible from the Internet. This zone usually hosts services such as Web, Email, DNS, Proxy etc. The firewall should allow traffic from the Internet towards DMZ1 only (see Traffic Line 1 above). Also, only the required TCP/UDP ports must be allowed (such as 80, 443, 25 etc).
DMZ2 – Intermediary Between Internal and External Networks
DMZ2, on the diagram, is an intermediary zone set up to host application servers, database servers, and other services available to both the public internet and internal employees. To protect the internal environment from the public internet, DMZ2 acts as an intermediary between public users. Creating an additional step from the public internet to DMZ2 reduces risks from a compromise and cybersecurity event. For example, a threat might compromise a service on DMZ1, but it still must compromise another security layer before reaching the internal environment.
Some enterprise environments have a public-facing web server and a web-based application dedicated to employee productivity. For example, a web-based customer service application might pull data from a publicly available web application. In this example, the front-end public web server should communicate with a web application server in a separate security zone. The example diagram has a web application in DMZ1 and an employee-accessible web server in DMZ2.
Security experts suggest that a web application sending and receiving data on a database must not be installed on the same physical machine as the database server. Separating physical devices adds a layer of security, requiring cyber-attackers to compromise two separate environments, which reduces risks. The added layer also increases the chance that intrusion protection services will detect anomalous behavior and alert administrators before both machines can be compromised. Mitigating risks is the primary goal for security infrastructure, and no environment is completely protected against all cyber threats.
The above arrangement protects the internal private network since any compromise of the database or application servers via the DMZ1 servers will not result in access to the protected internal network. Network security always works in layers; the two DMZ environments add these layers to the protected internal environment.
In the diagrammed example, the firewall is configured to only allow access to DMZ2 from DMZ1 on authorized ports indicated by the red line labeled “2.” Also, DMZ2 has limited access to and from the internal zone, indicated by the red line “3.” Traffic flow from the internal network to DMZ2 is set for exceptional cases, such as accessing an internal management server, automated backup procedures, or authentication services on an Active Directory server. All these exceptional cases are examples, but an enterprise environment might have these scenarios or more when firewalls are configured between DMZ environments.
Internal Security Zone
This zone usually hosts internal user workstations and other critical servers such as file servers, Active Directory servers, internal databases, specialized applications (ERP, accounting software), etc. The firewall must not allow direct access from the internet to this Internal network. Moreover, outgoing Web traffic from users in this network can use an HTTP Proxy server (see Traffic Line 4) located in DMZ1 to access the internet. Companies can implement countless network perimeter topologies to facilitate their business needs. The discussion above suggests a solid firewall zone segmentation to achieve strong network security in an enterprise environment.
Use this, and it should ensure you have solid network security.
A Few Other Firewall Configuration Best Practices
The example diagram won’t represent every enterprise network, but it means a robust network security environment. Here are a few best practices you can incorporate into your firewall configurations and infrastructure design:
- Keep audit logs: Logs are necessary for investigations and analysts to detect suspicious behavior. Keep logs based on your retention plan to support incident response after a cyber event.
- Default deny: It’s better to allow traffic rather than default allow all traffic except on specific ports. Set firewalls to allow only traffic necessary for business services.
- Label everything: Firewalls allow administrators to label rules, and labeling helps other administrators understand traffic flow. Labeling rules avoid any mistakes in configurations that could be detrimental to the security of your environment.
- Secure administrator accounts: Use strong passwords on accounts with permission to change firewall settings and rotate passwords and keys regularly to reduce the window of opportunity during an account compromise.
- Always test configurations: Before deploying a firewall to production, test settings and ensure traffic flow is as expected.
- Update firmware: Security patches are essential to the security of your environment, and developers deploy firmware updates to address specific security vulnerabilities. By keeping firewalls updated, patches known vulnerabilities that could threaten the integrity of your entire environment.
- Regularly audit firewall configurations: Changes happen even after testing a firewall before deployment to production. Administrators should devise a plan to periodically audit firewall settings to ensure that no new changes alter the security of your network environment.
- Configure firewalls using the least privilege principle: The least privilege principle says that users should only have access to data necessary to perform their job function. Firewall configurations should follow this strategy to avoid an overly permissive traffic flow, which could lead to an unexpected system compromise.
- Use a change management plan: Firewall changes affect traffic flow, so they can negatively impact security, network availability, and integrity. Design a change management plan to determine the best time of the day to deploy changes and warn users that the change may impact the availability of applications.
- Have a rollback plan: If changes or a firewall negatively impact network availability after deployment, have a rollback plan ready to return the network to its initial state.
- Automate repeatable tasks: Administrators using automation are much less likely to make mistakes, so automate repeatable tasks when you can.
Read TitanHQs Complete Network Security Checklist
Are you an IT professional who wants to protect your internal data and network environment?
Talk to a security specialist at TitanHQ for help or email us at firstname.lastname@example.org with any questions.
Enhance your network security with WebTitan DNS filtering solution. Book a free demo
Book Free Demo