Creating a DMZ with Two Threat Defenders

1. Objective

The following use case illustrates how two Threat Defenders can be set up to create a demilitarized zone (DMZ).

This use case assumes a medium-sized example company with headquarters and several subsidiaries and employees in the field, such as travelling sales people. The company hosts its database servers at the headquarters. The subsidiaries and field employees need to remotely access the database servers at the headquarters.

To protect the database servers from external threats, a DMZ is created using two Threat Defenders. The DMZ separates the internal network from publicly available services.

Remote access is granted via VPN. The outer Threat Defender manages VPN access from the Internet to the DMZ; the inner Threat Defender manages the connections between the DMZ and the database servers.

Note that this example only shows how Threat Defender can be configured to create a DMZ. It does not include behavior-based traffic management. This has to be set up separately.

2. Setting up VPN Access to the DMZ

The outer Threat Defender manages VPN access to the DMZ.

VPN access to DMZ
Fig. 1: Threat Defender handles VPN access to the DMZ.

In this scenario, Threat Defender replaces the network switch. This means the various subnets have to be connected to Threat Defender with separate physical wiring. Otherwise, Threat Defender will not be able to see the traffic inside the DMZ.

Threat Defender has to be configured in a way that only the required VPN protocols are directly connected to the VPN server (VPN concentrator). The VPN server then authenticates the VPN clients and assigns them an IP address in the VPN clients subnet.

The network is segmented using static and dynamic network objects. The VPN, mail and application servers are assigned to separate static network objects. The incoming VPN clients are automatically assigned to a dynamic network object.

A dedicated rule set manages the network traffic. The clients stored in the dynamic network object may access the mail and application servers in the DMZ. Only the servers handle the data. This way, no external threats can enter the internal network.

2.1. Creating the Static Network Objects

Create static network objects to segment the network. The VPN, mail and application servers are all assigned to separate static network objects. This adds transparency and allows for detailed analyses of the network traffic under Analytics.

The following table shows the required settings of the static network objects.

The table contains example IP addresses by way of illustration.

Name Network IP Addresses
Application Servers Internal 10.10.20.0/27
Mail Servers Internal 10.10.30.0/29
VPN Server Internal 10.10.10.0/29
VPN Clients Internal 192.168.0.0/20

For detailed instructions on how to create a static network object, refer to Creating Static Network Objects.

2.2. Creating a Dynamic Network Object

Create a dynamic network object that stores the IP and MAC addresses of the VPN clients that connect to the DMZ. This way, Threat Defender creates a dedicated VPN network with a limited retention time. Due to the timeout, inactive connections are automatically terminated after the timeout expires.

Storing both IP and MAC addresses allows for detailed analyses of who connects to the network using the Threat Defender analytics feature.

The following table shows the required settings of the dynamic network object:

Name Network Size Timeout
VPN Clients Internal 4000 600

For detailed instructions on how to create a global dynamic network object, refer to Creating Dynamic Network Objects.

2.3. Creating the Rule Set

To configure Threat Defender to handle VPN access to the DMZ, you need to set up the following rule set comprising six global rules. The Log action is enabled in all rules. This provides valuable information on the network traffic that can be analyzed in the Analytics section of Threat Defender.

  • Rule 1 allows incoming VPN connections to the VPN server.
  • Rule 2 adds the IP and MAC addresses of all VPN clients to the VPN Clients dynamic network object.
  • Rule 3 grants the VPN clients access to DNS servers. Note that the DNS Servers static network object is preset on Threat Defender. If necessary, adapt it to your requirements.
  • Rule 4 allows the VPN clients to access the mail servers.
  • Rule 5 allows the VPN clients to access the application servers.
  • Rule 6 rejects all remaining traffic.
Rule Source Destination Condition Actions
1. External VPN Server Classification
Included Applications/Protocols: OpenVPN
Log: Notice
Final Action: Allow Traffic and Skip to Next Scenario
2. VPN Clients Any Log: Notice
Dynamic Network Object
Operation: Add
Host Identifier: Both
Who: Client
Target Dynamic Network Object: VPN Clients
3. VPN Clients DNS Servers Log: Notice
Final Action: Allow Traffic and Skip to Next Scenario
4. VPN Clients Mail Servers Classification
Included Applications/Protocols: IMAP, SMTP, POP
Log: Notice
Final Action: Allow Traffic and Skip to Next Scenario
5. VPN Clients Application Servers Classification
Included Applications/Protocols: HTTP
Log: Notice
Final Action: Allow Traffic and Skip to Next Scenario
6. Any Any Log: Medium
Final Action: Drop Traffic and Stop Processing

For detailed instructions on how to create a rule, refer to Creating Global Rules.

Click the APPLY CHANGES button in the header to activate your configuration changes.

With this rule set, Threat Defender allows VPN connections to access the DMZ and rejects all other traffic.

3. Handling Traffic between the DMZ and the Internal Network

The inner Threat Defender is located between the DMZ with the VPN, mail and application servers and the internal network with the database servers. It isolates the two network parts from each other and handles communication between them.

DMZ and internal network
Fig. 2: Threat Defender handles traffic between the DMZ and the internal network.

3.1. Creating the Static Network Objects

Create a static network object for the application servers in the DMZ and another one for the database servers in the internal network.

The following table shows the required settings of the static network objects.

The table contains example IP addresses by way of illustration.

Name Network IP Addresses
Application Servers Internal 10.10.20.0/27
Database Servers Internal 10.10.100.0/26

For detailed instructions on how to create a static network object, refer to Creating Static Network Objects.

3.2. Creating the Rule

Create a rule that allows the application servers to access the database servers for database queries. This example assumes that the database servers run a SQL database.

Rule Source Destination Condition Actions
1. Application Servers Database Servers Classification
Included Applications/Protocols: MySQL
Log: Notice
Final Action: Allow Traffic and Skip to Next Scenario

With this rule, the application servers can contact the database servers which can answer their queries. However the database servers cannot actively contact the DMZ.

4. Result

Two Threat Defenders create a DMZ that contains the VPN, mail and application servers. The database servers of the company are located behind the DMZ. This grants them a second level of protection from external threats.

If suitable policies for behavior-based traffic management are implemented, Threat Defender can detect threats and react to them. These policies have to be configured in addition to the rule sets described above.

results matching ""

    No results matching ""