Fortigate Konfiguration als Web-Server Reverse Proxy

Im folgenden Beitrag möchte ich eine Fortigate als HTTPS-Reverse-Proxy für meinen HTTP-Web-Server am DMZ-Interface konfigurieren (HTTPS/HTTP Reverse Proxy). Ausgangsbasis für die Konfiguration ist FortiOS 6.0 und der Web-Server soll mit folgenden Einstellungen abgesichert werden:

  • SSL/TLS-Version: ausschließlich TLS 1.2 ist erlaubt (erst möglich ab FortiOS 5.4)
  • Cipher Groups: ausschließlich 2 sichere Cipher Groups sind erlaubt
  • HSTS (HTTP Strict Transport Security): aktiviert
  • SSL-Offloading: Client <-> Fortigate (half) – Fortigate zu Server ist unverschlüsselt, daher kein SSL
Virtual Server erstellen und absichern

Im ersten Schritt wird der Virtual Server erstellt und mit den oben definierten Einstellungen gehärtet.

config firewall vip
  edit <vServer-Name>
    set name <vServer-Name>
    set comment "vServer HTTPS -> HTTP Reverse Proxy"
    set type server-load-balance
    set server-type https
    set extinf wan1
    set extip <vServer-IP>
    set extport 443
    set ldb-method static
    set persistence none
    set ssl-mode half
    set ssl-certificate <Certificate-Name>
    config realservers
      edit 1
        set ip <Internal-Webserver-IP>
        set port 80
        set status active
      next
    end
# TLS 1.2 erzwingen
    set ssl-max-version tls-1.2
    set ssl-min-version tls-1.2
# sichere Ciphers konfigurieren
    set ssl-server-algorithm custom
    config ssl-server-cipher-suites 
      edit 1
        set cipher TLS-ECDHE-ECDSA-WITH-CHACHA20-POLY1305-SHA256
      next
      edit 2
        set cipher TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384
      next
    end
    set ssl-dh-bits 2048
    set ssl-client-renegotiation secure
    set ssl-client-fallback enable
# HSTS konfigurieren; verfügbar ab FortiOS 5.6
    set ssl-hsts enable
    set ssl-hsts-age 31536000
    set ssl-hsts-include-subdomains enable 
  next
end

Hinweis zur <vServer-IP>:
Die Angabe entspricht entweder einer einzelnen öffentlichen IP-Adresse am WAN Interface der Fortigate bei statischer IP-Adressvergabe oder 0.0.0.0 bei dynamischer IP-Adressvergabe z.B. PPPoE Anschlüssen .

Firewall Policy

Als Nächstes ist eine Inbound Firewall Policy für den Virtual Server zu konfigurieren. Im folgenden Beispiel konfiguriere ich die Minimal-Einstellungen. UTM Features wie IPS, AV, etc. könnten (und sollten) natürlich zusätzlich konfiguriert werden, sofern die UTM-Features lizenziert sind.

config firewall policy
  edit <n>
    set srvintf wan1
    set srcaddr all
    set dstintf dmz
    set dstaddr <vServer-Name>
    set schedule always
    set service HTTP
  next
end
Prüfen der Konfiguration
config firewall vip
  edit <vServer-Name>
    get
  next
end
Exkurs: HTTPS/HTTPS Reverse Proxy

Im Regelfall sollte natürlich auch die Kommunikation von der Fortigate zum Backend-Server verschlüsselt sein. Hier die geänderten/hinzugefügten Konfigurationszeilen für Full-SSL-Offloading. Wichtig ist, dass dem Zertifikat des Backend-Servers auf der Fortigate vertraut wird, da das im Virtual Server angegebene Zertifikat nur für die Kommunikation zum Client präsentiert wird und nicht zur Kommunikation zum Backend-Server. Ist das Zertifikat des Backend-Servers z.B. von einer internen PKI signiert, muss das CA Zertifikat auf der Fortigate in den Local CA Certificates (System->Certificates) vorhanden sein, damit eine verschlüsselte Kommunikation erfolgen kann.

config firewall vip
  edit <vServer-Name>
    set ssl-mode full
    config realservers
      edit 1
         set port 443
      next
    end
    set ssl-server-max-version tls-1.2
    set ssl-server-min-version tls-1.2
  next
end
config firewall policy
  edit <n>
    set service HTTPS
  next
end
Einschränkungen

Leider gibt es auch einige Funktionen, die mit der FortiGate allein nicht funktionieren und den Einsatz einer FortiWeb erforderlich machen.

Die größte Einschränkung, die für einen Reverse Proxy jedoch eigentlich recht wichtig sein kann, ist die Authentifizierung. Es funktioniert aktuell nicht, dass die FortiGate die Authentifizierung übernimmt, d.h. trotz Reverse Proxy muss der Webservice die Authentifizierung übernehmen und trotz Reverse Proxy werden daher erst mal alle Anfragen an den Webservice weitergeleitet. Möchte man eine Authentifizierung an der Fortigate, muss man auf ein SSL-VPN Web-Portal ausweichen.

Quellen:
https://blog.paessler.com/using-a-fortinet-fortigate-as-reverse-proxy-for-prtg-all-the-config-you-need

6 Antworten

  1. Ralf Ebert sagt:

    Ist es immer noch so, dass die FortiGate die Authentifizierung nicht übernehmen kann ? Bzw. ist das Modell oder OS abhängig ?

    • Hallo Ralf. Zumindest mit meiner Fortigate 61 mit FortiOS 6.2 ist es immer noch so. Dafür möchte Fortinet sein Produkt FortiWeb eingesetzt sehen. Gruß. Andreas

      • Alex sagt:

        Warum sollte die FortiGate die Authentifizierung nicht übernehmen können?

        In Authentification Rules einfach ein Scheme und eine Rule anlegen, einer Gruppe zuweisen und der Proxy policy als Destination eine User Gruppe mitgeben.

        • Hallo Alex
          Danke für deinen Kommentar. Also ich hab’s einfach nicht direkt an der Fortigate hinbekommen.
          Ich möchte z.B. einen Webserver hinter der Fortigate betreiben und habe dazu die Konfiguration wie oben beschrieben angelegt. Als Anmeldung möchte ich eine Basic Authentication Anmeldemaske erhalten.
          Folgendes habe ich ausprobiert:
          Policy & Objects -> Authentication Rules -> New Authentication Scheme

          • Name: BasicAuth Scheme
          • Method: Basic
          • User database: Other -> hier habe ich dann z.B. meinen LDAP Server ausgewählt

          Policy & Objects -> Authentication Rules -> New Authentication Rule

          • Name: BasicAuth Rule
          • Source address: all
          • Protocol: HTTP
          • Authentication scheme: BasicAuth Scheme
          • IP-based Authentication: Enabled
          • SSO Authentication Scheme: Off

          Danach habe ich eine Gruppe mit Usern des LDAP-Servers angelegt und der Policy in den Source Parameter hinzugefügt.
          Leider bewirkt das nichts. Die Verbindung wird ohne Anmeldung aufgebaut.
          Vielleicht kannst du ja kurz detaillierter schreiben wie das geht oder wo mein Fehler liegt. Wo definiert man, welches Authentication Scheme und welche Rule überhaupt verwendet wird?
          Gruß
          Andreas

  2. Sven sagt:

    Naja, mit einem Reverse Proxy im eigentlichen Sinne hat das nix zu tun, das ist schlicht ein DNAT mit Port Forwarding, bei dem die Cyphers und TLS Versionen vorgegeben werden. Leider ist in der Policy auch kein IPS Profil verlinkt, insofern gibt es keinerlei Schutz gegen DDoS o.ä. Vulnerabilities. Eine Authentifizierung kann nicht gehen, da hierfür der lokale Proxy als Authentication Source dienen müsste, das tut er aber nur für die „Forward“ (Explizit) Proxy Funktion.

    • Hallo Sven
      Danke für deinen Kommentar. Bisschen mehr Möglichkeiten als DNAT hat man hier schon, aber richtig, das ist kein vollwertiger Reverse Proxy, dafür gibt’s ja die FortiWeb Appliances. Bzgl. IPS Profil: natürlich kann man eins in die Policy einbinden, ich hab das nur hier nicht gemacht, weil das nicht das Thema ist. Aber geht natürlich.
      Gruß
      Andreas

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.