Protect a web server with DMZ

Facebooktwittergoogle_plusredditpinterestlinkedinFacebooktwittergoogle_plusredditpinterestlinkedin

In this recipe, you will protect a web server by connecting it to your FortiGate’s DMZ network. A DMZ network (from the term ‘demilitarized zone’ is a secure network, protected by the FortiGate, that only grants access if it has been explicitly allowed. In this example the DMZ network allows access to a web server using different addresses for internal and external users, while preventing access from the web server to the internal network if the web server is compromised.

A WAN-to-DMZ security policy with a virtual IP (VIP) hides the DMZ address of the web server, allowing external users to access the web server using a public IP address (in this example., 172.20.120.22). An internal to DMZ security policy with NAT turned off allows internal users to access the web server using its DMZ address (10.10.10.22). Both of these security policies only allow access to the web server using HTTP and HTTPS. No other access is allowed.

Find this recipe for other FortiOS versions
5.2 | 5.4

1. Configuring the FortiGate’s DMZ interface

Go to System > Network > Interfaces. Edit the DMZ interface.

Using the DMZ interface is recommended but not required.

For enhanced security, disable all Administrative Access options.

 

2. Creating virtual IPs (VIPs)

Go to Policy & Objects > Objects > Virtual IPs. Create two virtual IPs: one for HTTP access and one for HTTPS access.

Each virtual IP has the same address, mapping from the public-facing interface to the DMZ interface. The difference is the port for each traffic type: port 80 for HTTP and port 443 for HTTPS.

In this example the Internet address of the web server is 172.20.120.22.

 

 

3. Creating security policies

Go to Policy & Objects > Policy > IPv4. Create a security policy to allow HTTP and HTTPS traffic from the Internet to the DMZ interface and the web server.

Do not enable NAT.

You can also enable logging for all sessions to make it easier to test the configuration.

 

Create a second security policy to allow HTTP and HTTPS traffic from the internal network to the DMZ interface and the web server.

Adding this policy allows traffic to pass directly from the internal interface to the DMZ interface.

Do not enable NAT.

You can also enable logging for all sessions to make it easier to test the configuration.

 

4. Results

Internet users and internal network users can access the web server by browsing to the web server’s Internet address (in this example, http://172.20.120.22 and https://172.20.120.22). Internal users can also access the web server using its DMZ address (in this example, http://10.10.10.22 and https://10.10.10.22).

Since only HTTP and HTTPS are enabled, the web server is not accessible using other protocols (such as FTP) and you also cannot ping the web server from the Internet or from the internal network.

Go to Policy & Objects > Monitor > Policy Monitor.

Use the policy monitor to verify that traffic from the Internet and from the internal network is allowed to access the web server. This verifies that the policies are configured correctly.

 

Go to Log & Report > Traffic Log > Forward Traffic.

The traffic log shows sessions from the internal network and from the Internet accessing the web server on the DMZ network.

 

For further reading, check out Firewall in the FortiOS 5.2 Handbook.

Bill Dickie

Our Fearless Documentation Leader at Fortinet
After completing a science degree at the University of Waterloo, Bill began his professional life teaching college chemistry in Corner Brook, Newfoundland and fell into technical writing after moving to Ottawa in the mid '80s. Tech writing stints at all sorts of companies finally led to joining Fortinet to write the first FortiGate-300 Administration Guide.

Latest posts by Bill Dickie (see all)

  • Was this helpful?
  • Yes   No
For this recipe to work the web server must be properly configured with its default route pointing at the FortiGate’s DMZ network.
  • SD

    Hi I am a little confused. You state the following: “An internal to DMZ security policy with NAT turned off allows internal users to access the web server using its DMZ address (10.10.10.22)”.

    However the DMZ server network in step 1 is 10.10.10.1/24. Is this a typo?

    • bdickie

      The address in step 1 (10.10.10.1/24) is the IP address of the FortiGate’s DMZ interface (not the DMZ network). The DMZ interface is just one of the devices on the DMZ network as is the web server. Let me know if you need more information.

  • SA

    Hi, I am curious if the DMZ port can be used with IPSEC tunnels that are connected over the WAN ports on a device like a 200D? Is that just a question of which internal networks can be routed in and out through the tunnel? We are using these to establish site to site VPN connectivity, between remote locations, not as border firewalls. The DMZ use concept could still apply here but none of the networks connected to the Fortinet devices have access to anything outside the tunnels.

    • bdickie

      There is no limitation that I am aware of that would prevent what you are trying to do. As long as the routing and addressing is set up correctly.

  • paradoxxxical

    Is it mandatory to put the webserver in the DMZ? Currently our mail server sends and receives mail through an external filtering and archiving service, but it’s not in the DMZ.

    • bdickie

      Putting your mail server or any server on a DMZ network is just a convention.

  • Najeeb Mohammad Hajji

    Thanks for the info
    is there any way to control virtual directories access using Fortigate 100D ?, all docs are referring to Fortiweb products.

    • Craig Poile

      Hi Najeeb,

      I work on the FortiWeb docs. I’m not sure which FortiWeb feature your are describing. Can you please re-phrase it, and point to the FortiWeb information you are referring to? Then we can figure out whether your FortiGate product has the capability.

      Sincerely,

      Craig

      • Najeeb Mohammad Hajji

        Hi Craig
        During web server access policy creation, is there anyway to control web server virtual directories access using fortiweb such as MS TMG 2010 (attached).
        Not only ports access but paths, for example allow access to virtaul directory /owa/* only. or /rpc/*

        • Craig Poile

          Hi Najeeb,

          I put your question to one of our FortiWeb system engineers, and this is his reply:

          Yes! FortiWeb provides this type of protection with URL restriction rules, which you can apply using either rules that control access based on URL, or an advanced access control rules, which control access based on attack signatures or other criteria.

          To restrict access to specific URL paths, most admins create URL access rules that allow and deny actions based on one or more URL paths. When you use access rules in a protection policy, FortiWeb applies the top-most rule first, so the order of execution is important. Using this approach, within one policy, you can create one rule that allows users access to /OWA/* and a second rule that denies access to all other URL paths.

          For more information, see the following FortiWeb online help topic: http://help.fortinet.com/fweb/554/index.htm#cshid=url_access_rule_add

          Alternatively, you can use an advanced access control rule to define URL restriction rules with multiple match conditions, including ones that match attack signatures.

          For more information, see the following FortiWeb online help topic:
          http://help.fortinet.com/fweb/554/index.htm#cshid=advanced_access_rule

          I hope that helps.

          Sincerely,

          Craig

          • Najeeb Mohammad Hajji

            Many Thanks
            This is Cool, you are a champ, i know you are a fortiweb expert, but is this possible within Fortigate 100D (Fortios 5.4).
            All the best.
            Najeeb

          • Victoria Martin

            Hi Najeeb, no, this feature is not available in FortiOS 5.4.

          • Najeeb Mohammad Hajji

            While this is a basic feature on obsolete ISA/TMG!!! i do not understand why it is not shipped with fortigate devices. please escalate this issue to your engineering teams.
            i see this very frustrating.

            kind regards.
            Najeeb

  • bdickie

    I just completed editing and re-testing this recipe with all released versions of FortiOS 5.2. This form of the recipe doesn’t require a HairPin NAT configuration. I decided to keep the external interfaces of the VIPs set to wan1. This recipe would also work if the VIP external interfaces were set to ANY.

  • Robert

    HairPin NAT to access the external IP from internal is described in http://kb.fortinet.com/kb/documentLink.do?externalID=FD36202

    • Victoria Martin

      Hi Robert,

      Thanks for sharing the link!

  • William Yeung

    How this should work if I am also using the wan load balancing feature? I tried to setup with the instruction above (except the policy will say source interface as wan-load-balance), I can’t visit the server with the public IP after the configuration.

    • bdickie

      Thanks for your comment. It turns out that this recipe is out of date and the FortiGate now blocks access to the external IP address of the web server from the internal network. So the only way to access the web server from the internal network is to use the DMZ IP address (through the DMZ to internal policy). This change is independent of the wan load balancing feature. Note to make the VIP work with the wan load balancing feature the VIP interface should be set to any. This is now considered a better practice than selecting a specific interface in the VIP configuration. Updating the recipe is now on my to do list.