|
|
| Zeile 41: |
Zeile 41: |
|
| |
|
| == FAQ == | | == FAQ == |
|
| |
| =MUST DELETE in FUTURE=
| |
| == Policy Rule ==
| |
|
| |
| === Gibt es für eine Firewall Policy Rule für FortiOS 5.4 betreffend benutzen Objekten eine Limite (Policy is too big for system)? ===
| |
|
| |
| Ja diese Limite existiert und zwar bei allen FortiOS Versionen. Dies bedeutet: wenn eine Firewall Policy Rule erstellt wird und in dieser Firewall Policy Rule wird zB eine Gruppe benutzt für Objekte und in dieser Gruppe exisiteren eine Vielzahl von Objekten kann es zu Fehlermeldungen kommen wie zB:
| |
|
| |
| "Policy is too big for system"
| |
|
| |
| Dieser Umstand tritt auf wenn zB ein Upgrade durchgeführt wird und nachträglich eine neue Firewall Policy Rule erstellt werden möchte. Die Limite für eine Firewall Policy Rule betreffend enthaltenen Objekte ist die Folgende:
| |
|
| |
| Für FortiOS 5.4.0 oder höher 9000+ Objekte
| |
|
| |
| Der Grund für diese Limite ist realtiv einfach. Eine Firewall Policy Rule wird in den Kernel eines FortiOS geschrieben. In diesem Kernel existieren "memory limits" und diese verhindern das mehr Memory alloziert wird als gesetzt. Wenn dieser Umstand eintritt dh. zB für die Limite von 8000 Objekten (FortiOS 5.2.4 und tiefer) muss die Firewall Policy aufgeteilt werden in zwei Firewall Policy Rules.
| |
|
| |
| === Unter FortiOS 5.4 für eine "Firewall Policy Rule" existiert die Position "Name" um was handelt es sich dabei? ===
| |
|
| |
| Wenn man unter FortiOS 5.4 eine neue Firewall Policy Rule" erstellt so fällt einem auf das im oberen Bereich eine Position existiert "Name". Wenn man für die zu erstellende "Firewall Policy Rule" per Standard keinen "Name" vergiebt so kann die "Firewall Policy Rule" nicht nicht entsprechend abgespeichert werden da per Standard die Vergabe des "Name" erzwungen wird. Diese Position indiziert einen "PCI Compliance" und wird für "Audits" benützt:
| |
|
| |
| [[Datei:Fortinet-1615.jpg]]
| |
|
| |
| Die Bezeichnung des "Name" kann nicht benützt werden um die Logs auf der FortiGate zu Filtern da keine entsprechende Position zur Verfügung steht um dies auszuführen. Ebenso ist diese Position in den "Log Refrence" nicht enthalten. Somit steht diese Position rein im Zusammenhang mit der "PCI Compliance" resp. "Audits". Dies wird dann ersichtlich wenn ein "PCI Compliance" Report ausgeführt wird:
| |
|
| |
| [[Datei:Fortinet-1617.jpg]]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Weitere Informationen dazu wie ein "PCI Compliance" Report ausgeführt wird und um was es sich dabei
| |
| handelt siehe nachfolgenden Artikel:
| |
|
| |
| [[FortiGate-5.4-5.6:FAQ#Was_ist_.22PCI_Compliance.22_und_wie_kann_ich_unter_FortiOS_5.4_einen_.22PCI_Compliance.22_Report_ausf.C3.BChren.3F]]
| |
|
| |
| Bei einem Upgrade auf FortiOS 5.4 werden zwar die bestehenden "Firewall Policy Rules" übernommen dh. ohne "Name" und auch wenn bestehende "Firewall Policy Rules" modifiziert werden wird die Position "Name" nicht erzwungen, jedoch bei jeder neu erstellten "Firewall Policy Rule" wird "Name" erzwungen. Möchte man diese Funktion deaktiveren dh. damit die Vergabe von "Name" nicht mehr erzwungen wird so kann dieses Feature über folgende Position aktiviert werden:
| |
|
| |
| System > Feature Select > Allow unnamed Policies
| |
|
| |
| Ebenso kann über CLI dies konfiguriert werden:
| |
|
| |
| # config system settings
| |
| # set gui-allow-unnamed-policy [enable | disable]
| |
| # end
| |
|
| |
| === Unter FortiOS 5.4 für eine "Firewall Policy Rule" existiert die Position "Central-NAT" nicht mehr was ist zu beachten? ===
| |
|
| |
| Unter FortiOS 5.0 sowie 5.2 konnte ein Source NAT anhand der folgenden Konfiguration/Funltopm in einer Firewall Policy Rule durchgeführt werden:
| |
|
| |
| • Use Outgoing Interface Address
| |
| • Use Dynamic IP Pool
| |
| • Use Central NAT Table
| |
|
| |
| Die "Central NAT Table" Funktion stand unter FortiOS 5.0 sowie 5.2 in einer Firewall Policy Rule nur dann zur Verfügung, wenn dieses Feature unter Kommandozeile aktiviert wurde. Unter FortiOS 5.4 steht nun nur noch folgende Positionen zur Verfügung:
| |
|
| |
| • Use Outgoing Interface Address
| |
| • Use Dynamic IP Pool
| |
|
| |
| Das Feature/Funktion für "Central NAT Table" kann unter FortiOS 5.4 nur unter bestimmten Umständen aktiviert werden resp. existiert Regulär nicht mehr. Bei einem Upgrade von FortiOS 5.2 auf 5.4 kommt es auf der Mgmt. Console (RS-232) deshalb zu folgenden "error" Meldungen:
| |
|
| |
| >>> "set" "central-nat" "enable" @ root.firewall.policy.10:command parse error (error -61)
| |
| >>> "set" "central-nat" "enable" @ root.firewall.policy.16:command parse error (error -61)
| |
| >>> "set" "central-nat" "enable" @ root.firewall.policy.18:command parse error (error -61)
| |
| >>> "set" "central-nat" "enable" @ root.firewall.policy.20:command parse error (error -61)
| |
| >>> "set" "central-nat" "enable" @ root.firewall.policy.21:command parse error (error -61)
| |
| >>> "set" "central-nat" "enable" @ root.firewall.policy.22:command parse error (error -61)
| |
| >>> "set" "central-nat" "enable" @ root.firewall.policy.23:command parse error (error -61)
| |
| >>> "set" "central-nat" "enable" @ root.firewall.policy.30:command parse error (error -61)
| |
| >>> "set" "central-nat" "enable" @ root.firewall.policy.24:command parse error (error -61)
| |
| >>> "set" "central-nat" "enable" @ root.firewall.policy.25:command parse error (error -61)
| |
| >>> "set" "central-nat" "enable" @ root.firewall.policy.26:command parse error (error -61)
| |
| >>> "set" "central-nat" "enable" @ root.firewall.policy.27:command parse error (error -61)
| |
| >>> "set" "central-nat" "enable" @ root.firewall.policy.28:command parse error (error -61)
| |
| >>> "set" "central-nat" "enable" @ root.firewall.policy.29:command parse error (error -61)
| |
|
| |
| Diese "error" Meldungen können nachträglich auf dem FortiOS ebenfalls über die CLI ausgelesen werden anhand des folgenden Kommandos:
| |
|
| |
| # diagnose debug config-error-log read
| |
|
| |
| Somit gilt folgendes für ein Upgrade von FortiOS 5.2 auf 5.4:
| |
|
| |
| • Für jede Firewall Policy Rule die "Central NAT Table" benutzt, wird "Use Outgoing Interface Address" konfiguriert!
| |
|
| |
| Wenn ein FortiOS als IPv4 Adresse auf zB dem "wan1" 1 public IPv4 Adresse benutzt, wird durch "Use Outgoing Interface Address" keine Aenderung durchgeführt. Sind auf dem "wan1" Interface mehrer Public IPv4 Adressen konfiguriert sei es anhand einer Subnet Mask, Secondary Interface oder ARP Eintrag und diese zusätzlichen IPv4 Adressen wurden im Source NAT anhand der Central NAT Table benutzt müssen die entsprechenden Firewall Policy Rules manuell überprüft und konfiguriert werden anhand der Funktion "Use Dynamic IP Pool". Das gleiche gilt für Source NAT Konfigurationen anhand der Central NAT Table im Bereich von privaten IPv4 Adressen im Zusammenhang zB eines IPSec site2site VPN's usw. Das IP Pool Objekt das in der Central NAT Table Funktion benutzt wurde, bleibt bei einem Upgrade unverändert bestehen und kann weiterhin für die "Dynamic IP Pool" Konfiguration benützt werden. Somit ersetzt die Funktion "Dynamic IP Pool" die Central NAT Table Konfiguration. Da die "Dynamic IP Pool" Funktion bereits auf FortiOS 5.0 sowie 5.2 existiert kann vor einem Upgrade oder nach einem Upgrade eine allfällige Modifikation durchgeführt werden. Wie ein Source NAT anhand der "Dynamic IP Pool" Konfiguration durchzuführen ist siehe nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.4-5.6:FAQ#Wie_konfiguriere_ich_unter_FortiOS_5.4_f.C3.BCr_eine_.22Firewall_Policy_Rule.22_ein_Source_NAT_anhand_.22Dynamic_IP_Pool.22_oder_.22Outgoing_Interface_Address.22.3F]]
| |
|
| |
| Wie schon erwähnt existiert jedoch im Hintergrund die "Central NAT Table" Funktion noch jedoch kann nur unter bestimmten Umständen/Voraussetzungen benutzt werden. Somit unter FortiOS 5.4 für die Benutzung der "Central NAT Table" gilt:
| |
|
| |
| • Wenn unter FortiOS 5.4 in einer Firewall Policy Rule ein VIP Objekt benutzt wird kann die Funktion "Central NAT Table"
| |
| nicht aktiviert werden! Wird dies dennoch versucht erscheint über die Kommandozeile folgender Error:
| |
|
| |
| # config system settings
| |
| # set central-nat enable
| |
| Cannot enable central-nat with firewall policy using vip (id=[Angabe der Policy ID mit VIP Objekt).
| |
|
| |
| Wenn die "Central NAT Table" Funktion somit genutzt werden soll, muss folgendes durchgeführt werden:
| |
|
| |
| • Entferne alle VIP Objekte in der Firewall Police Rule (Die VIP Objekte selber können bestehen bleiben)!
| |
|
| |
| • Aktiviere die "Central NAT Table" Funktion über die Kommandozeile:
| |
|
| |
| # config system settings
| |
| # set central-nat enable
| |
| # end
| |
|
| |
| • Konfiguriere anhand "IP Pool Objekt/e" die "Central NAT Table" die nach der Aktivierung in der Kommandozeile
| |
| im Mgmt. Web Interface ersichtlich ist unter:
| |
|
| |
| Policy & Objects > Central SNAT
| |
|
| |
| • Aktiviere für die entsprechende Firewall Policy Rule die NAT Funktion!
| |
|
| |
| Wenn dies durchgeführt wurde, stellt sich die Frage wie ein Destination NAT Konfiguration durchgeführt wird da ein exisitierendes VIP Objekt nicht mehr zu einer Firewall Policy Rule für ein Destination NAT hinzugefügt werden kann?! Ein Destination NAT wird nachwievor über ein entsprechendes VIP Objekt Konfiguriert, muss jedoch nicht mehr zu einer Firewall Policy Rule hinzugefügt werden! Dies wird auch indiziert durch den neuen Namen für die Menüposition für VIP Objekte:
| |
|
| |
| DNAT & VirtualIP's
| |
|
| |
| Durch das hinzufügen/erstellen eines VIP Objekts, wird die entsprechende Konfiguration (Destination NAT) direkt dem Kernel hinzugefügt und muss somit nicht zusätzlich einer Firewall Policy hinzugefügt werden! Um jedoch eine höhere Granularität zu erreichen, kann eine entsprechenden Firewall Policy Rule zB Service usw. hinzugefügt werden. Dies bedeutet: Als Destination für die entsprechende Firewall Policy Rule muss die "Mapped IP" (Interne IP) des VIP Objekts konfiguriert werden mit zB dem entsprechenden Service. Weitere Informationen findet man über folgenden KB Artikel:
| |
|
| |
| http://kb.fortinet.com/kb/microsites/search.do?cmd=displayKC&docType=kc&externalId=FD37587
| |
|
| |
| === Wie konfiguriere ich unter FortiOS 5.4 für eine "Firewall Policy Rule" ein Source NAT anhand "Dynamic IP Pool" oder "Outgoing Interface Address"? ===
| |
|
| |
| Wenn auf einem FortiOS 5.4 ein Source NAT konfiguriert werden soll kann dies anhand zweier Funktionen durchgeführt werden:
| |
|
| |
| • Use Outgoing Interface Address
| |
| • Use Dynamic IP Pool
| |
|
| |
| Wenn "Use Outgoing Interface Address" benutzt wird so wird das Source NAT anhand der IPv4 Adresse durchgeführt, die auf dem Interface der FortiGate konfiguriert wurde. Dies bedeutet folgendes:
| |
|
| |
| '''Beispiel: Use Outgoing Interface Address'''
| |
|
| |
| • In diesem Beispiel wird eine Anfrage durchgeführt eines Hosts/Client im LAN mit IPv4 Adresse zB 192.168.1.100 auf www.google.com.
| |
| Auf dem FortiGate Device ist ein "wan1" konfiguriert mit der IPv4 Adresse von 212.59.153.66/29. Das Routing für www.google.com ist
| |
| auf "wan1" konfiguriert anhand des Default Gateways!
| |
|
| |
| __________________________________________________________________
| |
| | '''Original''' || '''Translate''' |
| |
| |________________________________||________________________________|
| |
| | Source | Destination || Source | Destination |
| |
| |_______________|________________||_______________|________________|
| |
| | LAN IP | www.google.com || wan1 IP | www.google.com |
| |
| |_______________|________________||_______________|________________|
| |
| | 192.168.1.100 | www.google.com || 212.59.153.66 | www.google.com |
| |
| |_______________|________________||_______________|________________|
| |
|
| |
| Somit wird durch die Funktion "Use Outgoing Interface Address" ein Source NAT durchgeführt anhand der IPv4 Adresse 212.59.153.66.
| |
|
| |
| Wenn dies unter Mgmt. Web Interface für die entsprechende Firewall Policy konfiguriert werden möchte, muss innerhalb der Firewall Policy Rule die Position "NAT" aktiviert werden um ein Source NAT zu konfiguieren. Dies bedeutet: Die Position "NAT" innerhalb einer Firewall Policy Rule steht nur im Zusammenhang mit einem Source NAT und darf für "Destination NAT (VIP Objekt)" nicht aktiviert werden. Um eine Firewall Policy Rule anhand "Use Outgoing Inerface Address" zu konfigurieren führe folgendes durch:
| |
|
| |
| Policy & Objects > IPv4 Policy > Create New
| |
|
| |
| [[Datei:Fortinet-1688.jpg]]
| |
|
| |
| Diese Konfiguration ist relativ statisch denn diese unterstützt nur die konfigurierte IPv4 Adresse des Interfaces! Wenn jedoch mehrer IPv4 Adressen auf dem Interface konfiguriert sind oder ein Source NAT durchgeführt werden möchte anhand einer IPv4 Adresse die nicht auf einem Interface konfiguriert ist/wurde kann dies über die Funktion "Use Dynamic IP Pool" durchgeführt werden. Folgendes Beispiel:
| |
|
| |
| '''Beispiel: Use Dynamic IP Pool'''
| |
|
| |
| • In diesem Beispiel wird eine Anfrage durchgeführt eines Hosts/Client im LAN mit IPv4 Adresse zB 192.168.1.100 auf www.google.com.
| |
| Auf dem FortiGate Device ist ein "wan1" konfiguriert mit der IPv4 Adresse von 212.59.153.66/29. Für das Source NAT soll jedoch nicht
| |
| 212.59.153.66 benutzt werden sondern 212.59.153.67.e Das Routing für www.google.com ist auf "wan1" konfiguriert anhand des Default
| |
| Gateways!
| |
|
| |
| ___________________________________________________________________
| |
| | '''Original''' || '''Translate''' |
| |
| |________________________________||_________________________________|
| |
| | Source | Destination || Source | Destination |
| |
| |_______________|________________||________________|________________|
| |
| | LAN IP | www.google.com || IP Pool Objekt | www.google.com |
| |
| |_______________|________________||________________|________________|
| |
| | 192.168.1.100 | www.google.com || 212.59.153.67 | www.google.com |
| |
| |_______________|________________||________________|________________|
| |
|
| |
| Somit wird durch die Funktion "Use Dynamic IP Pool" ein Source NAT durchgeführt anhand der IPv4 Adresse 212.59.153.67.
| |
|
| |
| Wenn dies unter Mgmt. Web Interface für die entsprechende Firewall Policy konfiguriert werden möchte, ist die Ausgangslage ein entsprechendes "IP Pool" Objekt. Um dieses zu erstellen führe folgendes durch:
| |
|
| |
| Policy & Objects > IP Pools > Create New
| |
|
| |
| [[Datei:Fortinet-1689.jpg]]
| |
|
| |
| Unter CLI wird ein "IP Pool" Objekt folgendermassen konfiguriert:
| |
|
| |
| # config firewall ippool
| |
| # edit [Name des entsprechenden IP Pool Objekts]
| |
| # set comment [Gebe einen entsprechenden Kommentar ein]
| |
| # set type [overload | one-to-one | fix-port-range | port-block-allocation]
| |
| # set startip [IPv4 Adresse]
| |
| # set endip [IPv4 Adresse]
| |
| # set arp-reply [enable | disable]
| |
| # set arp-intf [Gebe das entsprechende Interface an für ARP; keine Definition = Any]
| |
| # end
| |
|
| |
| Danach erstelle eine neue Firewall Policy Rule in dem das "IP Pool" Object eingebunden wird:
| |
|
| |
| Policy & Objects > IPv4 Policy > Create New
| |
|
| |
| [[Datei:Fortinet-1690.jpg]]
| |
|
| |
| [[Datei:Fortinet-1691.jpg]]
| |
|
| |
| Möchte man anhand der Funktion "Dynamic IP Pool" für ein ganzes Subnet NAT durchführen zB für ein IPSec site2site VPN kann das innerhalb des "IP Pool" Objekts anhand der Option "Fixed Port Range" konfiguriert werden. Dies bedeutet: Wenn zB im LAN die IPv4 Adresse mit Subnet Mask 192.168.1.0/24 existiert, diese jedoch anhand eines Source NAT "translated" werden soll anhand IPv4 Adresse und Subnet Mask 10.10.10.0/24 kann folgendes "IP Pool" Objekt anhand "Fixed Port Range" erstellt werden:
| |
|
| |
| Policy & Objects > IP Pools > Create New
| |
|
| |
| [[Datei:Fortinet-1692.jpg]]
| |
|
| |
| Wird dieses "IP Pool" Object für eine "outgoing" Firewall Policy Rule eingebunden und somit ein Source NAT konfiguriert wird folgedes durchgeführt:
| |
|
| |
| • In diesem Beispiel wird als IPSec Destination 172.16.0.1 benutzt was wiederum die Encryption Domain darstellt!
| |
| ___________________________________________________________________
| |
| | '''Original''' || '''Translate''' |
| |
| |________________________________||_________________________________|
| |
| | Source | Destination || Source | Destination |
| |
| |_______________|________________||________________|________________|
| |
| | LAN IP | IPsec IP dst || IP Pool Objekt | IPsec IP dst |
| |
| |_______________|________________||________________|________________|
| |
| | 192.168.1.1 | 172.16.0.1 || 10.10.10.1 | 172.16.0.1 |
| |
| |_______________|________________||________________|________________|
| |
| | 192.168.1.2 | 172.16.0.1 || 10.10.10.2 | 172.16.0.1 |
| |
| |_______________|________________||________________|________________|
| |
| | 192.168.1.3 | 172.16.0.1 || 10.10.10.3 | 172.16.0.1 |
| |
| |_______________|________________||________________|________________|
| |
| | 192.168.1.4 | 172.16.0.1 || 10.10.10.4 | 172.16.0.1 |
| |
| |_______________|________________||________________|________________|
| |
| | 192.168.1.5 | 172.16.0.1 || 10.10.10.5 | 172.16.0.1 |
| |
| |_______________|________________||________________|________________|
| |
| | 192.168.1.6 | 172.16.0.1 || 10.10.10.6 | 172.16.0.1 |
| |
| |_______________|________________||________________|________________|
| |
|
| |
| Wie in diesem Beispiel gezeigt wird .1 it .1 aus dem Source NAT IPv4 Adresse und Subnet Mask übersetzt und .2 mit .2 usw. Wenn in den verschiedenen Konfigurationen für die zur Verfügung stehenden "IP Pool" Konfiguration dh. "overload", "one-to-one" sowie "Fixed Port Range" unterschiedliche IPv4 Adress Subnet Mask's benutzen gilt folgendes:
| |
|
| |
| • Wenn die Anzahl der Source Adressen gleich ist wie die definierte IP Pool Adressen wird eine 1:1 Uebersetzung ausgeführt für die
| |
| die definierten IPv4 Subnet Masks. Wenn in dieser Konstellation "Fixed Port Range" benutzt wird bleibt der Source Port des Hosts/
| |
| Client unverändert. Wenn in mehreren Firewall Policy Rules in dieser Konstellation das gleiche "IP Pool" Objekt benutzt wird oder
| |
| das gleiche IPv4 Subnet wird in mehreren "IP Pool" Objekt benutzt kann es zu Konflikten kommen!
| |
|
| |
| • Wenn die Anzahl der Source Adressen grösser ist als die definierten IP Pool Adressen wird ein sogenannter "wrap-around" Mechanismus
| |
| verwendet. Dies bedeutet: Es wird zufüllig eine IP aus dem definiert IP Pool Adress Subnet verwendet. Wird in dieser Konstellation
| |
| "Fixed Port Range" benutzt, bleibt der Source Port des Hosts/Client unverändert. Es können in dieser Konstellation Konflikte entstehen
| |
| da durch User verschiedenen Sessions geöffnet werden mit den gleichen Source IPv4 Adressen/Port, Destination IPv4 Adressen/Port sowie
| |
| das Protokoll (TCP 5 tuples).
| |
|
| |
| • Wenn die Anzahl der Source Adressen kleiner ist als die definierten IP Pool Adressen, werden einige IP Pool Adressen benützt und die
| |
| restlichen nicht.
| |
|
| |
| Somit wenn ein 1:1 Uebersetzung konfiguriert werden soll, sollte nicht "one-to-one" benutzt werden da diese Funktion den Source Port des Hosts/Client verändert. Soll der Source Port nicht verändert werden und eine 1:1 Uebersetzung durchgeführt werden muss "Fixed Port Range" benutzt werden!
| |
|
| |
| === Wie konfiguriere ich unter FortiOS 5.4 für eine "Firewall Policy Rule" ein Destination NAT anhand eines VIP Objekts? ===
| |
|
| |
| Wenn auf einem FortiOS 5.4 ein Destination NAT konfiguriert werden soll kann dies anhand eines VIP Objekts durchgeführt werden. Im
| |
| nachfolgenden Beispiel wird anhand einer NAT Table aufgezeigt wie sich ein "Destination NAT" darstellt:
| |
|
| |
| __________________________________________________________________
| |
| | '''Original''' || '''Translated''' |
| |
| |________________________________||________________________________|
| |
| | Source | Destination || Source | Destination |
| |
| |_______________|________________||_______________|________________|
| |
| | External | Ext Interface || External | Internal |
| |
| | IPv4 | IPv4 (ARP) || IPv4 | IPv4 Addresse |
| |
| |_______________|________________||_______________|________________|
| |
| |_______________|________________||_______________|________________|
| |
| | Source Port | Dest. Port || Source Port | Dest. Port |
| |
| |_______________|________________||_______________|________________|
| |
| | | || | |
| |
| | Original Port | Service Port || Original Port | Service Port |
| |
| | | || | Orig o. Transl |
| |
| |_______________|________________||_______________|________________|
| |
| | |
| |
| | |
| |
|
| |
| Public IPv4 -> VIP Objekt -> Internal IPv4 Address
| |
|
| |
| In diesem Beispiel wird über eine "External IPv4" Adresse auf das "Ext Interface" (IPv4; ARP) eine Anfrage ausgeführt auf einen Service Port
| |
| zB SMTP Port 25. Für ein Destination
| |
| NAT muss die entsprechende IPv4 Adresse die für ein Destination NAT benutzt wird entweder auf dem "Ext Interface" konfiguriert sein oder
| |
| als ARP Eintrag auf dem "Ext Interface" existieren. Die Translation dh. die Uebersetzung von der "Ext Interface" Adresse auf die "Internal
| |
| IPv4 Adresse" wird anhand der Defintion des "VIP Objekts" durchgeführt. Anhand der Definition des VIP Objektes wird bestimmt ob der
| |
| Destination Port unverändet bleibt dh. zB SMTP Port 25 oder für die Destination "Internal IPv4 Adresse" ein anderer Port benutzt wird.
| |
| Die "Source" der Anfrage bleibt unter normalen Umständen immer unverändert. Somit stellt das VIP Objekt die Ausgangslage dar eines
| |
| Destination NAT. Um die Konfiguration eines VIP Objekts durchzuführen müssen folgende Informationen vorhanden sein:
| |
|
| |
| • Welche IPv4 Adresse wird verwendet für die Original "Destination" |
| |
| • Welches "Ext Interface" wird benutzt für die Original "IPv4 Adresse" |-------> External
| |
| • Welcher Service Port wird verwendet für den Original "Dest. Port" |
| |
|
| |
| • Welche IPv4 Adresse wird verwendet für die Translated "Internal IPv4 Adresse" |
| |
| • Welches "Internal Interface" wird benutzt für die Translated "Internal IPv4 Adresse" |-------> Internal
| |
| • Welcher Service Port wird verwendet für den Translated "Dest. Port" |
| |
|
| |
| Ein "VIP Objekt" wird folgendermassen konfiguriert:
| |
|
| |
| Policy & Objects > Virtual IPs > Create New
| |
|
| |
| [[Datei:Fortinet-2151.jpg]]
| |
|
| |
| '''Name'''
| |
| Diese Position stellt den Namen dar des Objekts.
| |
|
| |
| '''Comments'''
| |
| Für diese Position kann ein entsprechender Kommentar für das vip objekt vergeben werden.
| |
|
| |
| '''Interface'''
| |
| Für diese Position muss das Interface gewählt werden auf dem die External IPv4 Adresse
| |
| existiert dh. Diese Position steht im direkten Zusammenhang mit der "External IP Address/Range".
| |
| Dies bedeutet wiederum: Anhand der Definition des Interfaces und der Defintion des "External IP
| |
| Address/Range" wird sofern nötig auf dem definiert Interface für die definierte "External IP
| |
| Address/Range" automatisch ein ARP Eintrag erstellt. Wenn es sich beim definierten Interface
| |
| zB WAN um ein Dynamisch konfiguriertes Interface handelt dh. zB PPPoE oder DHCP so muss für
| |
| die "External IP Address/Range" die IP "0.0.0.0 - 0.0.0.0" konfiguriert werden was wiederum
| |
| folgendes bedeutet: Durch diese Definition wird das VIP Objekt dynamisch für die momentan
| |
| existierende IPv4 Adresse auf dem definierten Interface angepasst.
| |
|
| |
| '''External IP Address/Range'''
| |
| Diese Position steht im direkten Zusammehang mit der Position "Interface". Für diese Position
| |
| muss die IPv4 Adresse konfiguriert werden die für das Destination NAT benutzt wird dh. zB
| |
| "193.193.135.66 - 193.193.135.66". Existiert diese IPv4 Adresse nicht auf dem definierten
| |
| Interface wird automatisch ein ARP Eintrag erstellt für die definierte IPv4 Adresse. Handelt
| |
| es sich beim Interface um ein dynamisches Interface dh. DHCP oder PPPoE muss 0.0.0.0 - 0.0.0.0
| |
| definiert werden!
| |
|
| |
| '''Mapped IP Address/Range'''
| |
| Für diese Position muss die Interne IPv4 Adresse definiert werden die benutzt wird um von der
| |
| Externen IPv4 Adresse auf die definierte Interne IPv4 Adresse zu Uebersetzen (Translate).
| |
|
| |
| '''Source Address Filter'''
| |
| Diese Position wird unter normalen Umständen nicht benutzt dh. durch diese Position kann ein
| |
| Source Filter gesetzt werden der den Zugriff auf die Externa IPv4 Adresse einschränkt. Die
| |
| Definition umfasst eine IPv4 Adress Range/Subnet!
| |
|
| |
| '''Port Forwarding'''
| |
| In dieser Position wird das Protokoll, der "External Service Port" sowie der "Map to Port"
| |
| definiert dh. Wird diese Positon nicht konfiguriert werden für die Definition des "External
| |
| IP Address/Range" sowie "Mapped IP Address/Range alle potentiellen TCP/UDP Ports (1 - 65535)
| |
| übersetzt und zugelassen. Aus diesem Grund empfehlen wir diese Position immer zu definieren.
| |
|
| |
| Die Konfiguration kann ebenfalls auf der CLI durchgeführt werden:
| |
|
| |
| # config firewall vip
| |
| # edit nat-ip-local-193.193.135.66-32-port-25
| |
| # set comment [Gebe Optional einen entsprechenden Kommentar an]
| |
| # set type static-nat
| |
| # unsset srcintf-filter
| |
| # unset src-filter
| |
| # set extintf [Definiere das External Interface zB "wan1"]
| |
| # set extip [Definiere eine External IPv4 Adresse zB "193.193.135.66"]
| |
| # set mappedip [Definiere ein Internal IPv4 Adresse zB "198.18.0.92"]
| |
| # set arp-reply enable
| |
| # set nat-source-vip disable
| |
| # set gratuitous-arp-interval 0
| |
| # set portforward enable
| |
| # set portmapping-type 1-to-1
| |
| # set protocol [Gebe das entsprechende Protokoll an zB "tcp"]
| |
| # set extport [Definiere den Externen Service Port zB "25"]
| |
| # set mappedport [Definiere den Internen Service Port zB "25"]
| |
| # end
| |
|
| |
| Als letzter Schritt muss nun das VIP Objekt in der entsprechenden Firewall Policy Rule für das "Internal Interface" definiert werden. Dies bedeutet: Die "Internet IPv4 Adresse" die im VIP Objekt definiert wurde steht im direkten Zusammenhang mit dem Outgoing Interface dh. das VIP Objekt wird als "Destination Address" definiert für das Interface das Routing technisch ermöglicht die Internal IPv4 Adresse zu erreichen die im VIP Objekt als "Mapped IP Address/Range" definiert wurde. Nachfolgend ein Beispiel das den Zugriff für Service SMTP für Source "all" dh. über "wan1" auf den Internen Server ermöglicht:
| |
|
| |
| Policy & Objects > IPv4 Policy > Create New
| |
|
| |
| [[Datei:Fortinet-2152.jpg]]
| |
|
| |
| === Wenn ich für eine "Firewall Policy Rule" unter FortiOS 5.4 verschiedenen "Inspection Mode" benütze (flow/proxy) was gilt? ===
| |
|
| |
| Neu unter FortiOS 5.4 wird der "Inspection Mode" Global konfiguriert dh. weitere Informationen siehe nachfolgenden Artikel:
| |
|
| |
| [[FortiGate-5.4-5.6:FAQ#Was_hat_sich_unter_FortiOS_5.4_betreffend_.22Security_Profiles.22_und_.22Inspection_Mode.22_grunds.C3.A4tzlich_ge.C3.A4ndert.3F]]
| |
|
| |
| Wie dieser Artikel aufzeigt ist es jedoch möglich für "Security Profiles" individuelle Konfigurationen für den "Inspection Mode" durchzuführen dh. "proxy mode" und/oder "flow mode". Wenn dies geschieht kann der Traffic jedoch nicht individuell nach Konfiguration im "proxy mode" und/oder "flow mode" abgearbeitet werden dh. es gilt dann:
| |
|
| |
| Wenn in einer Firwall Policy Rule "proxy mode" sowie "flow mode" Security Profiles gemischt werden, wird für alle UTM
| |
| Funktionen die beides anbieten dh. "proxy mode" und/oder "flow mode" automatisch "proxy mode" benutzt obwohl ein
| |
| Security Profile "flow mode" konfiguriert wurde!
| |
|
| |
| === Wieso kann ich für eine "Firewall Policy Rule" unter FortiOS 5.4 nicht verschiedenen "Interfaces" für eine Source/Destination definieren? ===
| |
|
| |
| Per Standard ist es möglich seit FortiOS 5.0 für eine Source und/oder Destination in einer Firewall Policy Rule mehrere Interfaces über Web Mgmt. Interface zu definieren. Ab FortiOS 5.4.1 gibt es jedoch eine Option die das verhindern kann:
| |
|
| |
| # config system settings
| |
| # set gui-multiple-interface-policy [enable | disable]
| |
| # end
| |
|
| |
| Ist diese Option Deaktiviert und es wird versucht ein Interface für Source und/oder Destination hinzu zufügen, wird das bestehende definierte Interface gelöscht und mit dem neu definierten überschrieben. Die Option "gui-multiple-interface-policy" hat keinen Einfluss wenn ein zusätzliches Interface für eine Source und/oder Destination über CLI hinzugefügt wird. Weitere Informationen betreffend Aktivierung/Deaktivierung von verschiedenen Gui Funktionen siehe auch nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.4-5.6:FAQ#Unter_FortiOS_5.4_sehe_ich_.C3.BCber_das_Web_Gui_nicht_alle_Features_wie_kann_ich_diese_aktivieren.2Fdeaktivieren.3F]]
| |
|
| |
| === Wie Blocke ich für eine "Firewall Policy Rule" unter FortiOS 5.4 Source Traffic für ein VIP Objekt? ===
| |
|
| |
| Wenn man ein Destination NAT dh. anhand eines VIP Objekts konfiguriert und die Source zB für "wan1" auf "all" gesetzt wird, stellt sich die Frage wie kann ich eine Firewall Policy Rule konfigurieren um bestimmte Source IPv4 Adressen zu Blocken. Ausgangslage für dieses Beispiel wäre folgende Firewall Policy Rule in der ein Destination NAT (VIP Objekt) konfiguriert ist für SMTP Service:
| |
|
| |
| [[Datei:Fortinet-2071.jpg]]
| |
|
| |
| Würde man vor dieser Firewall Policy Rule eine Firewall Policy Rule konfigurieren die den Traffic von einer bestimmten Source auf das internal LAN Interface Blockt, würde diese Firewall Policy Rule nicht für VIP Objekte angewendet werden da die Virtuellen IP Objekte im Hintergrund in der Virtuellen Policy anderst verarbeitet werden und somit VIP Objekte durch diese Firewall Policy Rule nicht berücksichtigt werden:
| |
|
| |
| [[Datei:Fortinet-2072.jpg]]
| |
|
| |
| Um dieser Firewall Policy Rule zu ermöglichen das VIP Objekte berücksichtigt werden, kann über CLI für die Firewall Policy Rule (Policy ID) durch Aktivierung der folgende Option dies ermöglicht werden:
| |
|
| |
| # config firewall policy
| |
| # edit [Gebe die entsprechende Policy ID an zB "9"]
| |
| # set match-vip [enable | disable]
| |
| # end
| |
|
| |
| Durch das Aktivieren der Option "match-vip" kann somit die Policy ID 9 den Traffic für VIP Objekte blockieren obwohl das VIP Objekt nicht explizit in der Firewall Policy Rule konfiguriert wurde da durch "match-vip" die entsprechende Firewall Policy angewiesen wird die Virtuellen Policy zu berücksichtigen. Wir empfehlen jedoch eine Firewall Policy Rule so zu konfigurieren in der das VIP Objekt explizit konfiguriert wird und somit explizit für eine bestimmte Source geblockt wird. Dadurch muss auf CLI die Option "match-vip" nicht explizit aktiviert werden:
| |
|
| |
| [[Datei:Fortinet-2073.jpg]]
| |
|
| |
| [[Datei:Fortinet-2074.jpg]]
| |
|
| |
| Wenn eine bestimmte Source generell ausgeschlossen werden soll für eine Destination oder im Gesamten zB über GeoIP empfehlen wir eine manuelle "Local-In Firewall Policy Rule". Diese kann nur über CLI konfiguriert werde und wird vor der regularen Firewall Policy und vor der Virtuellen Policy verarbeitet:
| |
|
| |
| # config firewall local-in-policy
| |
| # edit [Gebe eine entsprechende Policy ID an zB "1"]
| |
| # set ha-mgmt-intf-only disable
| |
| # set intf "wan1"
| |
| # set srcaddr "net-local-geo-ip-russia"
| |
| # set dstaddr "all"
| |
| # set action deny
| |
| # set service "ALL"
| |
| # set schedule "always"
| |
| # set auto-asic-offload enable
| |
| # set status enable
| |
| # end
| |
|
| |
| Durch diese "Local-In Firewall Policy Rule" wird somit sämtliche Traffic auf "wan1" mit der Source "net-local-geo-ip-russia" geblockt. Bei einer differenzierter Konfiguration von verschiedenen Services muss jedoch folgendes berücksichtigt werden: Für die "Local-In Firewall Policy" existiert keine "Clean-Up" Firewall Policy Rule dh. sämtlicher Traffic der nicht geblockt wird erreicht die reguläre Firewall Policies die über das Mgmt. Web Gui ersichtlich sind!
| |
|
| |
| === Unter FortiOS 5.4 für eine "Firewall Policy Rule" existiert die Funktion "Policy Learning Mode" um was handelt es sich dabei? ===
| |
|
| |
| Ab FortiOS 5.4.2 gibt es die Möglichkeit für eine Firewall Policy Rule die Funktion "Policy Learning Mode" zu aktivieren. Diese Funktion ist per Standard deaktiviert und muss über die CLI aktiviert werden sowie steht diese Funktion nur dann zur Verfügung, wenn der FortiGate Device über Reporting Funktionen verfügt. Dies ist zB bei kleineren Geräten nur für die FG-51E sowie FG-80D der Fall. Weitere Auskunft welche Geräte über die Reporting Funktion verfügen siehe nachfolgendes Dokument das Auskunft gibt welche Funktion bei welchem FortiGate Device zur Verfügung steht:
| |
|
| |
| [[Datei:FortiOS-Software-Platform-Matrix-54.pdf]]
| |
|
| |
| Um die Funktion "Policy Learning Mode" ueber CLI zu aktiviere führe folgendes aus:
| |
|
| |
| # config system settings
| |
| # set gui-policy-learning [enable | disable]
| |
| # end
| |
|
| |
| Wird diese Gui Option aktiviert, steht über Mgmt. Web Interface innerhalb einer Firewall Policy Rule neu der Learning Mode unter "Action" zur Verfügung:
| |
|
| |
| [[Datei:Fortinet-2138.jpg]]
| |
|
| |
| Wenn der "Policy Learning Mode" für eine Firewall Policy Rule aktiviert wird so gilt folgendes:
| |
|
| |
| Es werden im Flow Mode im Hintergrund folgende UTM Features resp. Profiles der Firewall Policy Rule hinzugefügt:
| |
|
| |
| • av-profile
| |
| • webfilter-profile
| |
| • spamfilter-profile
| |
| • dlp-sensor
| |
| • ips-sensor
| |
| • application-list
| |
| • profile-protocol-options
| |
|
| |
| Diese UTM Profiles sind statischer Natur und können nicht editiert werden. Die Funktion "SSL inspection" (deep
| |
| inspection) wird für diese Firewall Policy Rule für die der "Policy Learning Mode" aktiviert ist deaktiviert!
| |
| Nachfolgende Funktionen/Profiles werden nicht zur dieser Firewall Policy Rule im "Policy Learning Mode" hinzugefügt:
| |
|
| |
|
| |
| • DNS Filter (Kein Flow Mode vorhanden)
| |
| • Web Application Firewall (Kein Flow Mode vorhanden)
| |
| • CASI(Benötigt für die Grundfunktionen Hauptsächlich "SSL inspection")
| |
|
| |
| Diese Funktion kann Hauptsächlich benutzt werden für Analysezweck dh. Wenn Firewall Policy Rules die implementiert werden sollen umbekannt sind, kann über diese Funktion anhand eines Reportings eruiert werden welche Firewall Policy Rules implementiert werden müssen. Dazu muss ein einwandfreies Logging auf dem FortiGate Device konfiguriert sowie zur Verfügung stehen (Disk Logging). Wie eine einwandfreie Log Konfiguratin für einen FortiGate Device durchzuführen ist siehe nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.4-5.6:FAQ#Wie_sieht_eine_vollst.C3.A4ndige_Log_Konfiguration_f.C3.BCr_FortiOS_5.4_aus_und_wie_wird_diese_durchgef.C3.BChrt.3F]]
| |
|
| |
| Wenn die Funktion "Policy Learning Mode" für eine Firewall Policy Rule aktiviert wurde und Logging einwandfrei zur Verfügung steht, kann nach einiger Zeit ein Report über folgende Menüposition erstellt werden:
| |
|
| |
| Log & Report > Learning Report
| |
|
| |
| Unter dieser Position stehen zwei Reports zur Verfügung:
| |
|
| |
| • Full Report
| |
| • Report Summary
| |
|
| |
| Diese Reports können über eine "schedule" automatisiert werden für "5 Minuten oder 1 Stunde. Die Reports sind direkt auf der entsprechenden Seite ersichtlich.
| |
|
| |
| === Wie Konfiguriere ich unter FortiOS 5.4 für eine "Firewall Policy Rule" ein "Hairpin NAT" und um was handelt es sich dabei? ===
| |
|
| |
| Dieser Begriff "Hairpin NAT" steht im Zusammenhang mit einem VIP Objekt resp. mit einem Destination NAT. Nachfolgende Abbildung zeigt ein klassiches Szenario in dem "Hairpin NAT" benutzt wird:
| |
|
| |
| [[Datei:Fortinet-1356.jpg]]
| |
|
| |
| Dieses Szenario zeigt die Problematik, wenn ein internal User aus dem LAN Segment ein DMZ Server erreichen möchte jedoch nicht über einen internen DNS Server verfügt sondern externen zB ISP DNS Server benutzt. Dies bedeutet: Durch die Anfrage des FQDN des DMZ Servers durch den internen Users im LAN Segment zB über Browser wird durch die auf dem Client/Workstation des Users Konfigurierten ISP DNS Server anstelle der internen IPv4 Adresse des DMZ Servers 10.10.10.10 die Public IPv4 Adresse des DMZ Server zurück gegeben. Somit muss für den internen User im LAN Segment betreffend Firewall Policy die Public IPv4 Adresse im Zusammenhang mit einem VIP Objekt benutzt werden um den DMZ Server zu erreichen. Sofern möglich sollten solche Konfigurationen verhindert werden und ein Split DNS Server Konfiguration in Betracht gezogen werden da ein "Hairpin NAT" aus Performance Gründen verhindert werden sollte. Weiter Informationen wie ein Split DNS Server Konfiguriert wird siehe nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.4-5.6:FAQ#Wie_kann_ich_unter_FortiOS_5.4_f.C3.BCr_einen_Fortigate_Device_einen_Split_DNS_Server_Konfigurieren.3F]]
| |
|
| |
| Wenn aus irgendwelchen Gründen kein Split DNS Server Konfiguriert werden kann so kann als Alternative eine DNS Translation Konfiguriert werden. Weitere Informationen dazu siehe nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.4-5.6:FAQ#Kann_ich_auf_einer_FortiGate_unter_FortiOS_5.4_eine_bestimmte_.22DNS_Anfrage.22_umschreiben_.28translation.29.3F]]
| |
|
| |
| Wenn ein Split DNS Server sowie eine DNS Translation keine Alternative bieten, kann ein Hairpin NAT Konfiguriert werden. Nachfolgende Konfiguration zeigt anhand des zu Beginn gezeigten Szenarion in der 172.16.1.10 die Public IP4v Adresse benutzt wird, wie diese Konfiguration durchzuführen ist:
| |
|
| |
| '''Konfiguration des DMZ Objekts 10.10.10.10:'''
| |
|
| |
| # config firewall address
| |
| # edit [Name des entsprechenden Objekts zB "host-10.10.10.10-32"]
| |
| # set subnet [IPv4 Adresse 10.10.10.10/32]
| |
| # end
| |
|
| |
| '''Konfiguration des LAN Segment Objekts 192.168.1.100:'''
| |
|
| |
| # config firewall address
| |
| # edit [Name des entsprechenden Objekts zB "node-192.168.1.100-32"]
| |
| # set subnet [IPv4 Adresse 192.168.1.100/32]
| |
| # end
| |
|
| |
| '''Konfiguration VIP Objekt für HTTPS:'''
| |
|
| |
| # config firewall vip
| |
| # edit [Name des entsprechenden VIP Objekts zB "nat-ip-172.16.1.10-32-tcp-443"]
| |
| # set extip 172.16.1.10
| |
| # set extintf [Gebe das entsprechende Interface an für die Public IPv4 Adresse; In unserem Beispiel "wan1"]
| |
| # set mappedip 10.10.10.10
| |
| # set portforward enable
| |
| # set extport 443
| |
| # set mappedport 443
| |
| # next
| |
| # end
| |
|
| |
| '''Konfiguration Firewall Policy Rule Public "wan1 to dmz" für HTTPS:'''
| |
|
| |
| # config firewall policy
| |
| # edit [Vergebe einen entsprechenden Integer zB "1"]
| |
| # set srcintf "wan1"
| |
| # set dstintf "dmz"
| |
| # set srcaddr "all"
| |
| # set dstaddr [Name des entsprechenden VIP Objekts zB "nat-ip-172.16.1.10-32-tcp-443"]
| |
| # set action accept
| |
| # set schedule "always"
| |
| # set service "HTTPS"
| |
| # next
| |
| # end
| |
|
| |
| Die nachfolgende Firewall Policy Rule entspricht in den meisten Fällen der Rule die dem LAN Segment erlaubt auf das Internet zu zugreifen:
| |
|
| |
| '''Konfiguration Firewall Policy Rule Internal "internal to wan1" für HTTPS:'''
| |
|
| |
| # config firewall policy
| |
| # edit [Vergebe einen entsprechenden Integer zB "2"]
| |
| # set srcintf "internal"
| |
| # set dstintf [Gebe das entsprechende Interface an für die Public IPv4 Adresse; In unserem Beispiel "wan1"]
| |
| # set srcaddr [Name des entsprechenden LAN Objekts zB "node-192.168.1.100-32"]
| |
| # set dstaddr "all"
| |
| # set action accept
| |
| # set schedule "always"
| |
| # set service "HTTPS"
| |
| # set nat enable
| |
| # next
| |
| # end
| |
|
| |
| '''Konfiguration Firewall Policy Rule Internal "internal to dmz" für HTTPS:'''
| |
|
| |
| # config firewall policy
| |
| # edit [Vergebe einen entsprechenden Integer zB "3"]
| |
| # set srcintf "internal"
| |
| # set dstintf "dmz"
| |
| # set srcaddr [Name des entsprechenden LAN Objekts zB "node-192.168.1.100-32"]
| |
| # set dstaddr [Name des entsprechenden VIP Objekts zB "nat-ip-172.16.1.10-32-tcp-443"]"
| |
| # set action accept
| |
| # set schedule "always"
| |
| # set service "HTTPS"
| |
| # next
| |
| # end
| |
|
| |
| Eine weitere Möglichkeit anstelle für die hier gezeigte Firewall Policy ID "3" ist die Folgende: Anstelle des VIP Objektes unter "dstaddr" zu Konfigurieren wird "all" für "dstaddr" Konfiguriert. Wird "all" benutzt muss über Kommandozeile für Policy ID "3" die Option "match-vip" aktiviert werden:
| |
|
| |
| # config firewall policy
| |
| # edit [Vergebe einen entsprechenden Integer zB "3"]
| |
| # set srcintf "internal"
| |
| # set dstintf "dmz"
| |
| # set srcaddr [Name des entsprechenden LAN Objekts zB "node-192.168.1.100-32"]
| |
| # '''set dstaddr "all"'''
| |
| # set action accept
| |
| # set schedule "always"
| |
| # set service "HTTPS"
| |
| # '''set match-vip enable'''
| |
| # next
| |
| # end
| |
|
| |
| Nun kann die Konfiguration getestet werden!
| |
|
| |
| === Wie ist das Verhalten unter FortiOS 5.4 für eine Firewall Policy Rule wenn diese geändert wird? ===
| |
|
| |
| Wenn unter FortiOS 5.4 eine neue Firewall Policy Rule erstellt wird und diese nachträglich abgeändert wird, so fragt man sich was im Hintergrund mit den existierenden Sessions resp. neuen Sessions geschieht? Ebenfalls stellt sich die Frage ob es eine Rolle spielt, wenn nur die Firewall Policy Rule selber abgeändert wird oder zB ein Address Object, Service Object, Scheduled usw. im Zusammenhang mit einer Firewall Policy Rule? Die zuständige Option die das Verhalten der Sessions für eine Firewall Policy Rule steuert ist die Folgende:
| |
|
| |
| # config system settings
| |
| # set firewall-session-dirty [check-all | check-new | check-policy-option]
| |
| # end
| |
|
| |
| Die Möglichkeiten innerhalb der Option "firewall-session-dirty" sind die Folgenden:
| |
|
| |
| • '''check-all'''
| |
|
| |
| Durch "check-all" werden alle bestehenden Sessions für eine Firewall Policy Rule Aenderung durch ein "flush"
| |
| neu Evaluiert. Dies ist ebenfalls die Standard Einstellung für die Option "firewall-session-dirty". In
| |
| bestimmten Fällen bei Benutzung von mehr als 2000 Firewall Policy Rule kann durch "check-all" ein kurzfristige
| |
| hohe Auslastung des CPU ausgelöst werden. Dabei kann die Situation entschärft werden in dem die Firewall Policy
| |
| Rule Reihenfolgen optimiert wird dh. die meist benützten Firewall Policy Rule sollten sich zu Beginn der Policy
| |
| Rule Base befinden. Siehe auch nachfolgender Artikel:
| |
|
| |
| http://kb.fortinet.com/kb/documentLink.do?popup=true&externalID=FD37210&languageId=
| |
|
| |
| • '''check-new'''
| |
|
| |
| Durch "check-new" werden alle existierenden Sessions für eine Firewall Policy Rule Aenderung belassen und nur
| |
| die neue Verbindungen werden Evaluiert für die Aenderung in der Firewall Policy Rule. Durch "check-new" wird
| |
| der CPU nicht in dem Masse ausgelastet wie bei "check-all" und/oder "check-policy-option" jedoch besteht die
| |
| Gefahr eines "packet loss".
| |
|
| |
| • '''check-policy-option'''
| |
|
| |
| Durch "check-policy-option" wird das "firewall-session-dirty" Feld für eine Firewall Policy Rule benützt.
| |
|
| |
|
| |
| Somit wird durch die verschiedenen Möglichkeiten das "firewall-session-dirty" Feld einer Session benützt um das Verhalten zu steuern. Das Feld einer Session für "firewall-session-dirty" ist das Folgende:
| |
|
| |
| state= [dirty | may_dirty | persistent]
| |
|
| |
| Für die Anwendung der Option "firewall-session-dirty" gibt es drei Situationen:
| |
|
| |
| '''firewall-session-dirty check-all'''
| |
|
| |
| Durch diese Konfiguration wird das "state=" Feld einer neuen Session für eine existierende Firewall Policy Rule
| |
| gesetzt mit:
| |
|
| |
| state=may_dirty
| |
|
| |
| Wird eine Aenderung auf der Firewall Policy Rule für diese Session durchgeführt, wird das "state=" Feld geändert
| |
| in:
| |
|
| |
| state=dirty
| |
|
| |
| Nun wird die Session neu Evaluiert für die Firewall Policy Aenderung und nachträglich wird das "state=" Feld
| |
| geändert auf:
| |
|
| |
| state=may_dirty
| |
|
| |
| Dabei ist zu berücksichtigen: Wie schon erwähnt spielt es keine Rolle ob die Firewall Policy Rule selber geändert
| |
| wird oder Adress Objekte usw. eine Firewall Policy Rule. Sobald der Inhalt einer Firewall Policy Rule gändert wird
| |
| in welchem Sinne auch immer wird das hier beschriebenen Scenario ausgelöst!
| |
|
| |
| '''firewall-session-dirty check-new'''
| |
|
| |
| Durch diese Konfiguration wird das "state=" Feld einer neuen Session für eine existierende Firewall Policy Rule
| |
| gesetzt mit:
| |
|
| |
| state=persistent
| |
|
| |
| Wird eine Aenderung auf der Firewall Policy Rule für diese Session durchgeführt, wird keine neue Evaluierung der
| |
| Firewall Policy Rule durchgeführt da das "state=" Feld auf "persistent" steht. Die Session behält dieses "state="
| |
| Feld bis die Session beendet wird.
| |
|
| |
| '''firewall-session-dirty check-policy-option'''
| |
|
| |
| Durch diese Konfiguration wird in den Firewall Policy Rule's auf Kommandozeile folgendes Kommando zur Verfügung
| |
| gestellt:
| |
|
| |
| firewall-session-dirty [check-all | check-new]
| |
|
| |
| Somit muss nach der Aktivierung der Option "firewall-session-dirty check-policy-option" in "config system settings"
| |
| jede einzelne Firewall Policy Rule anhand "check-all" oder "check-new" Konfiguriert werden. Das Verhalten in einer
| |
| Firewall Policy Rule im Zusammenhang mit einer Sessions betreffend "check-all" sowie "check-new ist gemäss
| |
| vorhergehender Beschreibung! Wenn "firewall-session-dirty check-policy-option" im Zusammenhang mit "check-new" für
| |
| eine Firewall Policy Rule benützt wird sowie in dieser Firewall Policy Rule ein "scheduled" Objekt Konfiguriert wurde,
| |
| ended die Session sobald die Stop-Time für das "scheduled" Objekt erreicht wurde. Soll jedoch die existierende Session
| |
| über die Stop-Time erhalten bleiben bis diese beendet wird, muss in der Firewall Policy Rule die Option "schedule-timeout
| |
| disabled" gesetzt werden. Dadurch wird nach der "Stop-Time" des "schedule" Objekts das "state=" Feld auf "persistent"
| |
| gesetzt und die Session bleibt erhalten bis diese beendet wird.
| |
|
| |
| == Session ==
| |
|
| |
| === Wie kann ich unter FortiOS 5.4 die aktiven "Sessions" auf meinem System anzeigen/auflisten lassen? ===
| |
|
| |
| Wenn auf einem FortiOS alle aktiven "Sessions" die existieren in der Anzahl aufgelistet werden sollen kann nachfolgender Befehl benutzt werden:
| |
|
| |
| # get system session status
| |
| The total number of sessions for the current VDOM: 14
| |
|
| |
| Möchte man nun die einzelnen "Sessions" auflisten ohne deren Details kann nachfolgender Befehl benutzt werden:
| |
|
| |
| # get system session list
| |
| PROTO EXPIRE SOURCE SOURCE-NAT DESTINATION DESTINATION-NAT
| |
| udp 63 192.168.5.2:56751 - 192.168.1.1:53 -
| |
| udp 179 193.193.135.66:26730 - 193.193.135.65:53 -
| |
| udp 73 193.193.135.66:26967 - 193.193.135.65:53 -
| |
| tcp 5 192.168.1.1:3418 - 192.168.1.10:514 -
| |
| udp 175 193.193.135.70:5246 - 193.193.135.66:5246 -
| |
| udp 179 193.193.135.66:1024 - 193.193.135.65:514 -
| |
| udp 175 193.193.135.70:39322 - 193.193.135.66:5247 -
| |
| udp 179 0.0.0.0:68 - 255.255.255.255:67 -
| |
| udp 160 192.168.3.3:46417 - 192.168.3.1:5247 -
| |
| tcp 3599 192.168.5.2:49170 - 192.168.2.1:22 -
| |
| udp 175 192.168.3.3:5246 - 192.168.3.1:5246 -
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Nachfolgend die Beschreibung der einzelnen Spalten:
| |
|
| |
| PROTO Transportprotokoll der Session (ISO-Model Schicht 4)
| |
| EXPIRE Zeit bevor die Session terminiert wird
| |
| SOURCE Source IP Adresse und Source Portnummer
| |
| SOURCE-NAT Source NAT IP Adresse ein '-' steht für kein NAT.
| |
| DESTINATION Destination IP Adresse und Destinations Portnummer
| |
| DESTINATION-NAT Destination NAT IP Adresse ein '-' steht für kein NAT
| |
|
| |
| Wenn auf einem "produktiven System alle aktiven "Sessions" aufgelistet werden kann diese Liste enorm lang sein. Um die Liste der "Sessions" zu filtern kann "grep" benutzt werden. Nachfolgend ein Beispiel
| |
|
| |
| # get system session list | grep [Such Pattern zB 192.168.3.1]
| |
| udp 160 192.168.3.3:46417 - 192.168.3.1:5247 -
| |
| udp 175 192.168.3.3:5246 - 192.168.3.1:5246 -
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Wie der filter "grep" benutzt wird und welche Optionen dieser Befehl beinhaltet zeigt nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.4-5.6:FAQ#Kann_ich_unter_FortiOS_5.4_Linux.2FUnix_basierenden_Befehl_.22grep.22_auf_der_Kommandozeile_ben.C3.BCtzen.3F]]
| |
|
| |
| Zu den aufgelisteten "Sessions" sowie zur "Session Table" können detailliert Informationen angezeigt und aufgelistet werden. Nachfolgend eine Uebersicht über die zur Verfügung stehenden Kommandos sowie deren Anwendung:
| |
|
| |
| # get system session-info expectation
| |
| # get system session-info full-stat
| |
| # get system session-info list
| |
| # get system session-info statistics
| |
| # get system session-info ttl
| |
|
| |
| Diese Kommandos zeigen folgende Informationen:
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Das Ausführen dieser Befehle kann auf der Console unmengenen von Daten auslösen. Speziell für Devices mit
| |
| hoher Auslastung ist dies zu berücksichtigen.
| |
|
| |
| '''expectation''' Listet/zeigt die zu erwartenden Sessions auf!
| |
|
| |
| '''full-stat''' Listet detaillierte Informationen auf betreffend der Session Table sowie deren zu erwartenden Session, Errors, Statistic usw.
| |
|
| |
| '''statistics''' Listet die gleichen Informationen auf wie "full-stat" jedoch ohne "session table" sowie "expected session"
| |
|
| |
| '''list''' Listet detaillierte Informationen über jede Session auf wie Protokoll Nummer, Shaping Informationen, Policy usw.
| |
|
| |
| '''ttl''' Listet die Informationen auf betreffend der momentanen Konfiguration betreffend "config system session-ttl" sowie die globalen
| |
| Einstellungen sowie die spezifizierten Protokoll Konfigurationen sofern diese existieren.
| |
|
| |
| === Welche Informationen werden für eine einzelne Session unter FortiOS 5.4 in der "Session" Liste aufgeführt und was bedeuten diese? ===
| |
|
| |
| Wenn der nachfolgender Befehl auf einer FortiGate ausgeführt wird, werden sämtliche "Sessions" mit deren detaillierten Informationen aufgelistet:
| |
|
| |
| # diagnose sys session list
| |
|
| |
| Im "output" ist jede einzelne aktive "Session" mit deren Details aufgeführt. Als Beispiel nachfolgender Output einer Session:
| |
|
| |
| session info: proto=6 proto_state=02 duration=11 expire=21 timeout=3600 flags=00000000 sockflag=00000000 sockport=0 av_idx=0 use=3
| |
| origin-shaper=
| |
| reply-shaper=
| |
| per_ip_shaper=
| |
| ha_id=0 policy_dir=0 tunnel=/
| |
| state=local nds
| |
| statistic(bytes/packets/allow_err): org=120/2/0 reply=176/2/1 tuples=2
| |
| orgin->sink: org out->post, reply pre->in dev=0->7/7->0 gwy=0.0.0.0/0.0.0.0
| |
| hook=out dir=org act=noop 198.18.0.1:21164->198.18.0.90:514(0.0.0.0:0)
| |
| hook=in dir=reply act=noop 198.18.0.90:514->198.18.0.1:21164(0.0.0.0:0)
| |
| pos/(before,after) 0/(0,0), 0/(0,0)
| |
| misc=0 policy_id=0 auth_info=0 chk_client_info=0 vd=0
| |
| serial=002606e7 tos=ff/ff ips_view=0 app_list=0 app=0
| |
| dd_type=0 dd_mode=0
| |
| npu_state=00000000
| |
|
| |
| Dabei werden unzählig Positionen mit deren detaillierten Informationen aufgeführt. Diese haben folgende Bedeutung:
| |
|
| |
| proto=6 Gibt an um welches Protokoll es sich handelt zB 6 = TCP. Weitere Informationen zu den Protokoll Nummern siehe auch nachfolgender Artikel:
| |
|
| |
| [[Allgemein:Assigned-Internet-Protocol-Numbers-RFC]]
| |
|
| |
| proto_state=02 Die erste Stelle des "proto_state" gibt an ob diese Session Client Seiting eine "proxy_based" Inspection ist dh. wenn es sich um keine "proxy_based"
| |
| Inspection handelt wird eine "0" gesetzt. Die zweite Stelle dh. in unserem Beispiel "2" gibt Server Seitig den "state" an. Die gülten "states" sind:
| |
|
| |
| [[Datei:Fortinet-1418.jpg]]
| |
|
| |
| [[Datei:Fortinet-1419.jpg]]
| |
|
| |
| '''Proto_state Feld für TCP'''
| |
| Weil eine FortiGate eine "stateful firewall" ist überwacht das FortiOS ebenfalls die "reply session. Aus diesem Grund verfügt der "proto_state=OR" dh.
| |
| Orginal "direction" und Reply "direction":
| |
|
| |
| [[Datei:Fortinet-2153.jpg]]
| |
|
| |
| '''Proto_state Feld für SCTP'''
| |
| Ab FortiOS 4.2 unterstützt ein FortiGate Device resp. FortiOS ebenfalls "stateful firewalling" für SCTP:
| |
|
| |
| [[Datei:Fortinet-2154.jpg]]
| |
|
| |
| '''Proto_state Feld für UDP'''
| |
| Obwohl UDP ein "sessionless" Protokoll darstellt überwacht ein FortiOS für UDP 2 Status:
| |
|
| |
| '''State''' '''Value'''
| |
| UDP Reply not seen 0
| |
| UDP Reply seen 1
| |
|
| |
| '''Proto_state Feld für ICMP (proto 1)'''
| |
| Für ICMP existiert kein Status und ein FortiOS zeigt für ICMP immer "proto_state=00"
| |
|
| |
| expire=21 Diese Positione gib an wie lange die Session noch gültig ist bis diese gelöscht wird resp. abgelaufen ist (TTL = time to live).
| |
|
| |
| origin-shaper= Gibt an ob ein Traffic Shaper benutzt wird. Wenn ein Traffic Shaper benutzt wird werden Informationen ausgegeben betreffend Priorität und Bandbreite.
| |
| reply-shaper= Nachfolgend ein Beispiel:
| |
| per_ip_shaper=
| |
| origin-shaper=OutShapper prio=2 guarantee 12800Bps max 128000Bps traffic 92Bps
| |
| reply-shaper=InShaper prio=4 guarantee 2560Bps max 25600Bps traffic 125Bps
| |
| per_ip_shaper=PerIPShaper
| |
|
| |
| state=may dirty none app ntf Der "state" indiziert die "session flags". Dazu nachfolgende Liste der meistgebrauchten "session flags":
| |
|
| |
| log Session is being logged
| |
| local Session is to/from local stack (orgin or terminated from FortiGate)
| |
| ext Session is created by a firewall session helper
| |
| ndr Session will be checked by IPS signature
| |
| nds Session will be checked by IPS anomaly
| |
| br Session is being bridged (TP mode)
| |
| npu Session can be offloaded to NPU
| |
| wccp Session is handled by WCCP (Version 4.0)
| |
| npd Session cannot be offloaded to NPU
| |
| redir Session is being processed by an application layer proxy
| |
| authed Session was successfully authenticated
| |
| auth Session required (or required) authentication
| |
|
| |
| Grundsätzlich wird jedes "erste" Packet über die Firewall Policy kontrolliert. Wenn dieses Packet erlaubt wird über die Firewall Policy wird eine "session"
| |
| erstellt und bezeichnet (flag) als "may_dirty". Wenn eine Aenderung in der Firewall Policy durchgeführt wird so werden "alle" existierenden "sessions" von
| |
| "may_dirty" auf "diry" gesetzt. Dadurch werden sämtliche Packet ab diesem Zeitpunkt nicht mehr über den NPU gesendet sondern zum CPU. Der CPU kontrolliert
| |
| abermals das Packet in der Firewall Policy und wenn dieses erlaubt wird, werden diese "sessions" auf "may_dirty" gesetzt. Wenn dieses Packet in der Firewall
| |
| Policy nicht erlaubt wird werden diese Packet verworfen und mit einem "flag" "block" versehen. Danach verbleibt die "session" im Memory bis diese den TTL
| |
| resp. "expire" erreicht. So kann die FortiGate über die "flags" "dirty"und/oder "may_dirty" erkenne/evaluieren nach einer Modifikation der Firewall Policy
| |
| ob diese weiterhin erlaubt werden (may_dirty) resp. die entsprechende "session" geblockt werden (block).
| |
|
| |
| policy_id=0 Gibt an welche Firewall Policy-ID benutzt wurde. Die Firewall Policy-ID 0 indiziert eine "Local-In Policy".
| |
|
| |
| statistic Steht für den Packet Counter der auch über die Firewall Policy der FortiGate ersichtlich ist. Nachfolgend ein Beispiel:
| |
|
| |
| statistic (bytes/packets/err): org=3408/38/0 reply=3888/31/0 tuples=2
| |
|
| |
| hook=out dir=org Gibt an wie die Packete für "out" und "in" verarbeiet werden dh. wenn NAT (Network Address Translation) benutzt wird so werden die Positionen "act=snat"
| |
| hook=in dir=reply sowie "act=dnat" aufgeführt. Aus den nachfolgenden Informationen kann eruiert werden wie NAT durchgeführt wurde. Nachfolgend ein Beispiel mit NAT:
| |
|
| |
| hook=post dir=org act=snat 100.1.10:50194 -> 216.58.216.110:80(10.200.1.1:50194)
| |
| hook=pre dir=reply act=dnat 216.58.216.110:80 -> 10.200.1.1:50194(10.0.1.10:50194)
| |
|
| |
| npu_state=00000000 Zeigt ob eine Session über "hardware acceleration" beschleunigt wurde. Wenn dies der Fall ist resp. möglich wäre wird "npu info:" aufgeführt mit den
| |
| entsprechenden "counters" für die "hardware acceleration" aus denen man entnehmen kann ob die Session über die Hardware Beschleunigung abgearbeitet wurde.
| |
| Nachfolgend ein Beispiel:
| |
|
| |
| npu info: flag=0x00/0x00, offload=0/0, ips_offload=0/0, epid=0/0, ipid=0/0, vlan=0/0
| |
|
| |
| no_ofld_reason Zeigt den Grund wieso eine Session nicht über "hardware acceleration" beschleunigt wird! Nachfolgend ein Beispiel:
| |
|
| |
| no_ofld_reason: redir-to-av redir-to-ips non-npu-intf
| |
|
| |
| user= Wenn eine Session erstellt wird für eine Verbindung im Zusammenhang mit Authentifizierung wird der "user=" sowie die Gruppenzugehörigkeit "group=" sowie
| |
| group= das "authed" Flag gesetzt.
| |
| authed
| |
|
| |
| Nachfolgender Link zeigt ebenfalls diese Information im gleichen Sinne:
| |
|
| |
| http://kb.fortinet.com/kb/documentLink.do?externalID=FD30042
| |
|
| |
| === Wie kann ich unter FortiOS 5.4 herausfinden ob eine Session über den NP Prozessor beschleunigt wird (Offloading)? ===
| |
|
| |
| Um für die einzelnen "Sessions" herauszufinden ob eine "Session" über den NP Prozessor beschleunigt wird, kann dies im Mgmt. Web Interface aktiviert werden. Dazu muss folgendes gewählt werden:
| |
|
| |
| FortiView > All Sessions > [Rechtsklick auf eine Spalte zB "Source"] > [Wähle im "Dropdownmenu" FortiASIC] > [Bestätige mit "Apply"]
| |
|
| |
| [[Datei:Fortinet-1634.jpg]]
| |
|
| |
| Um auf der CLI die detaillierten Informationen einer einzelnen "Sessions" aufzulisten sowie mit deren Informationen herauszufinden ob "Sessions" beschleunigt werden benutze folgender Befehl:
| |
|
| |
| # diagnose sys session list
| |
|
| |
| Unter FortiOS 5.4 wird für eine "Session" wenn diese nicht beschleunigt wird neu der Grund innerhalb "no_ofld" aufgelistet dh. in der "Session" erscheint folgendes:
| |
|
| |
| no_ofld_reason: redir-to-av redir-to-ips non-npu-intf
| |
| no_ofld_reason: local.
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Die Information zB "redir-to-av" indiziert unter "no_ofld_reason" das die Beschleunigung nicht durchgeführt werden konnte
| |
| da für den Traffic ein "redirect" (redir-*) durchgeführt wurde. Für dieses Beispiel zur "Antivirus Engine"!
| |
|
| |
| Ebenfalls indiziert die nachfolgende Position keine Beschleunigung und deckt sich mit "no_ofld":
| |
|
| |
| npu_state=00000000
| |
|
| |
| Wenn eine Session Accelerated wird oder die Möglichkeit dazu besteht wird folgendes ausgegeben:
| |
|
| |
| npu info: flag=0x00/0x00, offload=0/0, ips_offload=0/0, epid=0/0, ipid=0/0, vlan=0/0
| |
|
| |
| Was die einzelnen Positionen in einer Session idizieren resp. bedeuten kann im folgenden Artikel nachgelesen werden:
| |
|
| |
| [[FortiGate-5.4-5.6:FAQ#Welche_Informationen_werden_f.C3.BCr_eine_einzelne_Session_unter_FortiOS_5.4_in_der_.22Session.22_Liste_aufgef.C3.BChrt_und_was_bedeuten_diese.3F]]
| |
|
| |
| Wenn man jedoch auf einem Device arbeitet mit vielen "Sessions" sollte anhand eines gesetzten Filters für "Sessions" gearbeitet werden dh. zB alle "Sessions" für eine bestimmte Policy-ID, Source-IP usw. Dazu kann die Filter Funktion benutzt werden. Die zur Verfügung stehenden Filter sind:
| |
|
| |
| # diagnose sys session filter
| |
| vd Index of virtual domain. -1 matches all.
| |
| sintf Source interface.
| |
| dintf Destination interface.
| |
| src Source IP address.
| |
| nsrc NAT'd source ip address
| |
| dst Destination IP address.
| |
| proto Protocol number.
| |
| sport Source port.
| |
| nport NAT'd source port
| |
| dport Destination port.
| |
| policy Policy ID.
| |
| expire expire
| |
| duration duration
| |
| proto-state Protocol state.
| |
| clear Clear session filter.
| |
| negate Inverse filter.
| |
|
| |
| Zum Beispiel um einen bestimmten Port oder eine Destination Adresse zu Filtern müssen folgende Befehle verwendet werden:
| |
|
| |
| # diagnose sys session filter dport [Port]
| |
| # diagnose sys session filter dst [Destination IPv4 Adresse]
| |
|
| |
| Den Filter kann mit folgendem Befehl überprüft werden:
| |
|
| |
| # diagnose sys session filter
| |
| session filter:
| |
| vd: any
| |
| proto: any
| |
| proto-state: any
| |
| source ip: any
| |
| NAT'd source ip: any
| |
| dest ip: '''[Destination IPv4 Adresse]'''
| |
| source port: any
| |
| NAT'd source port: any
| |
| dest port: '''[Port]'''
| |
| policy id: any
| |
| expire: any
| |
| duration: any
| |
|
| |
| Der Filter ist jetzt gesetzt kann nun benutzt werden, um die betreffende "Session/s" aufzulisten:
| |
|
| |
| # diagnose sys session list
| |
|
| |
| Den "Session" Filter kann mit folgendem Befehl gelöscht oder zurückgesetzt werden:
| |
|
| |
| # diagnose sys session filter clear
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Wird dieser Befehl "ohne" Filter ausgeführt so werden sämtliche Sessions gelöscht. Aus diesem Grund ist dieser Befehl
| |
| mit Vorsicht auszuführen! Dies bedeutet ebenfalls: Wenn bestimmte "sessions" gelöscht werden sollen müssen diese
| |
| vorgängig mit einem entsprechenden Filter gesetzt werden. Dieser Filter kann nachträglich mit "diagnose sys session
| |
| filter" kontrolliert werden! Wenn nachträglich "diagnose sys session clear" ausgeführt wird, werden sämgliche "sessions"
| |
| gemäss dem gesetzten Filter für "diagnose sys session filter" gelöscht!
| |
|
| |
| Danach kann wiederum kontrolliert werden ob dies durchgeführt wurde:
| |
|
| |
| # diagnose sys session filter
| |
|
| |
| Zusätzlich wenn der FortiGate Device über einen NP6 Prozessor verfügt über CLI überprüft werden welche Sessions dem NP6 Prozessor übergeben werden. Um die ID des NP6 zu verifizieren kann auf CLI unter FortiOS 5.4 folgendes benutzt werden:
| |
|
| |
| # get hardware npu np6 [dce | ipsec-stats | port-list | session-stats | sse-stats]
| |
|
| |
| Die verschiedenen Optionen haben folgende Bedeutung:
| |
|
| |
| dce NP6 - non-zero subengine drop counters.
| |
| ipsec-stats - NP6 IPsec offloading statistics.
| |
| port-list - NP6 port list.
| |
| session-stats - NP6 session offloading statistics counters.
| |
| sse-stats - show hardware session statistics counters
| |
|
| |
| Danach kann anhand der ID des NP6 eine entsprechende Abfrage durchgeführt werden zB:
| |
|
| |
| # diagnose npu np6 sse-stats [ID des NP6 zB "0"]
| |
| Counters SSE0 SSE1 Total
| |
| --------------- --------------- --------------- ---------------
| |
| active 35189 34937 '''70126'''
| |
| insert-total 134611036 134624481 269235517
| |
| insert-success 134611036 134624481 269235517
| |
| delete-total 134575847 134589544 269165391
| |
| delete-success 134575847 134589544 269165391
| |
| purge-total 0 0 0
| |
| purge-success 0 0 0
| |
| search-total 3799074893 3871207649 3375315246
| |
| search-hit 3580496168 3652493853 2938022725
| |
| --------------- --------------- --------------- ---------------
| |
| pht-size 8421376 8421376
| |
| oft-size 8355840 8355840
| |
| oftfree 8355763 8355758
| |
| PBA 3001
| |
|
| |
| # diagnose npu np6 sse-stats [ID des NP6 zB "1"]
| |
| Counters SSE0 SSE1 Total
| |
| --------------- --------------- --------------- ---------------
| |
| active 37977 37861 '''75838'''
| |
| insert-total 134842807 134847764 269690571
| |
| insert-success 134842807 134847764 269690571
| |
| delete-total 134804830 134809903 269614733
| |
| delete-success 134804830 134809903 269614733
| |
| purge-total 0 0 0
| |
| purge-success 0 0 0
| |
| search-total 3890365012 4023832938 3619230654
| |
| search-hit 3670809994 3804413458 3180256156
| |
| --------------- --------------- --------------- ---------------
| |
| pht-size 8421376 8421376
| |
| oft-size 8355840 8355840
| |
| oftfree 8355749 8355755
| |
| PBA 2983
| |
|
| |
| Der "output" zeigt die Anzahl der "half" Sessions für einen definierten NP6. Eine typische Sessions basiert auf zwei "half" Sessions dh. "ingress" und "egress". Das hier gezeigte Beispiel zeigt 70126 "half" Sessions auf "NP6_0" sowie 75838 "half" Session auf "NP6_1"! Unter FortiOS 5.4 ist es möglich für eine Firewall Policy Rule ein "accounting" zu aktiveren resp. zu deaktivieren. Per Standard ist das "accounting" aktiviert (enable-by-log) sofern das "logging" für die entsprechende Firewall Policy Rule aktiviert wurde:
| |
|
| |
| # config system np6
| |
| # edit np6_0
| |
| # set per-session-accounting [disable | all-enable | enable-by-log]
| |
| # end
| |
|
| |
| Wenn das "logging" auf einer Firewall Policy Rule keinen Einfluss haben soll auf die "accounting" Funktion kann die Option "all-enable" gesetzt werden!
| |
|
| |
| === Was bedeutet "Offloading" Sessions" unter FortiOS 5.4 und wie funktioniert die Funktion "Offloading"? ===
| |
|
| |
| FortiGate’s und auch andere Hersteller Typen benutzen für die Acceleration ein "offloading". Offloading bedeutet: Wenn ein neues Paket/Session gesendet wird so wird dieses als "diry" gekennzeichnet und somit über den CPU abgearbeitet. Wenn weitere Pakete folgen dh. mit gleicher Source, Destination usw. wird dies durch das "offloading" erkannt und das Paket/Session wird als "may dirty" gekennzeichnet. Dadurch wird für diese Pakete/Sessions ein "offloading" durchgeführt dh. es wird nicht mehr über den CPU abgearbeitet sondern durch das "offloading" (NP). Wenn sich an der Firewall Policy oder an der Konfiguration etwas ändert wird daS Paket abermals als "dirty" gekennzeichnet und somit wird eine Verarbeitung über CPU erzwungen (kein offloading) usw. Nachfolgende Grafik visualisiert diesen Paket Flow dirty / may dirty):
| |
|
| |
| [[Datei:Fortinet-1633.jpg]]
| |
|
| |
| Der zuständige ASIC-Prozessor für dieses „Offloading“ ist der NP Prozessor zB. bei der FG-60D/90D ist ein "NP4Lite" Prozessor im Einsatz. Weitere Informationen darüber welcher Device über welchen Prozessor, Memory sowie NP verfügt siehe nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.4-5.6:FAQ#Wo_finde_ich_eine_Uebersicht_welcher_FortiGate_Device_zB_.C3.BCber_wieviel_.22Memory.22_verf.C3.BCgt.2C_ein_.22SOC.22_und.2Foder_.22NP.22_verbaut_ist.3F]]
| |
|
| |
| Ein "offloading" auf einer FortiGate muss nicht aktiviert werden sondern ist in jeder Firewall Policy Rule per Standard aktiviert durch folgende Konfiguration:
| |
|
| |
| # config firewall policy
| |
| # edit [Policy ID Nummer]
| |
| # set auto-asic-offload [enable / disable]
| |
| # end
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Es muss berücksichtig werden, dass bei einem Troubleshooting nicht mehr alle Pakete/Sessions in einem
| |
| "Paket Sniffer" (diagnose sniffer Paket) angezeigt werden. Der Grund ist der folgende: Solange die
| |
| Paket als "dirty" gekennzeichnet" werden werden diese über den CPU abgearbeitet und sind im "kernel"
| |
| über den "Paket Sniffer" ersichtlich. Werden die Paket als "may dirty" gekennzeichnet dh. es wird ein
| |
| "offloading" durchgeführt werden die Paket direkt zum NP gesendet dh. nicht mehr über den Kernel und
| |
| somit sind die Paket für den "Paket Sniffer" nicht mehr ersichtlich.
| |
|
| |
| Ebenso ist betreffend UTM Features folgendes zu berücksichtigen: Wenn für eine Firewall Policy Rule ein Security Profile konfiguriert wird dh. zB. "Antivirus" so wird kein "offloading" mehr durchgeführt, da das Paket/Session durch den "CP" (Content Prozessor) abgearbeitet werden muss und somit kann das Paket nicht den direkten Weg über den "NP" Prozessor wählen. Somit anstelle die Option "auto-asic-offload" für eine Firewall Policy Rule zu deaktiveren um "offload" zu deaktivieren, kann das gleiche erreicht werden in dem vorübergehend für die entsprechende Firewall Policy ein Security Profile aktiviert wird. Somit muss festgestellt werden: Ist für eine Firewall Policy Rule ein UTM Features aktiviert wird kein "offloading" mehr durchgeführt!
| |
|
| |
| === Wie beeinflusst unter FortiOS 5.4 die Option "check-protocol-header" eine Session sowie das "Offloading"? ===
| |
|
| |
| Unter "system global" existiert eine Option "check-protocol-header". Diese Option ist zuständig wie die "protocol headers" innerhalb des "TCP Headers" untersucht werden. Die Option kann folgendermassen gesetzt werden:
| |
|
| |
| # config system global
| |
| # set check-protocol-header [loose | strict]
| |
| # end
| |
|
| |
| Die zwei zur Verfügung stehenden Optionen haben folgende Bedeutung:
| |
|
| |
| • loose — Das FortiOS untersucht im "basic" Verfahren die "protocol headers" in dem das FortiOS überprüft ob der
| |
| "TCP Header" Teil einer Session ist. Ebenso umfasst die "basic" Ueberprüfung die Länge des Layer 4 "TCP
| |
| Headers", des "IP Headers", die "IP Version", die "IP Checksu"m sowie ob die "IP Optionen" korrekt
| |
| gesetzt sind.
| |
|
| |
| • strict — Das FortiOS führt sämtliche "basic" Verfahren durch plus ob die ESP Packete über die korrekte Sequenz
| |
| Nummer verfügen sowie SPI und Datalänge.
| |
|
| |
| Per Standard ist die Option auf "loose" gesetzt und und somit beeinflusst "loose" das "Offloading" nicht. Wird die Option auf "strict" gesetzt wird das "Offloading" resp. die "Beschleunigung" (Acceleration) komplett deaktiviert da die zusätzlichen ESP Packete sowie SPI und Datenlänge untersucht werden. Wenn die Option "strict" gesetzt wird erscheint aus diesem Grund ein entsprechender Hinweis.
| |
|
| |
| # config system global
| |
| # set check-protocol-header strict
| |
| # end
| |
| Warning: This setting may break compatibility with some vendors and applications, cause loss of existing
| |
| sessions,reduce overall system performance, drop ESP traffic from VPN tunnels terminated at this unit,
| |
| and disable all hardware acceleration!
| |
| Do you want to continue? (y/n)
| |
|
| |
| Somit sollte "strict" nur dann benutzt werden wenn die zusätzlichen Verfahren wie ESP Sequenz Nummer, SPI und Datenlänge aus Security technigschen Gründen verifiziert werden müssen.
| |
|
| |
| === Gibt es eine Möglichkeit unter FortiOS 5.4 die Session Table und Resourcen (CPU/Memory) zu optimieren? ===
| |
|
| |
| Die Einstellungen eines FortiOS betreffend des Verhalten der Sessions dh. des Traffic Flow ist bei kleinen Devices gleich wie bei grösseren Devices. Die Einstellungen/Optionen die das Verhalten des Traffic Flow resp. der Sessions beeinflusst dh. ob eine Session beendet wird sind die Folgenden:
| |
|
| |
| # config system global
| |
| # set tcp-halfclose-timer [Default Wert 120 Sekunden]
| |
| # set tcp-halfopen-timer [Default Wert 10 Sekunden]
| |
| # set tcp-timewait-timer [Default Wert 1 Sekunden]
| |
| # set udp-idle-timer [Default Wert 180 Sekunden]
| |
| # end
| |
|
| |
| Jeder Traffic Flow der durch das FortiOS abgearbeitet wird, steht im Zusammenhang mit einer Session. Je weniger Sessions verarbeitet werden desto weniger CPU sowie Memory werden benötigt. Um diese Sessions resp. die Session Table eines FortiOS Devices zu reduzieren gibt es vers. Ansätze. Einer davon ist die Session nach einer bestimmten Zeit zu löschen da diese nicht mehr gebraucht werden. Wenn ein Traffic Flow durch das FortiOS abgearbeitet wird, wird die entsprechende Session in der Session Table geschrieben. Wird diese Session nicht mehr benutzt wird diese nicht einfach gelöscht sondern es beginnt ein "timer" für die Session zu laufen. Ist dieser "timer" abgelaufen da die Session in der Session Table nicht mehr benutzt wird so wird diese aus der Session Table gelöscht. Dies gilt für "TCP" und/oder "UDP" Sessions. Somit stehen alle Sessions im Zusammenhang mit diesen Session "timer". Je tiefer die "timer" desto schneller werden die nicht mehr gebrauchten Sessions gelöscht und desto weniger Resourcen (RAM) werden benötigt. Ebenso tragen sogenannten "TCP stuck Sessions" in "half-opened", "half-closed" oder "even established" Status dazu bei, dass Resourcen zur Verfügung gestellt werden müssen (RAM). Auch diese "TCP stuck Sessions" können schneller durch den "timer" aus der Session Table entfernt werden und tragen somit bei weniger Resourcen zu binden (RAM). Mögliche Werte um die Session Table zu veringern können zB folgendermassen aussehen:
| |
|
| |
| # config system global
| |
| # set tcp-halfclose-timer 30
| |
| # set tcp-halfopen-timer 30
| |
| # set tcp-timewait-timer 0
| |
| # set udp-idle-timer 60
| |
| # end
| |
|
| |
| Nachfolgend eine grafische Darstellung dieser Funktionen:
| |
|
| |
| [[Datei:Fortinet-1417.jpg]]
| |
|
| |
| '''tcp-timewait-timer'''
| |
| Auf dem Wert "tcp-timewait-timer" existiert eine Verzögerung von 10 Sekunden dh. wenn der Wert auf "0 gesetzt wird, so wir
| |
| die Session 10 Sekunden geöffnet gehalten um nachträglich nach 10 Sekunden geschlossen zu werden!
| |
|
| |
| '''halfclose-timer'''
| |
| Beim Wert "halfclose-timer" ist folgendes zu berücksichtigen: Wenn ein Client eine Session initiert und nach der Datenübertragung
| |
| der Gegenstelle übermittelt, dass diese beendet ist geschieht folgendes:
| |
|
| |
| '''Client Initiates Close''' {[FIN,ACK]----------------->}
| |
| {<---------------------[ACK]}
| |
|
| |
| Durch "FIN,ACK" wird der Gegenstelle mitgeteilt "Datenübertragung beendet bitte bestätigen". Danach sendet die Gegenstelle ein
| |
| "Acknoledge" (ACK) als Bestätigung. Der Zustand der Session auf dem FortiOS ist nun "halfclose" und der Timer beginnt zu laufen
| |
| (Standard 120 Sekunden):
| |
|
| |
| '''Connection Is Half-Closed''' {<---------------[more data]}
| |
| {[Data ACK]---------------->}
| |
|
| |
| Sobald der "timer" für "halfclose" abgelaufen ist (Standard 2 Minuten; 120 Sekunden) wird die Session geschlossen:
| |
|
| |
| '''Connection's''' {<-----------------[FIN,ACK]}
| |
| '''Other Half" Closes''' {[ACK]--------------------->}
| |
|
| |
| Bestimmte Protokolle wie zB DNS tragen dazu bei das viele Sessions augebaut werden müssen. Diese spezifischen Protokolle sind nur kurz in Gebrauch tragen jedoch durch Ihre "timer" zur Auslastung bei. Diese spezifischen Protokolle sollten nicht über die "globalen" Optionen verändert werden sondern im Protokoll selber spezifisch dh. Anstelle des Standard Definition von zB DNS in einer Firewall Policy Rule zu arbeiten wird ein spezifisches Service Objekt für DNS erstellt in dem die verschiedenen "timer" spezfisch für das Objekt gesetzt werden können. Das gleiche gilt für zB SIP dh. wir die globale Definition "udp-idle-timer 180" auf eine kleineren Wert gesetzt kommt es bei vielen SIP Provider zu Problemen da durch zB die Definition 60 Sekunden Gespräche vorzeitig beendet werden. Um ein Service Objekt mit spezfischer "timer" Konfiguration zu erstellen um dieses in einer Firewall Policy zu benutzen führe folgendes durch:
| |
|
| |
| # config firewall service custom
| |
| # edit [Name des Service zB "UDP-53" oder "UDP-5060"]
| |
| # set tcp-halfclose-timer [Default 0 = Wert von "config system global"; Gültig Werte "1 to 86400" Sekunden]
| |
| # set tcp-halfopen-timer [Default 0 = Wert von "config system global"; Gültig Werte "1 to 86400" Sekunden]
| |
| # set tcp-timewait-timer [Default 1; 0 = Wert von "config system global"; Gültig Werte "0 to 300" Sekunden]
| |
| # set udp-idle-timer [Default 0 = Wert von "config system global"; Gültig Werte "1 to 86400" Sekunden]
| |
| # end
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Wenn eine erhebliche Menge an DNS-Transaktionen über die FortiGate abgewickelt werden und "Virutal IP Address"
| |
| oder "DNS Server" werden vom FortiOS nicht benützt, kann der "dns-udp session helper" gelöscht werden. Das
| |
| entfernen des "dns-udp session helper" reduziert sowie limitiert die Kernel Resourcene für den DNS Traffic.
| |
|
| |
| # show system session-helper
| |
|
| |
| # edit 12 (1)
| |
| # set name dns-udp
| |
| # set port 53
| |
| # set protocol 17
| |
| # next
| |
|
| |
| # config system session-helper
| |
| # delete 12
| |
| # end
| |
|
| |
| Ebenfalls ist es möglich für einen Service ein "TTL" (Time To Live) zu setzen. Diese Konfiguration steht jedoch nicht im Zusammenhang mit den "timers" ausgenommen "Half-Closed". Dies bedeutet: Ist ein Traffic Flow im Status "Half-Closed" kommt "TTL" zum Zuge. Weitere Informationen zu "TTL" siehe nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.4-5.6:FAQ#Wie_kann_ich_unter_FortiOS_5.4_f.C3.BCr_eine_Session_die_.22TTL.22_.28Time_To_Live.29_konfigurieren_und_was_ist_dabei_zu_beachten.3F]]
| |
|
| |
| === Wie kann ich unter FortiOS 5.4 für eine Session die "TTL" (Time To Live) konfigurieren und was ist dabei zu beachten? ===
| |
|
| |
| Wenn für eine Session resp. für einen Service zB SIP die "TTL" (Time to Live) angepasst werden muss so sollten in erster Linie die "timers" mitberücksichtigt werden. Weitere Informationen betreffend "timers" siehe nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.4-5.6:FAQ#Gibt_es_eine_M.C3.B6glichkeit_unter_FortiOS_5.4_die_Session_Table_und_Resourcen_.28CPU.2FMemory.29_zu_optimieren.3F]]
| |
|
| |
| Im vorhergehenden Artikel wird beschrieben das die "TTL" für eine Session dann zum Zuge kommt wenn die Session resp. der Traffic sich im "Half-Closed" Status befindet. Die "TTL" einer Session resp. einer Traffic Flows sollte dann angepasst werden, wenn die Verbindung einer Session aus unerklärlichen Gründen beendet wird. Dabei spielen verschiedene Umstände eine Rolle. In bestimmten Fällen kann es dazu kommen, dass eine Session betreffend "TTL" kleiner ist als die des Servers/Clients. Die Auswirkungen sind die Folgenden: Das FortiOS beendet die Session da im "Half-Closed" Status die "TTL" der Session abgelaufen ist. Der Server/Client versucht jedoch diese Session wieder zu benutzen die auf Server/Client Seite immer noch aktiv ist da kein RST (reset) gesendet wurde. Dabei sendet der Server/Client zum FortiOS Traffic der jedoch nicht mehr beantwortet werden kann da die Session auf dem FortiOS nicht mehr existiert. Da der Traffic des Servers/Clients zum FortiOS nicht mehr beantwortet wirde beendet auch der Server/Client die Session und es kommt zu einem unerwünschten Unterbruch. Um die Globalen "TTL" Informationen für Sessions aufzulisten kann nachfolgender Befehl benutzt werden:
| |
|
| |
| # get system session-info ttl
| |
| list session timeout:
| |
| Default timeout=3600
| |
|
| |
| Wenn das "TTL" in einer Client und/oder Server Konstellation unterschiedlich sind kann das FortiOS über die Firewall Policy angewiesen werden nach Ablauf der "TTL" im "Half-Close" Status ein explizites RST (reset) zu senden. Damit wird dem Client und/oder Server durch das RST explizit mitgeteilt, dass die Session beendet ist. Dies ist ab FortiOS 5.2 möglich durch die nachfolgende Konfiguration, die in der Firewall Policy Rule für diesen Traffic Flow der durch die Client/Server benutzt wird:
| |
|
| |
| # config firewall policy
| |
| # edit [ID der gewünschten Firewall Policy Rule zB "1"]
| |
| # set timeout-send-rst enable
| |
| # end
| |
|
| |
| Wenn die Session "TTL" für einen spezifische Session resp. Service/Port geändert werden soll, sollte in erster Linie die Globale Einstellung der "TTL" nicht erhört werden da dadurch die Globale "TTL" für alle Service/Port geändert wird. Der Grund ist der Folgende: Sämtliche Service/Port beinhalten in Ihrer Konfiguration für "TTL" sowie "timers" die Konfiguration "0" was auf die Globalen Einstellungen verweist:
| |
|
| |
| '''Globale "TTL" Konfiguration'''
| |
|
| |
| # config system session-ttl
| |
| # set default [3600]
| |
| # config port
| |
| # edit [Gebe einen Integer an zB 1]
| |
| # set end-port [Gebe den Endport an]
| |
| # set protocol [Gebe das Protokol an zB tcp]
| |
| # set start-port [Gebe den Startport an]
| |
| # set timeout [Gebe das Timout an in Sekunden oder never]
| |
| # end
| |
| # end
| |
|
| |
| Durch die "port" Konfiguration in den Globalen Einstellungen ist es möglich zusätzlich einen Port Bereich sowie für diesen ein "timeout" zu konfigurieren. Dies sollte jedoch nur dann durchgeführt werden, wenn über mehrere Ports die "TTL" konfiguriert werden soll. Wenn nur für einen spezifischen Port/Service die "TTL" und/oder "timers" konfiguriert werden soll, sollte dies explizit im spezifischen Port/Service durchgeführt werden. Dabei sollte folgendes beachtet werden: Wenn ein Port/Service über mehrer Firewall Policy Rule's benützt wird jedoch das Problem nur auf einer spezifischen Firewall Policy Rule existiert sollte für diese Firewall Policy Rule explizit ein neuer Service/Port konfiguriert werden damit so gewährleistet ist, dass die restlichen Firewall Policy Rules nicht beinträchtigt werden. Um einen spezifischen Port/Service zu konfigurieren mit dessen explizit konfigurierten "TTL" sowie "timers" führe folgendes auf der CLI durch:
| |
|
| |
| '''Port/Service Spezifische "TTL" Konfiguration'''
| |
|
| |
| # config firewall service custom
| |
| # edit [Name des Service zB "UDP-5060"]
| |
| # set category [Setze sofern gewünscht eine entsprechende Kategorie; für mehr Info benutze ?]
| |
| # set comment [Setze Optional einen entsprechenden Kommentar]
| |
| # set protocol [ICMP | ICMP6 | IP | TCP/UDP/SCTP]
| |
| # set protocol-number [Setze das entsprechende Protokoll dh. zB für TCP "6" oder zB UDP "17"]
| |
| # set session-ttl [Default 0 = Wert von "config system session-ttl"; Gültig Werte "300 to 604800" Sekunden]
| |
| # set tcp-halfclose-timer [Default 0 = Wert von "config system global"; Gültig Werte "1 to 86400" Sekunden]
| |
| # set tcp-halfopen-timer [Default 0 = Wert von "config system global"; Gültig Werte "1 to 86400" Sekunden]
| |
| # set tcp-timewait-timer [Default 1; 0 = Wert von "config system global"; Gültig Werte "0 to 300" Sekunden]
| |
| # set udp-idle-timer [Default 0 = Wert von "config system global"; Gültig Werte "1 to 86400" Sekunden]
| |
| # set tcp-portrange [Setze den entsprechenden TCP Port oder Port Range zB 23 oder 22-23]
| |
| # set udp-portrange [Setze den entsprechenden UDP Port oder Port Range]
| |
| # set visibility [enable | disable]
| |
| # end
| |
|
| |
| Zusätzlich ist es auch möglich die "TTL" explizit für spezifische Firewall Policy Rule zu konfigurieren. Dabei ist folgendes zu beachten: Wenn in der Firewall Policy Rule mehrere Ports/Services definiert sind gelten für alle definierten Ports/Services die konfigurierte "TTL". Auch in so einem Fall ist es ratsam die Firewall Policy Rule in einzelne Ports/Services zu Splitten um nicht betroffenen Ports/Services zu beinträchtigen. Die entsprechende Konfiguration für eine Firewall Policy Rule wird auf der CLI folgendermassen durchgeführt:
| |
|
| |
| # config firewall policy
| |
| # edit [ID der gewünschten Firewall Policy Rule zB "1"]
| |
| # set session-ttl [Default 0 = Wert von "config system session-ttl"; Gültig Werte "300 to 604800" Sekunden]
| |
| # end
| |
|
| |
| == Inspection Mode ==
| |
|
| |
| === Was hat sich unter FortiOS 5.4 betreffend "Security Profiles" und "Inspection Mode" grundsätzlich geändert? ===
| |
|
| |
| Für FortiOS 5.2 und tiefer wurde der "Inspection Mode" dh. "proxy mode" und/oder "flow mode" über die "Security Profiles" gesteuert. Dies bedeutet: Es gab keine "Globale" Einstellung um den Mode eben "proxy" und/oder "flow" Mode zu bestimmen. Dies ist nun möglich dh. der "Inspecton Mode" kann nun "Global" konfiguriert werden und gilt als Konfiguration für sätmliche bestehenden und neu erstellten "Security Profiles". Die Konfiguration wird unter Mgmt. Web Interface über folgender Position konfiguriert:
| |
|
| |
| [[Datei:Fortinet-1620.jpg]]
| |
|
| |
| [[Datei:Fortinet-1621.jpg]]
| |
|
| |
| Wie man sieht wird bei dieser Konfiguration ein Hinweis eingeblendet dh. "Warning" um darauf hinzuweisen, dass dieser Wechsel des "Inpsection Mode" zur Folge hat, dass entsprechende "Security Profiles" umgeschrieben werden. Dieser Hinweis dh. die "Warning" wird nur über Mgmt. Web Interface angzeigt dh. wird die Konfiguration mit nachfolgenden Kommando über CLI durchgeführt, wird kein entsprechender Hinweis gezeigt:
| |
|
| |
| # config system settings
| |
| # set inspection-mode [proxy | flow]
| |
| # end
| |
|
| |
| Somit steht neu der "Inspection Mode" für jede VDOM im "vdom" Mode individuell zur Verfügung und kann seperat konfiguriert werden da die Option unter "config system settings" verfügbar ist dh. keine "Globale" Konfiguration sondern für jede VDOM konfigurierbar:
| |
|
| |
| # config vdom
| |
| # edit [VDOM Name zB "root"]
| |
| # config system settings
| |
| # set inspection-mode [proxy | flow]
| |
| # end
| |
|
| |
| Wenn der "Inspection Mode" geändert wird dh. von "proxy mode" auf "flow mode" oder umgekehrt so führt das FortiOS 5.4 im Hintergrund folgende Modifikationen automatisch durch:
| |
|
| |
| -> Für jedes "Antivirus" Profile wird das Kommando "set inspection-mode [proxy | flow]" durchgeführt.
| |
|
| |
| -> Für jedes "WebFilter" Profile wird das Kommando "set inspection-mode [proxy | flow]" durchgeführt.
| |
|
| |
| -> Wenn Global unter "config system settings" von "proxy mode" auf "flow mode" umkonfiguriert wird so
| |
| wird für jede "Firewall Policy Rule" für die ein "Security Profile" im "proxy mode" existiert dieses
| |
| entfernt!
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Wenn die "proxy mode" Security Profiles in den Firewall Policy Rules entfernt werden wie beschrieben so ist diese
| |
| Konfiguration nicht mehr Rückgängig zu machen dh. es ist umbedingt empfohlen vorgängig ein Backup der Konfiguration
| |
| durchzuführen. Ebenso empfiehlt es sich über Mgmt. Console den folgenden "debug" für die CLI zu aktivieren um so zu
| |
| sehen was genau bei der Aenderung durchgeführt wird:
| |
|
| |
| # diagnose debug cli -1
| |
|
| |
| Desweiteren ist ebenfalls zu berücksichtigen "was" mit den Security Profiles "Antivirus" sowie "WebFilter" durchgeführt wird, wenn der "Inspection Mode" geändert wird. Nachfolgende Tabelle zeigt au welche Unterschiede in den verschiedenen "Inspection Mode" für "Antivirus" sowie "WebFilter" Security Profiles existieren:
| |
|
| |
| [[Datei:Fortinet-1622.jpg]]
| |
|
| |
| [[Datei:Fortinet-1623.jpg]]
| |
| [[Datei:Fortinet-1624.jpg]]
| |
|
| |
| Nichts desto trotz und obwohl die Konfiguration unter "config system settings" konfiguriert wird, steht in den "Security Profiles" die "proxy mode" und "flow mode" unterstützten die Option per Standard bei Folgenden "Security Profiles" zur Verfügung um individuell eine Konfiguration durchzuführen:
| |
|
| |
| # config [webfilter | antivirus] profile
| |
| # edit [Name des Profiles]
| |
| # set inspection-mode [proxy | flow]
| |
| # end
| |
|
| |
| Somit fragt man sich, ob diese "Security Profiles" dh. "WebFilter" und/oder "Antivirus" die einzigen die individuell konfiguriert werden können da andere "Security Profiles" ebenfalls im "proxy mode" und/oder "flow mode" unterstüzen. Nachfolgende Tabelle zeigt auf welche "Security Profiles" welchen "Inspection Mode" unterstützen:
| |
|
| |
| [[Datei:Fortinet-1625.jpg]]
| |
|
| |
| Somit kann auch ein "DLP" sowie ein "Spamfilter" auf "flow mode" konfiguriert werden jedoch sind diese per Standard im "proxy mode" und werden bei Aenderung des "Globalen" Mode unter "config system settings" nicht in "flow mode" unkonvertiert und verbleiben somit im "proxy mode":
| |
|
| |
| # config dlp sensor
| |
| # edit [Name des Profiles]
| |
| # set flow-based [enable | disable]
| |
| # end
| |
|
| |
| # config spamfilter profile
| |
| # edit [Name des Profiles]
| |
| # set flow-based [enable | disable]
| |
| # end
| |
|
| |
| Wenn der "Inspection Mode" für verschiedenen "Security Profiles" individuell konfiguriert wird ist zu berücksichtigen, was durchgeführt wird in einer "Firewall Policy Rule" wenn beide "Inspection Mode" benützt werden dh. "proxy mode" und/oder "flow mode". Weitere Informationen dazu siehe nachfolgenden Artikel:
| |
|
| |
| [[FortiGate-5.4-5.6:FAQ#Wenn_ich_f.C3.BCr_eine_.22Firewall_Policy_Rule.22_unter_FortiOS_5.4_verschiedenen_.22Inspection_Mode.22_ben.C3.BCtze_.28flow.2Fproxy.29_was_gilt.3F]]
| |
|
| |
| === Wird unter FortiOS 5.4 betreffend "deep-inspection" für Transparent/Explizit Proxy die TLS 1.2 Verschlüsselung unterstützt? ===
| |
|
| |
| TLS 1.2 wird grundsätzlich im Zusammenhang mit "deep-inspection" für Explizit/Transparent Proxy auf einer FortiGate ab FortiOS 5.2.1 unterstützt! TLS 1.2 für SSL Offloading steht ab FortiOS 5.2.8 zur Verfügung. Somit werden folgenden Funktionen im Zusammenhang mit TLS 1.2 unter FortiOS 5.4 unterstützt:
| |
|
| |
| • Transparent proxy-based SSL deep-inspection
| |
| • Explicit-proxy-based SSL deep-inspection
| |
| • SSL offload (LoadBalancer VIP)
| |
| • Wan Opt SSL tunnels
| |
| • SIP over SSL/TLS
| |
|
| |
| == Cluster Mode ==
| |
|
| |
| === Kann ich unter FortiOS 5.4 mit unterschiedlichen FortiGate Devices einen Cluster betreiben? ===
| |
|
| |
| Das FortiGate FortiOS Cluster Protokoll (FGCP) basiert grundsätzlich auf der Hardware. Somit ist es nicht möglich einen FortiGate Cluster mit unterschiedlicher Hardware zu betreiben. Es gilt als Voraussetzung, dass beide FortiGate Devices für einen Cluster Mode identisch sind und über die exakt gleiche Hardware Verfügung und auch gleich bestückt sind was wiederum folgendes bedeutet: Werden identische FortiGate Devices für einen Cluster Mode betrieben muss zusätzlich folgendes berücksichtigt werden:
| |
|
| |
| • Gleiche Hardware in SKU, Revision und Generation
| |
| • Gleiche Konfiguration/Grösse für die Harddisk (Formatiert/Unformatiert)
| |
| • Gleiche Zusatz Karten (AMC / FMC)/Interfaces
| |
| • Gleicher Mode für Switch Mode
| |
| • Gleiche FortiOS Firmware
| |
| • Gleicher Operation Mode (Transparent/NAT)
| |
| • Gleicher VDOM Mode
| |
|
| |
| Wie in diesem Artikel erklärt, müssen Grundsätzlich beide FortiGate Device für einen Cluster Mode über die gleiche SKU, Revision sowie Generation verfügen. Dies bedeutet: Ein FortiGate Device basiert auf diesen Angaben dh. SKU, Revision und Generation. Fortinet kennt keine EAN Code der den FortiGate Device eindeutig identifiziert. Wenn somit Fortinet ein Modell modifiziert, bleibt die SKU bestehen und die Revision sowie Generation wird erhöht. Somit existieren zB für FG-60D folgende Modelle wobei es sich immer um die gleiche SKU handelt:
| |
|
| |
| '''SKU''' '''Revision''' '''Generation'''
| |
|
| |
| FG-60D P12397-02-06 1
| |
| FG-60D P14482-03-01 2
| |
| FG-60D P14482-03-04 2
| |
| FG-60D P14482-03-02 2
| |
|
| |
| Dieser Umstand spielt dann eine Rolle, wenn nachträglich eine bestehende Standalone Installation erweitert werden möchte mit einer Cluster Mode Installation. Einen FortiGate Device kann nicht anhand der Revision und Generation nachträglich bestellt werden dh. auch ein Distributor hat keine Informationen darüber, welche FortiGate Revision und Generation momentan ausgeliefert werden. Die Revsion kann wie folgt über die CLI verifiziert werden:
| |
|
| |
| # get system status | grep Part-Number
| |
| system Part-Number: P14482-03
| |
|
| |
| Die Generation eines Fortinet Devices kann nicht über die CLI verifiziert werden dh. wenn diese Verifiziert werden muss so muss die entsprechende Generation über ein Support Ticket abgeklärt werden. Somit ist eine nachträglicher Erweiterung einer Standalone Installation auf eine Cluster Mode Installation schwierig. Ausgehend davon, dass die FortiGate Devices zwar identisch sind (Hardware, Interfaces, Disk usw) jedoch über verschiedenen Revisions und Generations verfügen, kann dennoch ein Cluster Mode konfiguriert werden anhand nachfolgenden Befehls in der CLI, der das Cluster Protokoll (FGCP) anweist, die Revision und Generation zu ignorieren:
| |
|
| |
| # execute ha ignore-hardware-revision status
| |
| The ignore mode is disabled
| |
|
| |
| # execute ha ignore-hardware-revision enable
| |
| # execute ha ignore-hardware-revision status
| |
| The ignore mode is enabled
| |
|
| |
| Dies ist zwar eine Möglichkeit wird jedoch von Fortinet nicht empfohlen für einen einwandfreien Betrieb des Cluster Mode. Diesem Umstand ist auch dann Rechnung zu tragen wenn ein FortiGate Device betreffend eines Defektes über ein Support Ticket (RMA) ausgetauscht wird. Dies bedeutet: Wir empfehlen im Support Ticket zu erwähnen dh. das der FortiGate Device in einem Cluster Mode betrieben wird, damit Fortinet den richtigen Device mit der korrekten Revision und Generation zustellt. Wenn der FortiGate Device offiziell als Cluster Mode bestellt wurde und Fortinet verfügt nicht mehr für einen RMA Austausch über einen FortiGate Device mit der gleichen Revision sowie Generation, stellt Fortinet zwei identische FortiGate Devices zur Verfügung um den Umstand der Revision und Generation Rechnung zu tragen. Fortinet hat nachfolgendes Dokument unter FortiOS 5.2 released um genauer aufzuzeigen wie das Cluster Protokoll FGSP Funktioniert und ist nachwievor gültig für FortiOS 5.4:
| |
|
| |
| [[Datei:FGSP_Configuration_Guide.pdf]]
| |
|
| |
| === Wie kann ich unter FortiOS 5.4 für FortiGate Devices einen Cluster Mode konfigurieren? ===
| |
|
| |
| Wenn man einen Cluster Mode für Fortigate Devices konfigurieren möchte, gilt als Voraussetzung folgender Artikel:
| |
|
| |
| [[FortiGate-5.4-5.6:FAQ#Kann_ich_unter_FortiOS_5.4_mit_unterschiedlichen_FortiGate_Devices_einen_Cluster_betreiben.3F]]
| |
|
| |
| Wenn diese Voraussetzungen gegeben sind kann ein Cluster Mode konfiguriert werden. In unserem Beispiel gehen wir von folgendem Beispiel aus:
| |
|
| |
| __________
| |
| | |
| |
| | INTERNET |
| |
| |__________|
| |
| |
| |
| _______|______
| |
| ________________| |________________
| |
| | | Red Switch | |
| |
| | WAN1 |______________| | WAN1
| |
| _____|_____ _____|_____
| |
| | | | |
| |
| | |<------ internal7 Heartbeat ------->| |
| |
| | | | |
| |
| | FORTI | | FORTI |
| |
| | | | |
| |
| | |<------ internal1 Heartbeat ------->| |
| |
| |___________| |___________|
| |
| | | ______________ | |
| |
| | | internal1 | | internal1 | |
| |
| | |________________| Green Switch |_______________| |
| |
| | |______________| |
| |
| | | |
| |
| internal6 _____|____ internal6
| |
| | |
| |
| | LAN |
| |
| |__________|
| |
|
| |
|
| |
| Wenn für ein Cluster Mode ein Interface anhand DHCP und/oder PPPoE betrieben werden möchte empfiehlt Fortnet diese Interface im ersten Schritt statisch zu konfiguriren und erst nach dem der Cluster Mode vervollständigt wurde diese Interfaces für DHCP und/oder PPPoe zu konfigurieren. Wie ein FortiGate Cluster Mode für FortiGate-VM zu konfigurieren ist siehe den entsprechendne Hinweis am Ende dieses Artikels. Eine FortiGate Cluster Mode Konfiguration kann über Web Mgmt. Interface durchgeführt werden oder über CLI:
| |
|
| |
| System > HA
| |
|
| |
| [[Datei:Fortinet-2146.jpg]]
| |
|
| |
| # config system ha
| |
| # set mode a-p
| |
| # set priority [0-255; Standard 128]
| |
| # set group-name [Gruppen Name des Cluster Verbundes]
| |
| # set password [Passwort für den Gruppen Namen des Cluster Verbundes]
| |
| # set hbdev "internal1" 50 "internal7" 100
| |
| # set hb-interval [ 1-20 (100 Millisekunden); Standard 2 (200 Millisekunden)]
| |
| # set hb-lost-threshold [ 1 - 60 Packete; Standard 6]
| |
| # set encryption [enable | disable]
| |
| # set session-pickup [enable | disable]
| |
| # set ha-mgmt-status [enable | disable]
| |
| # set ha-mgmt-interface [Name des Interfaces zB "internal6]
| |
| # set ha-mgmt-interface-gateway [IPv4 Adresse Default Gateway für "ha-mgmt-interface"]
| |
| # set ha-uptime-diff-margin [Standard 300 Sekunden (5 Minuten)]
| |
| # set override [enable | disable]
| |
| # end
| |
|
| |
| # config system global
| |
| # set hostname [Hostname des FortiGate Devices]
| |
| # end
| |
|
| |
| '''Hostname'''
| |
| Wenn FortiGate Devices im Cluster Mode betrieben wird muss jedem Node ein Hostname vergeben werden. Dies kann über Mgmt.
| |
| Web Interface oder CLI durchgeführt werden! In einem FortiGate Cluster Mode ist es nicht möglich, dass Master und Slave
| |
| über den gleichen Hostnamen verfügen.
| |
|
| |
| '''Mode'''
| |
| Ein FortiGate Cluster Mode kann im Active-Passive sowie Active-Active betrieben werden. Wir empfehlen einen Active-Passive und
| |
| auf keinen Fall einen Active-Active Cluster Mode!
| |
|
| |
| '''Device Priority'''
| |
| Die Priority indiziert mit dessen Wert die Priorität des Nodes. Dieser Wert steht nicht Zusammenhang in einem anderen Wert in der
| |
| Konfiguration. Der höhere Wert der Priority für zwei FortiGate Devices im Cluster Mode indiziert den Master Node.
| |
|
| |
| '''Reserve Management Port für Cluster Member'''
| |
| Wir empfehlen ein dezidiertes Mgmt. Interface zu konfigurieren für den Cluster Mode eines FortiGate Devices. Dies bedeutet folgendes:
| |
| Dieses dezidierte Mgmt. Interface wird für jeden Node im Cluster Mode konfiguriert/definiert und ist vom Cluster Mode im Allgemeinen
| |
| ausgenommen. Somit kann über dieses dezidierte Mgmt. Interface der FortiGate Node im Cluster Mode verwaltet oder zB über SNMP überwacht
| |
| werden. Für dieses Interface kann eine IPv4 Adresse als "overlapping-subnet" definiert werden, was durch das FortiOS per Standard im
| |
| normal Fall verhindert wird (overlapping-subnet). Wird das LAN Interface zB im Segment 192.168.1.0/24 definiert, können diese dezidierten
| |
| Mgmt. Interface's für das gleiche Segment konfiguriert werden. Unter CLI steht für dieses dezidierte Mgmt. Interface ebenfalls exklusiv
| |
| die Konfiguration eines Default Gateway zu Verfügung. Wenn ein FortiAnalyzer oder FortiManager an einen FortiGate Device im Cluster Mode
| |
| eingebunden werden, wird dies über das LAN Interface (Standard root vdom) durchgeführt und darf nicht über die dezidierten Mgmt. Interfaces
| |
| durchgeführt werden da jeder Node über seine eigene IPv4 Adresse auf dem dezidierten Interface verfügt und somit eine Registrierung mit
| |
| unterschiedlichen IPv4 Adressen auf dem FortiAnalyzer/FortiManager nicht möglich ist.
| |
|
| |
| '''Group Name / Password'''
| |
| Wenn ein Cluster Mode definiert wird, muss der vergebenen Gruppen Namen und/oder Passwort exklusiv für diesen Cluster Verbund vergeben
| |
| werden. Diese Exklusivität der vergebenen Informationen unterscheiden potentiell verschiedenen existierende FortiGate Cluster in einem
| |
| Netzwerk Segment.
| |
|
| |
| '''Enable Session Pick-up'''
| |
| Ueber die Hearbeat Interfaces wird die Session Table des FortiGate Devices im Cluster Mode übermittelt. Damit dies durchgeführt wird,
| |
| muss die Funktion "Session Pick-up" aktiviert werden. Wird "Session Pick-up" nicht aktiviert, kommt es bei einem Failover zu einem
| |
| Unterbruch da der Standby Node (Slave) nicht über die nötigen Informationen verfügt (Session Table) um die Sessions zu übernehmen.
| |
| Somit ist ein FortiGate Cluster Mode ohen Session-Pickup ein Cluster basierend auf reinem Hardware Failover!
| |
|
| |
| '''Port Monitor'''
| |
| Die Funktion Port Monitor in der die verschiedenen Interfaces überwacht werden, indiziert ein Failover Mechanismus. Dies bedeutet:
| |
| Wird Port Monitor für die verschiedenen Interfaces aktiviert, ist das der erste Mechanismus der einen Failover auslöst. Wenn somit auf
| |
| dem Master Node ein Interface runtergefahren wird oder auf Link Down geht, überprüft der Cluster Mode Mechanismus wieviele Interfaces
| |
| auf dem Slave Node zur Verfügung stehen. Ist der Wert des Slave Node betreffend Interfaces höhere wird ein Failover ausgelöst. Port
| |
| Monitor darf nicht für Heartbeat, dezidierte Mgmt. Interfaces oder für Interfaces die nicht in Gebrauch sind aktiviert werden.
| |
|
| |
| '''Heartbeat'''
| |
| Fortinet empfiehlt für das Primary Heartbeat Interface im Minimum ein dezidiertes Interface zu benützen. Ein zweites Heartbeat
| |
| Interface zu definieren, dass als Backup aggiert für das Primary Heartbeat Interface ist möglich muss jedoch nicht dezidiert
| |
| erfolgen. Somit kann für ein Backup Heartbeat Interface durchaus zB das LAN Interface konfiguriert werden. Es ist auch durchaus
| |
| möglich als Backup Heartbeat Interface das WAN Interface zu definieren, jedoch sollte dann die Session Table Verschlüsselt werden.
| |
| Das Heartbeat Interface wird anhand einer Priority definiert. Der höhere Wert der Priority zweier definierten Heartbeat Interfaces
| |
| indiziert das Primary Heartbeat Interface. Der tiefere Wert indiziert das Backup Heartbeat Interface und wird somit nur durch das
| |
| FortiOS benutzt, wenn das Primary Heartbeat Interface nicht mehr zur Verfügung steht. Sind beide Werte zweier definierten Hearbeat
| |
| Interfaces gleich, werden beide als Primary indiziert und gleichzeitig genutzt. Für Heartbeat Interfaces darf die Monitor Funktion
| |
| nicht aktiviert werden. Wird die Verschlüsselung benutzt für die Heartbeat Funktion anhand der CLI Konfiguration "encryption" werden
| |
| die Heartbeat Packete anhand AES-128 Verschlüsselt und die Authentication wird anhand SHA1 durchgeführt. Für die Authentication muss
| |
| kein Username und/oder Passwort gesetzt werden da die Authentication anhand des Gruppen Name und Passwort durchgeführt wird. Der
| |
| "hb-interval" der in der CLI konfiguriert werden kann indiziert den Interval der benützt wird um die Heartbeat Packete zu senden.
| |
| Der "hb-lost-threshold" gibt an wieviele Packet verloren gehen dürfen bevor ein Failover ausgeführt wird. Wenn der Umstand eintrifft,
| |
| dass sich die FortiGate Nodes eines Clusters gegenseitig nicht mehr sehen kommt es zu einem "split-brain" was wiederum folgendes
| |
| bedeutet: Beide FortiGate Nodes in einem Cluster Verbund gehen in den Standalone Mode und sind somit Master. Dabei kommt es unweigerlich
| |
| zu einem Netzwerkunterbruch. Dies sollte durch die Konfiguration zweier Heartbeat Interfaces verhindert werden. Dabei ist es Wichtig
| |
| das diese Heartbeat Interfaces nicht die gleichen Transportwege benützen wie zB die gleichen Switches usw. damit Gewährleistet ist das
| |
| ein "split-brain" nicht eintrifft.
| |
|
| |
| [[Datei:Fortinet-336.jpg]]
| |
|
| |
| Ausgehen davon das die Port Monitor Funktion aktiviert wurde, ist dies somit der erste Mechanismus der einen Failover auslösen kann. Dies bedeutet: Der FortiGate Node in einem Cluster Verbund der über mehr Interfaces verfügt (Port Monitor) wird als Master deklariert. Der zweite Mechanismus der einen Failover auslösen kann ist "Age" was wiederum "ha-uptime" bedeutet und nicht zu verwechseln ist mit der System Uptime. Dies bedeutet ebenfalls: Der FortiGate Node in einem Cluster Verbund der eine grössere "ha-uptime" verfügt, wird als Master deklariert. Die "ha-uptime" wird über die Option "ha-uptime-diff-margin" gesetzt (Standard 300 Sekunden = 5 Minuten). Dieser Mechanismus wird noch vor der Device Priority ausgeführt und wird empfehlen dies zu ändern da "Age intransparent ist. Dies bedeutet: Durch nachfolgenden Befehl wird die Device Priority vor Age gesetzt:
| |
|
| |
| # config system ha
| |
| # set override enable
| |
| # end
| |
|
| |
| Wenn FortiGate Devices im Cluster Mode konfiguriert werden, empfehlen wir folgenden Vorgehensweise: Ausgehend davon, dass ein FortiGate Master Node Device komplett konfiguriert wurde für Standalone und sich bereits im entsprechenden Segment befindet resp. Produktiv ist, kann im laufenden Betrieb der Cluster Mode aktiviert werden. Achte dabei darauf, dasd die Port Monitor Funktion nicht aktiviert wird für die einzelnen Interfaces. Temporaer kann die Verbindung zur Fortigate verloren gehen da die Fortigate bei der Bestätigung der Cluster Mode Konfiguration die MAC Adresse der Interfaces entfernt und eine virtuelle MAC Adresse für den Cluster erstellt. Nachdem dies durchgeführt wurde, konfiguriere das entsprechende dezidierte Mgmt. Interface und die entsprechenden Administrtion Zugriffsrechte wie https, ssh usw für dieses dezidierte Mgmt. Interfaces sowie LAN Interface. Sofern nötig konfiguriere ebenfalls den Default Gateway für das dezidierte Interface. Danach teste den Zugriff über die Administrativen Zugriffe wie https, ssh usw. sei es auf das dezidierte Interface und/oder LAN Interface. Wenn alle Tests erfolgreich waren, führe auf dem FortiGate Master Node Device ein Backup durch über das Mgmt. Web Interface. Danach führe folgendes durch mit dem FortiGate Slave Node Device aus wobei zu berücksichtigen ist das der Device nicht verbunden ist mit einem produktiven Netzwerk Segment:
| |
|
| |
| Installiere den FortiGate Slave Node Device von Grundauf Neu mit dem entsprechenden FortiOS analog Master Node Device. Verifiziere
| |
| die Konfiguration des Slave Node Device dh. diese muss Analog des Master Node Device ausgeführt werden. Dies bedeutet: Wurde die
| |
| Disk auf dem Master Node Device formatiert muss diese ebenfalls auf dem Slave Node Device formatiert werden. Ist der Master Node
| |
| Device betreffend Interfaces im Switch Mode oder Interface Mode muss der Slave Node Device ebenfalls über den gleichen Mode verfügen.
| |
| Wenn die Grundinstallation des Slave Nodes Device Analog des Master Node Device ist führe auf dem FortiGate Slave Node Device ein
| |
| Restore durch anhand des FortiGate Master Node Devices. Nachdem Neustart des FortiGate Slave Node Device verbinde dich über die
| |
| entsprechenden konfigurierten Administrativen Zugriffs Rechte auf das LAN Interface des FortiGate Slave Node Device sowie ändere
| |
| die Konfiguration für folgende Position:
| |
|
| |
| Konfiguriere einen neuen Hostnamen für den FortiGate Slave Node Device über CLI:
| |
|
| |
| # config system global
| |
| # set hostname [Hostname des FortiGate Devices]
| |
| # end
| |
|
| |
| Konfiguriere für das dezidierte Mgmt. Interface eine entsprechende IPv4 Adresse im gleichen Segment wie für FortiGate Master Node Device.
| |
| Dies kann über Mgmt. Web Interface oder CLI durchgeführt werden:
| |
|
| |
| System > Interface > [Markiere das entsprechende Interface] > Edit
| |
|
| |
| # config system interface
| |
| # edit [Name des Interfaces zB "internal6"]
| |
| # set ip [IPv4 Adresse und Subnet Mask]
| |
| # end
| |
|
| |
| Konfiguriere für den Cluster Mode resp. für FortiGate Slave Node Device die Priority. Dies kann über Web Mgmt. Interface sowie CLI
| |
| durchgeführt werden:
| |
|
| |
| System > Config > HA > [Klicke Rechts auf das Edit Symbole]
| |
|
| |
| # config system ha
| |
| # set priority [Priority des FortiGate Slave Node Devices]
| |
| # end
| |
|
| |
| Fahre den FortiGate Slave Node Device runter!
| |
|
| |
| Nun kann der FortiGate Slave Node Device im entsprechenden produktiven Segment installiert werden. Nachdem Neustart sollte der FortiGate Slave Node Device über Serielle Mgmt. Console überwacht werden. Sobald der FortiGate Slave Node Device vollständig gestartet ist erscheint auf der Console folgendes:
| |
|
| |
| [Hostname des Slaves] login: slave's external files are not in sync with master, sequence:0. (type CERT_LOCAL)
| |
| slave's external files are not in sync with master, sequence:1. (type CERT_LOCAL)
| |
| slave's external files are not in sync with master, sequence:2. (type CERT_LOCAL)
| |
| slave's external files are not in sync with master, sequence:3. (type CERT_LOCAL)
| |
| slave's external files are not in sync with master, sequence:4. (type CERT_LOCAL)
| |
|
| |
| Nach 2 - 3 Minuten erscheint dann:
| |
|
| |
| slave succeeded to sync external files with master
| |
|
| |
| Dieser Sync wird alle 15 Minuten durchgeführt dh. der FortiGate Master Node Device überschreibt die Konfiguration des FortiGate Slave Nodes Devices über das Heartbeat Interface. Wird auf FortiGate Master Node Device eine Konfiguration geändert wird die Aenderung sofort auf dem FortiGate Slave Node Device geschrieben. Wird Irrtümlicherweise eine Konfiguration auf dem FortiGate Slave Node Device durchgeführt wird diese Konfiguration spätestens vom FortiGate Master Node Device nach 15 Minuten auf dem FortiGate Slave Node Device überschrieben. Wenn der Cluster Mode aktiv ist können die einzelnen FortiGate Nodes im Cluster Verbund nicht mehr einzeln angesprochen werden, ausser über die dezidierten Mgmt. Interfaces. Wird ein Administrativer Zugriff auf den FortiGate Cluster zB über https anhand der LAN Interface IPv4 Adresse, wird man automatisch auf den momentanen FortiGate Master Node Device verbunden und kann dort die Konfiguration durchführen. Als letzen Schritt kann nun die Port Monitor Funktion für die entsprechenden einzelnen Interfaces aktiviert werden. Bevor dies jedoch durchgeührt wird, ist es Wichtig sich zu vergewissern das die Layer2 Verbindung für die einzelnen Interfaces einwandfrei in Ordnung sind dh. zB kein Duplex Mismatch usw. Danach kann unter folgender Position die Port Monitor Funktion für die entsprechenden einzelnen Interfaces aktiviert werden:
| |
|
| |
| System > Config > HA > [Klicke Rechts auf das Edit Symbole]
| |
|
| |
| # config system ha
| |
| # set monitor [Name der Interfaces zB "internal1 wan1"]
| |
| # end
| |
|
| |
| Nun kann ein Failover Test durchgeführt werden dh. setze ein Interface auf dem FortiGate Master Node Device auf down:
| |
|
| |
| # config system interface
| |
| # edit [Name des Interfaces zB "wan1"]
| |
| # set status down
| |
| # end
| |
|
| |
| Ueber Mgmt. Web Interface verifiziere im Dashboard ob ein Failover durchgeführt wurde. Achte dabei auf die Serien Nummer resp. Hostnamen der Cluster Member/Nodes. Wenn der Test erfolgreich durchgeführt wurde aktiviere wiederum das Interface das down gesetzt wurde. Weitere Auskunft über spezifische Konfigurationen im Cluster Mode gibt folgendes Fortinet Dokument das zB auch beschreibt wie ein Cluser Mode für FortiGate-VM zu konfigurieren ist (Siehe Menüpunkt FortiGate-VM for VMware HA configuration):
| |
|
| |
| [[Datei:Fortigate-HA-54.pdf]]
| |
|
| |
| === Wie kann ich unter FortiOS 5.4 für einen FortiGate HA Cluster den Fail-Over Indikator "age" anpassen? ===
| |
|
| |
| In einem Fail-Over Scenario für deinen FortiGate HA Cluster arbeitet das FortiOS mit verschiedenen Indikatoren die einen Fail-Over auslösen können. Per FortiOS Standard sind dies folgende Indikatoren:
| |
|
| |
| [[Datei:Fortinet-336.jpg]]
| |
|
| |
| Diese Indikatoren werden top-down abgearbeitet und können einen Fail-Over auslösen. Aus verschiedenen Gründen empfehlen wir folgende Option auf einem FortiGate HA Cluster zu aktivieren:
| |
|
| |
| # config system ha
| |
| # set override [enable | disable]
| |
| # end
| |
|
| |
| Wenn diese Option "override" aktiviert wird so wird die "Device Priority" vor "age" als Indikator eines Fail-Overs ausgeführt. Es gibt jedoch verschiedenen Gründe den Standard zu belasse dh. "age" wird vor "Device Priority" durchgeführt. Dabei ist folgendes zu beachten: Der Indikator "age" basiert auf der "HA Uptime eines FortiGate Devices" im HA Cluster dh. dies ist nicht zu verwechseln mit der "HA Uptime eines FortiGate Devices". Somit ist die "HA Uptime eines FortiGate Devices" die Zeit die ein Cluster Node Mitglied ist in einem FortiGate HA Cluster Verbund. Wenn man die Differenz die herangezogen wird für den Indikator "age" verändern möchte (Per Default gilt 300 Sekunden oder 5 Minute) zB bei einem Firmware Upgrade (Dauer des Upgrades) kann folgendes über die Console eingegeben werden:
| |
|
| |
| # config system ha
| |
| # set ha-uptime-diff-margin [Dauer in Sekunden von 1 - 65535; Standard 300 Sekunden]
| |
| # end
| |
|
| |
| Um die Differenz für "age" eines FortiGate Devices im HA Cluster anzuzeigen benütze folgenden Befehl:
| |
|
| |
| # diagnose sys ha dump-by all-vcluster
| |
| HA information.
| |
| vcluster id=1, nventry=2, state=work, digest=3.25.f5.b7.eb.67...
| |
| ventry idx=0,id=1,FGT3HD3915807993,prio=128,0,claimed=0,override=1,flag=0x01,'''time=0''',mon=0
| |
| mondev=port4,50port3,50port2,50port1,50alsochlu-sg0-ag,50
| |
| ventry idx=1,id=1,FGT3HD3915807690,prio=64,0,claimed=0,override=1,flag=0x00,'''time=-2913''',mon=0
| |
|
| |
| Der erste Eintrag betreffend der Zeile "ventry" zeigt den Device auf dem der Administrator momentan eingeloggt ist. Die zweite Zeile betreffend "ventry" zeigt den untergeordneten Node im HA Cluster. Die Zeile "mondev" gibt an welche Interface überwacht werden (Port Monitor). Auf dem HA Cluster Node auf dem der Administrator momentan eingeloggt ist zeigt betreffend "time=" immer "0". Der untergordnete Node im Cluster zeigt die Differenz zum Primary Node dh. in unserem Beispiele "2913" (2913 geteil durch 10 = 291.3 Sekunden). Wenn nun "age" per Standard auf "300" Sekunden steht, hat dies keinen Einfluss als Kriterium ob der Device zum Primary Node wird oder nicht, denn solange die Differenz der Devices diese "300" Sekunden nicht übersteigt hat "age" keinen Einfluss. Für den hier gezeigten Befehl stehen weitere Optionen zur Verfügung:
| |
|
| |
| # diagnose sys ha dump-by
| |
| all-xdb Dump all xdb.
| |
| all-vcluster Dump all vcluster.
| |
| rcache Dump rcache.
| |
| all-group Dump all group.
| |
| memory Dump memory.
| |
| debug-zone Dump HA debug zone.
| |
| vdom Dump HA vdom info.
| |
| kernel Dump HA kernel info.
| |
| device Dump HA device.
| |
| stat Dump HA statistics.
| |
| sesync Dump HA session sync peers
| |
|
| |
| Wenn nun aus vers. Gründen die "age" zurückgestellt werden soll (wenn zB der Primary Note über die Priorität gesteuert werden soll), kann folgender Befehl ausgeführt werden wobei zur berücksichtigen ist, dass dieser Befehl je nach Situation ein Fail-Over ausführt und das dieser Befehl alle Nodes in einen Cluster betrifft dh. alle "age" Informationen werden für alle Nodes in einem Cluster zurückgestellt:
| |
|
| |
| # diagnose sys ha reset-uptime
| |
|
| |
| === Wie erlange ich unter FortiOS 5.4 für FortiGate Devices im Cluster Mode Zugriff auf den Cluster Node Slave? ===
| |
|
| |
| Wenn man einen Cluster Mode für FortiGate Devices aktiviert und keine dezidierten Mgmt. Interfaces benutzt ist der Cluster Node Slave nicht mehr für ein Zugriff sei es über Mgmt. Interface oder CLI erreichbar da FortiGate Devices im Cluster Mode zu einem logischen Device vereint wird. Dies bedeutet: Wenn man somit über die Cluster Mode IPv4 Adresse zugreift für das der Mgmt. Web Interface
| |
| freigegeben wurde antwortet immer der Cluster Node Master. Dies gilt auch für den Zugriff per SSH resp. CLI. Somit empfehlen wir die Konfiguration von dezidierten Interfaces damit auf jeden Cluster Node seperat zugegriffen werden kann. Weitere Informationen zu den dezidierten Mgmt. Interfaces siehe nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.4-5.6:FAQ#Wie_kann_ich_unter_FortiOS_5.4_f.C3.BCr_FortiGate_Devices_einen_Cluster_Mode_konfigurieren.3F]]
| |
|
| |
| Stehen diese dezidierten Mgmt. Interfaces jedoch nicht zur Verfügung, kann über eine Telnet Sessions (l2ep-eth-type) innerhalb des Heartbeats eine Verbindung zum Cluster Node Slave aufgebaut werden. Dies wird folgendermassen durchgeführt:
| |
|
| |
| • Erstelle eine SSH Verbindung anhand der IPv4 Adresse für das FortiGate Interface im Cluster Mode für das
| |
| der Administrative Access für SSH konfiguriert wurde.
| |
|
| |
| Wenn eine Verbindung zur IPv4 Adresse für das FortiGate Interface im Cluster Mode durchgeführt wird so
| |
| wird automatisch eine Verbindung zum Cluster Node Master erstellt. Danach führe folgendes aus:
| |
|
| |
| # execute ha manage ?
| |
| <id> please input peer box index.
| |
| <0> Subsidary unit [Serial Nummer des Devices[
| |
|
| |
| Wähle nun die entsprechende "id" des Devices resp. des nicht aktiven Nodes zB:
| |
|
| |
| # execute ha manage 0
| |
|
| |
| Nun wird in der Kommandozeile (CLI) der Prompt des nicht aktiven Cluster Nodes resp. des Slaves angezeigt!
| |
|
| |
| === Unter FortiOS 5.4 welche Informationen werden für einen FortiGate Device im HA Cluster Synchronisiert? ===
| |
|
| |
| Wenn unter FortiOS 5.4 ein HA Cluster konfiguriert wird so wird per Standard kein Session Fail-Over durchgeführt dh. dazu muss die entsprechende Option im Mgmt. Web Interface oder in der CLI gesetzt werden:
| |
|
| |
| Config > HA > Enable Session Pick-up
| |
|
| |
| # config system ha
| |
| # set session-pickup [enable | disable]
| |
| # end
| |
|
| |
| Nun wenn die Option "Session Pick-up" aktiviert ist werden die Sessions über das definierte Heartbeat Interface/s auf die Cluster Node/s Synchronisiert, damit diese in einem Fail-Over auf den Cluster Node/s zur Verfügung stehen. Dabei ist jedoch zu berücksichtigen, dass nicht alle Sessions für eine Synchronisation zur Verfügung stehen resp. nicht alle Sessions auf den Cluster Node/s Synchronisiert werden können und somit in einem Fail-Over übernommen werden können. Speziell im UTM Bereich können verschiedenen Sessions nicht Synchronisiert werden. Das FortiGate Cluster Protokoll Synchronisert keine Informationen im Zusammenhang mit folgenden Funktionen:
| |
|
| |
| • Antivirus Scanning im Zusammenhang mit folgenden Protokollen/Sessions:
| |
|
| |
| HTTP, HTTPS, FTP, IMAP, IMAPS, POP3, POP3S, SMTP, SMTPS, IM, CIFS und NNTP
| |
|
| |
| • WebFilter und FortiGuard WebFilter im Zusammenhang mit folgenden Protokollen/Sesssions:
| |
|
| |
| HTTP und HTTP
| |
|
| |
| • SpamFilter im Zusammenhang mit folgenden Protokollen/Sesssions:
| |
|
| |
| IMAP, IMAPS, POP3, POP3S, SMTP und SMTPS
| |
|
| |
| • DLP im Zusammenhang mit folgenden Protokollen/Sessions:
| |
|
| |
| IMAP, IMAPS, POP3, POP3S, SMTP, SMTPS, SIP, SIMPLE, and SCCP
| |
|
| |
| • DLP Archiving im Zusammenhang mit folgenden Protokollen/Sessions:
| |
|
| |
| HTTP, HTTPS, FTP, IMAP, IMAPS, POP3, SMTP, SMTPS, IM, NNTP, AIM, ICQ, MSN, Yahoo! IM, SIP, SIMPLE und SCCP (signal control sessions)
| |
|
| |
| Weitere Informationen findet man im nachfolgenden Fortinet Dokument unter der Position "Session failover not supported for all sessions":
| |
|
| |
| [[Datei:Fortigate-HA-54.pdf]]
| |
|
| |
| Desweitere ist zu berücksichtigen, dass UDP und ICMP Sessions per Standard ebenfalls nicht Synchronisiert werden jedoch die Möglichkeit dazu besteht diese mit nachfolgender Option zu Synchronsieren:
| |
|
| |
| # config system ha
| |
| # session-pickup-connectionless [enable | disable]
| |
| # end
| |
|
| |
| Die Sessions für UDP und ICMP sollten jedoch nur dann aktiviert werden wenn dies aus irgendwelchen Gründen benötigt wird!
| |
|
| |
| === Wie kann ich unter FortiOS 5.4 für FortiGate Devices im Cluster Mode die Heartbeat Informationen Verschlüsseln? ===
| |
|
| |
| Wie unter nachfolgenden Link beschrieben sollte für FortiGate Devices im Cluster Mode minimum ein dezidiertes Heartbeat Interface benutzt/definiert werden:
| |
|
| |
| [[FortiGate-5.4-5.6:FAQ#Wie_kann_ich_unter_FortiOS_5.4_f.C3.BCr_FortiGate_Devices_einen_Cluster_Mode_konfigurieren.3F]]
| |
|
| |
| Wie in obigen Artikel erwähnt kann jedoch zu Failover Zwecken ein zweites Heartbeat Interface definiert werden. Dieses muss jedoch nicht dezidiert sein und kann mit einem kleinere Wert dh. Priority definiert werden. Eine Heartbeat Interface mit einer kleineren Priority wird somit nur dann benutzt, wenn das Heartbeat Interface mit dem höheren Wert aus irgendwelchen Gründen nicht mehr zur Verfügung steht. Bei der Definierung eines Failover Heartbeat Interface ist es Wichtig immer ein Interface zu definieren, dass in jedem Fall zur Verfügung steht um einen "split-brain" zu verhindern dh. das beide Cluster Nodes Master werden da sich beide Cluster Nodes nicht mehr sehen. In gewissen Situationen steht somit nur noch das wan Interface zur Verfügung das durchaus genutzt werden kann. Wird ein wan Interface mit einer kleineren Priority als Failover Heartbeat Interface definiert, sollte die Verschlüsselung aktiviert werden da ansonsten die Heartbeat Informationen dh. Session Informationen über das wan Interface ins Internet unverschlüsselt komuniziert werden. Um die Verschlüsselung für die Heartbeat Informationen zu aktivieren führe folgendes aus:
| |
|
| |
| # config system ha
| |
| # set authentication [enable | disable]
| |
| # set encryption enable
| |
| # end
| |
|
| |
| Für die Verschlüsselung muss keine zusätzliche Konfiguration durchgeführt werden, denn die Verschlüsselung selber wird anhand AES-128 durchgeführt und für die Authentifizerung wird die definierte "group-name" sowie das definierte "password" unter "config system ha" herangezogen und anhand SHA1 die Authentifizierung durchgeführt!
| |
|
| |
| === Welche IPv4 Adressen, Ehernet Type sowie MAC Adressen werden unter FortiOS 5.4 für FortiGate Devices im Cluster Mode benutzt? ===
| |
|
| |
| Das FGCP (FortiGate Cluster Protokoll) vergibt "link-local IPv4 Adressen" (RFC 3927) im Range 169.254.0.x für Heartbeat Interfaces sowie für die inter-VDOM Links. Wenn FortiGate Devices im Cluster Mode initial gestartet wird so wird dem Primary Cluster Heartbeat Interface auf dem Cluste Node Master die IPv4 Adresse 169.254.0.1 zugewiesen und für den Cluster Node Slave eine IPv4 Adresse aus folgendem Range 169.254.0.2-63. Für inter-VDOM Links wird der Range 169.254.0.65 und höher benutzt. Um die vergebene IPv4 Adresse für das Heartbeat für FortiGate Devices im Cluster Mode zu eruieren, gebe folgendes Kommando über die Console ein:
| |
|
| |
| # get system ha status
| |
| Model: 300D
| |
| Mode: a-p
| |
| Group: 0
| |
| Debug: 0
| |
| ses_pickup: enable, ses_pickup_delay=disable
| |
| Master:128 alsochlu-sg0e1 FG300D3913601712 1
| |
| Slave : 96 alsochlu-sg0e2 FG300D3913602452 0
| |
| number of vcluster: 1
| |
| vcluster 1: work 169.254.0.2
| |
| Master:0 FG300D3913601712
| |
| Slave :1 FG300D3913602452
| |
|
| |
| Die MAC Addressen für die einzelnen Interfaces für FortiGate Devices im Cluster Mode setzen sich wie folgt zusammen
| |
|
| |
| 00-09-0f-09-<group-id_hex>-<vcluster_integer><idx>
| |
|
| |
| Die <group-id_hex> ist die HA Group ID des HA Clusters umgerechnet in Hexdecimal. Nachfolgende Tabelle zeigt auf wie die Group ID in Hexdecimal für die virtuelle MAC Adresse umgerechnet wird:
| |
|
| |
| [[Datei:Fortinet-334.jpg]]
| |
|
| |
| Der <vcluster_integer> ist 0 für den virtuellen Cluster 1 und für den virtuellen Cluster 2 die 2. Wenn die VDom Funktion nicht aktiviert ist, setzt der FortiGate Cluster Mode die 1 und alle Interfaces befinden sich in der VDom "root". Wenn man die Formel anwendet für einen virtuellen Cluster oder einer virtuellen Domain (VDom) ändert sich die MAC Adress Formel nicht dh. man wendet diese an ob VDom existiert oder virtuelle Cluster angewendet wird. Die Position <idx> in der Formel, ist die Anzahl der Interfaces. Interfaces werden durchnummeriert von 0 bis x wobei x für die Nummer des Interfaces steht. Interfaces werden in "hash map" aufgelistet. Dies bedeutet: Das diese zuerst Alphabetisch geordnet werden und danach nach Index Nummer! Somit variert nur die Position <idx> für virtuelle MAC Adressen resp. für die verschiedenen Interfaces. Die Position <vcluster_integer> variert nur dann wenn die Fuktion VDom aktiviert wird. Nachfolgend einige Beispiele für virtuelle MAC Adressen und deren Umrechnung:
| |
|
| |
| '''Group ID 0 (Default) VDom's Funktion nicht aktiviert'''
| |
|
| |
| • port1 virtual MAC: 00-09-0f-09-00-00
| |
| • port10 virtual MAC: 00-09-0f-09-00-01
| |
| • port2 virtual MAC: 00-09-0f-09-00-02
| |
| • port3 virtual MAC: 00-09-0f-09-00-03
| |
| • port4 virtual MAC: 00-09-0f-09-00-04
| |
| • port5 virtual MAC: 00-09-0f-09-00-05
| |
| • port6 virtual MAC: 00-09-0f-09-00-06
| |
| • port7 virtual MAC: 00-09-0f-09-00-07
| |
| • port8 virtual MAC: 00-09-0f-09-00-08
| |
| • port9 virtual MAC: 00-09-0f-09-00-09
| |
| • port11 virtual MAC: 00-09-0f-09-00-0a
| |
| • port12 virtual MAC: 00-09-0f-09-00-0b
| |
|
| |
| '''Group ID 34 (Default) VDom's Funktion nicht aktiviert'''
| |
|
| |
| • port1 virtual MAC: 00-09-0f-09-22-00
| |
| • port10 virtual MAC: 00-09-0f-09-22-01
| |
| • port2 virtual MAC: 00-09-0f-09-22-02
| |
| • port3 virtual MAC: 00-09-0f-09-22-03
| |
| • port4 virtual MAC: 00-09-0f-09-22-04
| |
| • port5 virtual MAC: 00-09-0f-09-22-05
| |
| • port6 virtual MAC: 00-09-0f-09-22-06
| |
| • port7 virtual MAC: 00-09-0f-09-22-07
| |
| • port8 virtual MAC: 00-09-0f-09-22-08
| |
| • port9 virtual MAC: 00-09-0f-09-22-09
| |
| • port11 virtual MAC: 00-09-0f-09-22-0a
| |
| • port12 virtual MAC: 00-09-0f-09-22-0b
| |
|
| |
| Bevor der Cluster Mode für FortiGate Devices aktiviert wird sieht die MAC Adresse für ein Interface folgendermassen aus:
| |
|
| |
| # get hardware nic internal
| |
|
| |
| MAC: 02:09:0f:78:18:c9
| |
| Permanent_HWaddr: 02:09:0f:78:18:c9
| |
|
| |
| Dies bedeutet die MAC Adresse ist gleich Permenent_HWaddr. Wenn nun der Cluster Mode aktiviert wird für FortiGate Devices und man nachträglich das Interface abermals kontrolliert sieht man, dass dem Interface zur Permanent_HWaddr eine virtuell zugewiesen wurde:
| |
|
| |
| # get hardware nic internal
| |
|
| |
| MAC: '''00:09:0f:09:00:02'''
| |
| Permanent_HWaddr: 02:09:0f:78:18:c9
| |
|
| |
| Da der Cluster Mode aktiviert wurde, wurden jedem Interface zur Permenent_HWaddr eine virtuelle MAC Adresse zugewiesen basierend auf der vorgängingen Erklärung. Kommt es aus irgendwelchen Gründen zu Problemen dh. MAC Adress Konflikten im Zusammenhang mit der virtuellen MAC Adresse der Interfaces für den Cluster Mode muss nur die Group ID für den Cluster Mode geändert werden da diese die virtuelle MAC Adresse des Cluster Mode steuert:
| |
|
| |
| # config system ha
| |
| # set group-id <id_integer>
| |
| # end
| |
|
| |
| Im Zusammenhang mit dem Heartbeat Interface ist ebenfalls das Ethernet Feld/Type zu beachten. Normale IPv4 Packete sind 802.3 Packete die über ein Ethernet Feld/Type verfügen mit dem folgenden Wert:
| |
|
| |
| 0x0800
| |
|
| |
| Andere Werte werden innerhalb des Ethernet Feld/Types als Level 2 Frames verstanden anstelle von IPv4 Packete. Heartbeat Packete im Cluster Mode von FortiGate Devices im NAT/Route Mode benutzen das Ethernet Feld/Type 0x8890 (ha-eth-type). Diese Packete werden speziell dazu benutzt die Nodes des Clusters Verbunds und/oder anderen Cluster Nodes im Netz zu finden. Heartbeat Packete für FortiGate Devices im Transparent Mode (hc-eth-type) benutzen das Ethernet Feld/Type 0x8891. Für den Cluster Mode im Zusammenhang mit Telnet Sessions (l2ep-eth-type) der benutzt wird um vom Cluster Node Master zum Cluster Node Slave eine Telnet Session zu öffnen, benützen das Ethernet Feld/Type 0x8893. Somit gilt:
| |
|
| |
| • NAT/Route Mode 0x8890 ha-eth-type
| |
| • Transparent Mode 0x8891 hc-eth-type
| |
| • Telnet Sessions 0x8893 l2ep-eth-type
| |
|
| |
| Damit die Heartbeat Komunikation einwandfrei durchgeführt werden kann, muss der eingesetzte Switch der für das/die Heartbeat Interfaces benutzt wird, diese Ethernet Feld/Types erlauben. Ist dies nicht der Fall da der Switch diese Ethernet Feld/Types bereits für interne Funktionen benutzt, muss der Ethernet Feld/Type modifiziert werden. Dies kann über folgende Kommandozeile durchgeführt werden:
| |
|
| |
| # config system ha
| |
| # set ha-eth-type [ha_ethertype_4-digit_hex]
| |
| # set hc-eth-type [hc_ethertype_4-digit_ex]
| |
| # set l2ep-eth-type [l2ep_ethertype_4-digit_hex]
| |
| # end
| |
|
| |
| Dieser Umstand kommt in seltenen Fällen vor und ist zB bei Cisco N5K/Nexus Switches der Fall da das Ethernet Feld/Type 0x8890 bereits für interne Funktionen eines Cisco N5K/Nexus Switches benutzt wird. Wenn dieser Switch solche Ethernet Feld/Type Packete erhält, verwirft er diese (CRC errors) und dies verhindern somit eine einwandfreie Komunikation zwischen den FortiGate Cluster Nodes innerhalb eines Cluster Verbundes. Die Lösung wäre somit wie hier beschrieben das Ethernet Feld/Type auf einen ungenutzten Wert zu modifizieren zB 0x888!
| |
|
| |
| === Unter FortiOS 5.4 für FortiGate Nodes in einem HA Cluster ist die Auslastung auf einem Heartbeat Interface zu hoch? ===
| |
|
| |
| Wenn in einem FortiGate HA Cluster die Auslastung steigt wird der CPU stark beansprucht. In so einem Fall kann es vorkommen, dass die Heartbeat Packete durch den Primary Node im HA Cluster nicht innerhalb einer gegebenen Zeit über das Heartbeat Interface zum Slave Node im HA Cluster gesendet werden kann. In so einem Fall kann es zu einem unkontrollierten Fail-Over kommen da der Slave Node vom Primary Node keine oder verspätete Informationen/Sessions erhält und dadurch der Slave Node den Primary Node Part übernimmt (Fail-Over). So eine Situation kann ebenfalls durch eine "syn flood attacke" ausgelöst werden die den FortiGate Cluster komplett auslastet und somit die nötigen Heartbeat Packet nicht oder verspätet zum Slave Node gesendet werden können. Wenn der Grund eines unkontrollierten Fail-Over die Auslastung des Heartbeat für regulärem Traffic ist so können die "interval" und/oder die "threshold" der Packet angepasst werden um einen unkontrollierten Fail-Over zu verhindern. Dazu können über die Console folgende Kommandos benützt werden:
| |
|
| |
| # config system ha
| |
| # set hb-interval [Gebe den Interval in Sekunden an 1 - 20]
| |
| # set hb-lost-threshold [Gebe den Thresold dh. wieviele Packete 1 - 60]
| |
| # set helo-holddown [Gebe den Holddown in Sekunden an 5 - 300]
| |
| # end
| |
|
| |
| Nachfolgend die Erklärung der einzelnen Optionen:
| |
|
| |
| '''hb-interval'''
| |
| Der Heartbeat "interval" definiert Zeitlichen wielange benötigt wird um die Heartbeat Packete zum Slave Node zu senden.
| |
| Per Standard gilt "2" (200 ms). Der "interval" Range der konfiguriert werden kann ist 1 bis 20. Wenn der Heartbeat
| |
| "interval" zu tief ist, wird die Bandbreite unnötig ausgelastet. Wenn der Heartbeat "interval" zu gross gesetzt ist,
| |
| verliert der Cluster an Sensitivität betreffend Netzwerkveränderungen etc. Der "interval" steht ebenfalls im Zusammenhang
| |
| mit dem "threshold" dh. wenn der "threshold" auf 6 Packete konfiguriert ist und der "interval" auf 2 so wird ein Fail-Over
| |
| ausgelöst wenn der Cluster innerhalb von 6 X 200 ms = 1200 ms (1.2 Sekunden) keine Packete mehr erhält. Somit stehen hier
| |
| Konfigurations Möglichkeiten zur Verfügung um lange Strecken Rechnung zu tragen dh. wenn der "delay" zur Uebermittlung
| |
| von Packeten grösser wird.
| |
|
| |
| '''hb-lost-threshold'''
| |
| Der "threshold" gibt an wieviel Packete verloren gehen dürfen, bevor ein Fail-Over ausgelöst wird. Per Standard gelten "6"
| |
| Packete (möglich 1 - 60 Packete). Dies bedeutet: Wenn der Slave Node 6 Packete nicht bekommt, geht der Slave Node davon
| |
| das der Primary Node nicht mehr korrekt funktioniert und zum Primary wird (Fail-Over). Das Gleiche gilt für den Primary
| |
| Node selbst dh. wenn er vom Slave Node die 6 Packet nicht bestätigt bekommt geht der Primary Node davon aus das der Slave
| |
| Node nicht mehr ordnungsgemäss funktioniert. Im Generellen gilt: je kleiner der "threshold" desto schneller wird ein
| |
| Fail-Over durchgeführt resp. desto Sensitiver reagiert der Cluster auf Netzwerkveränderungen.
| |
|
| |
| '''helo-holddown'''
| |
| Der "helo" State "hold-down" ist die Dauer in Sekunden die der Cluster wartet, bis dieser vom "helo" State zum "work"
| |
| State wechselt. Nach einem Fail-Over oder beim starten des Clusters arbeitet der Cluster im "helo" State dh. Heartbeat
| |
| Packete werden im Cluster zu den Nodes im Cluster gesendet damit jeder Node im Cluster sich austauschen kann. Sobald
| |
| alle Nodes im Cluster Verbund erreicht wurden geht der Status auf "work" State. Sehen sich die Nodes im Cluster aus
| |
| irgendwelchen Gründen nicht, kann dies zu Unterbrüchen führen da der Cluster nicht vervollständigt werden kann. Ein
| |
| Grund, dass sich die Nodes nicht finden ist zB ein unterschiedlicher Standort mit weiten Strecken zwischen den
| |
| Standorten dh. durch den "delay" in der Heatbeat Komunikation kann der Status nicht von "helo" State in den "work"
| |
| State wechseln. In so einem Fall kann die Zeit die benötigt wird, damit die Nodes untereinander komunizieren können
| |
| heraufgesetzt werden. Per Standard gilt 20 (20 Sekunden). Die Zeitspanne die konfiguriert werden kann ist 5 bis 300 Sekunden.
| |
|
| |
|
| |
| Eine weitere optimierungs Möglichkeit wäre bei einem hohen Aufkommen von Sessions über das Heatbeat Interface zusätzliche Ports zu definieren um das Heatbeat Interface zu entlasten. Bei dieser Möglichkeit werden nicht zusätzliche Heatbeat Interface definiert, sondern durch die Konfiguration der zusätzlichen Ports zum Heartbeat Interface wird die FortiGate angewiesen ein "load balancing" über diese definierten Ports durchzuführen. Dies bedeutet: Die Session Table wird grundsätzlich über das definierte Heartbeat Interface durchgeführt und die zusätzlich definierten Ports übernehmen die Arbeit des Heartbeat Interface's in dessen Namen. Somit übernehmen die definierten Ports die Synchronisation. Dies bedeutet ebenfalls, dass über das definierte Heartbeat Interface keine Uebermittlung stattfindet solange die definierten Ports erreichbar sind. Sind diese definierten Ports nicht mehr erreichbar (available), übernimmt wiederum das definierte Heartbeat Interface die Arbeit der Uebermittlung. Die definierten Ports müssen Netzwerktechnisch wie ein Heartbeat Interface innerhalb eines Cluster verbunden werden. Um in einem HA Cluster diese Ports zu konfigurieren führe folgendes durch:
| |
|
| |
| # config system ha
| |
| # set session-sync-dev [Definiere die einzelnen Ports zB "port10 port12"]
| |
| # end
| |
|
| |
| Diese Konfiguration der zusätzlichen Ports resp. eines Heartbeat "load balancing" sollten nur dann durchgeführt werden, wenn wirklich ein sehr hohes Aufkommen von Sessions zu erwarten ist oder stattfindet! Die Konfiguration der zusätzlichen Ports ist über Web Mgmt. Interface nicht ersichtlich resp. nicht möglich und muss über CLI durchgeführt werden.
| |
|
| |
| === Wie kann ich unter FortiOS 5.4 ein Debug für das Heartbeat Interface resp. den HA Cluster Sync Prozess ausführen? ===
| |
|
| |
| Wenn in einem FortiGate HA Cluster der HA Synchronisation Prozess genauer untersucht werden soll kann dies mit dem entsprechenden Debug Befehl durchgeführt werden. Da bei diesem Debug viele Inforationen in die Console geschrieben werden ist zu empfehlen SSH zu benutzen sowie für die SSh Session Logging zu aktivieren. Dazu muss folgendes ausgeführt werden:
| |
|
| |
| 1. Konfiguriere "putty" für logging dh. alle Informationen werden in ein Log aufgezeichnet (Category > Session > Logging > All session output)
| |
| 2. Erstelle eine Consolen Verbindung zur FortiGate (RS232 basierend resp. Seriell)
| |
| 3. Führe ein Login durch und gebe folgendes ein:
| |
|
| |
| '''Setze alle Debug Filter zurück'''
| |
|
| |
| # diagnose debug reset
| |
|
| |
| '''Setze einen Debug Filter für "hasync"
| |
|
| |
| # diagnose debug application hasync -1
| |
|
| |
| '''Aktiviere für den debug "output" den "timestamp"'''
| |
|
| |
| # diagnose debug console timestamp enable
| |
|
| |
| '''Aktiviere den Debug Modus mit dem gesetzen Debug Filter'''
| |
|
| |
| # diagnose debug enable
| |
|
| |
| Nachfolgend ein Ausschnitt eines Debug Outputs:
| |
|
| |
| --------------- hasync -1 output ---------------
| |
|
| |
| conn=0x34dda90 created, nconnections=1
| |
| conn=0x34dda90 accepted, dst=169.254.0.2
| |
| conn=0x34dda90, recv all 1604 bytes data. no file data to recv
| |
| conn=0x34dda90 added to list of sync_type=5(config)
| |
| upd_cfg_api.c[260] upd_cfg_extract_av_db_version-version=05002000AVDB00201-00039.00324-1609121911
| |
| upd_cfg_api.c[260] upd_cfg_extract_av_db_version-version=05002000AVDB00701-00039.00324-1609121910
| |
| upd_cfg_api.c[260] upd_cfg_extract_av_db_version-version=05002000AVDB00401-00001.00000-1210171547
| |
| upd_cfg_api.c[353] upd_cfg_extract_irdb_botnet_db_version-version=05002000IRDB00101-00003.00162-1609122000
| |
| upd_cfg_api.c[214] upd_cfg_extract_avips_engine_version-version=05002000AVEN02800-00005.00178-1606301426
| |
| conn=0x34dda90, conn_buf=0x34f0250, all 8 bytes data is sent, no file to send
| |
| conn_buf=0x34f0250 closed
| |
| conn=0x34dda90 closed, nconnections=0
| |
| conn=0x34dda90 created, nconnections=1
| |
| conn=0x34dda90 connecting, dst=169.254.0.2
| |
| conn=0x34dda90, conn_buf=0x34f0250, new connection created for serialize_write to 169.254.0.2
| |
| conn=0x34dda90, conn_buf=0x34f6300 appended
| |
| conn=0x34dda90 connected, dst=169.254.0.2
| |
| conn=0x34dda90, conn_buf=0x34f0250, all 520 bytes data is sent, no file to send
| |
| conn=0x34dda90, recv all 8 bytes data. no file data to recv
| |
| conn_buf=0x34f0250 closed
| |
| conn=0x34dda90, next_conn_buf=0x34f6300, buf_len=512, more conn_buf to write
| |
| conn=0x34dda90, conn_buf=0x34f6300, all 520 bytes data is sent, no file to send
| |
| conn=0x34dda90, recv all 8 bytes data. no file data to recv
| |
| conn=0x34dda90, all conn_buf has been written
| |
| conn_buf=0x34f6300 closed
| |
| conn=0x34dda90 closed, nconnections=0
| |
|
| |
| --------------- hasync -1 output ---------------
| |
|
| |
| Im vorhergehenden Befehl wurde der Debug Befehl mit "-1" definiert was wiederum bedeutet den tiefsten Debug Level zu benützen resp. alle Informationen. Anhand von verschiedenen Debug Levels für "hasync" dh. 1-19 sowie 50-53 ist es möglich innerhalb des Debug "hasync" nur spezifische Informationen anzeigen zu lassen. Diese Debug Levels haben folgende Bedeutung:
| |
|
| |
| 1 Dump all states of debug switches.
| |
| 2 Turn off all debug switches.
| |
| 3 Toggle debug switch of hsync core.
| |
| 4 Toggle debug switch of ha-diff.
| |
| 5 Toggle debug switch of FIB.
| |
| 6 Toggle debug switch of route6.
| |
| 7 Toggle debug switch of BYOD.
| |
| 8 Toggle debug switch of endpoint_compliance.
| |
| 9 Toggle debug switch of NEB.
| |
| 10 Toggle debug switch of zebos.
| |
| 11 Toggle debug switch of haconf.
| |
| 12 Toggle debug switch of proxy.
| |
| 13 Toggle debug switch of time.
| |
| 14 Toggle debug switch of snmp.
| |
| 15 Toggle debug switch of gtp.
| |
| 16 Toggle debug switch of auth.
| |
| 17 Toggle debug switch of IPsec.
| |
| 18 Toggle debug switch of fdb.
| |
| 19 Toggle debug switch of arp.
| |
| 50 Dump ha sync statistics.
| |
| 51 Dump FIB information.
| |
| 52 Dump extfile's signature.
| |
| 53 Recalculate external files signature.
| |
|
| |
| Eine weitere Möglichkeit um einen Synchronisation Prozess zu überprüfen ist auf Session Base dh. wenn die Session Liste mit nachfolgenden Befehl abgefragt wird so wird die Anzahl Sessions ausgegeen die in der Session Liste aktiv sind. Diese Anzahl Session basieren auf den Sessions die mit dem Flag "synced" versehen sind. Somit kann auf dem zB Slave Node das gleiche Kommando ausgeführt werden um zu kontrollieren ob die gleiche Anzahl Session vorhanden ist/sind:
| |
|
| |
| # diag sys session list | grep synced -c
| |
|
| |
| === Wie kann ich unter FortiOS 5.4 für einen FortiGate HA Cluster einen Manuelle Synchronisation ausführen? ===
| |
|
| |
| Wenn ein FortiGate HA Cluster konfiguriert wird, Synchronisiert der Master alle 15 Minuten die Konfiguration auf die anderen Cluster Nodes resp. den Slave Node. Dieser Prozess der Synchronisation der Konfiguration des Master auf alle anderen Nodes, kann weder gestoppt noch beeinflusst werden, auch wenn die anderen Nodes über eine andere Konfiguration verfügen. Dies bedeutet: Der Master Node in einem Cluster überschreibt immer unwiederruflich die anderen Nodes ohne Ausnhame. Möchte man aus irgendwelchen Gründen diesen Prozess der Synchronisation Manuell ausführen kann dies folgendermassen durchgeführt werden:
| |
|
| |
| '''Ueberprüfung der HA Cluster Checksum'''
| |
|
| |
| master # diagnose sys ha checksum cluster
| |
|
| |
| ================== FGT3HD3915807993 ==================
| |
|
| |
| is_manage_master()=1, is_root_master()=1
| |
| debugzone
| |
| global: 15 e0 a9 c6 dc a9 fc bd db f6 f3 e6 5e fa 2b c9
| |
| root: e1 a1 53 06 bf ee 79 ee b1 a2 b1 12 fd c1 4d 66
| |
| all: eb e8 1b 1f 27 ba 77 7d 3f 7d 14 28 6c 70 ec c1
| |
|
| |
| checksum
| |
| global: 15 e0 a9 c6 dc a9 fc bd db f6 f3 e6 5e fa 2b c9
| |
| root: e1 a1 53 06 bf ee 79 ee b1 a2 b1 12 fd c1 4d 66
| |
| all: eb e8 1b 1f 27 ba 77 7d 3f 7d 14 28 6c 70 ec c1
| |
|
| |
| ================== FGT3HD3915807690 ==================
| |
|
| |
| is_manage_master()=0, is_root_master()=0
| |
| debugzone
| |
| global: 15 e0 a9 c6 dc a9 fc bd db f6 f3 e6 5e fa 2b c9
| |
| root: e1 a1 53 06 bf ee 79 ee b1 a2 b1 12 fd c1 4d 66
| |
| all: eb e8 1b 1f 27 ba 77 7d 3f 7d 14 28 6c 70 ec c1
| |
|
| |
| checksum
| |
| global: 15 e0 a9 c6 dc a9 fc bd db f6 f3 e6 5e fa 2b c9
| |
| root: e1 a1 53 06 bf ee 79 ee b1 a2 b1 12 fd c1 4d 66
| |
| all: eb e8 1b 1f 27 ba 77 7d 3f 7d 14 28 6c 70 ec c1
| |
|
| |
| slave # diagnose sys ha checksum cluster
| |
|
| |
| ================== FGT3HD3915807690 ==================
| |
|
| |
| is_manage_master()=0, is_root_master()=0
| |
| debugzone
| |
| global: 15 e0 a9 c6 dc a9 fc bd db f6 f3 e6 5e fa 2b c9
| |
| root: e1 a1 53 06 bf ee 79 ee b1 a2 b1 12 fd c1 4d 66
| |
| all: eb e8 1b 1f 27 ba 77 7d 3f 7d 14 28 6c 70 ec c1
| |
|
| |
| checksum
| |
| global: 15 e0 a9 c6 dc a9 fc bd db f6 f3 e6 5e fa 2b c9
| |
| root: e1 a1 53 06 bf ee 79 ee b1 a2 b1 12 fd c1 4d 66
| |
| all: eb e8 1b 1f 27 ba 77 7d 3f 7d 14 28 6c 70 ec c1
| |
|
| |
| ================== FGT3HD3915807993 ==================
| |
|
| |
| is_manage_master()=1, is_root_master()=1
| |
| debugzone
| |
| global: 15 e0 a9 c6 dc a9 fc bd db f6 f3 e6 5e fa 2b c9
| |
| root: e1 a1 53 06 bf ee 79 ee b1 a2 b1 12 fd c1 4d 66
| |
| all: eb e8 1b 1f 27 ba 77 7d 3f 7d 14 28 6c 70 ec c1
| |
|
| |
| checksum
| |
| global: 15 e0 a9 c6 dc a9 fc bd db f6 f3 e6 5e fa 2b c9
| |
| root: e1 a1 53 06 bf ee 79 ee b1 a2 b1 12 fd c1 4d 66
| |
| all: eb e8 1b 1f 27 ba 77 7d 3f 7d 14 28 6c 70 ec c1
| |
|
| |
| Bei beiden Nodes dh. auf dem Master sowie auf dem Slave muss die "checksum" übereinstimmen! In unserem Beispiel wurde das Kommando auf jedem Node ausgeführt und die "checksum" ist auf beiden Node's gleich dh. der HA Cluster ist "in-sync". Ist dies nicht der Fall kann eine Manuell Synchronisation ausgeführt werden:
| |
|
| |
| master # execute ha synchronize start
| |
| starting synchronisation with HA master.......
| |
|
| |
| Danach kann wieder über <code>diagnose sys ha checksum Show</code> überprüft werden ob nun die "checksum" übereinstimmt. Ist die "checksum" unterschiedlich muss folgendes berücksichtigt werden: Jedes Objekt dh. zB Adress Objekt der Konfiguration wird anhand einer "checksum" Kalkuliert. Kann eines dieser Objekte nicht Synchronisiert werden kann zB eine neue Rekalkulation der Objekte ausgeführt werden mit folgendem Kommando:
| |
|
| |
| master # diagnose sys ha checksum recalculate
| |
| slave # diagnose sys ha checksum recalculate
| |
|
| |
| Danach sollte wieder ein manuell Synchronisation auf dem Master ausgeführt werden:
| |
|
| |
| master # execute ha synchronize start
| |
| starting synchronisation with HA master.......
| |
|
| |
| Nun sollte wieder die "checksum" überprüft werden anhand des Kommandos "diagnose sys ha cluster-csum". Ist die "checksum" immer noch unterschiedlich muss eruiert werden, welches Objekt betroffen ist resp. nicht Synchronisiert werden kann. Dies bedeutet: Wie schon erwähnt stellen diese einzelnen "checksum" innerhalb des Kommandos "diagnose sys ha cluster-csum" einzelne Objekte der Konfiguration dar. Diese einzelnen Positionen können anhand folgendes Befehls eingesehen werden und müssen wiederum mit deren "checksum" auf beiden Nodes übereinstimmen. Die Position resp. "checksum" eines Objekts resp. "tablename" die nicht übereinstimmt, ist zuständig für die fehlerhafte Synchronisation. Wenn dieses Object resp. "tablename" verifiziert werden kann, muss das Objekt wie zB Adress Objekte über Mgmt. Web Interface und/oder CLI überprüft, korrigiert oder eventuell gelöscht werden sowie nachträglich eine Rekalkulation und manuelle Synchronisation ausgeführt werden. Um die "checksum" der Objekte einzusehen stehen Levels von 01-04 zur Verfügung sowie die Möglichkeit VDom spezifische "checksum" abzurufen. Somit kann folgendes Kommando auf Master und Slave zur Ueberprüfung der "checksum" ausgeführt werden:
| |
|
| |
| # diagnose sys ha showcsum [Level 01-04] [VDom Name zB "root"]
| |
| system.object-tag: 00000000000000000000000000000000
| |
| system.settings: 91c22fb52fb2a2d307e70ec37da4d3ac
| |
| system.sit-tunnel: 00000000000000000000000000000000
| |
| system.arp-table: 00000000000000000000000000000000
| |
| system.ipv6-neighbor-cache: 00000000000000000000000000000000
| |
| system.vdom-sflow: 00000000000000000000000000000000
| |
| system.vdom-netflow: 00000000000000000000000000000000
| |
| system.vdom-dns: 00000000000000000000000000000000
| |
| system.replacemsg-group: e7834b5d38988f4a34a33fbec505fb06
| |
| system.session-ttl: 00000000000000000000000000000000
| |
| system.dhcp.server: 8f037f10ea79bf4b9df1c27a3bb77eab
| |
| system.dhcp6.server: 00000000000000000000000000000000
| |
| extender-controller.extender: 00000000000000000000000000000000
| |
| system.zone: 00000000000000000000000000000000
| |
| firewall.address: c6cfadd7b7e7893d5ef37d5dd7307da8
| |
| firewall.multicast-address: fbebccef5be92c99c41361c7e52c248f
| |
| firewall.address6: 42b4192de47b1924483fab0817c48a8d
| |
| system.ipv6-tunnel: 00000000000000000000000000000000
| |
| firewall.addrgrp: b49ad3712b937d26fc2f4f46c4606813
| |
| firewall.addrgrp6: 00000000000000000000000000000000
| |
| firewall.service.category: 1a2c593cb5a327725b7b3cf26bd3842e
| |
| firewall.service.custom: fc34d3c54d6704cb8256a5c467c07e1d
| |
| firewall.service.group: c1575532866ae8f7b7e1b162732164ad
| |
| webfilter.ftgd-local-cat: 0c92a88595ebd3cba438a03a2c5c26ba
| |
| ips.sensor: e6078769e4a02346580bd350e05f828d
| |
| firewall.shaper.traffic-shaper: 00000000000000000000000000000000
| |
| firewall.shaper.per-ip-shaper: 00000000000000000000000000000000
| |
| web-proxy.profile: 9d4fce1c7c106d7fb2b2a59c163fd779
| |
| web-proxy.global: 26bdc19e117ffeebedd97853bca1787c
| |
| web-proxy.explicit: 00000000000000000000000000000000
| |
| web-proxy.forward-server: 00000000000000000000000000000000
| |
| web-proxy.forward-server-group: 00000000000000000000000000000000
| |
| wanopt.webcache: 00000000000000000000000000000000
| |
| ftp-proxy.explicit: 00000000000000000000000000000000
| |
| web-proxy.url-match: 00000000000000000000000000000000
| |
| application.custom: 00000000000000000000000000000000
| |
| application.rule-settings: 00000000000000000000000000000000
| |
| application.list: f911b72091be7f2259e7329db3146973
| |
| dlp.filepattern: 00000000000000000000000000000000
| |
| dlp.fp-sensitivity: 00000000000000000000000000000000
| |
| dlp.fp-doc-source: 00000000000000000000000000000000
| |
| dlp.sensor: 80768743871914f18e5e04ee80baa79c
| |
| webfilter.content: 00000000000000000000000000000000
| |
| webfilter.content-header: 00000000000000000000000000000000
| |
| webfilter.urlfilter: c6969556ab7ad7f732072f9746239e22
| |
| webfilter.ips-urlfilter-setting: 00000000000000000000000000000000
| |
| spamfilter.bword: 00000000000000000000000000000000
| |
| spamfilter.bwl: 00000000000000000000000000000000
| |
| spamfilter.mheader: 00000000000000000000000000000000
| |
| spamfilter.dnsbl: 00000000000000000000000000000000
| |
| spamfilter.iptrust: 00000000000000000000000000000000
| |
| log.threat-weight: 8f2bb2e12352b920da714e31fa68ae6c
| |
| netscan.assets: 00000000000000000000000000000000
| |
| netscan.settings: 00000000000000000000000000000000
| |
| icap.server: 00000000000000000000000000000000
| |
| icap.profile: 9d4fce1c7c106d7fb2b2a59c163fd779
| |
| system.network-visibility: 00000000000000000000000000000000
| |
| vpn.certificate.ocsp-server: 00000000000000000000000000000000
| |
| vpn.certificate.setting: 00000000000000000000000000000000
| |
| user.radius: d22bd0c5d99a6c3f6e14826148404219
| |
| user.tacacs+: 00000000000000000000000000000000
| |
| user.ldap: 00000000000000000000000000000000
| |
| user.pop3: 00000000000000000000000000000000
| |
| user.fsso: 00000000000000000000000000000000
| |
| user.adgrp: 00000000000000000000000000000000
| |
| user.fsso-polling: 00000000000000000000000000000000
| |
| user.fortitoken: 00000000000000000000000000000000
| |
| user.password-policy: 00000000000000000000000000000000
| |
| user.local: b36903e5840e462fb75c25cf6c533f11
| |
| user.setting: 00000000000000000000000000000000
| |
| user.peer: 00000000000000000000000000000000
| |
| user.peergrp: 00000000000000000000000000000000
| |
| user.group: 4d3bf9b26a8bad6be19075a2683b1e62
| |
| user.device: 00000000000000000000000000000000
| |
| user.device-group: 00000000000000000000000000000000
| |
| user.device-access-list: 00000000000000000000000000000000
| |
| user.security-exempt-list: 00000000000000000000000000000000
| |
| vpn.ssl.web.realm: 00000000000000000000000000000000
| |
| vpn.ssl.web.virtual-desktop-app-list: 00000000000000000000000000000000
| |
| vpn.ssl.web.host-check-software: 00000000000000000000000000000000
| |
| vpn.ssl.web.portal: 00000000000000000000000000000000
| |
| vpn.ssl.settings: dafc27a290133d4c97c9bc40320868b3
| |
| vpn.ssl.web.user-bookmark: 00000000000000000000000000000000
| |
| voip.profile: dddba01afd2fc4a59b5153df2d290365
| |
| webfilter.profile: 048f1ef6ee2cfa930788157473f059a1
| |
| webfilter.override: 00000000000000000000000000000000
| |
| webfilter.override-user: 00000000000000000000000000000000
| |
| webfilter.ftgd-warning: 00000000000000000000000000000000
| |
| webfilter.ftgd-local-rating: d988f8427134260070217b4372affa27
| |
| webfilter.search-engine: 71dbbd492416b0202b47e85f71bc4e49
| |
| vpn.ipsec.phase1: 00000000000000000000000000000000
| |
| vpn.ipsec.phase2: 00000000000000000000000000000000
| |
| vpn.ipsec.manualkey: 00000000000000000000000000000000
| |
| vpn.ipsec.concentrator: 00000000000000000000000000000000
| |
| vpn.ipsec.phase1-interface: 00000000000000000000000000000000
| |
| vpn.ipsec.phase2-interface: 00000000000000000000000000000000
| |
| vpn.ipsec.manualkey-interface: 00000000000000000000000000000000
| |
| vpn.pptp: 00000000000000000000000000000000
| |
| vpn.l2tp: 00000000000000000000000000000000
| |
| vpn.ipsec.forticlient: 00000000000000000000000000000000
| |
| system.gre-tunnel: 00000000000000000000000000000000
| |
| system.ipip-tunnel: 00000000000000000000000000000000
| |
| system.dns-database: 00000000000000000000000000000000
| |
| system.dns-server: 00000000000000000000000000000000
| |
| log.custom-field: 00000000000000000000000000000000
| |
| antivirus.settings: 00000000000000000000000000000000
| |
| antivirus.quarantine: 00000000000000000000000000000000
| |
| antivirus.profile: 1f8f5954d75aa417047199b4664013ae
| |
| spamfilter.profile: 061a6e89de8ec433363c74b91dd45ae2
| |
| wanopt.settings: 41ed65cfe619f2b23df2d33f13278746
| |
| wanopt.peer: 00000000000000000000000000000000
| |
| wanopt.auth-group: 00000000000000000000000000000000
| |
| wanopt.ssl-server: 00000000000000000000000000000000
| |
| wanopt.profile: 9102047a738af3311271ca99cf5ee889
| |
| system.virtual-wan-link: 00000000000000000000000000000000
| |
| firewall.schedule.onetime: 00000000000000000000000000000000
| |
| firewall.schedule.recurring: a5da71db6bc1f00d6b8dfa96083c174e
| |
| firewall.schedule.group: 00000000000000000000000000000000
| |
| firewall.ippool: 00000000000000000000000000000000
| |
| firewall.ippool6: 00000000000000000000000000000000
| |
| firewall.ldb-monitor: 00000000000000000000000000000000
| |
| firewall.vip: 00000000000000000000000000000000
| |
| firewall.vip46: 00000000000000000000000000000000
| |
| firewall.vip6: 00000000000000000000000000000000
| |
| firewall.vip64: 00000000000000000000000000000000
| |
| firewall.vipgrp: 00000000000000000000000000000000
| |
| firewall.vipgrp46: 00000000000000000000000000000000
| |
| firewall.vipgrp6: 00000000000000000000000000000000
| |
| firewall.vipgrp64: 00000000000000000000000000000000
| |
| firewall.ipmacbinding.setting: 00000000000000000000000000000000
| |
| firewall.ipmacbinding.table: 00000000000000000000000000000000
| |
| firewall.profile-protocol-options: 73b2cdbd6645daf9b07e7f4fd6c555d4
| |
| firewall.ssl-ssh-profile: fffff034f8a65cd99c929fa1e1cba8ce
| |
| firewall.profile-group: 00000000000000000000000000000000
| |
| firewall.identity-based-route: 00000000000000000000000000000000
| |
| firewall.auth-portal: 00000000000000000000000000000000
| |
| firewall.policy: 79d63fd5b370b0e8440164076de508aa
| |
| firewall.local-in-policy: 00000000000000000000000000000000
| |
| firewall.policy6: 00000000000000000000000000000000
| |
| firewall.local-in-policy6: 00000000000000000000000000000000
| |
| firewall.ttl-policy: 00000000000000000000000000000000
| |
| firewall.policy64: 00000000000000000000000000000000
| |
| firewall.policy46: 00000000000000000000000000000000
| |
| firewall.explicit-proxy-policy: 00000000000000000000000000000000
| |
| firewall.dnstranslation: 00000000000000000000000000000000
| |
| firewall.multicast-policy: 00000000000000000000000000000000
| |
| firewall.interface-policy: 00000000000000000000000000000000
| |
| firewall.interface-policy6: 00000000000000000000000000000000
| |
| firewall.DoS-policy: 00000000000000000000000000000000
| |
| firewall.DoS-policy6: 00000000000000000000000000000000
| |
| firewall.sniffer: 00000000000000000000000000000000
| |
| firewall.central-nat: 00000000000000000000000000000000
| |
| firewall.ip-translation: 00000000000000000000000000000000
| |
| endpoint-control.settings: 00000000000000000000000000000000
| |
| endpoint-control.profile: d52bd0f1cad26461a21a827745e4f962
| |
| ips.rule-settings: 00000000000000000000000000000000
| |
| ips.custom: 42713d22db0d063c169b09a795cff369
| |
| ips.settings: 00000000000000000000000000000000
| |
| wireless-controller.setting: 8bef78ab3e5c9a78f8dea3729b973807
| |
| wireless-controller.wids-profile: 438a1136dddd93ec7f532431e3198716
| |
| wireless-controller.wtp-profile: 830bee33e7991c7bf72f1aca88bb2539
| |
| wireless-controller.wtp: 6e89dee243d1ef2a61c5272ea0e39f7f
| |
| wireless-controller.ap-status: 00000000000000000000000000000000
| |
| log.syslogd.override-setting: 00000000000000000000000000000000
| |
| log.memory.setting: 43188b82b01677cc16e8954e649e8879
| |
| log.disk.setting: 43188b82b01677cc16e8954e649e8879
| |
| log.eventfilter: 00000000000000000000000000000000
| |
| log.memory.filter: 00000000000000000000000000000000
| |
| log.disk.filter: 00000000000000000000000000000000
| |
| log.fortiguard.override-setting: 00000000000000000000000000000000
| |
| log.setting: 35187c178f999d345b011b68b743c70c
| |
| log.gui-display: e76f150acba6c16f705b142d34a4d989
| |
| log.fortianalyzer.override-setting: 00000000000000000000000000000000
| |
| router.access-list: 00000000000000000000000000000000
| |
| router.access-list6: 00000000000000000000000000000000
| |
| router.aspath-list: 00000000000000000000000000000000
| |
| router.prefix-list: 00000000000000000000000000000000
| |
| router.prefix-list6: 00000000000000000000000000000000
| |
| router.key-chain: 00000000000000000000000000000000
| |
| router.community-list: 00000000000000000000000000000000
| |
| router.route-map: 00000000000000000000000000000000
| |
| router.rip: c38ebf5e4ad46dd10d0ff61250114ad8
| |
| router.ripng: c38ebf5e4ad46dd10d0ff61250114ad8
| |
| router.static: a1af911b5d65f8505d40c4b633bf458d
| |
| router.policy: 00000000000000000000000000000000
| |
| router.policy6: 00000000000000000000000000000000
| |
| router.static6: 00000000000000000000000000000000
| |
| router.ospf: 5622a8a7e17ba59f7a555d99a52732d9
| |
| router.ospf6: 5622a8a7e17ba59f7a555d99a52732d9
| |
| router.bgp: 4a2522444f080d88f8f14b9777c914d5
| |
| router.isis: db03d6f3e00b1c7e8be8cb3b2bbb9ca6
| |
| router.multicast-flow: 00000000000000000000000000000000
| |
| router.multicast: 00000000000000000000000000000000
| |
| router.multicast6: 00000000000000000000000000000000
| |
| router.auth-path: 00000000000000000000000000000000
| |
| router.setting: 00000000000000000000000000000000
| |
| router.bfd: 00000000000000000000000000000000
| |
| system.proxy-arp: 00000000000000000000000000000000
| |
| system.link-monitor: 00000000000000000000000000000000
| |
| system.wccp: 00000000000000000000000000000000
| |
| system.nat64: 00000000000000000000000000000000
| |
| system.monitors: 00000000000000000000000000000000
| |
|
| |
| Zusätzlich kann ein Objekt resp. "tablename" das nicht über die korrekte "checksum" verfügt resp. nicht "in-sync" ist mit nachfolgenden Befehl näher angeschaut werden:
| |
|
| |
| # diagnose system ha showcsum [path.object/tablename zB "system.admin"]
| |
|
| |
| === Wie kann ich unter FortiOS 5.4 für einen FortiGate HA Cluster über Kommandozeile den Status eines HA Cluster abfragen? ===
| |
|
| |
| Wenn ein FortiGate HA Cluster konfiguriert wird und es nachträglich zu Problemen kommt sind nachfolgende Kommandos über CLI unabdingbar um den Status eine Cluster abzufragen. Dazu stehen verschiedenen Kommandos zur Verfügung:
| |
|
| |
| '''Liste momentane HA Cluster Konfiguration auf'''
| |
|
| |
| # show full-configuration system ha
| |
| config system ha
| |
| set group-id 0
| |
| set group-name "alsochlu-sg0e0"
| |
| set mode a-p
| |
| set password ENC SoVIEtxuVejitqhA7akmWZh2Lajd9sRywB7uzts6cjK72PWJGOK+bt2kq2wA96UDz0XDhOevJVhFumk4arrKMRyhuENVOSDa4T3ukb+asBctsYFrojPuN0PZ+hiJV1Ez24Rxz7rf/l1mzWgxLzzjgQWUcbwWFpkKb8LN/UDNX1KVXVYWf4HefS8vC2H8moUV7UxmkA
| |
| set hbdev "mgmt2" 100 "port1" 50
| |
| unset session-sync-dev
| |
| set route-ttl 10
| |
| set route-wait 0
| |
| set route-hold 10
| |
| set sync-config enable
| |
| set encryption enable
| |
| set authentication enable
| |
| set hb-interval 2
| |
| set hb-lost-threshold 6
| |
| set helo-holddown 20
| |
| set gratuitous-arps enable
| |
| set arps 5
| |
| set arps-interval 8
| |
| set session-pickup enable
| |
| set session-pickup-connectionless disable
| |
| set session-pickup-delay disable
| |
| set update-all-session-timer disable
| |
| set session-sync-daemon-number 1
| |
| set link-failed-signal disable
| |
| set uninterruptible-upgrade enable
| |
| set ha-mgmt-status enable
| |
| set ha-mgmt-interface "mgmt1"
| |
| set ha-mgmt-interface-gateway 198.18.0.1
| |
| set ha-mgmt-interface-gateway6 ::
| |
| set ha-eth-type "8890"
| |
| set hc-eth-type "8891"
| |
| set l2ep-eth-type "8893"
| |
| set ha-uptime-diff-margin 300
| |
| set vcluster2 disable
| |
| set override enable
| |
| set priority 128
| |
| set override-wait-time 0
| |
| set monitor "alsochlu-sg0-ag" "port1" "port2" "port3" "port4"
| |
| unset pingserver-monitor-interface
| |
| set pingserver-failover-threshold 0
| |
| set pingserver-slave-force-reset enable
| |
| set pingserver-flip-timeout 60
| |
| set ha-direct disable
| |
| end
| |
|
| |
| '''Zeige den momentanen Status des HA Cluster'''
| |
|
| |
| # get system ha status
| |
| Model: FortiGate-300D
| |
| Mode: a-p
| |
| Group: 0
| |
| Debug: 0
| |
| ses_pickup: enable, ses_pickup_delay=disable
| |
| Master:128 alsochlu-sg0e1 FGT3HD3915807993 0
| |
| Slave : 64 alsochlu-sg0e2 FGT3HD3915807690 1
| |
| number of vcluster: 1
| |
| vcluster 1: work 169.254.0.1
| |
| Master:0 FGT3HD3915807993
| |
| Slave :1 FGT3HD3915807690
| |
|
| |
| # diagnose sys ha status
| |
| HA information
| |
| Statistics
| |
| traffic.local = s:0 p:902969644 b:406343463943
| |
| traffic.total = s:0 p:902531052 b:406030845215
| |
| activity.fdb = c:0 q:0
| |
|
| |
| Model=300, Mode=2 Group=0 Debug=0
| |
| nvcluster=1, ses_pickup=1, delay=0
| |
|
| |
| HA group member information: is_manage_master=1.
| |
| FGT3HD3915807993, 0. Master:128 alsochlu-sg0e1
| |
| FGT3HD3915807690, 1. Slave: 64 alsochlu-sg0e2
| |
|
| |
| vcluster 1, state=work, master_ip=169.254.0.1, master_id=0:
| |
| FGT3HD3915807993, 0. Master:128 alsochlu-sg0e1(prio=0, rev=0)
| |
| FGT3HD3915807690, 1. Slave: 64 alsochlu-sg0e2(prio=1, rev=1)
| |
|
| |
| '''Liste die Synchronisations Checksum des HA Cluster auf'''
| |
|
| |
| Folgender Befehl zeigt ob der Cluster "in synch" ist dh. die Checksum muss auf beiden Nodes gleich sein:
| |
|
| |
| # diagnose sys ha showcsum
| |
| is_manage_master()=1, is_root_master()=1
| |
| debugzone
| |
| global: 15 e0 a9 c6 dc a9 fc bd db f6 f3 e6 5e fa 2b c9
| |
| root: e1 a1 53 06 bf ee 79 ee b1 a2 b1 12 fd c1 4d 66
| |
| all: eb e8 1b 1f 27 ba 77 7d 3f 7d 14 28 6c 70 ec c1
| |
|
| |
| checksum
| |
| global: 15 e0 a9 c6 dc a9 fc bd db f6 f3 e6 5e fa 2b c9
| |
| root: e1 a1 53 06 bf ee 79 ee b1 a2 b1 12 fd c1 4d 66
| |
| all: eb e8 1b 1f 27 ba 77 7d 3f 7d 14 28 6c 70 ec c1
| |
|
| |
| Für das Kommando "diagnose sys ha" stehen weitere Optionen zur Verfügung:
| |
|
| |
| # diagnose sys ha ?
| |
| stats statistics
| |
| status status
| |
| mac Mac Information.
| |
| showcsum Show HA checksum.
| |
| csum-recalculate Re-calculate HA checksum.
| |
| cached-csum Show HA cached checksum.
| |
| cluster-csum Show HA cluster checksum.
| |
| dump-by Dump HA data by name.
| |
| fib FIB information.
| |
| hadiff HA diff debug.
| |
| reset-uptime Reset HA up time.
| |
| session-sync-dev Session sync ports.
| |
| recalculate-extfile-signature Recalculate external files signature in hasync daemon.
| |
| sync-stats Dump session sync statistics.
| |
| extfile-sig Dump extfile's signature.
| |
|
| |
| <!--- == VDOM ==
| |
| === Wie schalte ich den VDOM Modus auf der FortiGate ein? ===
| |
| Damit man das VDOM Feature auf der FortiGate benutzen kann, muss dieses über WebGui oder über die CLI eingeschaltet werden.
| |
| {| class="wikitable"
| |
| |-
| |
| ! Konfiguration über das WebGui !! Beschreibung !! Konfiguration über CLI
| |
| |-
| |
| |[[Datei:Fortinet-1910.jpg]] ||Dadurch wird Ihr FortiGate nicht neu gestartet, man wird aber ausgelogt von der FortiGate und muss sich neu einloggen.||<pre># config system global
| |
| # set vdom-admin enable
| |
| # end
| |
| </pre>
| |
| |-
| |
| |}
| |
| -->
| |
|
| |
| == Radius ==
| |
|
| |
| === Wie konfiguriere ich auf einer FortiGate unter FortiOS 5.4 eine "Radius" Authentifizierung? ===
| |
|
| |
| Eine Radius Authentifizierung kann in verschiedenen Services für eine Authentifizierung genützt werden. Dabei kann ein lokaler User als Radius Authentifizierung konfiguriert werden oder eine Gruppe. Ausgangslage für die Authentifizierung ist die Konfiguration der Radius Anbindung. Diese kann über CLI oder über Mgmt. Web Interface durchgeführt werden:
| |
|
| |
| User & Device > RADIUS Servers > Create New
| |
|
| |
| [[Datei:Fortinet-2031.jpg]]
| |
|
| |
| Wenn man die Radius Server Konfiguration über CLI durchführen möchte so kann folgendes konfiguriert werden:
| |
|
| |
| # config user radius
| |
| # edit [Name des Radius Servers]
| |
| # set server [IPv4 Adresse des Radius Servers]
| |
| # set secret [Shared Secret des Radius Servers]
| |
| # set secondary-server [IPv4 Adresse des Secondary Radius Servers]
| |
| # set secondary-secret [Shared Secret des Secondary Radius Servers]
| |
| # set tertiary-server [IPv4 Adresse des Tertiary Radius Servers]
| |
| # set tertiary-secret [Shared Secret des Tertiary Radius Servers]
| |
| # set timout [Definition des Timouts für den Radius Server 0 - 300 Sekunden; Standard 5]
| |
| # set all-usergroup [disable | enable]
| |
| # set use-management-vdom [enable | disable}
| |
| # set nas-ip [IPv4 Adress der NAS IP oder Station ID; Standard 0.0.0.0]
| |
| # set acct-interim-interval [Accounting Interval 600 - 86400 Sekunden; Standard 0]
| |
| # set radius-coa [disable | enable]
| |
| # set radius-port [Radius Port; Standard 0]
| |
| # set h3c-compatibility [disable | enable]
| |
| # set auth-type [auto | ms_chap_v2 | ms_chap | chap | pap]
| |
| # set source-ip [Source IPv4 Adresse der Radius Anfrage]
| |
| # set username-case-sensitive [disable | enable]
| |
| # set password-renewal [disable | enable]
| |
| # config accounting-server
| |
| # edit [Gebe einen entsprechenden Integer an zB "1"]
| |
| # set status [disable | enable]
| |
| # set server [IPv4 Adresse für den Accounting Server]
| |
| # set secret [Shared Secret des Accounting Servers]
| |
| # set port [Accounting Port]
| |
| # set source-ip [Source IPv4 Adresse der Accounting Anfrage]
| |
| # end
| |
| # end
| |
|
| |
| Der Standard Port für alle Radius Server wird unter "system global" konfiguriert und ist per Standard auf 1812 konfiguriert, kann jedoch für jeden einzelnen Radius Server konfiguriert werden anhand "radius-port"! Wenn mehrere Radius Server dh. zB secondary-server definiert werden so werden diese nur benutzt wenn der primary nicht erreichbar ist. Wenn der Radius Server korrekt konfiguriert wurde können lokale User basierend auf Radius oder ein lokale Gruppe basierend auf Radius konfiguriert werden, die in den verschiedenen Services für eine Authentifizierung benutzt werden können:
| |
|
| |
| User & Device > User Definition > Create New
| |
|
| |
| [[Datei:Fortinet-2032.jpg]]
| |
|
| |
| [[Datei:Fortinet-2033.jpg]]
| |
|
| |
| [[Datei:Fortinet-2034.jpg]]
| |
|
| |
| Die Definition einer Email Adresse sowie Two-Factor Authentication ist Optional. Dieser lokal erfasste User kann nun zu einer lokalen Gruppen hinzugefügt werden sowie der lokale User und/oder Gruope zu den verschiedenen Service für eine Authentifizierung genutzt werden. Eine Gruppe basierend auf Radius Authentifizierung kann folgendermassen konfiguriert werden:
| |
|
| |
| User & Device > User Groups > Create New
| |
|
| |
| [[Datei:Fortinet-2035.jpg]]
| |
|
| |
| [[Datei:Fortinet-2036.jpg]]
| |
|
| |
| Diese lokale Gruppe kann nun in den verchiedenen Services für eine Authentifizierung genutzt werden. Wenn in einer lokalen Gruppe ein Radius Server hinzugefügt wird, dürfen in dieser Gruppe keine lokalen User hinzugefügt werden für die eine Radius Server Konfiguration durchgeführt wurde.
| |
|
| |
| === Wie konfiguriere ich auf einer FortiGate unter FortiOS 5.4 eine "Radius" Authentifizierung inkl. Radius Attributes? ===
| |
|
| |
| Im Zusammenhang mit einer Radius Authentifizierung können verschiedene Radius Attributes verwendet werden. Diese Radius Attributes werden auf einem Radius Server zB FortiAuthenticator für eine User Authentifizierung dem Radius Client zB einem FortiGate Device nach erfolgreicher Authentifizierung mitgegeben/zurückgesendet damit der Radius Client basierend auf diesen Radius Attributes Aktionen, Zugehörigkeit etc. Ausführen kann. Weitere Informationen zu den Radius Attributes findet man unter folgenden Link:
| |
|
| |
| https://de.wikipedia.org/wiki/Remote_Authentication_Dial-In_User_Service
| |
|
| |
| Somit können anhand Radius Attributes zB innerhalb einer Authentifizierung eine Gruppen Zugehörigkeit des Users mitgegeben werden. Nachfolgendes Beispiel zeigt, wie auf einem FortiGate Device eine Radius Authentifizierung durchgeführt wird und anhand dem Radius Attribute "Fortinet-Group-Name" die Gruppen Zugehörigkeit dem FortiGate Device mitgeteilt wird. Dabei werden keine Lokalen User auf dem FortiGate Devie erfasst sondern die User Informationen befinden sich auf dem FortiAuthenticator resp. Radius Server. Die benutzte Authentifizierung spielt dabei keine Rolle dh. ob eine Einfach Authentifizierung, ActiveDirectory Authentifizierung oder Two-Factor Authentifizierung auf dem FortiAuthenticator resp. Radius Server benutzt wird. Im nachfolgenden Beispiel wird gezeigt wie 3 Gruppen für Radius Authentifizierung anhand Radius Attributes Konfiguriert werden die zB für eine SSL-VPN Authentifizierung benutzt werden können. Konfiguriere auf dem FortiGate Device ein Radius Server:
| |
|
| |
| User & Device > RADIUS Servers > Create New
| |
|
| |
| [[Datei:Fortinet-2175.jpg]]
| |
|
| |
| Konfiguriere auf dem FortiGate Device zB 3 Gruppen für zB SSL-VPN Authentifizierung dh. gr-admin, gr-user, gr-support. Dabei spielen die existierenden Gruppen auf dem Radius Server zB FortiAuthenticator eine entscheidende Rolle dh. diese Gruppen werden auf dem FortiAuthenticator ebenfalls wiederspiegelt anhand der Gruppen gr_admin, gr_user sowie gr_support. Welche Authentifizierung in diesen Gruppen benutzt wird oder ob es sich um Lokale User oder ActiveDirectory User handelt spielt dabei keine Rolle. Wichtig dabei ist Folendes: In den Gruppen muss der Radius Server hinzugefügt werden sowie ein entsprechendes "Radius Attribute" dh. in unserem Beispiel der Gruppen Name der erstellten Gruppe:
| |
|
| |
| User & Device > User Groups > Create New
| |
|
| |
| [[Datei:Fortinet-2176.jpg]]
| |
|
| |
| [[Datei:Fortinet-2177.jpg]]
| |
|
| |
| [[Datei:Fortinet-2178.jpg]]
| |
|
| |
| Wenn diese Konfiguration zB im Zusammenhang mit SSL-VPN benutzt wird so erstelle für jede Gruppe ein entsprechendes IP Subnet Objekt sowie ein entsprechendes SSL-VPN Tunnel/Portal Mode Templage. Dies bedeutet:
| |
|
| |
| gr-admin SSL-VPN Portal "gr-admin-ssl-vpn" SSL-VPN IP Pool "198.18.8.0/27"
| |
| gr-user SSL-VPN Portal "gr-user-ssl-vpn" SSL-VPN IP Pool "198.18.8.32/27"
| |
| gr-support SSL-VPN Portal "gr-support-ssl-vpn" SSL-VPN IP Pool "198.18.8.64/27"
| |
|
| |
| Konfiguriere für die SSL-VPN Portal Templates jeweils für die entsprechende Gruppe den SSL-VPN IP Pool (Tunnel Mode) sowie definiere unter SSL-VPN Settings alle SSL-VPN IP Pool Subnets für "IP Ranges". Zusätzlich in den SSL-VPN Settings füge unter "Authentication/Portal Mapping die entsprechende Gruppe zum entsprechenden SSL-VPN Portal Template und benütze keinen "realm". Es ist empfohlen die SSL-VPN IP Pool Adressen als Statische Route zu Konfiguriren für das Interface "ssl.root". Für die Firewall Policy Rules wird für jede Gruppe eine seperate Firewall Policy Rule erfasst basierend auf dem Incoming Interface "ssl.root", für Source das entsprechende SSL-VPN IP Pool Subnet sowie die entsprechenden Gruppe. Für die Destinationen und Services können unterschiedlich Konfiguriert werden. Somit verfügt jede Gruppe über sein SSL-VPN Portal, SSL-VPN IP Pool Subnet sowie Firewall Policy Rule. Die Konfiguration auf der FortiGate ist abgeschlossen dh. weitere detail Informationen wie ein SSL-VPN Konfiguriert wird siehe auch nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.4-5.6:FAQ#Wie_kann_ich_unter_FortiOS_5.4_ein_SSL-VPN_f.C3.BCr_Portal.2FTunnel_Mode_auf_einer_FortiGate_konfigurieren.3F]]
| |
|
| |
| Wenn nun auf dem FortiGate Device für SSL-VPN eine Authentifizierung durchgeführt wird so werden die Authentifizierungs Informationen zum Radius Server gesendet. Zu diesem Zeitpunkt steht nicht fest ob der User Authorisiert ist eine Authentifizierung durchzuführen und welcher Gruppe dieser angehört. Auf dem Radius Server resp. FortiAuthenticator muss nun ein Radius Client Konfiguriert werden für den FortiGate Device. Dazu siehe nachfolgender Artikel:
| |
|
| |
| [[FortiAuthenticator:FAQ#Wie_kann_ich_auf_einem_FortiAuthenticator_ein_Radius_Client_Konfigurieren.3F]]
| |
|
| |
| Erstelle auf dem Radius Server resp. FortiAuthenticator 3 Gruppen Analog zu den Gruppen auf dem FortiGate Device dh. gr_admin, gr_user sowie gr_support. Wie dies durchzuführe ist siehe nachfolgender Artikel:
| |
|
| |
| [[FortiAuthenticator:FAQ#Wie_kann_ich_auf_einem_FortiAuthenticator_eine_Gruppe_erstellen_und_diese_f.C3.BCr_einen_Radius_Client_Konfigurieren.3F]]
| |
|
| |
| Wie gesagt dabei spielt es keine Rolle welche Authentifizierung oder Realm benutzt wird. Grundsätzlich können alle 3 Gruppen anhand der Filter Funktion "Groups" zum Radius Client als "Realm" "Local | Local Users" hinzugefügt werden. Wichtig dabei ist dass das entsprechende Radius Attribute in den Gruppen definiert wird. Dies bedeutet zB Der FortiAuthenticator Gruppe "gr_admin" wird als Radius Attribute "Fortinet-Group-Name" hinzugefügt und definiert als "gr-admin". Somit wird für einen User in dieser Gruppe dem FortiGate Device "Fortinet-Group-Name" = "gr-admin" übermittelt und somit das entsprechende SSL-VPN Portal, SSL-VPN IP Pool Subnet sowie die entsprechende Firewall Policy Rule durch die Definierung der entsprechenden Gruppe zugewiesen. Weitere Informtionen wie ein Radius Attribute zu konfigurieren ist siehe nachfolgender Artikel:
| |
|
| |
| [[FortiAuthenticator:FAQ#Wie_Konfiguriere_ich_auf_einem_FortiAuthenticator_Radius_Attributes.3F]]
| |
|
| |
| Sobald die Konfiguration auf dem FortiAuthenticator abgeschlossen ist kann die Konfiguration getestet werden! Kommt es zu Problemen sollte ein Debug ausgeführt werden um zu sehen ob die entsprechenden Radius Attribues übermittelt werden vom Radius Server resp. FortiAuthenticator:
| |
|
| |
| [[FortiGate-5.4-5.6:FAQ#Wie_kann_ich_auf_einer_FortiGate_unter_FortiOS_5.4_f.C3.BCr_eine_.22Radius.22_Konfiguration_ein_Troubleshooting_durchf.C3.BChren.3F]]
| |
|
| |
| === Wie kann ich auf einer FortiGate unter FortiOS 5.4 für eine "Radius" Konfiguration ein Troubleshooting durchführen? ===
| |
|
| |
| Wenn man eine Radius Server Anbindung unter FortiOS 5.4 konfiguriert so wird auf der FortiGate ein Radius Server Anbindung konfiguriert mit der IPv4 Adresse oder FQDN des Radius Servers. Die Authentifizierung der Radius Server Anbindung auf der FortiGate zum Radius Server wird über ein definiertes "Preshared Key" konfiguriert. Ebenso muss der FortiGate Device anhand dess IPv4 Adresse oder FQDN Name der IPv4 Adresse der FortiGate auf dem Radius Server als "Radius Client" konfiguriert werden. Anhand dieser Konfiguration sowie des "Preshared Key" wird der Traffic über TCP 1812 (New Radius) sowie das Accounting TCP 1813 verschlüsselt und Authorisiert. Um die Komunikation zwischen dem Radius Client und Radius Server zu überprüfen stehen verschiedenen Kommandos zur Verfügung. Um die Radius Anbindung auf dem FortiGate Device über CLI anhand eines Users zu testen kann folgendes ausgeführt werden:
| |
|
| |
| # diagnose test authserver radius [Server Name] [Schema] [Gebe einen entsprechenden User an] [Gebe das Passwort an des gewählten Users]
| |
|
| |
| ls "Schema" kann folgendes definiert werden:
| |
|
| |
| chap, pap, mschap, mschap2
| |
|
| |
| Wird kein spezifisches "Schema" definiert benutzt das "diagnose test" Kommando "auto". Um den Traffic über TCP Port 1812 anhand des Sniffers aufzuzeichnen kann folgendes Kommando benutzt werden:
| |
|
| |
| # diagnose sniffer packet [Name des Interfaces zB "internal"] 'port 1812' 3
| |
|
| |
| Muss der Radius Port von New Radius 1812 auf Old Radius 1645 konfiguriert werden, kann dies Global für alle definierten Radius Server unter "system global" durchgeführt werden oder in der Radius Server Konfiguration selber:
| |
|
| |
| # config system global
| |
| # set radius-port [Definiere den entsprechenden TCP Port; Standard 1812]
| |
| # end
| |
|
| |
| # config user radius
| |
| # edit [Name des Radius Servers]
| |
| # set radius-port [Radius Port; Standard 0]
| |
| # end
| |
|
| |
| Der Traffic der Radius Anbindung kann ebenfalls über Debug aufgezeichnet und Analysiert werden. Dabei ist zu berücksichtigen, dass es zwei unterschiedliche Deamons/Service zur Verfügung stehen im Zusammenhang mit Debug:
| |
|
| |
| • authd (Deamon für alle lokalen sowie remote Authentifizierungen inkl. FSSO)
| |
| • radiusd (Fortigate radius deamon)
| |
| • fnbamd (Fortigate non-blocking auth deamon)
| |
|
| |
| Bei diesem Debug Vorgang wird relativ viel "output" erzeugt in einer Session. Deshalb ist es wichtig den "output" über eine SSH Verbindung durchzuführen sowie den "output" in ein Log File zu schreiben, damit dieser "output" später für eine Analyse zur Verfügung steht. Für ein "debug" führe folgendes auf der CLI aus:
| |
|
| |
| 1. Konfiguriere "putty" für logging dh. alle Informationen werden in ein Log aufgezeichnet (Category > Session > Logging > All session output)
| |
| 2. Erstelle eine Consolen Verbindung zur FortiGate per SSH
| |
| 3. Führe ein Login durch und gebe folgendes ein:
| |
|
| |
| '''Setze alle Debug Filter zurück'''
| |
|
| |
| # diagnose debug reset
| |
|
| |
| '''Setze einen Debug Filter für "fnbamd" und/oder "authd"'''
| |
|
| |
| # diagnose debug application [fnbamd | authd | radiusd] –1
| |
|
| |
| '''Aktiviere für den debug "output" den "timestamp"'''
| |
|
| |
| # diagnose debug console timestamp enable
| |
|
| |
| '''Aktiviere den Debug Modus mit dem gesetzen Debug Filter'''
| |
|
| |
| # diagnose debug enable
| |
|
| |
| In diesem Beispiel werden beide Filter dh. für "fnbamd" sowie "authd" aktiviert. Für eine detailliert Analyse kann es empfehlenswert sein nur die einzelnen Filter zu setzen. Nach der Konfiguration des Filter sowie Aktivierung des Debug kann eine entsprechende Abfrage resp. Authentifizierung basierend auf Radius durchgeführt werden und der "output" gemäss gesetzten Filter "fnbamd" und/oder "authd" wird erstellt. Nach erfolgten "debug" sollte die "debug" Funktion deaktiviert und der gesetzte Filter zurück gesetzt werden:
| |
|
| |
| '''Deaktiviere die Debug Funktion'''
| |
|
| |
| # diagnose debug disable
| |
|
| |
| '''Dektiviere für den debug "output" den "timestamp"'''
| |
|
| |
| # diagnose debug console timestamp disable
| |
|
| |
| '''Setze den Debug Filter zurück'''
| |
|
| |
| # diagnose debug reset
| |
|
| |
| == Active Directory / LDAP ==
| |
|
| |
| === Wie konfiguriere ich auf einer FortiGate unter FortiOS 5.4 ein "Active Directory/LDAP" Authentifizierung? ===
| |
|
| |
| Wenn unter FortiOS 5.4 ein "ActiveDirectory" konfiguriert werden möchte, kann dies über das Mgmt. Web Interface durchgeführt werden oder CLI. Wenn zB ein LDAP wie "OpenLDAP" konfiguriert werden muss, kann dies zwar über Mgmt. Web Interface durchgeführt werden, jedoch ist dabei zu berücksichtigen, dass unter CLI die entsprechenden Optionen wie zB "group-member-check" sowie "member-attr" korrekt für den "OpenLDAP" gesetzt werden müssen. Um ein Windows basierendes "ActiveDirectory" über Web Mgmt. Interface zu konfigurieren gehe folgendermassen vor:
| |
|
| |
| User & Device > LDAP Servers > Create New
| |
|
| |
| [[Datei:Fortinet-1671.jpg]]
| |
|
| |
| [[Datei:Fortinet-1672.jpg]]
| |
|
| |
| Nachfolgend für die einzelnen Positionen eine Beschreibung was zu konfigurieren ist:
| |
|
| |
| '''Name:'''
| |
|
| |
| Für diese Position muss ein Name für den entsprechenden LDAP Server vergeben werden. Dieser Name steht nicht im Zusammenhang
| |
| mit dem LDAP Server und kann frei gewählt werden. Wir empfehlen hier den Host Namen des LDAP Servers zu konfiguriren!
| |
|
| |
| '''Server IP/Name:'''
| |
|
| |
| Unter dieser Position muss entweder die IPv4 Adresse oder der FQDN des LDAP Servers konfiguriert werden. Wenn der FQDN Name
| |
| des LDAP Servers konfiguriert wird, muss dem FortiOS ermöglicht werden über die konfigurierten "System DNS Server" diesen FQDN
| |
| Name des LDAP Servers aufzulösen. Um keine Abhängigkeiten zu einem DNS Server zu schaffen empfehlen wir die IPv4 Adresse des
| |
| LDAP Servers zu konfigurieren! Wenn dennoch ein FQDN des LDAP Servers konfiguriert wird kann die DNS Auflösung über CLI auf
| |
| dem FortiOS kurz getestet werden:
| |
|
| |
| # execute ping [IPv4 Adresse des LDAP Servers]
| |
|
| |
| Desweiteren stehen auf CLI weitere "Server IP/Name" für Secondary und Tertiary Server Konfiguration zur Verfügung. Werden diese
| |
| konfiguriert werden diese Fallback Server nur dann genutzt, wenn der Primary LDAP Server nicht zur Verfügung steht resp. der
| |
| Secondary Server:
| |
|
| |
| # config user ldap
| |
| # edit [Name des LDAP Servers]
| |
| # set server [IPv4 Adresse des LDAP Servers]
| |
| # set secondary-server [Secondary IPv4 Adresse des LDAP Servers]
| |
| # set tertiary-server [Tertiary IPv4 Adresse des LDAP Servers]
| |
| # end
| |
|
| |
| '''Server Port:'''
| |
|
| |
| Per Standard ist für diese Position der Standard Port eines LDAP Servers konfiguriert dh. Port "389". Durch diesen per Standard
| |
| gesetzten Port wird die Komunikation zwischen dem FortiOS und dem LdAP Servers unverschlüsselt durchgeführt. Möchte man für eine
| |
| sichere Komunikation eine Verschlüsselung konfgurieren, muss die Position "Secure Connection" aktiviert werden. Wird diese Position
| |
| aktiviert, so kann für die Verschlüsselung zwischen "LDAPS" und "STARTTLS" gewählt werden. Der LDAP Port wird bei einer "Secure
| |
| Connection" per Standard auf "636" gesetzt. Bei beiden verschlüsselungs Varianten muss ein entsprechendes Zertifikat definiert
| |
| werden dh. das entsprechende Zertifikat basierend auf dem Active Directory/LDAP muss auf dem FortiOS eingespielt werden und nach
| |
| dem Import auf dem FortiOS unter "Certificate" ausgewählt werden! Per Standard wird unter einem Active Directory/LDAP Konfiguration
| |
| "LDAPS" benutzt.
| |
|
| |
| '''Common Name Identifiert:'''
| |
|
| |
| Unter dieser Position wird definiert wie der User im Active Directory/LDAP gesucht wird. Per Standard wird für diese Position als
| |
| Common Name Identifier "cn" gesetzt kann jedoch für ein Active Directory/LDAP ebenfalls auf "sAMAccountName" gesetzt werden. Dabei
| |
| ist folgendes zu beachten:
| |
|
| |
| • cn = Anhand "cn" wird das Active Directory/LDAP mit dem "vollständigen Namen" des Users im Active Directory/LDAP
| |
| gesucht. Dies bedeutet: Der User muss als Login Usernamen den "Vollständigen Namen" benutzen anstelle des
| |
| Active Directory/LDAP Usernamens sprich "sAMAccountName"!
| |
|
| |
| • sAMAccountName = Anhand des "sAMAccountName" wird das Active Directory/LDAP anhand des Usersname der im Active Directory/LdAP
| |
| für den User definiert wurde durchsucht, anstelle des "vollständigen Namens" wie unter "cn" beschrieben!
| |
|
| |
| '''Distinguished Name:'''
| |
|
| |
| Der "Distinguished Name" eines Active Directory/LDAP Servers definiert die "domainComponent" eine Organization. Dies bedeutet:
| |
| Dieser Name identifiziert das Objekt innerhalb der Hierarchie des Verzeichnisses, und zwar von der untersten Ebene (dem Objekt
| |
| selbst) durch alle Container hindurch bis zum Ursprung des Verzeichnisses, was bei Active Directory/LDAP die Domäne ist. Und
| |
| genau dies Active Directory Domaine muss hier definiert werden. Ausgehend davon, dass ein entsprechender Name sowie IPv4 oder
| |
| FQDN Name für das Active Directory/LDAP vergeben wurde, kann anhand "Fetch DN" der "Distinguished Name" vom Active Directory/LDAP
| |
| abgefragt werden sofern ein "Simple" und/oder "Anonymous" Bind Type zum Active Directory/LDAP erlaubt wird. Ist als "Bind Type"
| |
| Regular gesetzt muss ein für die "Regular" Bind Type Verbindung ein entsprechender Administrator mit dessen Passwort definiert
| |
| werden. Was dabei zu berücksichtigen ist siehe nachfolgend der Abschnitt "Bind Type". Ein "Distinguised Name" sieht per Standard
| |
| für ein Active Directory/LDAP folgendermassen aus:
| |
|
| |
| dc=mydomain,dc=ch
| |
|
| |
| Besitzt ein Active Directory/LDAP mehrer Organisationen dh. "Organization unit" (ou) und der "Distinguished Name" soll für eine bestimmte
| |
| Organisation konfiguriert werden sieht ein "Distinguised Name" folgendermassen aus:
| |
|
| |
| ou=Oranization,dc=mydomain,dc=ch
| |
|
| |
| '''Bind Type:'''
| |
|
| |
| Unter der Position "Bind Type" wird definiert wie die Verbindung zum Active Directory/LDAP Server durchgeführt werden soll. Bei
| |
| "Simple" und "Anonymous" muss kein "User DN" mit einem entsprechenden "Password" definiert werden. Unter "Regular" muss dieser
| |
| "User DN" sowie dessen "Password" definiert werden. Wir empfehlen per Standard "Regular" zu benutzen und "Simple" sowie "Anonymous"
| |
| Bind auf dem Active Directory nicht zu erlauben. Damit ein "Regular" Bind Type durchgeführt werden kann, benötigt man einen Active
| |
| Directory/LDAP Administrator "User DN" mit dessen "Password". Dieser Administrator resp. "User DN" sollte im Active Directory/LDAP
| |
| über volle Rechte für "read-only" verfügen. Es sollte sich dabei nicht um den Standard "Administrator" des Active Directory/LDAP
| |
| handeln sondern explizit für diese Anbdindung konfiguriert werden. Wenn nach der Konfiguration des Administrators auf dem Active
| |
| Directory/LDAP der "User DN" verifiziert werden muss, kann auf dem Active Directory/LDAP in einer DOS Box folgendes durchgeführt
| |
| werden, um den "User DN" zu verifizieren. Dabei muss berücksichtigt werden, dass die DOS Box die auf dem Active Directory/LDAP
| |
| anhand "cmd" geöffnet wird, als "Administrator" geöffnet wird ansonsten können nachfolgende Kommandos nicht durchgeführt werden
| |
| und es kommt zu Fehlermeldungen:
| |
|
| |
| Um "Regular Bind" zu konfiguriren sind 3 Grundsätzliche Informationen unerlässlich:
| |
|
| |
| • Administrator Username und dessen Passwort
| |
|
| |
| • User DN (User DN des Administrators)
| |
| • Bind DN (Distiguished Name des Administrators)
| |
|
| |
| '''User DN'''
| |
|
| |
| > dsquery user -name [Name des Adminstrators]
| |
| cn=Adminstrator,cn=users,dc=mydomain,dc=ch
| |
|
| |
| '''Bind DN'''
| |
|
| |
| > dsquery user -samid Administrator
| |
| cn=Adminstrator,cn=users,dc=mydomain,dc=ch
| |
|
| |
| Somit muss als "User DN" für Bind Type "Regular" folgendes konfiguriert werden:
| |
|
| |
| cn=Adminstrator,cn=users,dc=mydomain,dc=ch
| |
|
| |
| Nach Abschluss der Konfiguration sollte diese anhand des "Test" Button getestet werden. Dies bedeutet: Wird dies durchgeführt und die Konfiguration wurde korrekt durchgeführt, öffnet sich ein zusätzliches Fenster in dem das Active Directory/LDAP ersichtlich ist und der "tree" des Active Directory/LDAP abgebildet wird sowie ermöglicht wird in der Active Directory/LDAP Hirarchie zu "browsen"! Um eine entsprechende Konfiguration auf CLI durchzuführen kann folgendes durchgeführt werden:
| |
|
| |
| # config user ldap
| |
| # edit [Name des LDAP Servers]
| |
| # set server [IPv4 Adresse des LDAP Servers]
| |
| # set secondary-server [Secondary IPv4 Adresse des LDAP Servers]
| |
| # set tertiary-server [Tertiary IPv4 Adresse des LDAP Servers]
| |
| # set source-ip [Source IPv4 Adresse für die LDAP Anfrage]
| |
| # set cnid [Definiere den Common Name dh zB "sAMAccountName" oder "cn"; Standard "cn"]
| |
| # set dn [Definiere den Distinguished Name zB "dc=mydomain,dc=ch"]
| |
| # set type [simple | anonymous | regular]
| |
| # set username [Definiere den "User DN" für Administrator wenn "Regular" benutzt wird]
| |
| # set password [Definiere das Passwort für "User DN" des Administrators]
| |
| # set group-member-check [user-attr | group-object]
| |
| # set group-object-filter [Definiere den Group Object Filer sofern "group-object" benutzt wird]
| |
| # set secure [disable | starttls | ldaps]
| |
| # set ca-cert [Definiere das entsprechende Zertifikat sofern "secure" aktiviert wird]
| |
| # set port [Definiere den LDAP Server Port; Standard 389 oder 636]
| |
| # set password-expiry-warning [enable | disable ; Passwort Expiry Warnings]
| |
| # set password-renewal [enable | disable ; Passwort Expiry Renewal]
| |
| # set member-attr [Definiere das Member Attribute "groupMembership", "memberOf"; Standard "memberOf"]
| |
| # set search-type [Definiere den Search Type; Standard "nested"]
| |
| # end
| |
|
| |
| Wird für den LDAP Server die "password-expiry-warning" sowie "password-renewal" Optionen aktiviert, muss darauf geachtet werden das "Regular" benutzt wird sowie der defnierte "User DN" für den Administrator mit dessen Passwort über "read-write" Rechte im Active Directory/LDAP verfügen. Der Grund ist der Folgende: wenn die Option "password-renewal" aktiviert ist so muss ein Schreibprozess durch die LDAP Anbindung auf dem FortiOS durch den definierten "User DN" in das ActiveDirecory erfolgen! Ohne "read-write" Rechte des Administrators resp. des definierte "User DN" der die Anbindung zum ActiveDirectory ermöglicht, kann dieser Schreibprozess nicht erfolgen. Im Grundsatz wird dies nicht empfohlen! Wenn diese Funktion des "password-renewal" genutzt wird, muss zwingend eine Verschlüsselung konfiguriert werden sowie der Bind Type "Regular" dh. die Active Directory/LDAP Server Anbindung muss über Port 636 sowie anhand "starttls" oder "ldaps" und dem entsprechenden Zertifikat erfolgen. Wie schon erwähnt kann die Konfiguration nach Abschluss einer Active Directory/LDAP Konfiguration über das Mgmt. Web Interface über den "Test" Button getestet werden. Ebenfalls empfehlen wir die Anbindung anhand eines regulären Active Directory/LDAP Users zu testen. Dies kann auf der CLI mit folgenden Befehl durchgeführt werden:
| |
|
| |
| # diagnose test authserver ldap [IPv4 Adresse oder FQDN Name des Active Directory/LDAP Server] [Username] [Passwort]
| |
| authenticate '[Username]' against 'WindowsLDAP' succeeded!
| |
|
| |
| Dieser Test testet einen definierten User mit dessen Passwort für die erfolgte Active Directory/LDAP Server Konfiguration. Dies bedeutet: Dieser Test zeigt ob der User mit dem entsprechenden Usernamen und Passwort im Active Directory/LDAP existiert. Dieser Test berücksichtigt unter normalen Umständen jedoch keine Group Membership usw. sondern zeigt nur ob der Username im Active Directory/LDAP existiert und überprüft dessen Passwort. Ist dieser Test erfolgreich, ist die Active Directory/LDAP Anbindung generell korrekt konfiguriert. Möchte man ein tieferes Troubleshooting durchführen für eine Active Directory/LDAP Anbindung kann dies anhand "debug" durchgeführt werden. Weitere Informationen dazu siehe nachfolgenden Artikel:
| |
|
| |
| [[FortiGate-5.4-5.6:FAQ#Wie_kann_ich_auf_einer_FortiGate_unter_FortiOS_5.4_f.C3.BCr_eine_.22Active_Directory.2FLDAP.22_Konfiguration_ein_Troubleshooting_durchf.C3.BChren.3F]]
| |
|
| |
| === Wie konfiguriere ich auf einer FortiGate unter FortiOS 5.4 ein "User/Gruppe" für Active Directory/LDAP Authentifizierung? ===
| |
|
| |
| Ausgehend davon, dass ein Active Direcotry/LDAP Konfiguration korrekt durchgeführt wurde können User und/oder Gruppen für die verschiedenen Funktionen wie zB SSL-VPN für eine Active Directory/LDAP Authentifizierung konfiguriert werden. Wie ein Active Directory/LDAP Konfiguration durchgeführt wird siehe nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.4-5.6:FAQ#Wie_konfiguriere_ich_auf_einer_FortiGate_unter_FortiOS_5.4_ein_.22Active_Directory.2FLDAP.22_Authentifizierung.3F]]
| |
|
| |
| Wenn eine einfach Authentifizierung (Username und Passwort) für einen User konfiguriert werden soll, kann dies anhand des Mgmt. Web Interfaces durchgeführt werden. Dazu wähle folgendes:
| |
|
| |
| User & Device > User Definition > Create New
| |
|
| |
| [[Datei:Fortinet-1673.jpg]]
| |
|
| |
| [[Datei:Fortinet-1674.jpg]]
| |
|
| |
| [[Datei:Fortinet-1675.jpg]]
| |
|
| |
| Danach kann anhand des "LDAP Tree" der gewünschte User gesucht und hinzugefügt werden. Der User kann nachträglich zu einer "Gruppe" hinzugefügt werden, jedoch darf in dieser Gruppe unter "Remote groups" der "Active Directory/LDAP" Server nicht hinzugefügt werden. Dies bedeutet: Wenn die User auf dem FortiOS einzeln als "lokale" User über den Active Directory/LDAP Server hinzugefügt werden, dürfen diese nicht Mitglied sein von einer lokalen "Gruppe" in dem der Active Directory/LDAP Server unter "Remote Server" hinzugefügt wurde! Wird keine zweifach Authentifizierung durchgeführt dh. die User sollen anhand Username und Passwort eine Authentifizierung durchführen und es sollen keine "lokalen" User auf dem FortiOS erfasst werden, kann eine Active Directory/LDAP Konfiguration anhand eine "lokalen" Gruppe durchgführt werden. Dazu wird eine "lokale" Gruppe erfasst und unter "Remote groups" der konfigurierte Active Directory/LDA" Server hinzugefügt. In diesem Schritt kann unter "Regular" Bind Type entweder "with group search" oder "without group search" gewählt werden:
| |
|
| |
| User & Device > User Groups > Create New
| |
|
| |
| [[Datei:Fortinet-1679.jpg]]
| |
|
| |
| [[Datei:Fortinet-1680.jpg]]
| |
|
| |
| Wird der Active Directory/LDAP Server unter "Remote Serve" ausgewählt und sofort bestätigt dh. keine Gruppe hinzugefügt wir ein "Any" konfiguriert:
| |
|
| |
| [[Datei:Fortinet-1681.jpg]]
| |
|
| |
| Diese Konfiguration "Any" bedeutet "without group search" was wiederum folgendes bedeutet: Es wird im Active Directory/LDAP der ganze "tree" durchsucht nach dem entsprechenden User und nicht nach einer spezifischen Gruppe. Soll ein "group search" konfiguriert werden so kann innerhalb des "Remote Server" Konfiguration unter "Groups" eine oder mehrer Gruppen hinzugefügt werden die berücksichtigt werden sollen. Somit wird nur diese entsprechenden Gruppen im Active Directory/LDAP herangezogen für eine Authentifizierung. Die entsprechenden User müssen für die Authentifizierung diesen Active Directory/LDAP Gruppen hinzugefügt werden:
| |
|
| |
| [[Datei:Fortinet-1682.jpg]]
| |
|
| |
| Wenn für ein User eine zweichfach Authentifizierung konfiguriert werden muss zB für FortiToken, SMS oder Email Authentifzierung muss der User auf dem FortiOS als "lokaler" User aus dem Active Directory/LDAP Server hinzugefügt werden. Auch in diesem Fall gilt: Wenn die User auf dem FortiOS einzeln als "lokale" User für eine zweifach Authentifizierung über den Active Directory/LDAP Server hinzugefügt werden, dürfen diese nicht Mitglied sein von einer lokalen "Gruppe" in dem der Active Directory/LDAP Server unter "Remote Server" hinzugefügt wurde! Die zweifach Authentifizierung kann innerhalb des hinzugefügten Active Directory/LDAP Users für FortiToken, SMS sowie EMail konfiguriert werden. Die Voraussetzung für eine zweifach Authentifizierung basierend für SMS oder Email sind entweder ein "SMS Custom" oder ein "Email Service". Dabei ist zu berücksichtigen, dass ein SMS Versandt nur möglich ist über einen "Email to SMS" Provider und nicht über HTTP/S "get" und/oder "post". Ein "SMS Custom" kann unter CLI folgendermassen konfiguriert werden:
| |
|
| |
| '''SMS Custom'''
| |
|
| |
| # config system sms-server
| |
| # edit [Name des SMS Service]
| |
| # set mail-server [FQDN des SMS Mail Server]
| |
| # next
| |
| # end
| |
|
| |
| Ein Email Server wird über CLI folgendermassen konfiguriert:
| |
|
| |
| '''Email Service'''
| |
|
| |
| # config system email-server
| |
| # set reply-to [Absender Email Adresse]
| |
| # set server [FQDN SMTP Server]
| |
| # set port [Gebe einen entsprechenden Port an zB "25"]
| |
| # set source-ip [Optional gebe eine Source IPv4 Adresse an für den Absender der SMTP Nachricht]
| |
| # set source-ip6 [Optional gebe eine Source IPv6 Adresse an für den Absender der SMTP Nachricht]
| |
| # set authentication [enable | disable]
| |
| # set username [Username für die Authentifizierung]
| |
| # set password [Passwort für die Authentifizierung]
| |
| # set validate-server [enable| disable]
| |
| # set security [none | smtps | starttls]
| |
| # end
| |
|
| |
| Weitere Inforamtionen zum Email Service siehe auch nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.4-5.6:FAQ#Wie_kann_ich_unter_FortiOS_5.4_f.C3.BCr_eine_FortiGate_den_.22Email_Service.22_konfigurieren.3F]]
| |
|
| |
| Somit sind die Voraussetzungen für einen SMS Service, Email Service oder auch FortiToken gegeben kann der "lokale" User für zweifach Authentifizierung konfiguriert werden. Die Aktivierung eines spezifischen zweifach Authentifizierungs Service zB SMS und Email muss über CLI für den User aktiviert werden:
| |
|
| |
| '''Zweifach Authentifizierung basierend auf SMS Custom'''
| |
|
| |
| # config user local
| |
| # edit [Name des lokeln User aus Active Directory/LDAP]
| |
| # set type ldap
| |
| # set two-factor sms
| |
| # set sms-server custom
| |
| # set sms-custom-server [Name des SMS Service der konfiguriert wurde unter "system sms-server"]
| |
| # set sms-phone [Defniere die Mobile Nummer des Active Directory/LDAP Users zB "0041798556715"]
| |
| # set ldap-server [Name des konfigurierten Active Directory/LDAP Server]
| |
| # end
| |
|
| |
| '''Zweifach Authentifizierung basierend auf Email Service'''
| |
|
| |
| # config user local
| |
| # edit [Name des lokeln User aus Active Directory/LDAP]
| |
| # set type ldap
| |
| # set two-factor email
| |
| # set email-to [Email Adresse des Active Directory/LDAP Users zB "andrea.soliva@also.com"]
| |
| # set ldap-server [Name des konfigurierten Active Directory/LDAP Server]
| |
| # end
| |
|
| |
| Nach der Konfiguration auf der CLI sieht der entsprechende Active Directory/LDAP User über Mgmt. Web Interface folgendermassen aus:
| |
|
| |
| '''Zweifach Authentifizierung basierend auf SMS Custom'''
| |
|
| |
| [[Datei:Fortinet-1676.jpg]]
| |
|
| |
| '''Zweifach Authentifizierung basierend auf Email Service'''
| |
|
| |
| [[Datei:Fortinet-1677.jpg]]
| |
|
| |
| Wird die zweifach Authentifizierung anhand FortiTokens durchgeführt, und ausgehend davon das die entsprechenden FortiToken auf dem FortiOS korrekt registriert wurden, muss folgendes durchgeführt werden:
| |
|
| |
| '''Zweifach Authentifizierung basierend auf FortiToken'''
| |
|
| |
| # config user local
| |
| # edit [Name des lokeln User aus Active Directory/LDAP]
| |
| # set type ldap
| |
| # set two-factor fortitoken
| |
| # set fortitoken [Serial Nummer des entsprechenden FortiToken zB "FTKMOBXXXXXXXXX"]
| |
| # set sms-server [fortiguard | custom]
| |
| # set sms-custom-server [Name des SMS Service der konfiguriert wurde unter "system sms-server"]
| |
| # set sms-phone [Defniere die Mobile Nummer des Active Directory/LDAP Users zB "0041798556715"]
| |
| # set ldap-server [Name des konfigurierten Active Directory/LDAP Server]
| |
| # end
| |
|
| |
| [[Datei:Fortinet-1678.jpg]]
| |
|
| |
| In diesem Beispiel wurden nicht der physische FortiToken benützt sondern ein FortiTokenMobile dh. anhand einer "App" existiert der FortiToken Software basierend auf einem Mobile Device. In so einem Fall, muss der Activation Code über "SMS" oder "Email" für die Aktivierung des FortiTokenMobile dem entsprechenden Mobile Device (Mobile Nummer) für den User aus dem Active Directory/LDAP zugesendet werden. Bei einem physischen FortiToken fällt dieser Schritt zur Aktivierung des FortiToken weg.
| |
|
| |
| === Wie kann ich auf einer FortiGate unter FortiOS 5.4 für eine "Active Directory/LDAP" Konfiguration ein Troubleshooting durchführen? ===
| |
|
| |
| Wenn es für eine "Active Directory/LDAP" Konfiguration zu Problemen kommt, kann ein "debug" durchgeführt werden. Dieser "debug" wird anhand des "Fortigate non-blocking auth deamon" durchgeführt und wird auch als Service "fnbamd" bezeichnet. Dabei wird relativ viel "output" erzeugt in einer Session. Deshalb ist es wichtig den "output" in ein Log File zu schreiben, damit dieser "output" später für eine Analyse zur Verfügung steht. Für ein "debug" führe folgendes auf der CLI aus:
| |
|
| |
| 1. Konfiguriere "putty" für logging dh. alle Informationen werden in ein Log aufgezeichnet (Category > Session > Logging > All session output)
| |
| 2. Erstelle eine Consolen Verbindung zur FortiGate per SSH
| |
| 3. Führe ein Login durch und gebe folgendes ein:
| |
|
| |
| '''Setze alle Debug Filter zurück'''
| |
|
| |
| # diagnose debug reset
| |
|
| |
| '''Setze einen Debug Filter für "fnbamd"'''
| |
|
| |
| # diagnose debug application fnbamd –1
| |
|
| |
| '''Aktiviere für den debug "output" den "timestamp"'''
| |
|
| |
| # diagnose debug console timestamp enable
| |
|
| |
| '''Aktiviere den Debug Modus mit dem gesetzen Debug Filter'''
| |
|
| |
| # diagnose debug enable
| |
|
| |
| Danach kann eine entsprechende Abfrage resp. Authentifizierung basierend auf Active Directory/LDAP durchgeführt werden und der "output" gemäss gesetzten Filter "fnbamd" wird erstellt. Nach erfolgten "debug" sollte die "debug" Funktion deaktiviert und der gesetzte Filter zurück gesetzt werden:
| |
|
| |
| '''Deaktiviere die Debug Funktion'''
| |
|
| |
| # diagnose debug disable
| |
|
| |
| '''Dektiviere für den debug "output" den "timestamp"'''
| |
|
| |
| # diagnose debug console timestamp disable
| |
|
| |
| '''Setze den Debug Filter zurück'''
| |
|
| |
| # diagnose debug reset
| |
|
| |
| Eine weitere Möglichkeit Authentifizierungsprobleme für Active Directory/LDAP zu untersuchen ist das Sniffer Kommando. Dabei werden innerhalb des Sniffer "output" Frames in "HEX" ausgegeben die nachträglich intepretiert werden könnnen. Nachfolgend eine Liste der verschiedenen Meldungen:
| |
|
| |
| 0x525 - user not found
| |
| 0x52e - invalid credentials
| |
| 0x530 - not permitted to logon at this time
| |
| 0x531 - not permitted to logon from this workstation
| |
| 0x532 - password expired
| |
| 0x533 - account disabled
| |
| 0x701 - account expired
| |
| 0x773 - user must reset password
| |
| 0x775 - account locked out
| |
|
| |
| # diagnose sniffer packet any "port 389" 3
| |
|
| |
| Der Filter für das Sniffer Kommando sollte so gut wie möglich eingeschränkt werden dh. Kombinationen wie zB die IPv4 Adresse des Clients bei dem Authentifizierungs Probleme auftreten können anhand eines Filters weiter einzuschränkt werden wie zB:
| |
|
| |
| # diagnose sniffer packet any "port 389 and host 192.168.1.1" 3
| |
|
| |
| Für weitere Informationen betreffend Sniffer Kommando siehe auch nachfolgender Artikel:
| |
|
| |
| [[FortiGate:Diagnose-Sniffer-Guide#diagnose_sniffer_packet]]
| |
|
| |
| == Virtual Servers ==
| |
|
| |
| === Wie kann ich unter FortiOS 5.4 einen Virtual Server für ActiveSync/OWA Konfigurieren und was ist dabei zu berücksichtigen? ===
| |
|
| |
| Wenn man eine TMG Installation durch einen FortiGate Device ablösen möchte oder ActiveSync/OWA über einen FortiGate Device schützen möchte kann dies durch folgende Konfiguration durchgeführt werden:
| |
|
| |
| • Destination NAT (Vip Object) ohne SSL-Offloading
| |
| • Virtual Server (Reverse Proxy) / Destination NAT mit SSL-Offloading
| |
|
| |
| Wenn kein SSL-Offloading durchgeführt wird dh. anhand eines klassischen Destination NAT kann die Session vom Client/Host zum ActiveSync/OWA Server nicht Inspected werden anhand zB Application Control, IPS Profile da die Session für HTTPS (Port 443) verschlüsselt ist und somit nicht aufgebrochen werden kann. Somit ist diese Konfigurtion zwar möglich jedoch bietet diese Konfigurtion keinen effektiven Schutz für Angreifer über HTTPS da der Traffic nicht Inspected werden kann. Dennoch ist diese Implementation für kleinere Unternehmen eine übliche Konfiguration. Möchte man einen effektiven Schutz konfigurieren muss dies anhand eines Virtual Servers der ein Reverse Proxy darstellt durchgeführt werden. Dabei kann der Traffic des Client/Host zum Virtual Server der FortiGate anhand des Zertifikates aufgebrochen (SSL-Offloading) werden und somit vollumfänglich Inspected werden. Nachfolgend eine Darstellung der Verbindung:
| |
|
| |
| ________________________________ _____________________________
| |
| | | | |
| |
| Client/Host ---> Internet -------> | Virtual Server (Reverse Proxy) | -----> VIP Object (Destination NAT) -----> | |
| |
| | | | Exchange ActiveSync/OWA |
| |
| <------- [Session 1] ------------> | SSL-Offloading/Inspection | <-------------- [Session 2] -------------> | |
| |
| | | | Exchange Privat Certificate |
| |
| Client/Host Public Certificate --> | Exchange Privat Certificate | <------ Exchange Public Certificate -----> | |
| |
| |________________________________| |_____________________________|
| |
|
| |
| Wenn diese Konfiguration eines Virtual Servers mit SSL-Offloading durchgeführt wird, muss die Performance für ein SSL-Offloading berücksichtigt werden dh. SSL-Offloading steht unter FortiOS 5.4 nur FortiGate Devices zur Verfügung ab FG-100D dh. die Konfiguration steht für FortiGate Device kleiner als FG-100D nicht zur Verfügung. Wenn eine Session von einem Client/Host zur FortiGate gesendet wird ist der erste Schutz den eine FortiGate bieten kann die DDoS Policy (Distributed Denial of Service Attack). Unter FortiOS 5.4 ist es neu möglich spezifisch für einen Server in unserem Fall ActiveSync/OWA Server eine DDoS Policy Rule zu implementieren um diesen vor DDoS Attacken zu schützen. Wie eine DDoS Policy Rule implementiert wird siehe nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.4-5.6:FAQ#Wie_kann_ich_unter_FortiOS_5.4_eine_DDos_Policy_Konfigurieren_und_was_muss_ich_ber.C3.BCcksichtigen.3F]]
| |
|
| |
| Damit die Virtual Server Konfiguration durchgeführt werden kann benötigen wir in erster Stelle ein VIP Objekte das unser Destination NAT für den Exchange Server resp. ActiveSync/OWA zur Verfügung stellt. Dieses VIP Objekt wird nicht wie üblich erstellt sondern über den Virtual Server (Reverse Proxy). Dies bedeutet: Durch die Konfiguration des Virtual Servers wird im Hintergrund anhand der Public IPv4 Adresse des ActiveSync/OWA Servers resp. Exchange effektiv ein VIP Objekt angelegt als Reverse Proxy. Durch das hinzufügen eines Real Servers zum Virtual Server dh. durch die Konfiguration der internen IPv4 Adresse für ActiveSync/OWA resp. Exchange innerhalb des Real Servers wird das Mapping dem Virtual Server resp. VIP Objekts hinzugefügt (Destination NAT). Dieses Objekt wird in einem späteren Schritt als normales VIP Objekt benutzt innerhalb einer Firewall Policy Rule um das Destination NAT zu Konfigurieren. Damit die Konfiguration des Virtual Servers durchgeführt werden kann muss nun das "Exchange Zertifikat" auf der FortiGate importiert werden. Dieser Schritt muss korrekt durchgeführt werden ansonsten kann kein erfolgreiches SSL-Offloading durchgeführt werden. Das nachfolgende Dokument gibt Auskunft wie dies durchgeführt werden kann:
| |
|
| |
| [[Datei:Fortios certificate management.pdf]] (Siehe Punkt 13/17/19)
| |
|
| |
| Nun erstelle im nächsten Schritt den Virtual Server (Reverse Proxy):
| |
|
| |
| Policy & Objects > Virtual Servers > Create New
| |
|
| |
| [[Datei:Fortinet-2140.jpg]]
| |
|
| |
| # config firewall vip
| |
| # edit [Name des Virtual Server zB "ActiveSync-OWA-Publishing"]
| |
| # set comment [Gebe einen entsprechenden Kommentar ein zB "Reverse Proxy ActiveSync/OWA"]
| |
| # set type server-load-balance
| |
| # unset src-filter
| |
| # unset extip
| |
| # set extip [IPv4 Public Adresse für ActiveSync/OWA resp. Exchange zB "193.193.135.66"]
| |
| # set extintf [Name des Interfaces für Public IPv4 Adresse für ActiveSync/OWA resp. Exchange zB "wan1"]
| |
| # set server-type https
| |
| # unset srcintf-filter
| |
| # unset monitor
| |
| # set persistence ssl-session-id
| |
| # unset extport
| |
| # set extport 443
| |
| # set ssl-mode full
| |
| # set ssl-certificate [Name des Private Certificate für ActiveSync/OWA resp. des Exchange Servers zB "Fortinet_CA_SSL"]
| |
| # end
| |
|
| |
| In der Virtual Server Konfiguration wird die Virtual Server IPv4 Adresse definiert. Diese Virtual Server IPv4 Adresse in unserem Beispiel "193.193.135.66" stellt die Public IPv4 Adresse dar für den ActiveSync/OWA Server resp. Exchange Server. Ebenso muss innerhalb des Virtual Servers das Certificate definiert werden dh. das Private Certificate des Exchange das im vorhergehenden Schritt auf dem FortiGate Device importiert wurde. In unserem Beispiel wäre dies das "Fortinet_CA_SSL" Certificat das jedoch nicht definiert werden darf und nur als Beispiel zur Verfügung steht. Als Interface muss das Interface definiert werden das benutzt wird um die Public IPv4 Adresse des ActiveSync/OWA resp. Exchange Servers zu erreichen. Nun muss der Real Server Konfiguriert werden dh. dieser Server stellt unser ActiveSync/OWA resp. Exchange Server dar im internen Netz:
| |
|
| |
| Policy & Objects > Real Servers > Create New
| |
|
| |
| [[Datei:Fortinet-2141.jpg]]
| |
|
| |
| # config firewall vip
| |
| # edit [Name des Virtual Server zB "ActiveSync-OWA-Publishing"]
| |
| # config realservers
| |
| # edit [Gebe einen entsprechenden Integer ein zB "0"]
| |
| # set ip [Interne IPv4 Adresse für ActiveSync/OWA resp. Exchange Servers 198.18.0.92
| |
| # set port 443
| |
| # unset healthcheck
| |
| # end
| |
| # end
| |
|
| |
| Damit in der später Konfigurierten Firewall Policy Rule eine Deep Inspection durchgeführt werden kann muss ein SSL Inspection Profile erstellt werden da wir in dieser Firewall Policy Rule benützen können. In diesem SSL Inspection Profile wird wiederum das Privat Certificate des Exchange Servers definiert das im ersten Schritt auf der FortiGate Importiert wurde. In unserem Beispiel wäre dies das "Fortinet_SSL" Certificat das jedoch nicht definiert werden darf und nur als Beispiel zur Verfügung steht:
| |
|
| |
| Security Profiles > SSL Inspection > Create New
| |
|
| |
| [[Datei:Fortinet-2142.jpg]]
| |
|
| |
| Nun erstellen wir eine Firewall Policy Rule und zwar folgendermassen:
| |
|
| |
| [[Datei:Fortinet-2143.jpg]]
| |
|
| |
| In der Firewall Policy Rule wird als Incoming Interface das Interface definiert das ebenfalls im Virtual Servers definiert wurde dh. das Interface das benutzt wird für die Public IPv4 Adresse des ActiveSync/OWA resp. Exchange Servers. Als Outgoing Interface wird das Interface definiert das benutzt wird für die Definition der Real Server IPv4 Adresse resp. dieses Outgoing Interface wird benutzt um die interne IPv4 Adresse des ActiveSync/OWA resp. Exchange Servers zu erreichen. Als Destination Address wird unser Virtual Server Objekt definiert das in Wirklichkeit ein VIP Objekt darstellt mit integriertem Reverse Proxy. Es ist zu empfehlen für einen ersten Test keine anderen Security Feature zu implementieren sondern lediglich den einwandfreien Zugriff auf ActiveSync/OWA resp. Exchange. Bie diesem Test darf keine Fehlermeldung betreffend Certificate erscheinen was wiederum gewährleistet, dass die korrekten Certificate in den FortiGate Device importiert und benützt werden. Bei diesem Test kann in einem ersten Schritt ebenfalls überprüft werden welche Verschlüsselungen zugelassen werden sowie welche "ciphers" (DiffiHellman). Dieser Test kann Online durchgeführt werden oder anhand eines lokalen Tools. Für einen Online Test aus dem Internet kann folgender Link benutzt werden:
| |
|
| |
| https://www.ssllabs.com/ssltest/analyze.html
| |
|
| |
| Wenn man ein lokales Tool benützen möchte kann folgendes Tool benützt werden:
| |
|
| |
| https://github.com/jvehent/cipherscan [[Datei:Cipherscan.txt]]
| |
|
| |
| Dieses Tool basiert auf eine "bash" Script das jedoch auch auf Windows ebenfalls ausgeführt werden kann. Weitere Informationen findet man über den vorhergehenden Link. Wird das Tool über Linux ausgeführt kann folgende Syntax benutzt werden:
| |
|
| |
| # /opt/scripts/cipherscan [Public IPv4 Adresse für ActiveSync/OWA resp. Exchange Server]:443
| |
|
| |
| Um zu sehen welche unsichere "ciphers" zugelassen sind kann folgendes Kommando ausgeführt werden:
| |
|
| |
| # openssl s_client -connect [Public IPv4 Adresse für ActiveSync/OWA resp. Exchange Server]:443 -cipher "RC4"
| |
|
| |
| Eine andere Variante dh. alle "RC4" "ciphers" zu durchsuchen und festzustellen ob anhand diesen eine Verbindung zustande kommt wäre folgender Befehl der auf den meisten Linux Derivaten funktionieren sollte:
| |
|
| |
| # for i in `openssl ciphers -v 'RC4' | awk '{print $1}'`; do echo -ne "$i\t" ; echo | openssl s_client -connect [Public IPv4 Adresse für ActiveSync/OWA resp. Exchange Server]:443 -cipher "$i" 2>&1 | grep New; done
| |
|
| |
| Grundsätzlich basiert speziell ActiveSync auf SSL und nicht TLS. Dabei spielen die "ssl-dh-bits" (DiffiHellman) eine entscheidende Rolle und es sollte kontrolliert werden ob diese betreffend SSL auf mind 2024 gesetzt sind:
| |
|
| |
| # config firewall.ssl setting
| |
| # set ssl-dh-bits [768 | 1024 | 1536 | 2048]
| |
| # end
| |
|
| |
| Unter FortiOS 5.4 ist es zusätzlich möglich diese "ssl-dh-bits" höhere zu setzen als 2048 jedoch ist dabei Folgendes zu berücksichtigen: Alle Fortigate Devices die über einen CP8 verfügen unterstützen nur "ssl-dh-bits" bis 2048. Bei FortiGate Devices die über einen CP9 verfügen können die "ssl-dh-bits" auf 3072 oder 4096 gesetzt werden. Wie schon erwähnt basiert ActiveSync auf SSL besser wäre jedoch TLS. Dies kann über den Exchange über das "Group Policy Object" konfiguriert werden anhand "FIPS Encryption". Wenn die "ssl-dh-bits" sowie eine event. Anpassung der "FIPS Encryption" durchgeführt wurde kann abermalls über die erwähnten Möglichkeiten einen Scan durchgeführt werden um die Modifikationen zu überprüfen. Der Zugriff über den Virtual Server resp. Reverse Proxy ist nun gewährleistet und die Funktion der Certicate wurde ebenfalls überprüft. Momentan exisitert weder über IPS (Intrusion Prevention System) noch über Application Control ein Schutz um die entsprechenden gewünschten Protokoll sowie Verhalten zu schützen. Im ersten Schritt erstellen wir ein IPS Profile für ActiveSync/OWA resp. für den Exchange Server. Dabei liegt der Fokus auf zwei Sensoren. Der Sensor "OWA-Publishing" schützt den OWA Server betreffend unerwünschter Manipulationen sowie eine Custom IPS Signatur die einen Schutz vor "brutforce attacken" bietet. Dieser Schutz betreffend "brutforce attacke" ist jedoch bereits bis zu einem Punkt gegeben da wir eine DDos Policy Rule implementiert haben die solche Angriffe im Vornerein verhindern sollte. Nichts desto trotz sollte diese zweite Stufe über IPS Profile inkl. der Custom IPS Signature Konfiguriert werden. Bevor die Konfiguration durchgeführt wird sollten alle IPS sowie Application Controll Informationen auf den neusten Stand gebracht werden:
| |
|
| |
| # execute update-now
| |
|
| |
| Durch dieses Kommando werden alle UTM Feature Datenbanken auf den neusten Stand gebracht und somit stehen alle IPS Sensoren sowie Application Control Einträge vollständig zur Verfügung. Das Update über "execute update-now" kann einige Minuten in Anspruch nehmen. Danach führe auf CLI folgendes aus:
| |
|
| |
| # config ips sensor
| |
| # edit "ActiveSync-OWA-Publishing"
| |
| # config entries
| |
| # edit 1
| |
| # set application IIS MS_Exchange
| |
| # set location server
| |
| # next
| |
| # end
| |
| # next
| |
| # end
| |
|
| |
| Durch diese CLI Kommandos wird ein IPS Profile erstellt betreffend "IIS MS_Exchange". Die "action" betreffend "IIS MS_Exchange" stehen auf "default" und sollte so belassen werden. Um die verschiedenen "default" Action für die vers. Sensoren einzusehen kann das IPS Profile über Mgmt. Web Interface eingesehen werden:
| |
|
| |
| Security Profiles > Intrusion Protection > ActiveSync-OWA-Publishing
| |
|
| |
| Nun erstellen wir die Custome IPS Signature. Diese gewährleistet, dass eine "brutforce attacke" betreffend Login OWA im Log ersichtlich ist oder geblockt werden kann. Dabei spielt die Definition "--within_abs 20" sowie "--rate 3,180" eine entscheidende Rolle dh. wenn eine "brutforce attacke" durchgeführt wird und zwar 20 mal innerhalb 180 Sekunden wird ein Log ausgelöst. Erstelle die IPS Custome Signature:
| |
|
| |
| # config ips custom
| |
| # edit "MS.OWA.Login.Error"
| |
| # set comment "MS.OWA.Login.Error"
| |
| <nowiki># set signature "F-SBID( --attack_id 3608; --name \"MS.OWA.Login.Error\"; --protocol tcp; --service http; --flow from_server,reversed; --pattern \"<div class=|22|signInError|22 20|role=|22|alert|22|>\"; --context body; --no_case; --pattern !\"<|2F|div>\"; --context body; --no_case; --within_abs 20; --rate 3,180;)"</nowiki>
| |
| # next
| |
| # end
| |
|
| |
| Nun fügen wir die Custom IPS Signature zu unserem bereits existierenden IPS Profile "ActiveSync-OWA-Publishing":
| |
|
| |
| # config ips sensor
| |
| # edit "ActiveSync-OWA-Publishing"
| |
| # config entries
| |
| # edit 2
| |
| # set rule [Rule ID resp. "--attack_id" zB "3608"]
| |
| # set status enable
| |
| # set log enable
| |
| # set action default
| |
| # end
| |
| # end
| |
|
| |
| Per Standard steht diese IPS custom Signature auf "Monitor all". Somit kann über das Log festgestellt werden ob eine "brutforce attacke" durchgeführt wird. Bei Bedarf kann die IPS custom signatur ebenfalls auf "set action block" gesetzt werden oder auf "set action quarantine". Nachträglich ist diese IPS custom Signatur ebenfalls innerhalb unseres IPS Profiles über Mgmt. Interface ersichtlich:
| |
|
| |
| Security Profiles > Intrusion Protection > ActiveSync-OWA-Publishing
| |
|
| |
| Als nächstes erstellen wir ein Application Profile. In diesem liegt der Fokus darin, dass nur entsprechende SSL/TLS Versionen erlaubt werden sowie über die verschiedenen Application Control Signaturen nur verschiedene Applikationen/Funktionen erlaubt werden. Dabei muss folgendes hinzugefügt werden:
| |
|
| |
| Für OWA folgende Signaturen: Outlook.Web.App, HTTPS.BROWSERS
| |
| Für ActiveSync folgende Signaturen: Activesync
| |
| Für OWA und ActiveSync SSL_SSLv3, SSL-TLSv1.0, SSL_TLSv1.1, SSL_TLS_1.2
| |
| Für Exchange Autodiscovery NTLM.HTTP, SOAP
| |
| Für Outlook Client Outlook.Anywherec
| |
|
| |
| Diese Angaben basierend auf Exchange 2016 und gehen davon aus, dass alle Funktionen genutzt werden dh. nicht nur ActiveSync. Wenn nur einzelne Funktionen genutzt werden wie zB ActiveSync sind nur die entsprechenden Application Control Signaturen zu benutzen. Die einfachste Art dieses Application Profile mit den entsprechenden Signaturen zu erstellen ist über CLI. Danach muss jedoch das Application Profile über Mgmt. Web Interface betreffend den Einträgen/Signaturen kontrolliert werden. Die hinzugfügten Application Signature sind alle auf "Monitor" dh. diese sind erlaubt. Alle anderen existierenden Signaturen sind auf Action "block". Erstelle das Applicaton Profile "ActiveSync-OWA-Publishing" über CLI und kontrolliere dieses nachträglich über Mgmt. Web Interface:
| |
|
| |
| # config application list
| |
| # edit "ActiveSync-OWA-Publishing"
| |
| # set comment "Reverse Proxy ActiveSync/OWA"
| |
| # unset replacemsg-group
| |
| # set other-application-action block
| |
| # set app-replacemsg enable
| |
| # set other-application-log enable
| |
| # set unknown-application-action block
| |
| # set unknown-application-log enable
| |
| # unset p2p-black-list
| |
| # set options allow-dns
| |
| # config entries
| |
| # edit 1
| |
| # unset risk
| |
| # unset category
| |
| # unset sub-category
| |
| # set application "26886" "40568" "17613" "39280" "24747" "16730" "41543" "41542" "41541" "41540"
| |
| # set action pass
| |
| # set log enable
| |
| # next
| |
| # edit 2
| |
| # unset risk
| |
| # set category "2" "3" "5" "6" "7" "8" "12" "15" "17" "19" "21" "22" "23" "25" "28" "29" "30" "31"
| |
| # unset sub-category
| |
| # unset application
| |
| # set protocols all
| |
| # set vendor all
| |
| # set technology all
| |
| # set behavior all
| |
| # set popularity 1 2 3 4 5
| |
| # unset tags
| |
| # set action block
| |
| # set log enable
| |
| # end
| |
| # end
| |
|
| |
| Security Profiles > Application Control > ActiveSync-OWA-Publishing
| |
|
| |
| [[Datei:Fortinet-2144.jpg]]
| |
|
| |
| Wenn ActiveSync/OWA genutzt wird sollte auch mit einem Antivirus Profile gearbeitet werden dh. Files die zB für Attachements in das OWA raufgeladen werden sollten über Antivirus überprüft werden. Erstelle ein entsprechendes Antivirus Profile:
| |
|
| |
| # config antivirus profile
| |
| # edit "ActiveSync-OWA-Publishing"
| |
| # set comment "Reverse Proxy ActiveSync/OWA"
| |
| # set inspection-mode proxy
| |
| # set mobile-malware-db disable
| |
| # end
| |
| # config antivirus profile
| |
| # edit "ActiveSync-OWA-Publishing"
| |
| # config http
| |
| # unset archive-block
| |
| # unset archive-log
| |
| # set options scan
| |
| # end
| |
| # config ftp
| |
| # unset options
| |
| # unset archive-block
| |
| # unset archive-log
| |
| # set emulator enable
| |
| # end
| |
| # config imap
| |
| # unset options
| |
| # unset archive-block
| |
| # unset archive-log
| |
| # set emulator enable
| |
| # set executables virus
| |
| # end
| |
| # config pop3
| |
| # unset options
| |
| # unset archive-block
| |
| # unset archive-log
| |
| # set emulator enable
| |
| # set executables virus
| |
| # end
| |
| # config smtp
| |
| # unset options
| |
| # unset archive-block
| |
| # unset archive-log
| |
| # set emulator enable
| |
| # set executables virus
| |
| # end
| |
| # config mapi
| |
| # unset options
| |
| # unset archive-block
| |
| # unset archive-log
| |
| # set emulator enable
| |
| # set executables virus
| |
| # end
| |
| # config nntp
| |
| # unset options
| |
| # unset archive-block
| |
| # unset archive-log
| |
| # set emulator enable
| |
| # end
| |
| # config nac-quar
| |
| # set infected none
| |
| # set log enable
| |
| # end
| |
| # set av-virus-log enable
| |
| # set av-block-log enable
| |
| # end
| |
|
| |
| Danach kann das Antivirus Profile kurz ebenfalls über Mgmt. Web Interface überprüft werden:
| |
|
| |
| Security Profiles > Antivirus > ActiveSync-OWA-Publishing
| |
|
| |
| Desweiteren sollten die allgemeine Möglichkeiten betreffend Antivirus nochmals überprüft werden dh. zB File Grösse, Heuristic usw. Weitere Informationen dazu siehe nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.4-5.6:FAQ#Antivirus]]
| |
|
| |
| Damit eine SSL-Inspection durchgeführt werden kann für diese UTM Profiles muss als Nächstes ein SSL-Inspection Profile erstellt werden. Wenn ein SSL-Inspection Profile über Mgmt. Web Interface erstellt wird für "Protecting SSL Server" wird im Hintergrund automatisch ein "ssl-exempt" durchgeführt und folgende Kategorien hinzugefügt:
| |
|
| |
| • 31 Finance and Banking
| |
| • 33 Health and Wellness
| |
| • 87 Personal Privacy
| |
|
| |
| Dies ist zu verhindern und für unseren Gebrauch des SSL-Inspection Profiles völlig Sinnlos. Aus diesem Grund empfehlen wir das SSL-Inspection Profile über CLI zu erstelle oder nachträglich die Einträge für "ssl-exempt" zu entfernen. Bei der Konfiguration ist auf die Position "set server-cert" zu achten dh. in unsere Beispiel wird "Fortinet_SSL" definiert was nicht benützt werden darf sondern es muss das Exchange Certificate das auf dem FortiGate Device importiert wurde angegeben werden:
| |
|
| |
| # config firewall ssl-ssh-profile
| |
| # edit "ActiveSync-OWA-Publishing"
| |
| # set comment "Reverse Proxy ActiveSync/OWA"
| |
| # set server-cert-mode replace
| |
| # config https
| |
| # set ports 443
| |
| # set status deep-inspection
| |
| # set client-cert-request bypass
| |
| # set unsupported-ssl block
| |
| # set allow-invalid-server-cert disable
| |
| # set untrusted-cert allow
| |
| # end
| |
| # config ftps
| |
| # set status disable
| |
| # end
| |
| # config imaps
| |
| # set status disable
| |
| # end
| |
| # config pop3s
| |
| # set status disable
| |
| # end
| |
| # config smtps
| |
| # set status disable
| |
| # end
| |
| # set whitelist disable
| |
| # set server-cert-mode replace
| |
| # set server-cert [Gebe das entsprechende Certificate an in unserem Beispiel zB "Fortinet_SSL"]
| |
| # set ssl-invalid-server-cert-log enable
| |
| # set rpc-over-https enable
| |
| # set mapi-over-https enable
| |
| # end
| |
|
| |
| # config firewall ssl-ssh-profile
| |
| # edit "ActiveSync-OWA-Publishing"
| |
| # config ssl-exempt
| |
| # del 1
| |
| # del 2
| |
| # del 3
| |
| # end
| |
| # end
| |
|
| |
| Wenn eine Firewall Poliy Rule in einem späteren Zeitpunkt erstellt wird, muss da Antivirus benutzt wird eine Proxy Options Profile erstellt werden für unverschlüsselten Traffic. Da wir in dieser Firewall Policy Rule jedoch nur verschlüsselter Traffic zulassen dh HTTPS (Port 443) ist dieses Proxy Option Profile nur ein Dummy in dem alles deaktiviert ist. Erstelle diese Proxy Option Profile über CLI:
| |
|
| |
| # config firewall profile-protocol-options
| |
| # edit "ActiveSync-OWA-Publishing"
| |
| # set comment "Reverse Proxy Dummy ActiveSync/OWA"
| |
| # set oversize-log enable
| |
| # set switching-protocols-log enable
| |
| # set rpc-over-http disable
| |
| # end
| |
| # config firewall profile-protocol-options
| |
| # edit "ActiveSync-OWA-Publishing"
| |
| # config http
| |
| # set status disable
| |
| # unset options
| |
| # end
| |
| # config ftp
| |
| # set status disable
| |
| # set options clientcomfort
| |
| # end
| |
| # config imap
| |
| # set status disable
| |
| # unset options
| |
| # end
| |
| # config mapi
| |
| # set status disable
| |
| # unset options
| |
| # end
| |
| # config pop3
| |
| # set status disable
| |
| # unset options
| |
| # end
| |
| # config smtp
| |
| # set status disable
| |
| # unset options
| |
| # end
| |
| # config nntp
| |
| # set status disable
| |
| # unset options
| |
| # end
| |
| # config dns
| |
| # set status disable
| |
| # end
| |
| # end
| |
|
| |
| Wie schon zu Beginn in diesem Artikel erwähnt und Illustriert wird eine Verbindung eines Client/Host aus dem Internet zu den Diensten auf dem Exchange dh. ActiveSync/OWA in zwei Sessions aufgebaut. Dies bedeutet: Die Verbindung resp. Session vom Client/Host zur Public IPv4 Adresse des FortiGate Devices wird auf dem Virtual Server resp. Reverse Proxy terminiert. Danach wird eine neue Session geöffnet auf die Dienste des Exchange dh. ActiveSync/OWA und diese wird über das VIP Objekt das in eine Firewall Policy Rule integriert wurde Inspected. In dieser Firewall Policy Rule fügen wir nun unser SSL-Inspection Profile hinzu sowie die vers. UTM Profiles dh. IPS Protection, Application Control sowie Antivirus. Somit wird effektiv auf dem Virtual Server resp. Reverse Proxy selber keine Deep Inspection durchgeführt sondern auf der Firewall Policy Rule mit dem VIP Object. Erstelle die entsprechende Firewall Policy Rule:
| |
|
| |
| Policy & Objects > IPv4 Policy > Create New
| |
|
| |
| [[Datei:Fortinet-2145.jpg]]
| |
|
| |
| Nun kann abermals ein Test durchgeführt werden sowie über "cipherscan" oder "ssllabs.com" ein Scan um die Einstellungen dh. SSL, TLS usw. zu überprüfen. Dabei ist Folgendes zu berücksichtigen: Wenn über den Virtual Server keine weiteren Einschränkungen gemacht werden können betreffend SSL/TLS, DH (DiffieHellman) usw. kann über das VIP Objekt "ActiveSync-OWA-Publishing" dies durchgeführt werden. Dies ist jedoch nur dann zu empfehlen, wenn über die entsprechenden Konfigurationen in Application Controll usw. dies nicht möglich ist. Es stehen innerhalb eines VIP Objekts im Zusammenhang mit SSL verschiedene Optionen zur Verfügung die unter FortiOS 5.4 neu sind. Dabei ist zu berücksichtigen das es 3 verschiedene Varianten gibt die Konfiguration betreffend Verschlüsselung zu beeinflussen die jedoch nur dann zur Verfügung stehen wenn "set type server-load-balance" gesetzt ist was für unser VIP Objekt "ActiveSync-OWA-Publishing" der Fall ist:
| |
|
| |
| '''Verschiedene SSL/TLS Versionen'''
| |
|
| |
| # config firewall vip
| |
| # edit [Name des entsprechenden VIP Objekts zB "ActiveSync-OWA-Publishing"]
| |
| # set type server-load-balance
| |
| # set server-type https
| |
| # set ssl-mode full
| |
| # set ssl-min-version [ssl-3.0 | tls-1.0 | tls-1.1 | tls-1.2]
| |
| # set ssl-max-version [ssl-3.0 | tls-1.0 | tls-1.1 | tls-1.2]
| |
| # set ssl-server-min-version [ssl-3.0 | tls-1.0 | tls-1.1 | tls-1.2 | client]
| |
| # set ssl-server-max-version [ssl-3.0 | tls-1.0 | tls-1.1 | tls-1.2 | client]
| |
| # end
| |
|
| |
| '''Verschiedenen "cipher" Möglichkeiten für Client/Host und Server'''
| |
|
| |
| # config firewall vip
| |
| # edit [Name des entsprechenden VIP Objekts zB "ActiveSync-OWA-Publishing"]
| |
| # set type server-load-balance
| |
| # set server-type https
| |
| # set ssl-mode full
| |
| # set ssl-algorithm [high | medium | low | custom]
| |
| # set ssl-server-algorithm [high | medium | low | custom | client]
| |
| # end
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Die Option "ssl-server-algorithm" hat folgende Bedeutung:
| |
|
| |
| • high AES oder 3DES cypher suites im ServerHello
| |
| • medium AES, 3DES oder RC4 cypher suites im ServerHello
| |
| • low AES, 3DES, RC4 oder DES cypher suites im ServerHello
| |
| • client Benutze den cypher suites des ClientHello zum ServerHello
| |
| • custom Definiert den cipher suite/s Manuell über "config ssl-server-cipher-suites" im ServerHello
| |
|
| |
| # config ssl-server-cipher-suites
| |
| # edit [Gebe einen entsprechenden Integer an zB "1"]
| |
| # set cipher [Definiere den entsprechende "cipher-suite" für die entsprechende Version dh. zB "ssl-3.0"]
| |
| # set versions [ssl-3.0 | tls-1.0 | tls-1.1 | tls-1.2]
| |
| # next
| |
| # edit [Gebe einen entsprechenden Integer an zB "1"]
| |
| # set cipher [Definiere den entsprechende "cipher-suite" für die entsprechende Version dh. zB "tls-1.2"]
| |
| # set versions [ssl-3.0 | tls-1.0 | tls-1.1 | tls-1.2]
| |
| # end
| |
|
| |
| Wenn Tests durchgeführt werden und es zu Problemen kommt ist eine einwandfreie Log Konfiguration absolute Voraussetzung um durch Log Anaylse Fehler zu erkennten. Wie auf einer FortiGate eine vollständige Log Konfiguration aussieht siehe nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.4-5.6:FAQ#Wie_sieht_eine_vollst.C3.A4ndige_Log_Konfiguration_f.C3.BCr_FortiOS_5.4_aus_und_wie_wird_diese_durchgef.C3.BChrt.3F]]
| |
|
| |
| Um ein weiteres Troubleshooting durchzuführen kann ein Debug durchgeführt werden:
| |
|
| |
| 1. Konfiguriere "putty" für logging dh. alle Informationen werden in ein Log aufgezeichnet (Category > Session > Logging > All session output)
| |
| 2. Erstelle eine SSH Verbindung zur FortiGate
| |
| 3. Führe ein Login durch und gebe folgendes ein:
| |
|
| |
| '''Setze alle Debug Filter zurück'''
| |
|
| |
| # diagnose debug reset
| |
|
| |
| '''Aktiviere für den debug "output" den "timestamp"'''
| |
|
| |
| # diagnose debug console timestamp enable
| |
|
| |
| '''Aktiviere für den debug den "vs" (Virtual Server)'''
| |
|
| |
| # diagnose debug application vs -1
| |
|
| |
| '''Aktiviere für den debug "flow"'''
| |
|
| |
| # diagnose debug flow show console enable
| |
| # diagnose debug flow show function-name enable
| |
| # diagnose debug flow filter sadd [Public IPv4 Adresse der Source reps. des Test Client/Hosts]
| |
| # diagnose debug flow filter dadd [Public IPv4 Adresse der Destination dh. ActiveSync/OWA resp. Exchange]
| |
| # diagnose debug flow trace start 1000
| |
|
| |
| Aktiviere den Debug Modus mit dem gesetzen Debug Filter
| |
|
| |
| # diagnose debug enable
| |
|
| |
| Nachdem das Troubleshooting erfolgreich durchgeführt wurde setze alle Filter zurück sowie deaktiviere den Debug Mode:
| |
|
| |
| # diagnose debug disable
| |
| # diagnose debug reset
| |
| # diagnose debug flow filter clear
| |
|
| |
| == Load Balancing ==
| |
|
| |
| === Wie kann ich unter FortiOS 5.4 ein Load Balancing konfigurieren und was ist dabei zu berücksichtigen? ===
| |
|
| |
| Unter FortiOS 5.4 wurde die Load Balancing Funktion erweitert dh. neu kann auf Client Seite sowie auf Virtual Server Seite die SSL/TLS Version eingeschränkt resp. konfiguriert werden. Ebenfalls ist es möglich die "cypher suites" Einzuschränken dh. unsicher "cypher suites" wie zB RC4, MD5 usw. auszuschliessen. Den Service "https" innerhalb der Load Balancing Funktion zu Konfigurieren resp. "set-ssl-mod full" ist ab FG-100x möglich resp. der Device muss die Funktion "SSL Offloading" unterstützen. Weitere Auskunft gibt die "FortiOS Software Platform Matrix":
| |
|
| |
| [[Datei:FortiOS-Software-Platform-Matrix-54.pdf]]
| |
|
| |
| Grundsätzlich basiert die Load Balancing Funktion auf einem VIP Objekt. Dieses VIP Objekt wird nachträglich in einer Firewall Policy wie für eine Destination NAT Konfiguriert. Dabei können für eine Firewall Policy UTM Features sei es im Proxy/Flow-Mode aktiviert werden jedoch keine Authentifizierung. Zusätzlich wird anhand der Health Check Funktion (ldb-monitor) die Real Server anhand den Protokollen HTTP, Ping sowie TCP überwacht um deren Verfügbarkeit festzustellen. Die Load Balancing Funktion unterstützt bis zu 8 Real Server sowie der Load Balancing Layer unterstützt:
| |
|
| |
| • Layer 7 HTTP, HTTPS, SSL
| |
| • Generischer Layer 4 TCP, UDP
| |
| • Generischer Layer 3 IP Protokolle
| |
|
| |
| Somit steht zu Beginn der Konfiguration eines Load Balancing die Health Check Konfiguration. Damit die entsprechenden Menü Positionen über Web Mgmt. Interface zur Verfügung stehen, muss das Feature Load Balancing aktiviert werden. Wie dies durchgeführt wird siehe nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.4-5.6:FAQ#Unter_FortiOS_5.4_sehe_ich_.C3.BCber_das_Web_Gui_nicht_alle_Features_wie_kann_ich_diese_aktivieren.2Fdeaktivieren.3F]]
| |
|
| |
| Danach kann ein Health Check über Folgende Position im Mgmt. Web Interface konfiguriert werden:
| |
|
| |
| Policy & Objects > Health Check > Create New
| |
|
| |
| [[Datei:Fortinet-2202.jpg]]
| |
|
| |
| [[Datei:Fortinet-2203.jpg]]
| |
|
| |
| [[Datei:Fortinet-2204.jpg]]
| |
|
| |
| Auf Kommandozeile wird ein Health Check folgendermassen konfiguriert:
| |
|
| |
| # config firewall ldb-monitor
| |
| # edit [Vergebe einen entsprechenden Namen zB "Ping-Health-Check"]
| |
| # set type [ping | tcp | http]
| |
| # set interval [Intervall in Sekunden 5 - 65535; Standard 10]
| |
| # set timeout [Timout in Sekunden 1 - 255; Standard 2]
| |
| # set retry [Retry 1 - 255; Standard 3]
| |
| # set port [Definition des benützten Ports; 0 = Es wird Port Defintion benutzt der Real Server Konfiguration]
| |
| # set http-get [Definition eines spezifischen Seite für Verfügbarkeit zB "/" (Fully Qualified Path Name)]
| |
| # set http-match [Zu erwartende Antwort/Inhalt Case Sensitive für erwartende Seite]
| |
| # set http-max-redirects [Maximu HTTP redirects; Standard 0; 0 = redirect wird nicht verfolgt]
| |
| # end
| |
|
| |
| Die Option http-get, http-match sowie http-max werden nur berücksichtigt in einen Health Check wenn "set type http" benützt wird. Die Option "port" wird für "set type ping" nicht berücksichtigt. Im nächsten Schritt der Konfiguration wird nun das entsprechende VIP Objekt konfiguriert mit den entsprechende Real Server. Dabei wird jedoch die Konfiguration im Mgmt. Web Interface nicht unter "Virtual IPs" durchgeführt sondern unter folgender Position:
| |
|
| |
| Policy & Objects > Virtual Servers > Create New
| |
|
| |
| Wird ein Device benutzt der über kein "SSL Offloading" Funktion verfügt, steht keine "set-ssl-mod full" Konfiguratin zur Verfügung:
| |
|
| |
| [[Datei:Fortinet-2205.jpg]]
| |
|
| |
| [[Datei:Fortinet-2206.jpg]]
| |
|
| |
| Auf Kommandozeile wird die Konfiguration folgendermassen durchgeführt:
| |
|
| |
| # config firewall vip
| |
| # edit [Vergebe einen entsprechenden Namen]
| |
| # set type server-load-balance
| |
| # set server-type [http | tcp | udp | ip | https | imaps | pop3s | smtps (465) | ssl]
| |
| # set ldb-method [static | round-robin | weighted | least-session | last-rtt | first-alive | http-host]
| |
| # set extip [Public IPv4 Adresse fuer Konfiguration "extintf"]
| |
| # set extintf [Interface Konfiguration für Public IPv4 Adresse "extip"]
| |
| # set extport [Konfiguration Port für "extip"]
| |
| # set arp-reply [disable | enable]
| |
| # set nat-source-vip [disable | enable]
| |
| # set gratuitous-arp-interval [Gratuitous ARP Interval in Sekunden 0 - 8640000; Standard 0 = disable]
| |
| # set srcintf-filter [Name des entsprechenden Interfaces]
| |
| # set http-ip-header [disable | enable]
| |
| # set monitor [Name des Konfigurierten Health Check zB "Ping-Health-Check"]
| |
| # set persistence [none | http-cookie | ssl-session-id]
| |
| # set http-multiplex [enable | disable]
| |
| # set max-embroyonic-connections [0 - 100000; Standard 1000]
| |
| # end
| |
|
| |
| Das sind die Grundsätzlichsten Funktion für "server-type" unvrschlüsselt. Wird ein verschlüsseltes Protokoll wie zB https konfiguriert stehen weitere Optionen für die Verschlüsselung zur Verfügung sei es für Client/Virtual Server sowie "cipher suite":
| |
|
| |
| '''SSL/TLS Version Client/Virtual Server'''
| |
|
| |
| # config firewall vip
| |
| # edit [Vergebe einen entsprechenden Namen]
| |
| # set type server-load-balance
| |
| # set server-type [https | imaps | pop3s | smtps (465) | ssl]
| |
| # set outlook-web-access [enable | disable]
| |
| # set weblogic-server [enable | disable]
| |
| # set websphere-server [enable | disable]
| |
| # set ssl-mode [half | full]
| |
| # set ssl-certificate [Name des entsprechenden Certificate]
| |
| # set ssl-dh-bits [768 | 1024 | 1536 | 2048 | 3072 | 4096]
| |
| # set ssl-pfs [allow | required | deny]
| |
| # set ssl-send-empty-frags [enable | disable]
| |
| # set ssl-client-fallback [enable | disable]
| |
| # set ssl-client-renegotiation [allow | deny | secure]
| |
| # set ssl-client-session-state-type [disable | time | count | both]
| |
| # set ssl-client-session-state-timout [1 - 14400 ; Standard 30]
| |
| # set ssl-client-session-state-max [1 - 10000 ; Standard 1000]
| |
| # set ssl-http-location-conversation [enable | disable]
| |
| # set ssl-min-version [ssl-3.0 | tls-1.0 | tls-1.1 | tls-1.2]
| |
| # set ssl-max-version [ssl-3.0 | tls-1.0 | tls-1.1 | tls-1.2]
| |
| # set ssl-server-min-version [ssl-3.0 | tls-1.0 | tls-1.1 | tls-1.2 | client]
| |
| # set ssl-server-max-version [ssl-3.0 | tls-1.0 | tls-1.1 | tls-1.2 | client]
| |
| # set ssl-algorithm [high | medium | low | custom | client]
| |
| # end
| |
|
| |
| Die zur Verfügung stehenden Optionen "high", "medium", "low", "custom" sowie "client" für "ssl-server-algorithm" haben folgenden Bedeutung:
| |
|
| |
| • high Bietet im "ServerHello" die "cipher suite" für AES sowie 3DES
| |
| • medium Bietet im "ServerHello" die "cipher suite" für RC4, AES sowie 3DES
| |
| • low Bietet im "ServerHello" die "cipher suite" für DES, RC4, AES sowie 3DES
| |
|
| |
| • custom Bietet im "ServerHello" manuell Konfigurierte "cipher suite" an
| |
| • client Bietet die Möglichkeit die "cipher suite" für "ClientHello" zu Konfigurieren.
| |
|
| |
| Wird "custom" gewählt kann die entsprechende SSL/TLS Version sowie "cipher suite" manuell Konfiguriert werden dh. nicht anhand von "high", "medium" sowie "low":
| |
|
| |
| # config firewall vip
| |
| # edit server-name
| |
| # set type server-load-balance
| |
| # set server-type [https | imaps | pop3s | smtps (465) | ssl]
| |
| # set ssl-mode [half | full]
| |
| # set ssl-algorithm custom
| |
| # config ssl-cipher-suites
| |
| # edit [Vergebe einen entsprechenden Integer zB "1"]
| |
| # set cipher [cipher-suite]
| |
| # set versions [ssl-3.0 | tls-1.0 | tls-1.1 | tls-1.2]
| |
| # end
| |
| # end
| |
|
| |
| Für die Konfiguration der "cipher-suite" steht folgendes zur Verfügung:
| |
|
| |
| # set cipher ?
| |
|
| |
| TLS-ECDHE-RSA-WITH-CHACHA20-POLY1305-SHA256 Cipher suite TLS-ECDHE-RSA-WITH-CHACHA20-POLY1305-SHA256.
| |
| TLS-ECDHE-ECDSA-WITH-CHACHA20-POLY1305-SHA256 Cipher suite TLS-ECDHE-ECDSA-WITH-CHACHA20-POLY1305-SHA256.
| |
| TLS-DHE-RSA-WITH-CHACHA20-POLY1305-SHA256 Cipher suite TLS-DHE-RSA-WITH-CHACHA20-POLY1305-SHA256.
| |
| TLS-DHE-RSA-WITH-AES-128-CBC-SHA Cipher suite TLS-DHE-RSA-WITH-AES-128-CBC-SHA.
| |
| TLS-DHE-RSA-WITH-AES-256-CBC-SHA Cipher suite TLS-DHE-RSA-WITH-AES-256-CBC-SHA.
| |
| TLS-DHE-RSA-WITH-AES-128-CBC-SHA256 Cipher suite TLS-DHE-RSA-WITH-AES-128-CBC-SHA256.
| |
| TLS-DHE-RSA-WITH-AES-128-GCM-SHA256 Cipher suite TLS-DHE-RSA-WITH-AES-128-GCM-SHA256.
| |
| TLS-DHE-RSA-WITH-AES-256-CBC-SHA256 Cipher suite TLS-DHE-RSA-WITH-AES-256-CBC-SHA256.
| |
| TLS-DHE-RSA-WITH-AES-256-GCM-SHA384 Cipher suite TLS-DHE-RSA-WITH-AES-256-GCM-SHA384.
| |
| TLS-DHE-DSS-WITH-AES-128-CBC-SHA Cipher suite TLS-DHE-DSS-WITH-AES-128-CBC-SHA.
| |
| TLS-DHE-DSS-WITH-AES-256-CBC-SHA Cipher suite TLS-DHE-DSS-WITH-AES-256-CBC-SHA.
| |
| TLS-DHE-DSS-WITH-AES-128-CBC-SHA256 Cipher suite TLS-DHE-DSS-WITH-AES-128-CBC-SHA256.
| |
| TLS-DHE-DSS-WITH-AES-128-GCM-SHA256 Cipher suite TLS-DHE-DSS-WITH-AES-128-GCM-SHA256.
| |
| TLS-DHE-DSS-WITH-AES-256-CBC-SHA256 Cipher suite TLS-DHE-DSS-WITH-AES-256-CBC-SHA256.
| |
| TLS-DHE-DSS-WITH-AES-256-GCM-SHA384 Cipher suite TLS-DHE-DSS-WITH-AES-256-GCM-SHA384.
| |
| TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA Cipher suite TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA.
| |
| TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA256 Cipher suite TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA256.
| |
| TLS-ECDHE-RSA-WITH-AES-128-GCM-SHA256 Cipher suite TLS-ECDHE-RSA-WITH-AES-128-GCM-SHA256.
| |
| TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA Cipher suite TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA.
| |
| TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA384 Cipher suite TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA384.
| |
| TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384 Cipher suite TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384.
| |
| TLS-ECDHE-ECDSA-WITH-AES-128-CBC-SHA Cipher suite TLS-ECDHE-ECDSA-WITH-AES-128-CBC-SHA.
| |
| TLS-ECDHE-ECDSA-WITH-AES-128-CBC-SHA256 Cipher suite TLS-ECDHE-ECDSA-WITH-AES-128-CBC-SHA256.
| |
| TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256 Cipher suite TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256.
| |
| TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA384 Cipher suite TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA384.
| |
| TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 Cipher suite TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384.
| |
| TLS-RSA-WITH-AES-128-CBC-SHA Cipher suite TLS-RSA-WITH-AES-128-CBC-SHA.
| |
| TLS-RSA-WITH-AES-256-CBC-SHA Cipher suite TLS-RSA-WITH-AES-256-CBC-SHA.
| |
| TLS-RSA-WITH-AES-128-CBC-SHA256 Cipher suite TLS-RSA-WITH-AES-128-CBC-SHA256.
| |
| TLS-RSA-WITH-AES-128-GCM-SHA256 Cipher suite TLS-RSA-WITH-AES-128-GCM-SHA256.
| |
| TLS-RSA-WITH-AES-256-CBC-SHA256 Cipher suite TLS-RSA-WITH-AES-256-CBC-SHA256.
| |
| TLS-RSA-WITH-AES-256-GCM-SHA384 Cipher suite TLS-RSA-WITH-AES-256-GCM-SHA384.
| |
| TLS-RSA-WITH-CAMELLIA-128-CBC-SHA Cipher suite TLS-RSA-WITH-CAMELLIA-128-CBC-SHA.
| |
| TLS-RSA-WITH-CAMELLIA-256-CBC-SHA Cipher suite TLS-RSA-WITH-CAMELLIA-256-CBC-SHA.
| |
| TLS-RSA-WITH-CAMELLIA-128-CBC-SHA256 Cipher suite TLS-RSA-WITH-CAMELLIA-128-CBC-SHA256.
| |
| TLS-RSA-WITH-CAMELLIA-256-CBC-SHA256 Cipher suite TLS-RSA-WITH-CAMELLIA-256-CBC-SHA256.
| |
| TLS-DHE-RSA-WITH-3DES-EDE-CBC-SHA Cipher suite TLS-DHE-RSA-WITH-3DES-EDE-CBC-SHA.
| |
| TLS-DHE-RSA-WITH-CAMELLIA-128-CBC-SHA Cipher suite TLS-DHE-RSA-WITH-CAMELLIA-128-CBC-SHA.
| |
| TLS-DHE-DSS-WITH-CAMELLIA-128-CBC-SHA Cipher suite TLS-DSS-RSA-WITH-CAMELLIA-128-CBC-SHA.
| |
| TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA Cipher suite TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA.
| |
| TLS-DHE-DSS-WITH-CAMELLIA-256-CBC-SHA Cipher suite TLS-DHE-DSS-WITH-CAMELLIA-256-CBC-SHA.
| |
| TLS-DHE-RSA-WITH-CAMELLIA-128-CBC-SHA256 Cipher suite TLS-DHE-RSA-WITH-CAMELLIA-128-CBC-SHA256.
| |
| TLS-DHE-DSS-WITH-CAMELLIA-128-CBC-SHA256 Cipher suite TLS-DHE-DSS-WITH-CAMELLIA-128-CBC-SHA256.
| |
| TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA256 Cipher suite TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA256.
| |
| TLS-DHE-DSS-WITH-CAMELLIA-256-CBC-SHA256 Cipher suite TLS-DHE-DSS-WITH-CAMELLIA-256-CBC-SHA256.
| |
| TLS-DHE-RSA-WITH-SEED-CBC-SHA Cipher suite TLS-DHE-RSA-WITH-SEED-CBC-SHA.
| |
| TLS-DHE-DSS-WITH-SEED-CBC-SHA Cipher suite TLS-DHE-DSS-WITH-SEED-CBC-SHA.
| |
| TLS-DHE-RSA-WITH-ARIA-128-CBC-SHA256 Cipher suite TLS-DHE-RSA-WITH-ARIA-128-CBC-SHA256.
| |
| TLS-DHE-RSA-WITH-ARIA-256-CBC-SHA384 Cipher suite TLS-DHE-RSA-WITH-ARIA-256-CBC-SHA384.
| |
| TLS-DHE-DSS-WITH-ARIA-128-CBC-SHA256 Cipher suite TLS-DHE-DSS-WITH-ARIA-128-CBC-SHA256.
| |
| TLS-DHE-DSS-WITH-ARIA-256-CBC-SHA384 Cipher suite TLS-DHE-DSS-WITH-ARIA-256-CBC-SHA384.
| |
| TLS-RSA-WITH-SEED-CBC-SHA Cipher suite TLS-RSA-WITH-SEED-CBC-SHA.
| |
| TLS-RSA-WITH-ARIA-128-CBC-SHA256 Cipher suite TLS-RSA-WITH-ARIA-128-CBC-SHA256.
| |
| TLS-RSA-WITH-ARIA-256-CBC-SHA384 Cipher suite TLS-RSA-WITH-ARIA-256-CBC-SHA384.
| |
| TLS-ECDHE-RSA-WITH-ARIA-128-CBC-SHA256 Cipher suite TLS-ECDHE-RSA-WITH-ARIA-128-CBC-SHA256.
| |
| TLS-ECDHE-RSA-WITH-ARIA-256-CBC-SHA384 Cipher suite TLS-ECDHE-RSA-WITH-ARIA-256-CBC-SHA384.
| |
| TLS-ECDHE-ECDSA-WITH-ARIA-128-CBC-SHA256 Cipher suite TLS-ECDHE-ECDSA-WITH-ARIA-128-CBC_SHA256.
| |
| TLS-ECDHE-ECDSA-WITH-ARIA-256-CBC-SHA384 Cipher suite TLS-ECDHE-ECDSA-WITH-ARIA-256-CBC_SHA384.
| |
| TLS-ECDHE-RSA-WITH-RC4-128-SHA Cipher suite TLS-ECDHE-RSA-WITH-RC4-128-SHA.
| |
| TLS-ECDHE-RSA-WITH-3DES-EDE-CBC-SHA Cipher suite TLS-ECDHE-RSA-WITH-3DES-EDE-CBC-SHA.
| |
| TLS-DHE-DSS-WITH-3DES-EDE-CBC-SHA Cipher suite TLS-DHE-DSS-WITH-3DES-EDE-CBC-SHA.
| |
| TLS-RSA-WITH-3DES-EDE-CBC-SHA Cipher suite TLS-RSA-WITH-3DES-EDE-CBC-SHA.
| |
| TLS-RSA-WITH-RC4-128-MD5 Cipher suite TLS-RSA-WITH-RC4-128-MD5.
| |
| TLS-RSA-WITH-RC4-128-SHA Cipher suite TLS-RSA-WITH-RC4-128-SHA.
| |
| TLS-DHE-RSA-WITH-DES-CBC-SHA Cipher suite TLS-DHE-RSA-WITH-DES-CBC-SHA.
| |
| TLS-DHE-DSS-WITH-DES-CBC-SHA Cipher suite TLS-DHE-DSS-WITH-DES-CBC-SHA.
| |
| TLS-RSA-WITH-DES-CBC-SHA Cipher suite TLS-RSA-WITH-DES-CBC-SHA.
| |
|
| |
| Nun muss der Load Balancing Funktion die Real Server hinzugefügt werden. Dies wird über Mgmt. Web Interface folgendermassen durchgeführt und in diesem Schritt wird den Real Servers der Virtual Server (VIP Objekt) hinzugefügt:
| |
|
| |
| Policy & Objects > Real Servers > Create New
| |
|
| |
| [[Datei:Fortinet-2207.jpg]]
| |
|
| |
| Unter Kommandozeile werden die Real Server im VIP Object mit nachfolgenden Kommando hinzugefügt:
| |
|
| |
| # config firewall vip
| |
| # edit server-name
| |
| # set type server-load-balance
| |
| # config realservers
| |
| # edit [Vergebe einen entsprechenden Integer zB "1"]
| |
| # set ip [IPv4 Adresse des Real Servers zB "198.18.0.60"]
| |
| # set port [Port des Real Servers zB "443"]
| |
| # set status [active | disable | standby]
| |
| # set holddown-interval [Holddown in Sekunden 30 - 65535; Standard 300]
| |
| # set healthcheck [enable | disable | vip]
| |
| # set max-connections [Maximum für Verbindungen 0-2147483647; Standard 0 = Unlimited]
| |
| # set client-ip [IPv4 Range für Clients]
| |
| # next
| |
| # edit [Vergebe einen entsprechenden Integer zB "2"]
| |
| # set ip [IPv4 Adresse des Real Servers zB "198.18.0.60"]
| |
| # set port [Port des Real Servers zB "443"]
| |
| # set status [active | disable | standby]
| |
| # set holddown-interval [Holddown in Sekunden 30 - 65535; Standard 300]
| |
| # set healthcheck [enable | disable | vip]
| |
| # set max-connections [Maximum für Verbindungen 0-2147483647; Standard 0 = Unlimited]
| |
| # set client-ip [IPv4 Range für Clients]
| |
| # end
| |
| # end
| |
|
| |
| Als letzen Schritt muss nun eine Firewall Policy Rule basierend auf einem Destination NAT konfiguriert werden dh. zB:
| |
|
| |
| [[Datei:Fortinet-2208.jpg]]
| |
| [[Datei:Fortinet-2209.jpg]]
| |
|
| |
| Bei dieser Firewall Policy Rule kann je nach Situation die UTM Features aktiviert werden. Eine Authentication für diese Firewall Policy Rule im Zusammenhang mit einem Load Balancing VIP Objekt wird nicht unterstützt. Die hier gezeigten Konfigurationsmöglichkeiten sowie zusätzliche Erläuterungen sind im nachfolgenden Fortinet Dokument beschrieben:
| |
|
| |
| [[Datei:Fortigate-Load-Balancing-54.pdf]]
| |
|
| |
| === Wie kann ich unter FortiOS 5.4 für die Load Balancing Funtion eine Diagnose ausführen? ===
| |
|
| |
| Für die Load Balancing Funktion steht über Kommandozeile verschiedenen Befehle zur Verfügung um eine Diagnose durchzuführen:
| |
|
| |
| '''Load Balancing Diagnose'''
| |
|
| |
| # diagnose firewall vip realserver [down | flush | healthcheck | list | up]
| |
| # diagnose firewall vip virtual-server [filter | log | real-server | session | stats]
| |
|
| |
| Um zB den Status der Real Server abzufragen kann folgendes ausgeführt werden:
| |
|
| |
| # diagnose firewall vip virtual-server real-server
| |
|
| |
| Desweiteren kann ein spezfischer Filter gesetzt werden um zB spezfische Informationen
| |
| zu erhalten:
| |
|
| |
| # diagnose firewall vip virtual-server filter [clear | dst | dst-port | list | name | negate | src | src-port| vd]
| |
|
| |
| Die verschiedenen Filter Funktionen haben folgende Bedeutung:
| |
|
| |
| • clear Löschen des vorhandenen Filters
| |
| • dst Destination Adress Range für den Filter
| |
| • dst-port Destination Port für den Filter
| |
| • list Auflisten des momentanen Filters
| |
| • name VIP Objekt Name für den Filter
| |
| • negate Negate eines spezifischen Filter Parameter
| |
| • src Source Adress Range für den Filter
| |
| • src-port Source Port für den Filter
| |
| • vd Index Nr. einer VDom (virtual domain). -1 = Alle
| |
|
| |
| '''Load Balancing Logging Diagnose'''
| |
|
| |
| Die Logging Diagnose verfügt über zwei Optione dh.:
| |
|
| |
| # diagnose firewall vip virtual-server log console [disable | enable]
| |
| # diagnose firewall vip virtual-server log filter [clear | dst | dst-port | list | name | negate | src | src-port| vd]
| |
|
| |
| Die Log Optionen "console" sowie "filter" haben folgende Bedeutung:
| |
|
| |
| • console Aktiviert oder Deaktiviert die Event Log Nachrichten des Virtual Servers
| |
| • filter Setzt einen entsprechenden Filter für das Debug Log
| |
|
| |
| Die verschiedenen Filter Funktionen haben folgende Bedeutung:
| |
|
| |
| • clear Löschen des vorhandenen Filters
| |
| • dst Destination Adress Range für den Filter
| |
| • dst-port Destination Port für den Filter
| |
| • list Auflisten des momentanen Filters
| |
| • name VIP Objekt Name für den Filter
| |
| • negate Negate eines spezifischen Filter Parameter
| |
| • src Source Adress Range für den Filter
| |
| • src-port Source Port für den Filter
| |
| • vd Index Nr. einer VDom (virtual domain). -1 = Alle
| |
|
| |
| '''Load Balancing Real Server Diagnose'''
| |
|
| |
| Folgendes Kommando kann benutzt werden um alle Real Server aufzulisten:
| |
|
| |
| # diagnose firewall vip virtual-server real-server list
| |
|
| |
| Im entsprechenden Output wird der Status aufgelistet des Real Server dh. zB :
| |
|
| |
| vd root/0 vs slb/2 addr 198.18.0.62:443 status 1/1
| |
| conn: max 10 active 0 attempts 0 success 0 drop 0 fail 0
| |
| http: available 0 total 0
| |
|
| |
| Dabei wird der Status anhand max, active, drop sowie fail indiziert. Diese haben
| |
| gemäss oberen Beispiel folgende Bedeutung:
| |
|
| |
| • max Indiziert, dass der Real Server Maximal 10 Verbindungen erlaubt
| |
| • active Anzahl momentaner Verbindungen zum Real Server
| |
| • attempts Anzahl versuchter Verbindungen zum Real Server
| |
| • drop Total Verbindungen in der ein "drop" ausgeführt wurde da Option "max" erreicht wurde
| |
| • fail Total Verbindungen zum Real Server die Fehlgeschlagen sind
| |
|
| |
| Wenn für den Virtual Server "http-multiplexing" aktiviert wurde indiziert die "http" Position für
| |
| "real-server list" wieviele Verbindungen zum Real Server zur Verfügung stehen sowie wieviele
| |
| Verbindungen durchgeführt wurden.
| |
|
| |
| == SSL-VPN ==
| |
|
| |
| === Was ist unter FortiOS 5.4 für ein SSL-VPN für Portal/Tunnel Mode betreffend Port Konfiguration zu berücksichtigen? ===
| |
|
| |
| Wenn ein SSL-VPN Portal sei es im Port/Tunnel Mode konfiguriert wird so stellt sich die Frage, welchen Port soll benützt werden für die SSL-VPN Funktion. Per Standard benutzt eine FortiOS Konfiguration den TCP Port 10443 da der TCP Port 443 bereits für den Administrativen Access benutzt wird. Somit sollte der Administrative Access Port verschoben werden auf zB TCP Port 8443. Dies kann über Mgmt. Web Inerface und/oder CLI durchgeführt werden:
| |
|
| |
| System > Settings > Administration Settings
| |
|
| |
| [[Datei:Fortinet-2020.jpg]]
| |
|
| |
| # config system global
| |
| # set admin-sport [Konfigurierte den entsprechenden TCP Port für HTTPS zB "8443"]
| |
| # end
| |
|
| |
| Sobald die Konfiguration durchgeführt wurde, kann der TCP Port für die SSL-VPN Funktion neu gesetzt werden:
| |
|
| |
| VPN > SSL-VPN Settings > Listen Port
| |
|
| |
| [[Datei:Fortinet-2021.jpg]]
| |
|
| |
| # config vpn ssl settings
| |
| # set port [Konfigurierte den entsprechenden TCP Port für SSL-VPN zB "443"]
| |
| # end
| |
|
| |
| Desweiteren ist es unter FortiOS 5.4 neu möglich einen Redirect für HTTP (TCP 80) auf HTTPS (SSL-VPN TCP Port) zu aktivieren wobei per Standard diese Funktion nicht aktiviert ist:
| |
|
| |
| # config vpn ssl settings
| |
| # set https-redirect [enable | disable]
| |
| # end
| |
|
| |
| Der TCP Port 443 für SSL-VPN kann jedoch nur dann definiert werden, wenn dieser Port für die Public IPv4 Adresse des entsprechenden Interfaces zB "wan1" nicht bereits in Gebrauch ist wie zB für ActiveSync VIP Adresse (Destination NAT)! Wenn dennoch der SSL-VPN TCP Port 443 benutzt werden soll auf dem "wan1" Interface obwohl dieser TCP Port 443 bereits in Gebrauch ist für zB ActiveSync gilt folgende Voraussetzung dies dennoch zu ermöglichen resp. zu Konfigurieren:
| |
|
| |
| • Eine Public IPv4 Adresse auf dem "wan1" Interface als Main IPv4 Adresse des Interface!
| |
| • Zweite Public IPv4 Adresse als Secondary IPv4 Adresse auf dem "wan1" Interface!
| |
|
| |
| Auch wenn auf dem zB "wan1" Interface eine zweite Public IPv Adresse als Secondary IPv4 Adresse konfiguriert wird, ändert sich die Situation nicht, denn der Administrative Access und die SSL-VPN Access stellen zwei System Services dar die sich innerhalb dieser System Services nicht einen und denselben TCP Port teilen können! Also muss konsequent für jeden System Service ein anderer Port vergeben werden zB für Adminstrative Access HTTPS 443 und für SSL-VPN HTTPS 10443. Um dem User dennoch auf dem "wan1" Interface zu ermöglichen den TCP Port 443 zu nutzen obwohl dieser bereits in Gebrauch ist, kann ein Workaround konfiguriert werden. Ausgangslage für diesen Workaround ist ein eigens dafür erstelltes Loopback Interface das anhand einer frei definierten IPv4 Adresse Konfiguriert wird. Diese IPv4 Adresse für dieses Loopback Interface darf nicht in einem Netzwerk Segment benutzt werden! Danach wird ein entsprechendes VIP Objekt das auf einem Loopback Interface konfiguriert wird sowie anhand der Secondary IPv4 Adresse auf dem "wan1" Interface der TCP Port 443 konfiguriert und über ein Port Forwarding anhand TCP Port 10443 der Zugriff auf die SSL-VPN Funktion ermöglicht. Somit wird logisch gesehen folgendes konfiguriert:
| |
|
| |
| wan1 Main IPv4 Adresse = TCP Port 443 --> '''Administrative Access TCP Port 443'''
| |
| wan1 Secondary IPv4 Adresse = TCP Port 443 --> VIP Objekt Secondary Public IPv4 Adresse TCP Port 443 --> Loopback Interface TCP Port Forwarding 10443 --> '''SSL-VPN Listen Port 10443'''
| |
|
| |
| Nachfolgendes Dokument von Fortinet erklärt diese Konfiguration Schritt für Schritt:
| |
|
| |
| [[Datei:Using-Port-443-for-MGMT-Access-and-SSL-VPN.pdf]]
| |
|
| |
| === Was ist unter FortiOS 5.4 für ein SSL-VPN für Portal/Tunnel Mode betreffend Protokoll Konfiguration zu berücksichtigen? ===
| |
|
| |
| Wenn ein SSL Port/Tunnel Mode konfiguriert wurde unter FortiOS 5.0/5.2 so wurde bis anhin für das Protokoll TCP benutzt! Dies bedeutet: es wurde eine enkapsulierte TCP Verbindung in einer TCP Verbindung benutzt was wiederum bedeutet: Informationen die durch den SSL Port/Tunnel Mode gesendet werden, sind enkapsuliert in einer HTTPS Verbindung die auf TCP basiert. Dies kann betreffend Timeouts usw. Problematisch sein und ist auch Performance technisch gesehen nicht Optimal. Wieso dem so ist zeigt nachfolgender Link auf:
| |
|
| |
| http://sites.inka.de/bigred/devel/tcp-tcp.html
| |
|
| |
| Neu unter FortiOS 5.4 wird per Standard UDP benutzt dh. eine DTLS (Datagram Transport Layer Security) Verbindung basierend auf UDP wobei die gleiche Security benutzt wird wie für SSL (TLS). Weitere Informationen betreffend DTLS siehe nachfolgender Link:
| |
|
| |
| https://en.wikipedia.org/wiki/Datagram_Transport_Layer_Security
| |
|
| |
| Diese UDP basierende DTLS Verbindung können die Performance dramatisch erhöhen da die verschiedenen Problematiken betreffend enkapsulierter TCP Verbindung über eine TCP Verbindung (HTTPS) nicht auftreten. Die Funktion DTLS zu aktivieren oder weiterhin TCP zu benutzen kann über folgende Konfiguration konfiguriert werden wobei zu berücksichtigen ist, dass DTLS per Standard aktiviert ist:
| |
|
| |
| # config vpn ssl settings
| |
| # set dtls-tunnel [enable | disable]
| |
| # end
| |
|
| |
| === Wie kann ich unter FortiOS 5.4 ein SSL-VPN für Portal/Tunnel Mode auf einer FortiGate konfigurieren? ===
| |
|
| |
| Wenn auf auf einem FortiGate Device ein SSL-VPN konfiguriert werden soll, muss unterschieden werden zwischen Portal und/oder Tunnel Mode. Beide Modi sind Unabhängig dh. es braucht keine Portal Mode um den Tunnel Mode zu betreiben und/oder Tunnel Mode um den Portal Mode zu betreiben. Beim Portal Mode handelt es sich um die Browser basierende Variante dh. über den Browser wird auf einem Portal das auf dem FortiGate Device zur Verfügung gestellt wird eingeloggt und anhand der zur Verfügung stehenden Connection Tools oder Bookmarks zB RDP, Port Forwarder, HTTP, HTTPS usw. auf eine interne Resource zugegriffen. Beim Tunnel Mode muss unter FortiOS 5.4 die FortiClient Software auf dem Host/Client für den SSL-VPN Zugriff installiert werden. Anhand dieser Host/Client FortiClient Software wird ein SSL basierender Tunnel zum FortiGate Device aufgebaut und der Zugriff erfolgt über diesen Tunnel. Auf jedem FortiGate Device kann ein SSL-VPN für Portal und/oder Tunnel Mode konfiguriert werden. Dabei ist die Anzahl der Portal limitiert. Auskunft über die Limitierungen im SSL-VPN Bereich gibt das "max_value" Dokument für FortiOS 5.4. Weitere Informationen siehe nachfolgender Link:
| |
|
| |
| [http://help.fortinet.com/fgt/54/max-values/5-4-0/max-values.html Datei:Fortigate-Max-Values-54.pdf] (FortiOS 5.4 Max Values / Online Version http://help.fortinet.com/fgt/54/max-values/5-4-0/max-values.html)
| |
|
| |
| Wenn dennoch versucht wird mehr Portale in deren Anzahl als durch "max_value" definiert ist zu konfigurieren, kommt es zu einer Fehlermeldung:
| |
|
| |
| # config vpn ssl web portal
| |
| # edit [Name des entsprechenden SSL-VPN Portals]
| |
| Too many entries in all tables of .vpn.ssl.web.portal in vdom root: 1 / vdom-max = 3
| |
|
| |
| In einigen Konfigurationsschritten werden Features angewandt die aktiviert werden müssen wie zB "Realm". Wie diese Features im Mgmt. Web Interface eines FortiGate Devices aktiviert werden siehe nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.4-5.6:FAQ#Unter_FortiOS_5.4_sehe_ich_.C3.BCber_das_Web_Gui_nicht_alle_Features_wie_kann_ich_diese_aktivieren.2Fdeaktivieren.3F]]
| |
|
| |
| Damit ein SSL-VPN Konfiguration durchgeführt werden kann benötigt man folgende Objekte:
| |
|
| |
| • SSL-VPN IPv4 Pool Objekt
| |
| • LAN IPv4 Objekt
| |
| • User/Gruppe Objekt
| |
| • SSL-VPN Portal Profiles
| |
|
| |
| In unserem Beispiel gehen wir von folgender Situation aus:
| |
|
| |
| ____________ _________________________
| |
| 193.193.135.66/29| | 198.18.0.1 | | Office IPv4 Pool 198.18.1.0/25
| |
| ----- WAN 1 -----| Fortigate |------ LAN -----| LAN Env. 198.18.0.0/24 |
| |
| |____________| |_________________________|
| |
|
| |
| Erstelle das SSL-VPN IP Pool Objekt das für folgende Funktion benutzt wird: Wird eine erfolgreiche Authentifizierung durchgeführt sei es für Portal und/oder Tunnel Mode, wird dem User eine IPv4 Adresse zugewiesen aus diesem IPv4 Pool Objekt resp. Subnet. Diese IPv4 Adresse benutzt ein User in einer aktiven Verbindung als dessen Source IPv4 Adresse:
| |
|
| |
| Policy & Objects > Addresses > Create New > net-local-ip-pool-ssl-vpn-198.18.1.0-25
| |
|
| |
| [[Datei:Fortinet-2007.jpg]]
| |
|
| |
| Erstelle das LAN IPv4 Objekt das für folgende Konfiguration benutzt wird: Für die Konfiguration muss das LAN IPv4 Subnet definiert werden um zwei Konfigurationen innerhalb des SSL-VPN durchzuführen. Einerseits wird das durch das LAN IPv4 Objekt die zu erreichende Destination resp. Ziel Adressen definiert und auf der anderen Seite dadurch ein Splitt Tunneling ermöglicht:
| |
|
| |
| Policy & Objects > Addresses > Create New > net-local-lan-198.18.0.0-24
| |
|
| |
| [[Datei:Fortinet-2008.jpg]]
| |
|
| |
| Erstelle eine Gruppe für den Tunnel Mode sowie für Portal Mode:
| |
|
| |
| User & Device > User Groups > Create New > gr-ssl-fc-tunnel-vpn-local-intra
| |
|
| |
| [[Datei:Fortinet-2009.jpg]]
| |
|
| |
| User & Device > User Groups > Create New > gr-ssl-fc-portal-vpn-local-intra
| |
|
| |
| [[Datei:Fortinet-2010.jpg]]
| |
|
| |
| Erstelle zwei User "local-0.intra" sowie "local-1.intra" und füge "local-0.intra" zur Gruppe "gr-ssl-fc-tunnel-vpn-local-intra" sowie "local-1.intra" zur Gruppe "gr-ssl-fc-web-vpn-local-intra" hinzu:
| |
|
| |
| User & Device > User Definition > Create New > Local User > User Name: local-0.intra
| |
|
| |
| [[Datei:Fortinet-2011.jpg]]
| |
|
| |
| User & Device > User Definition > Create New > Local User > User Name: local-1.intra
| |
|
| |
| [[Datei:Fortinet-2012.jpg]]
| |
|
| |
| Im nächsten Schritt werden die SSL-VPN Portal Profiles erstellt. Diese definieren welche Modi zur Verfügung stehen. In einem späteren konfigurations Schritt werden die entsprechenden SSL-VPN Gruppen zu diesen SSL-VPN Portal Profiles gemappt. In unserem Beispiel existieren zwei Gruppen dh. "gr-ssl-fc-tunnel-vpn-local-intra" sowie "gr-ssl-fc-portal-vpn-local-intra". Somit erstellen wir ein SSL-VPN Portal Profile für den Tunnel Mode sowie ein SSL-VPN Portal Profile für den Portal Mode. Zusätzlich wird ein "default" SSL-VPN Portal Profile erstellt, dass für alle User gilt die nicht Mitglied beider Gruppen sind. In diesem SSL-VPN Portal Profile werden keine Funktionen zur Verfügung gestellt und gilt somit als "default" SSL-VPN Portal Profile:
| |
|
| |
| VPN > SSL-VPN Portals > Create New > local-fc-portal-access.intra
| |
|
| |
| [[Datei:Fortinet-2013.jpg]]
| |
|
| |
| Unter "Predefined Bookmarks" können entsprechende Bookmarks für die User vorbereitet werden wie zB für RDP. Wird die Position "User Bookmarks" aktiviert so ist es den Usern für dieses SSL-VPN Portal Profile erlaubt eigenen Bookmarks zu erstellen! Desweiteren ist für die Konfiguration unter FortiOS 5.4 zu berücksichtigen, dass die RDP Native Funktion entfernt wurde und mit RDP HMTL5 ersetzt worden ist. Ebenso wurde im SSL-VPN Portal Profile für den Web Mode das "Tunnel Mode Widget" entfernt und steht somit aus Sicherheitsgründen nicht mehr zur Verfügung!
| |
|
| |
| VPN > SSL-VPN Portals > Create New > local-fc-tunnel-access.intra
| |
|
| |
| [[Datei:Fortinet-2014.jpg]]
| |
|
| |
| Das "default" SSL-VPN Portal Profile ist ein Profile das durch alle User genutzt wird die nicht Mitglied einer definierten Gruppe im Mapping ist. Dies bedeutet: Aus Sicherheitsgründen wird aus diesem Grund ein "default" SSL-VPN Portal Profile erstellt, dass über keine entsprechenden Funktion verfügt. Ein SSL-VPN Portal Profile kann nur dann erstellt werden wenn mindestens ein Mode aktiviert ist dh. für das "default" Portal Profile aktivieren wir den Web Mode jedoch aktivieren keine entsprechenden Funktionen:
| |
|
| |
| VPN > SSL-VPN Portals > Create New > local-fc-default-access.intra
| |
|
| |
| [[Datei:Fortinet-2015.jpg]]
| |
|
| |
| In den nächsten konfigurations Schritten wird unter der Menü Position "SSL-VPN Settings" ein Mapping Konfiguriert für die entsprechende Gruppen und SSL-VPN Portal Profiles. In diesem Mapping ist es zusätzlich möglich anhand eines "Realms" dieses Mapping zu differenzieren dh. zwischen Gruppen und SSL-VPN Portal Profiles nochmals zu differenzieren. Dieser Konfigurationsschritt ist Optional und wird nicht für jede Konfiguration benötigt. In unserem Beispiel erstellen wir einen "Realm" den wir zur Gruppe "gr-ssl-fc-portal-vpn-local-intra" sowie SSL-VPN Portal "local-fc-portal-access.intra" Mappen. Das Mapping erfolgt mit einem Realm "portal" dh. um das SSL-VPN Portal Profile "local-fc-portal-access.intra" für die Gruppe "gr-ssl-fc-portal-vpn-local-intra" aufzurufen, müssen die User den entsprechenden Realm "portal" eingeben ansonsten ist das SSL-VPN Portal nicht zugänglich und der User kann sich nicht anmelden dh.:
| |
|
| |
| https://[FQDN Public IPv4 Adresse des "wan1" Interfaces]/portal
| |
|
| |
| VPN > SSL-VPN Realms > Create New > portal
| |
|
| |
| [[Datei:Fortinet-2016.jpg]]
| |
|
| |
| Nun kann die SSL-VPN Konfiguration anhand der "SSL-VPN Settings" abgeschlossen werden. Dabei ist folgendes zu beachten: Unter "Authentication/Portal Mapping" wird wie schon erwähnt eine entsprechenden Gruppe anhand eines Realms zu einem SSL-VPN Portal Profile gemappt. In dieser Konfiguration dieses Mapping gilt wie für eine Firewall Policy Rule Definition "top down first match wins". Als sogenannte "clean-up" Rule muss ein entsprechendes SSL-VPN Portal Profile definiert werden das für alle anderen User resp. Gruppen gilt. Für diese Position wird unser "default" SSL-VPN Portal Profile definiert in dem zwar Web Mode aktiviert ist jedoch ohne jegliche Funktionen:
| |
|
| |
| VPN > SSL-VPN Settings
| |
|
| |
| [[Datei:Fortinet-2017.jpg]]
| |
|
| |
| Die Konfiguration des SSL-VPN Funktion sei es für Portal/Tunnel Mode ist grundsätzlich abgeschlossen. Damit die Funktion vervollständig wird hinsichtlich Routing und Firewall Policy Rule, muss auf der einen Seite der IPv4 IP Pool Adressen auf das "ssl.root" Interface geroutet werden sowie eine entsprechende Firewall Police Rule konfiguriert werden, die den Traffic des Users auf die entsprechenden Resourcen im LAN erlaubt:
| |
|
| |
| Network > Static Routes > Create New
| |
|
| |
| [[Datei:Fortinet-2018.jpg]]
| |
|
| |
| Dieser statische Route Eintrag muss nur dann erstellt werden, wenn für "vpn ssl settings" die Option "auto-tunnel-static-route" deaktiviert ist. Ist diese Option aktiviert so wird auf Layer 4 für den Service SSL-VPN ein Routing Eintrag erstellt. Dieser Eintrag da dieser im Layer 4 erstellt wird ist nicht über Layer 3 ersichtlich dh. in der Routing Table. Der entsprechende Routing Eintrag unter Layer 4 wird nur dann erstellt wenn ein User erfolgreich einer Verbindung etabliert hat!
| |
|
| |
| Policy & Objects > IPv4 Policy > Create New
| |
|
| |
| [[Datei:Fortinet-2019.jpg]]
| |
|
| |
| Die Konfiguration ist abgeschlossen und kann getestet werden! Für den SSL-VPN Portal Mode muss nun die folgende URL benützt werden:
| |
|
| |
| https://[FQDN Public IPv4 Adresse des "wan1" Interfaces]/portal
| |
|
| |
| Für den SSL-VPN Tunnel Mode muss die entsprechende Software auf dem Client/Host installiert werden. Wir empfehlen den FortiClient im "VPN-Only" Mode. Das entsprechende Software Packet wird über diese MediaWiki Seite zur Verfügung gestellt und über folgenden Link runtergeladen werden:
| |
|
| |
| [[FortiGate:KonfigExample#Typische_KMU_Konfiguration]]
| |
|
| |
| Bei der Auswahl des FortiClient ist folgendes zu beachten: FortiOS 5.4 sei es für SSL-VPN und/oder IPSec unterstützt kein FortiClient in der Version 5.0 dh. es muss der FortiClient 5.4 installiert werden oder FortiClient ab 5.2.5. Bei der Installation des FortiClient ist darauf zu achten dieser anhand administrations Rechten installiert wird. Wenn dies durchgeführt wird, kann über das FortiClient Menü eine entsprechende SSL-VPN Verbindung konfiguriert werden. Wenn eine Verbindung zur IPv4 Public Adresse oder FQDN des FortiGate Devices erstellt wird, sollte nach einer erfolgreichen Authentifizierung durch den User die Routing Einträge auf dem Client/Host kontrolliert werden. Dies bedeutet: Durch die Definition des Split Tunneling im SSL-VPN Portal Tunnel Profile "local-fc-tunnel-access.intra" wird anhand des definiert internen LAN IPv4 Subnet Adresse nach der erfolgreichen Authentifizierung durch den SSL-VPN Tunnel zum Client/Host ein entsprechender Routing Eintrag gesendet und lokal auf dem Client/Host erstellt. Dieser Routing Eintrag ist verantwortlich, dass ausschlieschlich nur der definierte IPv4 Subnet Adressen des internen LAN Segment durch den SSL-VPN Tunnel gesendet werden. Destinationen die nicht dieser Definition entsprechen dh. des internen IPv4 LAN Segments, werden über den definiert Default Gateway des Client/Host gesendet (Split Tunneling). Dieser Umstand sollte Rechnung getragen werden und beim Testen des Tunnel Modes kontrolliert werden. Die gesamte hier gezeigte Konfiguration kann ebenfalls über CLI durchgeführt werden. Nachfolgend werden die entsprechenden Kommandos gezeigt die für diese Konfiguration ausgeführt werden müssen. Dabei ist folgendes zu berücksichtigen: Die hier gezeigten Befehle zeigen nur die auszuführenden Kommandos dh. die Kommandos die nicht von der standard Konfiguration eines FortiOS abweichen werden hier nicht gezeigt:
| |
|
| |
| # config firewall address
| |
| # edit "net-local-ip-pool-ssl-vpn-198.18.1.0-25"
| |
| # set comment "SSL-VPN IP Pool local-sg0e0"
| |
| # set subnet 198.18.1.0 255.255.255.128
| |
| # next
| |
| # end
| |
|
| |
| # config firewall address
| |
| # edit "net-local-lan-198.18.0.0-24"
| |
| # set comment "Net lan local-sg0e0"
| |
| # set subnet 198.18.0.0 255.255.255.0
| |
| # next
| |
| # end
| |
|
| |
| # config user local
| |
| # edit "local-0.intra"
| |
| # set type password
| |
| # set passwd "[Password]"
| |
| # next
| |
| # end
| |
|
| |
| # config user local
| |
| # edit "local-1.intra"
| |
| # set type password
| |
| # set passwd "[Password]"
| |
| # next
| |
| # end
| |
|
| |
| # config user group
| |
| # edit "gr-ssl-fc-tunnel-vpn-local.intra"
| |
| # set group-type firewall
| |
| # set member "local-0.intra"
| |
| # next
| |
| # end
| |
|
| |
| # config user group
| |
| # edit "gr-ssl-fc-portal-vpn-local.intra"
| |
| # set group-type firewall
| |
| # set member "local-1.intra"
| |
| # next
| |
| # end
| |
|
| |
| # config vpn ssl web portal
| |
| # edit "local-fc-portal-access.intra"
| |
| # set web-mode enable
| |
| # set limit-user-logins enable
| |
| # config bookmark-group
| |
| # edit "gui-bookmarks"
| |
| # config bookmarks
| |
| # edit "RDP"
| |
| # set apptype rdp
| |
| # set server-layout de-de-qwertz
| |
| # set description "HTML5 RDP Connection"
| |
| # set host "198.18.0.94"
| |
| # set port 3389
| |
| # next
| |
| # end
| |
| # set heading "Welcome to local.ch"
| |
| # set custom-lang "en"
| |
| # next
| |
| # end
| |
|
| |
| # config vpn ssl web portal
| |
| # edit "local-fc-tunnel-acces.intra"
| |
| # set tunnel-mode enable
| |
| # set limit-user-logins enable
| |
| # set keep-alive enable
| |
| # set save-password enable
| |
| # set ip-pools "net-local-ip-pool-ssl-vpn-198.18.1.0-25"
| |
| # set split-tunneling-routing-address "net-local-lan-198.18.0.0-24"
| |
| # set dns-server1 198.18.0.91
| |
| # next
| |
| # end
| |
|
| |
| # config vpn ssl web portal
| |
| # edit "local-fc-default-access.intra"
| |
| # set web-mode enable
| |
| # set user-bookmark disable
| |
| # config bookmark-group
| |
| # edit "gui-bookmarks"
| |
| # next
| |
| # end
| |
| # set display-connection-tools disable
| |
| # set display-history disable
| |
| # set display-status disable
| |
| # set heading "SSL-VPN Portal - dummy"
| |
| # next
| |
| # end
| |
|
| |
| # config vpn ssl web realm
| |
| # edit "portal"
| |
| # set max-concurrent-user 100
| |
| # set login-page "<!DOCTYPE html>
| |
| <nowiki><html lang=\"en\" class=\"main-app\">
| |
| <head>
| |
| <meta charset=\"UTF-8\">
| |
| <meta http-equiv=\"X-UA-Compatible\" content=\"IE=8; IE=EDGE\">
| |
| <meta name=\"viewport\" content=\"width=device-width, initial-scale=1\">
| |
| <link href=\"/css/main-blue.css\" rel=\"stylesheet\" type=\"text/css\">
| |
| <title>
| |
| Please Login
| |
| </title>
| |
| </head>
| |
| <body>
| |
| <div class=\"view-container\">
| |
| <form class=\"prompt\" action=\"%%SSL_ACT%%\" method=\"%%SSL_METHOD%%\" name=\"f\" autocomplete=\"off\">
| |
| <div class=\"content with-header\">
| |
| <div class=\"header\">
| |
| <div>
| |
| WARNING!
| |
| <br>
| |
| <br>
| |
| You must have prior authorization to login to this system. All connections are logged and monitored. By login to this system you fully consent to all monitoring. Unauthorized login or use will be prosecuted to the full extent of the law. You have been warned!
| |
| </div>
| |
| </div>
| |
| <div class=\"sub-content\">
| |
| <div class=\"wide-inputs\">
| |
| %%SSL_LOGIN%%
| |
| </div>
| |
| <div class=\"button-actions wide\">
| |
| <button class=\"primary\" type=\"button\" name=\"login_button\" id=\"login_button\" onClick=\"try_login()\">
| |
| Login
| |
| </button>
| |
| </div>
| |
| </div>
| |
| </div>
| |
| </form>
| |
| </div>
| |
| </body>
| |
| %%SSL_HIDDEN%%
| |
| </html>
| |
| "</nowiki>
| |
| # next
| |
| # end
| |
|
| |
| # config vpn ssl settings
| |
| # set servercert "Fortinet_Factory"
| |
| # set idle-timeout 1800
| |
| # set tunnel-ip-pools "net-local-ip-pool-ssl-vpn-198.18.1.0-25"
| |
| # set dns-suffix "local.intra"
| |
| # set dns-server1 198.18.0.91
| |
| # set port 443
| |
| # set auto-tunnel-static-route disable
| |
| # set source-interface "wan1"
| |
| # set source-address "all"
| |
| # set source-address6 "all"
| |
| # set default-portal "local-fc-default-access.intra"
| |
| # config authentication-rule
| |
| # edit [Gebe einen entsprechenden Integer an zB "1"]
| |
| # set source-interface "wan1"
| |
| # set source-address "all"
| |
| # set groups "gr-ssl-fc-tunnel-vpn-local.intra"
| |
| # set portal "local-fc-tunnel-acces.intra"
| |
| # set auth local
| |
| # next
| |
| # edit [Gebe einen entsprechenden Integer an zB "2"]
| |
| # set source-interface "wan1"
| |
| # set source-address "all"
| |
| # set groups "gr-ssl-fc-portal-vpn-local.intra"
| |
| # set portal "local-fc-portal-access.intra"
| |
| # set realm "portal"
| |
| # set auth local
| |
| # next
| |
| # end
| |
| # end
| |
|
| |
| # config router static
| |
| # edit [Gebe einen entsprechenden Integer ein zB "2"]
| |
| # set dst 198.18.1.0 255.255.255.128
| |
| # set device "ssl.root"
| |
| # set comment "SSL VPN IPool local-sg0e0"
| |
| # end
| |
|
| |
| # config firewall policy
| |
| # edit [Gebe einen entsprechende Policy ID ein zB "2"]
| |
| # set srcintf "ssl.root"
| |
| # set dstintf "internal1"
| |
| # set srcaddr "net-local-ip-pool-ssl-vpn-198.18.1.0-25"
| |
| # set dstaddr "net-local-lan-198.18.0.0-24"
| |
| # set action accept
| |
| # set schedule "always"
| |
| # set service "ALL"
| |
| # set logtraffic all
| |
| # set groups "gr-ssl-fc-tunnel-vpn-local.intra" "gr-ssl-fc-portal-vpn-local.intra"
| |
| # set comments "Allow Incoming SSL VPN Tunnel Connection local-sg0e0"
| |
| # next
| |
| # end
| |
|
| |
| === Wie kann ich unter FortiOS 5.4 für ein SSL-VPN das Authentication und/oder IDLE Timeout setzen? ===
| |
|
| |
| Wenn ein SSL-VPN VPN sei es für ein VPN-Portal und/oder Tunnel Mode konfiguriert wird gibt es grundsätzlich zwei verschiedenen Timeouts dh. für IDLE sowie Authentication:
| |
|
| |
| • IDLE (maximale mögliche Zeit für eine Verbindung in der keine Datenpacket übermittelt werden)
| |
| • Authentication (maximale mögliche Zeit für eine Verbindung)
| |
|
| |
| Somit wenn ein User eine SSL-VPN sei es im VPN-Portal/Tunel Mode etabliert und kein Traffic resp. Datenpackete übermittelt werden greift das IDLE. Dieses kann nur Global für SSL-VPN konfiguriert werden:
| |
|
| |
| # config vpn ssl settings
| |
| # set idle-timeout [Standard 1800 Sekunden; Möglich 0-259200 (72 Stunden); 0 = no timeout)
| |
| # end
| |
|
| |
| Wenn nun zB eine SSL-VPN Verbindung sei es für VPN-Portal/Tunnel Mode das "idle-timeout" auf maximal 72 Stunden gesetzt wird oder 0 für kein Timeout, wird die Verbindung dennoch nach 8 Stunden beendet. Der Grund ist die folgende Option in den globalen Einstellungen die per Standard eine SSL-VPN Verbindung nach 8 Stunden beendet. Dabei spielt es keine Rolle ob Datenpacket übermittelt werden oder nicht denn diese Option indiziert die maximale Zeit einer möglichen Verbindung bevor sich ein User abermals einloggen muss:
| |
|
| |
| # config vpn ssl settings
| |
| # set auth-timeout [Standard 28800 Sekunden (8 Stunden); Möglich 10-259200 (72 Stunden); 0 = no timeout)
| |
| # end
| |
|
| |
| === Welche Software kann ich unter FortiOS 5.4 für SSL-VPN im Portal/Tunnel für verschiedene Devices einsetzen? ===
| |
|
| |
| Ausgehend davon das ein SSL-VPN im Portal/Tunnel Mode auf einer FortiGate unter FortiOS 5.4 korrekt konfiguriert wurde, kann für verschiedene Devices wie zB Windows, MacOSx, IOS oder Android Software von Fortinet eingesetzt werden. Wie ein SSL-VPN im Portal/Tunnel Mode auf einem FortiGate Device konfiguriert wird unter FortiOS 5.4 siehe nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.4-5.6:FAQ#Wie_kann_ich_unter_FortiOS_5.4_ein_SSL-VPN_f.C3.BCr_Portal.2FTunnel_Mode_auf_einer_FortiGate_konfigurieren.3F]]
| |
|
| |
| Grundsätzlich stellt Fortinet für den SSL-VPN Tunnel Mode den FortiClient Endpoint Security zur Verfügung. Dabei ist zu beachten, dass der FortiClient Endpoint Security im VPN-Only Mode benutzt wird. Dies bedeutet: Diese Art des FortiClient Endpoint Security beinhaltet nur SSL-VPN sowie die Möglichkeit für IPSec VPN und beinhaltet keine UTM Features. Ueber folgenden Link können diese FortiClient's Endpoint Security im VPN-Only Mode runtergeladen werden:
| |
|
| |
| [[FortiGate:KonfigExample#Typische_KMU_Konfiguration]]
| |
|
| |
| Basierend auf FortiOS 5.4 und FortiClient VPN-Only Mode oder FortiClient Tunnel Mode gilt folgendes:
| |
|
| |
| • Für Microsoft Windows 7/8/10 FortiClient Endpoint Security ab Version 5.2.5 oder ab Version 5.4
| |
| • Für Microsoft Windows 10 App Desktop/Phone FortiClient (Windows App) ab Version 1.0.0
| |
| • Für Apple MacOSx 10.8/9/10/11 FortiClient Endpoint Security ab Version 5.2.5 oder ab Version 5.4
| |
| • Für Apple iOS ab Version 9.0.0 FortiClient iOS ab Version 5.4.0.121
| |
| • Für Android ab Version 4.1 Jelly Bean, 4.4.3 KitKat, 5.0.1 Lollipop FortiClient VPN Android 5.2.6
| |
|
| |
| Auf dem folgenden Link sind die Release Notes und AdminGuides der verschiedenen FortiClient Versionen zu finden:
| |
| [[FortiClient:FAQ#Dokumentation]]
| |
|
| |
| Basierend auf FortiOS 5.4 SSL-VPN Portal Mode dh. eingesetzte Betriebssysteme sowie Browser gilt folgendes:
| |
|
| |
| • Microsoft Windows 7 SP1 (32-bit/64-bit) Microsoft Internet Explorer version 11
| |
| • Mozilla Firefox version 42
| |
| • Microsoft Windows 8/8.1 (32-bit/64-bit) Microsoft Internet Explorer version 11
| |
| • Mozilla Firefox 42
| |
| • Mac OS 10.9 Safari 7
| |
| • Linux CentOS version 6.5 Mozilla Firefox 42
| |
|
| |
| Desweiteren ist zu berücksichtigen, dass die Release Notes zu konsultieren sind betreffend SSL-VPN Tunnel Mode und den spezifischen Funktionen wie zB Split Tunneling, DNS Sufix usw.
| |
|
| |
| === Wie kann ich unter FortiOS 5.4 ein SSL-VPN für Portal/Tunnel Mode konfigurieren anhand einer 2ten Public IPv4 Adresse? ===
| |
|
| |
| Wenn man ein SSL-VPN für Portal/Tunnel Mode konfiguriert so wird unter normalen Umständen die Main IPv4 Adresse benutzt die auf dem zB "wan1" Interface konfiguriert wurde. Dazu siehe auch nachfolgenden Artikel:
| |
|
| |
| [[FortiGate-5.4-5.6:FAQ#Wie_kann_ich_unter_FortiOS_5.4_ein_SSL-VPN_f.C3.BCr_Portal.2FTunnel_Mode_auf_einer_FortiGate_konfigurieren.3F]]
| |
|
| |
| Im vorhergehenden Artikel wird beschrieben wie ein SSL-VPN für Portal/Tunnel Mode anhand der Main IPv4 Adresse auf dem zB "wan1" Interface konfiguriert wird. Dieser Artikel basiert auf folgendem Beispiel und benutzt somit als SSL-VPN Interface "wan1" und somit die IPv4 Adresse 193.193.135.66:
| |
| ____________ _________________________
| |
| 193.193.135.66/29| | 198.18.0.1 | | Office IPv4 Pool 198.18.1.0/25
| |
| ----- WAN 1 -----| Fortigate |------ LAN -----| LAN Env. 198.18.0.0/24 |
| |
| |____________| |_________________________|
| |
|
| |
| Nun möchte man jedoch die IPv4 Adresse 193.193.135.67 benutzen für das SSL-VPN Portal und nicht 193.193.135.66, stellt sich die Frage wie das zu bewerkstelligen ist? Ein Ansatz wäre ein Secondary Interface unter "wan1" zu konfigurieren anhand der IPv4 Adrese 193.193.135.67/32. Dies wird jedoch verhindert durch die CLI Option "allow-subnet-overlap disable". Diese Option verhindert, dass auf einem existierenden Interface ein Overlapping Subnet konfiguriert wird. Weitere Informationen zu "allow-subnet-overlap" siehe nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.4-5.6:FAQ#Wie_kann_ich_unter_FortiOS_5.4_f.C3.BCr_einen_FortiGate_Device_f.C3.BCr_ein_Interface_ein_.22overlapping.22_Subnet_Konfigurieren.3F]]
| |
|
| |
| Wenn diese Option "allow-subnet-overlap" aktiviert wird, kann auf dem "wan1" Interface anhand einer Secondary Interface IPv4 Adresse 193.193.135.67/32 konfiguriert werden und als SSL-VPN Portal/Tunnel Adresse unter VPN SSL Settings das "wan1" Interface. Dadurch kann zwar 193.193.135.67 benutzt werden für den SSL-VPN Portal/Tunnel Zugriff, jedoch wird dadurch nicht verhindert das 193.193.135.66 ebenfalls zur Verfügung steht für einen SSL-VPN Portal/Tunnel Mode Zugriff. Abhilfe würde eine Manuelle "Local-In Policy" Rule schaffen, die den Zugriff auf diese Adresse 193.193.135.66 und dem SSL-VPN Portal/Tunnel Mode verhindert. Diese Konfiguration einer Manuellen "Local-In Policy" Rule muss jedoch in der CLI durchgeführt werden anhand folgender Befehle:
| |
|
| |
| # config firewall local-in-policy
| |
| # edit [Gebe eine entsprechende Policy ID an zB "1"]
| |
| # set ha-mgmt-intf-only disable
| |
| # set intf "wan1"
| |
| # set srcaddr "all"
| |
| # set dstaddr [Gebe das entsprechende Objekt an für die IPv4 Adresse zB "pub-ip-193.193.135.66-32"
| |
| # set action deny
| |
| # set service [Gebe das entsprechende Objekt an für den SSL-VPN Port zB "https"]
| |
| # set schedule "always"
| |
| # set auto-asic-offload enable
| |
| # set status enable
| |
| # end
| |
|
| |
| Die Konfiguration anhand "allow-subnet-overlap enable" sollte jedoch verhindert werden, da durch diese Konfiguration resp. durch eine Fehlkonfiguration auf dem FortiOS ein potentieller "loop" verursacht werden kann und dieser durch das FortiOS nicht mehr verhindert wird! Eine weitere Lösung wäre die Konfiguration anhand eines VIP Objektes (Destination NAT) durchzuführen und unter VPN-SSL Settings ein spezifisches Interface zu konfigurieren das den Zugriff auf zB "wan1" nicht mehr ermöglich für den SSL-VPN Portal/Tunnel Mode. Dies kann anhand eines Loopback Interfaces konfiguriert werden. Dies bedeutet: Es wird ein spezifisches Loopback Interface konfiguriert anhand einer IPv4 Adresse die auf dem FortiOS resp. im Netzwerksegment nicht benützt wird. In unserem Beispiel benützen wir die IPv4 Adresse 198.18.100.1/32. Dabei sollte beachtet werden, dass ein Loopback Interface nicht anhand der Standard Loopback Interface Adressen konfiguiert wird dh. 127.0.x.x da diese IPv4 Adressen für verschiedenen Service unter FortiOS bereits benutzt werden. Um ein Loopback Interface zu konfigurieren führe folgendes durch:
| |
|
| |
| Network > Interfaces > Create New > Interfaces
| |
|
| |
| [[Datei:Fortinet-2112.jpg]]
| |
|
| |
| [[Datei:Fortinet-2113.jpg]]
| |
|
| |
| Als nächsten Schritt konfigurieren wir ein VIP Objekt (Destination NAT) anhand der Public IPv4 Adresse die für den Zugriff des SSL-VPN Portal/Tunnel Mode benützt werden soll und auf die Loopback Interface IPv4 Adresse Uebersetzt wird:
| |
|
| |
| Policy & Objects > Virtual IPs > Create New > Virtual IP
| |
|
| |
| [[Datei:Fortinet-2114.jpg]]
| |
|
| |
| Anhand dieses VIP Objekts und durch die Konfiguration 193.193.135.67 und "wan1" wird auf diesem Interface anhand der MAC Adresse des "wan1" im Hintergrund ein ARP Eintrag auf Layer 4 für 193.193.135.67 auf "wan1" erstellt! Nun muss für das SSL-VPN Portal/Tunnel Mode unter den SSL-VPN Settings das Loopback Interface definiert werden damit ausschliesslich dieses für SSL-VPN Tunnel/Portal Mode zur Verfügung steht und somit "wan1" für diesen Service ausgeschlossen wird:
| |
|
| |
| VPN > SSL-VPN Settings > Listen on Interface(s)
| |
|
| |
| [[Datei:Fortinet-2115.jpg]]
| |
|
| |
| Nun wird anhand einer regulären Firewall Policy Rule der SSL-VPN Zugriff konfiguriert dh. damit dieser über die entsprechende IPv4 193.193.135.67 zur Verfügung gestellt wird:
| |
|
| |
| Policy & Objects > IPv4 Policy
| |
|
| |
| [[Datei:Fortinet-2116.jpg]]
| |
|
| |
| Das definierte Interface für "Outgoing Interface" definiert unser zuvor konfiguriertes Loopback Interface. Wenn ein User nun https://193.193.135.67 zB für den Portal Mode im Browser aufruft, gibt diese IP auf dem "wan1" Interface antwort da auf diesem Interface für die IPv4 Adresse 193.193.135.67 ein ARP Eintrag im Layer 4 existiert. Da ein VIP Objekt (Destination NAT) für diese IPv4 Adresse existiert und Uebersetzt wird auf das Looback Interface sowie dieses wiederum unter SSL-VPN Settings definiert wurde als Interface, erscheint der SSL-VPN Portal/Tunnel Mode. Somit wird zwar durch diese Firewall Policy Rule der SSL-VPN Service zur Verfügung gestellt, jedoch eine Authentifizierung oder Zugriff auf interne Resource ist nicht möglich da keine entsprechende Firewall Policy Rule existiert. Damit eine Authentifizierung durchgführt werden kann sowie interne Resourcen aufgerufen werden können, muss für den SSL-VPN Service dh. "ssl.root" eine zusätzliche Firewall Policy Rule konfiguriert werden:
| |
|
| |
| Policy & Objects > IPv4 Policy
| |
|
| |
| [[Datei:Fortinet-2117.jpg]]
| |
|
| |
| Als letzter Schritt muss, sofern die "realm" Funktion benutzt wird, die Interfaces für diese "realms" kontrolliert werde um diese ebenfalls auf das Loopback Interface "nic-ssl-vpn" zu konfigurieren dh. die muss über CLI durchgeführt werden:
| |
|
| |
| # config vpn ssl settings
| |
| # get | grep source-interface
| |
| source-interface : "nic-ssl-vpn"
| |
| # config authentication-rule
| |
| # edit [Gebe einen entsprechenden Integer an für den "realm" Eintrag zB "1"]
| |
| # set source-interface nic-ssl-vpn
| |
| # end
| |
| # end
| |
|
| |
| Um ein Troubleshooting durchzuführen für diese Konfiguration sollte in erster Linie überprüft werden ob die entsprechende IPv4 Adresse resp. der entsprechende SSL-VPN Port erreichbar ist (SYN/ACK):
| |
|
| |
| # diagnose sniffer packet any "port [Gebe den entsprechenden Port an zB 443" 4
| |
|
| |
| Wenn dies zB nicht der Fall ist sollte überprüft werden ob das VIP Objekt angesprochen wird und ob der SSL-VPN Port der unter SSL-VPN Settings konfiguriert wurde antwort gibt. Dies kann anhand folgenden Befehls durchgeführt werden:
| |
|
| |
| # diagnose debug disable
| |
| # diagnose debug reset
| |
| # diagnose debug flow trace stop
| |
| # diagnose debug flow filter clear
| |
| # diagnose debug flow filter port [Gebe den entsprechenden Port an zB "443"]
| |
| # diagnose debug flow filter daddr [Gebe die entsprechende Public IPv4 Adresse an zB "193.193.135.71"]
| |
| # diagnose debug flow show console enable
| |
| # diagnose debug flow show function-name enable
| |
| # diagnose debug flow trace start 10
| |
| # diagnose debug enable
| |
| # diagnose debug flow trace start
| |
|
| |
| Nun kann die Konfiguration getestet werden. Weitere Informationen betreffend der SSL-VPN Portal/Tunnel Mode Konfiguration siehe nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.4-5.6:FAQ#Wie_kann_ich_unter_FortiOS_5.4_ein_SSL-VPN_f.C3.BCr_Portal.2FTunnel_Mode_auf_einer_FortiGate_konfigurieren.3F]]
| |
|
| |
| === Wie kann ich unter FortiOS 5.4 für ein SSL-VPN für Portal/Tunnel Mode eine Two-Factor Authentifizierung konfigurieren? ===
| |
|
| |
| Ausgangslage für eine Two-Factor Authentifizierung ist ein einwandfreie Konfiguration eines SSL-VPN Portal/Tunnel Mode. Wie diese durchzuführen ist siehe nachfolgenden Artikel:
| |
|
| |
| [[FortiGate-5.4-5.6:FAQ#Wie_kann_ich_unter_FortiOS_5.4_ein_SSL-VPN_f.C3.BCr_Portal.2FTunnel_Mode_auf_einer_FortiGate_konfigurieren.3F]]
| |
|
| |
| Diese Konfiguration kann danach erweitert werden mit einer Two-Factor Authentifizierung basierend auf:
| |
|
| |
| • Local User FortiGate Two-Factor Authentication FortiToken oder FortiToken Mobile
| |
| • Local User FortiGate Two-Factor Authentication ODA basierend auf Email oder SMS Provider
| |
| • Local User FortiGate Two-Factor Authentication LDAP/Radius basierend auf SMS oder FortiToken/FortiToken Mobile
| |
|
| |
| Wichtig bei einer Two-Factor Authentication auf einer FortiGate ist der folgende Umstand:
| |
|
| |
| • Für eine Two-Factor Authentication muss der User Lokal auf der FortiGate erfasst werden!
| |
|
| |
| Dies bedeutet: Auch wenn eine Two-Factor Authentication über LDAP oder Radius durchgeführt wird muss ein lokaler User auf der FortiGate konfiguriert werden. Eine Konfiguration in dem innerhalb einer Gruppe der Remote Authentication Server hinzugefügt wird zB Radius und der User lokal nicht auf der FortiGate existiert, ist nicht möglich! Deshalb gilt: Für jede Two-Factor Authentication muss der User auf einer FortiGate Lokal erfasst werden. Wenn eine Two-Factor Authentication konfiguriert werden soll anhand eines FortiToken, FortiToken Mobile oder ODA muss folgendermassen vorgeganen werden:
| |
|
| |
| '''ODA Two-Factor Authentication basierend über Email oder SMS'''
| |
|
| |
| Für eine ODA Two-Factor Authentication basierend auf Email muss der entsprechende Email Service als Voraussetzung konfiguriert
| |
| werden. Wie dies durchzuführen ist siehe nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.4-5.6:FAQ#Wie_kann_ich_unter_FortiOS_5.4_f.C3.BCr_eine_FortiGate_den_.22Email_Service.22_konfigurieren.3F]]
| |
|
| |
| Für eine ODA Two-Factor Authentication basierend auf SMS muss der entsprechende SMS Service/Provider als Voraussetzung konfiguriert
| |
| werden. Dabei ist folgendes zu berücksichtigen: Ein Versandt der SMS für Two-Factor Authentication ist nur über den Email Service
| |
| möglich dh. deshalb gilt für den SMS Versand ebenfalls als Voraussetzung ein konfigurierter Email Service! Ein Versand der SMS über
| |
| HTTP/S get und post ist direkt über eine FortiGate nicht möglich. Wie ein SMS Service/Provider auf einer FortiGate konfiguriert wird
| |
| siehe nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.4-5.6:FAQ#Wie_kann_ich_unter_FortiOS_5.4_auf_einer_FortiGate_einen_SMS_Service.2FProvider_konfigurieren.3F]]
| |
|
| |
| Wenn diese Voraussetzungen dh. konfigurierter Email Service sowie SMS Service/Provider bestehen kann ein lokaler User für Two-Factor
| |
| Authentication konfiguriert werden. Für diese Konfiguration muss die CLI benutzt werden da die Two-Factor Funktion für SMS/Email nur
| |
| über CLI konfiguriert werden kann:
| |
|
| |
| # config user local
| |
| # edit [Name des User zB "local-3.intra"]
| |
| # set type password
| |
| # set two-factor '''sms'''
| |
| # set sms-server custom
| |
| # set sms-custom-server [Name des SMS Service/Provider zB "swisscom"]
| |
| # set sms-phone [Mobile Nummer des User zB "41798456615"]
| |
| # set password [Passwort des Users]
| |
| # end
| |
|
| |
| # config user local
| |
| # edit [Name des User zB "local-4.intra"]
| |
| # set type password
| |
| # set two-factor '''email'''
| |
| # set email-to [Email Adresse des Users zB "local-4@local.intra"]
| |
| # set password [Passwort des Users]
| |
| # end
| |
|
| |
| Die über CLI erfassten User sind nachträglich über Mgmt. Web Interface wie üblich ersichtlich:
| |
|
| |
| [[Datei:Fortinet-2025.jpg]]
| |
|
| |
| [[Datei:Fortinet-2026.jpg]]
| |
|
| |
| Nach Abschluss der Konfiguration können die entsprechenden User zu einer lokalen Gruppe hinzugefügt werden, die benutzt wird in
| |
| der SSL-VPN Portal/Tunnel Mode Konfiguration für die Authentifizierung! Damit die Two-Factor Authentifizierung für SSL-VPN sei
| |
| es im Portal/Tunnel Mode durchgeführt werden kann, muss diese Two-Factor Authentifizierung für die SSL-VPN Funktion aktiviert
| |
| werden. Dies kann über CLI konfiguriert werden:
| |
|
| |
| # config vpn ssl settings
| |
| # set force-two-factor-auth [enable | disable]
| |
| # end
| |
|
| |
| '''FortiToken/FortiToken Mobile Two-Factor Authentication'''
| |
|
| |
| Wenn eine Two-Factor Authentication über FortiToken sowie FortiToken Mobile konfiguriert werden soll muss als Voraussetzung der
| |
| FortiToken oder FortiToken Mobile in aller erster Linie korrekt registriert werden. Weitere Informationen dazu siehe nachfolgenden
| |
| Artikel:
| |
|
| |
| [[FortiToken:FAQ]]
| |
|
| |
| Wenn der FortiToken oder FortiToken Mobile korrekt registriert wurde kann der entsprechende FortiToken einem User zugewiesen werden.
| |
| Um einen FortiToken Mobile einem User hinzuzufügen muss entweder ein Mobile Nummer und/oder eine Email Adresse definiert werden um
| |
| den entsprechenden Aktivierungs-Code dem User zu übermitteln. Aus diesem Grund gilt als Voraussetzung um diese zu ermöglichen die
| |
| Konfiguration eines SMS Service/Provider oder ein Email Service. Weitere Informationen dazu siehe nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.4-5.6:FAQ#Wie_kann_ich_unter_FortiOS_5.4_f.C3.BCr_eine_FortiGate_den_.22Email_Service.22_konfigurieren.3F]]
| |
| [[FortiGate-5.4-5.6:FAQ#Wie_kann_ich_unter_FortiOS_5.4_auf_einer_FortiGate_einen_SMS_Service.2FProvider_konfigurieren.3F]]
| |
|
| |
| Die Konfiguration eines lokalen User über CLi muss folgendermassen durchgeführt werden:
| |
|
| |
| # config user local
| |
| # edit [Name des User zB "local-5.intra"]
| |
| # set type password
| |
| # set two-factor '''fortitoken'''
| |
| # set fortitoken [Gebe den entsprechende FortiToken oder FortiToken Mobile an]
| |
| # set email-to [Email Adresse des Users zB "local-5@local.intra"]
| |
| # set sms-server custom
| |
| # set sms-custom-server [Name des SMS Service/Provider zB "swisscom"]
| |
| # set sms-phone [Mobile Nummer des User zB "41798456615"]
| |
| # set password [Passwort des Users]
| |
| # end
| |
|
| |
| Die Konfiguration über Mgmt. Web Interface wird folgendermassen durchgeführt:
| |
|
| |
| User & Device > User Definition > Create New > User Type > Local User
| |
|
| |
| [[Datei:Fortinet-2027.jpg]]
| |
|
| |
| [[Datei:Fortinet-2028.jpg]]
| |
|
| |
| [[Datei:Fortinet-2029.jpg]]
| |
|
| |
| [[Datei:Fortinet-2030.jpg]]
| |
|
| |
| Nach Abschluss der Konfiguration können die entsprechenden User zu einer lokalen Gruppe hinzugefügt werden, die benutzt wird in
| |
| der SSL-VPN Portal/Tunnel Mode Konfiguration für die Authentifizierung! Damit die Two-Factor Authentifizierung für SSL-VPN sei
| |
| es im Portal/Tunnel Mode durchgeführt werden kann, muss diese Two-Factor Authentifizierung für die SSL-VPN Funktion aktiviert
| |
| werden. Dies kann über CLI konfiguriert werden:
| |
|
| |
| # config vpn ssl settings
| |
| # set force-two-factor-auth [enable | disable]
| |
| # end
| |
|
| |
| '''LDAP oder Radius Two-Factor Authentication basierend auf FortiToken, FortiToken Mobile, ODA basierend auf SMS Service oder Email Service'''
| |
|
| |
| Für eine Two-Factor Authentifizierung basierend auf Radius oder LDAP Server muss ein entsprechender LDAP oder Radius Server
| |
| konfiguriert werden. Der Radius oder LDAP Server darf in einer Gruppe nicht als Remote Server konfiguriert werden sondern
| |
| der lokale User muss als LDAP oder Radius User konfiguriert werden. Ausgangslage ist somit die Konfiguration eines LDAP
| |
| oder Radius Servers. Weitere Informationen wie ein LDAP oder Radius Server Einbindung konfiguriert wird siehe nachfolgender
| |
| Artikel:
| |
|
| |
| [[FortiGate-5.4-5.6:FAQ#Wie_konfiguriere_ich_auf_einer_FortiGate_unter_FortiOS_5.4_ein_.22Active_Directory.2FLDAP.22_Authentifizierung.3F]]
| |
| [[FortiGate-5.4-5.6:FAQ#Wie_konfiguriere_ich_auf_einer_FortiGate_unter_FortiOS_5.4_eine_.22Radius.22_Authentifizierung.3F]]
| |
|
| |
| Wenn die Konfiguration des LDAP oder Radius Servers durchgeführt wurde, kann ein lokaler User für Two-Factor Authentication
| |
| konfiguriert werden sei es für FortiToken, FortiToken Mobile oder ODA basierend auf SMS Service oder Email Service. Dabei ist
| |
| die gleiche Konfiguration durchzuführen wie vorhergehend für diese Two-Factor Authentication erklärt. Der lokale User wird
| |
| anstelle von "password" auf die entsprechende Authentication gesetzt dh.:
| |
|
| |
| # config user local
| |
| # edit [Name des User zB "local-5.intra"]
| |
| # set type [ldap | radius]
| |
| # end
| |
|
| |
| Ein lokal zu konfigurierder LDAP User kann anhand des User Wizards direkt aus dem LDAP Verzeichnis gezogen werden sofern die
| |
| LDAP Konfiguration korrekt durchgeführt wurde. Nach Abschluss der Konfiguration können die entsprechenden User zu einer lokalen
| |
| Gruppe hinzugefügt werden, die benutzt wird in der SSL-VPN Portal/Tunnel Mode Konfiguration für die Authentifizierung! Dabei darf
| |
| in dieser Gruppe kein Remote Groupt resp. LDAP Server oder Radius Server hinzugefügt werden. Damit die Two-Factor Authentifizierung
| |
| für SSL-VPN sei es im Portal/Tunnel Mode durchgeführt werden kann, muss diese Two-Factor Authentifizierung für die SSL-VPN Funktion
| |
| aktiviert werden. Dies kann über CLI konfiguriert werden:
| |
|
| |
| # config vpn ssl settings
| |
| # set force-two-factor-auth [enable | disable]
| |
| # end
| |
|
| |
| Um einen Debug durchzuführen für SSL-VPN im Zusammenhang mit einer Two-Factor Authentication kann folgendes durchgeführt werden:
| |
|
| |
| 1. Konfiguriere "putty" für logging dh. alle Informationen werden in ein Log aufgezeichnet (Category > Session > Logging > All session output)
| |
| 2. Erstelle eine SSH Verbindung zur FortiGate.
| |
| 3. Führe ein Login durch und gebe folgendes ein:
| |
|
| |
| '''Setze alle Debug Filter zurück'''
| |
|
| |
| # diagnose debug reset
| |
|
| |
| '''Aktiviere für den debug "output" den "timestamp"'''
| |
|
| |
| # diagnose debug console timestamp enable
| |
|
| |
| '''Setze die verschiedenen Debug Filter für Two-Factor Authentication'''
| |
|
| |
| # diagnose debub application fnbamd -1
| |
| # diagnose debub application authd -1
| |
| # diagnose debub application sslvpn -1
| |
|
| |
| '''Aktiviere den Debug Modus mit dem gesetzen Debug Filter'''
| |
|
| |
| # diagnose debug enable
| |
|
| |
| Nach erfolgreichen Debug deaktiviere diesen wiederum und lösche die Filter:
| |
|
| |
| '''Dektiviere den Debug Modus mit dem gesetzen Debug Filter'''
| |
|
| |
| # diagnose debug disable
| |
|
| |
| '''Setze alle Debug Filter zurück'''
| |
|
| |
| # diagnose debug reset
| |
|
| |
| === Wie kann ich unter FortiOS 5.4 für ein SSL-VPN für Portal/Tunnel Mode eine Active Directory/LDAP Authentifizierung konfigurieren? ===
| |
|
| |
| Ausgangslage für eine Active Directory/LDAP Authentifizierung ist ein einwandfreie Konfiguration eines SSL-VPN Portal/Tunnel Mode. Wie diese durchzuführen ist siehe nachfolgenden Artikel:
| |
|
| |
| [[FortiGate-5.4-5.6:FAQ#Wie_kann_ich_unter_FortiOS_5.4_ein_SSL-VPN_f.C3.BCr_Portal.2FTunnel_Mode_auf_einer_FortiGate_konfigurieren.3F]]
| |
|
| |
| In der hier gezeigten Konfiguration eines SSL-VPN Portal/Tunnel Mode werden lokale User konfiguriert und diesen lokalen Gruppen hinzugefügt. Für eine Active Directory/LDAP Authentifizierung können zwar die User lokal konfiguriert werden dh. aus dem Active Directory/LDAP Verzeichnis gewählt werden und einer lokalen Gruppe hinzugefügt werden jedoch ist dies mit einigem Aufwand verbunden. Sofern keine Two-Factor Authentifizierung durchgeführt wird, kann der entsprechenden Active Directory/LDAP Server innerhalb der entsprechenden Gruppe unter "Remote Groups" direkt definiert werden. Dabei ist es möglich "Any" (Regular/Simple bind without search)zu konfigurieren oder eine entsprechende Gruppe oder Gruppen (Regular/Simple bind with search). Wie ein Active Directory/LDAP Server konfiguriert wird siehe nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.4-5.6:FAQ#Wie_konfiguriere_ich_auf_einer_FortiGate_unter_FortiOS_5.4_ein_.22Active_Directory.2FLDAP.22_Authentifizierung.3F]]
| |
|
| |
| Wie in einer lokalen Gruppe ein Active Directory/LDAP Server hinzugefügt und konfiguriert wird siehe nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.4-5.6:FAQ#Wie_konfiguriere_ich_auf_einer_FortiGate_unter_FortiOS_5.4_ein_.22User.2FGruppe.22_f.C3.BCr_Active_Directory.2FLDAP_Authentifizierung.3F]]
| |
|
| |
| Wenn dem User ermöglicht werden soll ein Passwort Renewal durchzuführen muss ein "Regular Bind" konfiguriert werden sowie der Administrator für "Regular Bind" muss über "read-write" Rechte im Active Directory/LDAP Verzeichnis verfügen. Wenn diese Voraussetzung gegeben ist, kann die entsprechende Funktion innerhalb des Active Directory/LDAP Server Konfiguration aktiviert werden:
| |
|
| |
| # config user ldap
| |
| # edit [Name des entsprechendne LDAP Servers]
| |
| # set password-expiry-warning [enable | disable]
| |
| # set password-renewal [enable | disable]
| |
| # end
| |
|
| |
| === Wie kann ich unter FortiOS 5.4 für ein SSL-VPN Portal/Tunnel Mode ein Host Check konfigurieren? ===
| |
|
| |
| Mit einem SSL-VPN Portal/Tunnel Mode ist es möglich einen sogenannten Host Check auszuführen dh. wenn der User zB über den Browser die SSL-VPN Seite für das Portal öffnet, wird im Hintergrund ein sogenannter Host Check ausgeführt. Dieser Host Check überprüft im Hintergrund anhand der Client/Host Software ob ein bestimmter "Registry Eintrag" existiert. Ist dieser Host Check erfolgreich wird die entsprechende Login Seite des SSL-VPN Portal geöffnet. Dieser Host Check kann ebenfalls im gleicher Art und Weise für den Tunnel Mode benützt werden dh. Versucht sich ein User über SSL-VPN Tunnel Mode einzloggen, wird das Einloggen nur dann erlaubt wenn der Host Check erfolgreich ist. Dies erlaubt zB ob ein Zugriff über einen bestimmten Device resp. Client/Host erlaubt ist oder nicht. Ein Anwendungsbeispiel wäre zB der Zugriff über einen Device resp. Client/Host im Internet Café soll verhindert werden und der Zugriff über einen Device wie ein Geschäfts Client/Host soll erlaubt werden. Damit dieser Host Check resp. anhand "Registry Check" im SSL-VPN Portal/Tunnel Mode angewendet werden kann, muss die SSL-VPN Client/Host Software dh. FortiClient auf dem Client/Host installiert werden. Ist dies nicht der Fall wird der Zugriff verhindert. Der Grund ist der Folgende: Um den Host Check durchzuführen anhand eines "Registry Eintrages" anzuwenden muss anhand einer lokalen Software dh. FortiClient dies überprüft werden. Da die FortiClient Software als Administrator installiert werden muss, sind die Voraussetzungen gegeben um den entsprechenden Host Check auszuführen resp. den Zugriff auf den Registry Eintrag zu ermöglichen! Ausgehend davon, dass ein SSL-VPN Portal/Tunnel Mode korrekt konfiguriert und getestet wurde kann diese Konfiguration für einen Host Check erweitert werden. Wie eine SSL-VPN Portal/Tunnel Mode Konfiguration durchgeführt wird siehe nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.4-5.6:FAQ#Wie_kann_ich_unter_FortiOS_5.4_ein_SSL-VPN_f.C3.BCr_Portal.2FTunnel_Mode_auf_einer_FortiGate_konfigurieren.3F]]
| |
|
| |
| Erstelle einen entsprechenden Host Check resp. Registry Eintrag verweis auf der CLI anhand folgender Befehle:
| |
|
| |
| # config vpn ssl web host-check-software
| |
| # edit [Vergebe einen Namen für den Host Check]
| |
| # config check-item-list
| |
| # edit [Gebe einen entsprechenden Integer an zB "1"]
| |
| # set target [Gebe den entsprechenden Registry Key an zB "HKLM\\SOFTWARE\\Something\\Example"]
| |
| # set type registry
| |
| # next
| |
| # end
| |
| # next
| |
| # end
| |
|
| |
| Binde den Host Check in das entsprechende SSL-VPN Portal/Tunnel Mode Profile:
| |
|
| |
| # config vpn ssl web portal
| |
| # edit [Name des entsprechenden Portal/Tunnel Mode]
| |
| # set host-check custom
| |
| # set host-check-policy [Name des Host Check Eintrage für "host-check-software"]
| |
| # next
| |
| # end
| |
|
| |
| Die Konfiguration ist abgeschlossen und kann getestet werden. Wenn ein Client/Host versucht im entsprechenden SSL-VPN Portal/Tunnel Mode für das ein Host Check konfiguriert wurde zu zugreifen und der entsprechende Registry Eintrag des Host Check existiert nicht oder der Client/Host verfügt nicht über die Client/Host Software dh. FortiClient wird folgendes angezeigt:
| |
|
| |
| '''SSL-VPN Tunnel Mode Host Check nicht erfolgreich!'''
| |
|
| |
| [[Datei:Fortinet-1371.jpg]]
| |
|
| |
| '''SSL-VPN Portal Mode Host Check nicht erfolgreich!'''
| |
|
| |
| [[Datei:Fortinet-1372.jpg]]
| |
|
| |
| '''Keine Client/Host Software dh. FortiClient vorhanden!'''
| |
|
| |
| If you see the yellow warning bar that the hostcheck ActiveX control is not installed or need permission to run, please click on it
| |
| to install or run it. Alternatively, if you do not want to install or run the ActiveX control, the host checking function can be
| |
| performed by a Java applet.
| |
|
| |
| === Wie kann ich unter FortiOS 5.4 für ein SSL-VPN Portal Mode ein Custome Language File konfigurieren? ===
| |
|
| |
| Auf einem FortiOS werden grundsätzlich keine anderen Sprachen im Mgmt. Web Interface ermöglicht ausser:
| |
|
| |
| [English | French | Spanish | Portuguese | Japanese | Tradional Chinese | Simplified Chinese | Korean]
| |
|
| |
| Diese Konfiguration der Sprachen setzt die entsprechende Sprache auf dem Mgmt. Web Interface sowie die Replacement Messages dh. ebenso das SSL-VPN Portal. Die entsprechende Sprache kann über folgende Position konfiguriert werden:
| |
|
| |
| System > Settings > Language > [English | French | Spanish | Portuguese | Japanese | Tradional Chinese | Simplified Chinese | Korean]
| |
|
| |
| Ab FortiOS 5.2 ist es zusätzlich möglich für ein SSL-VPN Portal ein Custome Language File selber zu erstellen. Dafür muss die entsprechende Funktion resp. Feature über CLI aktiviert werden:
| |
|
| |
| # config system global
| |
| # set gui-custom-language [enable | disable]
| |
| # end
| |
|
| |
| Wird dieses Feature aktiviert so steht eine neue Menüposotion zur Verfügung:
| |
|
| |
| System > Custome Languages
| |
|
| |
| [[Datei:Fortinet-2022.jpg]]
| |
|
| |
| Unter der Position "View/Download Sample Language Template" kann ein Beispiel eines Custome Language File runtergeladen werden. Dieses kann als Vorlage dienen um ein entsprechendes Sprachefile für ein SSL-VPN Portal zu erstellen. Nachfolgend ein Beispiel dieses "Sample Language Template":
| |
|
| |
| [[Datei:sample-language-template-54.txt]]
| |
|
| |
| Nachdem das entsprechende Sprachefile erstellt wurde, kann dieses über die "Custome Language" Menüposition wieder hochgeladen werden. Vergebe dazu einen Namen sowie eine Beschreibung:
| |
|
| |
| [[Datei:Fortinet-2023.jpg]]
| |
|
| |
| Nachträglich kann das entsprechende Sprachfile in einem SSL-VPN Portal Profile definiert werden:
| |
|
| |
| VPN > SSL VPN Portals > [Wähle das entsprechende SSL-VPN Portal Profile] > Language
| |
|
| |
| [[Datei:Fortinet-2024.jpg]]
| |
|
| |
| Das Sprachefile kann ebenfalls benutzt werden für "SSL VPN Personal Bookmarks" Funktion. Das entsprechende Sprachefile für diese Funktion "SSL VPN Personal Bookmarks" kann nur über CLI konfiguriert werden:
| |
|
| |
| # config vpn ssl web user-bookmark
| |
| # edit [Wähle einen entsprechenden Namen für die Bookmarks]
| |
| # set custom-lang [Wähle das entsprechende Sprachfile]
| |
| # end
| |
| # end
| |
|
| |
| Die Funktion "SSL VPN Personal Bookmarks" steht nicht per Standard über das Mgmt. Web Interface einer FortiGate zur Verfügung. Wie dieses Feature aktiviert wird siehe nachfolgenden Artikel:
| |
|
| |
| [[FortiGate-5.4-5.6:FAQ#Wie_kann_ich_unter_FortiOS_5.4_ein_SSL-VPN_f.C3.BCr_Portal.2FTunnel_Mode_auf_einer_FortiGate_konfigurieren.3F]]
| |
|
| |
| === Wie kann ich unter FortiOS 5.4 für ein SSL-VPN Portal/Tunnel Mode ein Windows OS Check konfigurieren? ===
| |
|
| |
| Mit einem SSL-VPN Portal/Tunnel Mode ist es möglich einen sogenannten Windows OS Check auszuführen dh. wenn der User zB über den Browser die SSL-VPN Seite für das Portal öffnet, wird im Hintergrund ein sogenannter Windows OS Check ausgeführt. Dieser Windows OS Check überprüft im Hintergrund anhand der Client/Host Software ob ein bestimmtes OS installiert ist und über einen bestimmten Patch Level verfügt. Beim Patch Level wird konfiguriert über welchen Patch Level er im Minimum verfügt! Ist dieser Windows OS Check erfolgreich wird die entsprechende Login Seite des SSL-VPN Portal geöffnet. Dieser Windows OS Check kann ebenfalls im gleicher Art und Weise für den Tunnel Mode benützt werden dh. Versucht sich ein User über SSL-VPN Tunnel Mode einzloggen, wird das Einloggen nur dann erlaubt wenn der Windows OS Check erfolgreich ist. Dies erlaubt zB ob ein Zugriff über einen bestimmten Device resp. Client/Host der über einen bestimmten Patch Level verfügt erlaubt ist oder nicht. Damit dieser Windows OS Check im SSL-VPN Portal/Tunnel Mode angewendet werden kann, muss die SSL-VPN Client/Host Software dh. FortiClient auf dem Client/Host installiert werden. Ist dies nicht der Fall wird der Zugriff verhindert. Der Grund ist der Folgende: Um den Windows OS Check durchzuführen mit dem entsprechenden Patch Level, muss anhand einer lokalen Software dh. FortiClient dies überprüft werden. Da die FortiClient Software als Administrator installiert werden muss, sind die Voraussetzungen gegeben um den entsprechenden Windows OS Check mit entsprechenden Patch Level auszuführen! Ausgehend davon, dass ein SSL-VPN Portal/Tunnel Mode korrekt konfiguriert und getestet wurde kann diese Konfiguration für einen Windows OS Check erweitert werden. Wie eine SSL-VPN Portal/Tunnel Mode Konfiguration durchgeführt wird siehe nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.4-5.6:FAQ#Wie_kann_ich_unter_FortiOS_5.4_ein_SSL-VPN_f.C3.BCr_Portal.2FTunnel_Mode_auf_einer_FortiGate_konfigurieren.3F]]
| |
|
| |
| Die Funktion des Windows OS Check muss im entsprechenden SSL-VPN Portal/Tunnel Mode Profile direkt konfiguriert werden:
| |
|
| |
| # config vpn ssl web portal
| |
| # edit [Name des entsprechenden Portals im Web Mode/Tunnel Mode]
| |
| # set os-check [enable | disable]
| |
| # config os-check-list [windows-7 | windows-8 | windows-8.1 | windows-2000 | windows-vista | windows-xp]
| |
| # set action [check-up-to-date | deny | allow]
| |
| # set latest-patch-level [1 - 255]
| |
| # set tolerance 1
| |
| # end
| |
| # end
| |
|
| |
| Wird die "action" auf "allow" gesetzt muss kein entsprechender Patch Level definiert werden da nur kontrolliert wird ob der Client/Host über das definierte "OS" verfügt. Möchte man einen minimum Patch Level konfigurieren, muss die Option "check-up-to-date" gesetzt werden! Wird "check-up-to-date" gesetzt, wird mit dem entsprechenden "latest-patch-level" der minimum Patch Level definiert. Somit steht die Definition "tolerance" im direkten Zusammenhang mit "latest-patch-level". Dies bedeutet: die "tolerance" definiert -1 für die Definition "latest-patch-level". Die Option kann differnziert angewendet werden dh. möchte man zB "windows-7" im "latest-patch-level" mit einer "tolerance 1" erlauben jedoch "windows-xp" nicht, würde man folgendes konfigurieren:
| |
|
| |
| # config vpn ssl web portal
| |
| # edit [Name des entsprechenden Portals im Web Mode/Tunnel Mode]
| |
| # set os-check enable
| |
| # config os-check-list windows-7
| |
| # set action check-up-to-date
| |
| # set latest-patch-level 2
| |
| # set tolerance 1
| |
| # end
| |
| # config os-check-list windows-xp
| |
| # set action deny
| |
| # end
| |
| # end
| |
|
| |
| === Wie kann ich unter FortiOS 5.4 für SSL-VPN Funktion für den SSL-VPN Deamon/Service einen Restart ausführen? ===
| |
|
| |
| Die normale Vorgehensweise auf einem FortiOS einen Deamon/Service neu zu starten ist über das Kommando "diagnose test application". Jedoch steht für die SSL-VPN Funktion kein entsprechender Befehl zur Verfügung. Eine nicht offizielle Variante ist den SSL-VPN Deamon/Service über dessen PID (Process ID) und anhand des "kill" Befehls neu zu starten. Damit dies durchgeführt werden kann, muss zuerst die PID (Prozess ID) eruiert werden:
| |
|
| |
| # diagnose sys top 5 20
| |
|
| |
| In der Liste die ausgegeben wird, werden alle Deamons/Service aufgelistet mit deren PID. Dabei ist unter normalen Umständen der Deamon/Service für SSL-VPN auch enthalten mit dem Namen "sslvpnd". Die zweite Spalte der List gibt die PID an. Folgendes Beispiel:
| |
|
| |
| sslvpnd 76 S 0.0 1.2
| |
|
| |
| Eine andere Variante die Prozess ID (PID) zu eruieren ist über den folgenden Befehl:
| |
|
| |
| # fnsysctl ls -l /var/run/
| |
|
| |
| Auch hier wird eine Liste ausgegeben mit allen Deamon/Services die auf dem System existieren. Im Gegesatz zu "diagnose sys top" werden jedoch Files aufgelistet der Deamon/Services und in diesen Files sind die jeweiligen PID der Deamon/Services enthalten. Unser Deamon/Service File hat den Namen:
| |
|
| |
| sslvpnd.pid
| |
|
| |
| Um nun das entsprechende File des Deamon/Service auszulesen um die PID zu erhalten führe folgendes aus:
| |
|
| |
| # fnsysctl more /var/run/sslvpnd.pid
| |
| 76
| |
|
| |
| Nun kann der SSL-VPN Deamon/Service neu gestartet werden anhand des "kill" Befehls sowie dem entsprechenden "kill level":
| |
|
| |
| # diagnose sys kill [Kill Level/Sequenz 1 - 32 wobei 11 den Prozess Stoppt und neu Startet] [PID des Prozesses zB. "76"]
| |
|
| |
| Um einen erfolgreichen Neustart des Deamons/Service zu bestätigen kann wiederum die PID eruiert werden und diese trägt bei einem Neustart nun eine neue PID Nummer:
| |
|
| |
| # fnsysctl more /var/run/sslvpnd.pid
| |
| 7101
| |
|
| |
| === Gibt es unter FortiOS 5.4 für ein SSL-VPN Portal/Tunnel Mode die Möglichkeit dem Deamon/Service mehr Resourcen zu zuweisen? ===
| |
|
| |
| Wenn ein SSL-VPN Portal/Tunnel Mode auf einer FortiGate als Deamon/Service (sslvpnd) den Usern zur Verfügung gestellt wird, kann diessem Deamon/Service mehr Resourcen zugewiesen werden. Dies ist jedoch nur möglich auf grösseren FortiGate Devices resp. FortiGate Devices die über mehrer CPU's verfügen. Mehr Resourcen werden zur Verfügung gestellt, in dem die "worker" Anzahl erhöht wird dh. damit stehen mehr "worker" innerhalb des Deamons/Services für SSL-VPN zur Verfügung. Dies benötigt jedoch im Hintergrund ebenfalls mehr CPU Resourcen sowie Memory. Die "worker" Anzahl kann nicht nur erhöht werden sondern auch limitiert. Die dazu zur Verfügung stehenden Kommandos sind die Folgenden:
| |
|
| |
| # config system global
| |
| # set ssl-worker-count [Anzahl "worker" Anzahl 0 - 4294967295; Standard 0]
| |
| # set sslvpn-max-workercount [Maximum Anzahl "worker" Prozesse für SSL-VPN; Standard 39]
| |
|
| |
| In diesem Zusammenhang stehen ebenfalls folgende zwei Optionen zur Verfügung, die für die Beschleuningung im SSL-VPN zuständig sind dh. durch die Aktivierung der zwei folgenden Optionen wird eine Hardware Beschleunigung über den Content Prozessor durchgeführt für "kpx" sowie "cipher". Dies bedeutet: Ueber den Content Prozessor wird die Verschlüsselung/Entschlüsselung des SSL-VPN Traffics durchgeführt:
| |
|
| |
| # config system global
| |
| # sslvpn-kxp-hardwareacceleration [enable | disable]
| |
| # sslvpn-cipherhardware-acceleration [enable | disable]
| |
| # end
| |
|
| |
| === Gibt es unter FortiOS 5.4 für ein SSL-VPN Portal/Tunnel Mode eine Statistik betreffend Resourcen? ===
| |
|
| |
| Eine SSL-VPN Portal/Tunnel Statistik betreffend Resourcen kann über CLI anhand folgenden Befehls aufgelistet werden:
| |
|
| |
| # diagnose vpn ssl statistics
| |
| SSLVPN statistics (root):
| |
| ------------------
| |
| Memory unit: 1
| |
| System total memory: 1928445952
| |
| System free memory: 1473814528
| |
| SSLVPN memory margin: 314572800
| |
| SSLVPN state: normal
| |
|
| |
| Max number of users: 0
| |
| Max number of tunnels: 0
| |
| Max number of connections: 0
| |
|
| |
| Current number of users: 0
| |
| Current number of tunnels: 0
| |
| Current number of connections: 0
| |
|
| |
| Bei dieser Statistik ist folgendes zu berücksichtigen: Wenn der "SSLVPN state" von "normal" auf "busy" wechselt, geht/befindet sich der SSL-VPN Deamon/Service im Conserve Mode. Oft ist der "busy" Status zurückzuführen auf zuwenig Memory resp. Resourcen. Wenn der SSL-VPN Deamon im Conserve Mode ist, heisst dies nicht das sich die FortiGate im Conserve Mode befindet! Die Ursache wieso der SSL-VPN Deamon/Service sich im Conserve Mode befindet sollte untersucht werden da dies geschieht um nicht die ganze FortiGate zu beeinträchtigen. Somit ist der Conserve Mode des SSL-VPN Deamons nicht gleich Conserve Mode des FortiOS!
| |
|
| |
| === Wie kann ich unter FortiOS 5.4 ein SSL-VPN für Portal/Tunnel Mode betreffend Security Absichern? ===
| |
|
| |
| Wenn man ein SSL-VPN für Portal/Tunnel Mode konfiguriert sind nachfolgende Einstellungen relevant betreffend der benutzten SSL/TLS Versionen sowie den
| |
| benützten "ciphers":
| |
|
| |
| • sslv3 : enable
| |
| • tlsv1-0 : enable
| |
| • tlsv1-1 : enable
| |
| • tlsv1-2 : enable
| |
| • algorithm : default
| |
| • banned-cipher :
| |
|
| |
| Diese Einstellungen wie hier aufgeführt sind die standard Einstellungen betreffend den benützten SSL sowie TLS Versionen. Unter FortiOS 5.4 im Gegensatz zu FortiOS 5.2 ist die SSLv2 per Standard nicht vorhanden dh. deaktiviert und steht nicht mehr zur Verfügung. Wenn die Option "algorithm" auf "default" konfiguriert wird, sind unsichere "ciphers" wie zB DES, RC4 erlaubt. Neu dazugekommen ist die Option "banned-cipher" anhand dieser unsichere "ciphers" oder bestimmte "ciphers" ausgeschlossen werden können. Dazu gehören folgende "ciphers":
| |
|
| |
| RSA Ban the use of cipher suites using RSA key.
| |
| DH Ban the use of cipher suites using DH.
| |
| DHE Ban the use of cipher suites using authenticated ephemeral DH key agreement.
| |
| ECDH Ban the use of cipher suites using ECDH key exchange.
| |
| ECDHE Ban the use of cipher suites using authenticated ephemeral ECDH key agreement.
| |
| DSS Ban the use of cipher suites using DSS authentication.
| |
| ECDSA Ban the use of cipher suites using ECDSA authentication.
| |
| AES Ban the use of cipher suites using either 128 or 256 bit AES.
| |
| AESGCM Ban the use of cipher suites AES in Galois Counter Mode (GCM).
| |
| CAMELLIA Ban the use of cipher suites using either 128 or 256 bit CAMELLIA.
| |
| 3DES Ban the use of cipher suites using triple DES
| |
| SHA1 Ban the use of cipher suites using SHA1.
| |
| SHA256 Ban the use of cipher suites using SHA256.
| |
| SHA384 Ban the use of cipher suites using SHA384.
| |
|
| |
| Somit wird die Option "algorithm default" konfiguriert kann anhand "banned-cipher" bestimmte "ciphers" ausgeschlossen werden. Dies sollte jedoch nicht als Ansatz gewählt werden um ein SSL-VPN im Port/Tunnel Mode betreffend Sicherheit abzusichern. Die empfohlene Methode ist "algorithm high" zu setzen damit automatisch alle unsicheren "ciphers" ausgeschlossen werden. Nachfolgend ein Beispiel wie dies anhand eine Tools über ein Linux überprüft werden kann:
| |
|
| |
| • Gehe auf folgenden Link
| |
|
| |
| https://github.com/jvehent/cipherscan
| |
|
| |
| Erstelle auf einem Linux ein File "cipherscan" und fülle es mit dem Inhalt der Datei "cipherscan" ab:
| |
|
| |
| # mkdir /opt/scripts
| |
| # vi /opt/scripts/cipherscan
| |
| # chown root:root /opt/scripts/cipherscan
| |
| # chmod 700 /opt/scripts/cipherscan
| |
|
| |
| Nachfolgend der Inhalt des Files "cipherscan" der über den angegegebenen Link runtergeladen werden kann:
| |
|
| |
| [[Datei:Cipherscan.txt]]
| |
|
| |
| • Eine weitere Möglichkeit den momentanen Status betreffend SSL/TLS Versionen sowie den "ciphers" zu eruieren
| |
| ist ein entsprechender Scan der zB. über folgenden öffentlichen Link zur Verfügung gestellt wird:
| |
|
| |
| https://www.ssllabs.com/ssltest/
| |
|
| |
| Nun muss anhand des Tools "cipherscan" oder über den öffentlichen Link ein Scan ausgeführt werden auf die IPv4 Adressse resp. Interface auf dem das SSL-VPN Portal/TUnnel Mode konfiguriert wurde. Im nachfolgenden Beispiel wurde das SSL-VPN Portal/Tunnel Mode auf dem LAN Interface konfiguriert mit der IPv4 Adresse 198.18.0.1:
| |
|
| |
| # /opt/scripts/cipherscan 198.18.0.1:443
| |
| custom openssl not executable, falling back to system one from /bin/openssl
| |
| ...............................
| |
| Target: 198.18.0.1:443
| |
|
| |
| prio ciphersuite protocols pfs curves
| |
| 1 ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 ECDH,prime256v1,256bits prime256v1
| |
| 2 ECDHE-RSA-AES256-SHA384 TLSv1.2 ECDH,prime256v1,256bits prime256v1
| |
| 3 ECDHE-RSA-AES256-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2 ECDH,prime256v1,256bits prime256v1
| |
| 4 DHE-RSA-AES256-GCM-SHA384 TLSv1.2 DH,2048bits None
| |
| 5 DHE-RSA-AES256-SHA256 TLSv1.2 DH,2048bits None
| |
| 6 DHE-RSA-AES256-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2 DH,2048bits None
| |
| 7 DHE-RSA-CAMELLIA256-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2 DH,2048bits None
| |
| 8 AES256-GCM-SHA384 TLSv1.2 None None
| |
| 9 AES256-SHA256 TLSv1.2 None None
| |
| 10 AES256-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2 None None
| |
| 11 CAMELLIA256-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2 None None
| |
| 12 ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 ECDH,prime256v1,256bits prime256v1
| |
| 13 ECDHE-RSA-AES128-SHA256 TLSv1.2 ECDH,prime256v1,256bits prime256v1
| |
| 14 ECDHE-RSA-AES128-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2 ECDH,prime256v1,256bits prime256v1
| |
| 15 DHE-RSA-AES128-GCM-SHA256 TLSv1.2 DH,2048bits None
| |
| 16 DHE-RSA-AES128-SHA256 TLSv1.2 DH,2048bits None
| |
| 17 DHE-RSA-AES128-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2 DH,2048bits None
| |
| 18 DHE-RSA-CAMELLIA128-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2 DH,2048bits None
| |
| 19 AES128-GCM-SHA256 TLSv1.2 None None
| |
| 20 AES128-SHA256 TLSv1.2 None None
| |
| 21 AES128-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2 None None
| |
| 22 CAMELLIA128-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2 None None
| |
| 23 DHE-RSA-SEED-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2 DH,2048bits None
| |
| 24 SEED-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2 None None
| |
| 25 ECDHE-RSA-RC4-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2 ECDH,prime256v1,256bits prime256v1
| |
| 26 RC4-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2 None None
| |
| 27 RC4-MD5 SSLv3,TLSv1,TLSv1.1,TLSv1.2 None None
| |
| 28 ECDHE-RSA-DES-CBC3-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2 ECDH,prime256v1,256bits prime256v1
| |
| 29 EDH-RSA-DES-CBC3-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2 DH,2048bits None
| |
| 30 DES-CBC3-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2 None None
| |
|
| |
| Certificate: UNTRUSTED, 2048 bit, sha1WithRSAEncryption signature
| |
| TLS ticket lifetime hint: 300
| |
| OCSP stapling: not supported
| |
| Cipher ordering: server
| |
|
| |
| Bei diesem "output" sieht man welche "ciphers" erlaubt werden wie zB "RC4" das als unsicher gilt. Ebenso sieht man welche TLS/SSL Versionen aktiviert sind resp. zur Verfügung stehen. Nun kann anhand der zu Beginn aufgeführten Optionen die verschiedenen TSL/SSL Versionen deaktiviert werden sowie um unsicher "ciphers" auszuschliesschen die Option "algorith high" konfiguriert werden:
| |
|
| |
| # config vpn ssl settings
| |
| # set sslv3 disable
| |
| # set tlsv1-0 disable
| |
| # set tlsv1-1 disable
| |
| # set algorithm high
| |
| # unset banned-cipher
| |
| # end
| |
|
| |
| Wenn die zur Verfügung stehenden TLS/SSL Versionen deaktiviert werden ist folgendes zu berücksichtigen: Die Kompatibilität betreffend dem Zugriff wird eingeschränkt dh. Wenn ein User im Browser die entsprechenden TLS Versionen nicht aktiviert hat und nur SSLv3 zur Verfügung steht, ist der Zugriff nicht mehr erlaubt wenn SSLv3 deaktiviert wurde. Nach der Konfiguration sollte abermals ein Scan ausgeführt werden um die neue Konfiguration zu überprüfen:
| |
|
| |
| # /opt/scripts/cipherscan 198.18.0.1:443
| |
| custom openssl not executable, falling back to system one from /bin/openssl
| |
| ..........................
| |
| Target: 198.18.0.1:443
| |
|
| |
| prio ciphersuite protocols pfs curves
| |
| 1 ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 ECDH,secp384r1,384bits secp384r1
| |
| 2 ECDHE-RSA-AES256-SHA384 TLSv1.2 ECDH,secp384r1,384bits secp384r1
| |
| 3 ECDHE-RSA-AES256-SHA TLSv1.2 ECDH,secp384r1,384bits secp384r1
| |
| 4 DHE-RSA-AES256-GCM-SHA384 TLSv1.2 DH,2048bits None
| |
| 5 DHE-RSA-AES256-SHA256 TLSv1.2 DH,2048bits None
| |
| 6 DHE-RSA-AES256-SHA TLSv1.2 DH,2048bits None
| |
| 7 DHE-RSA-CAMELLIA256-SHA TLSv1.2 DH,2048bits None
| |
| 8 AES256-GCM-SHA384 TLSv1.2 None None
| |
| 9 AES256-SHA256 TLSv1.2 None None
| |
| 10 AES256-SHA TLSv1.2 None None
| |
| 11 CAMELLIA256-SHA TLSv1.2 None None
| |
| 12 ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 ECDH,secp384r1,384bits secp384r1
| |
| 13 ECDHE-RSA-AES128-SHA256 TLSv1.2 ECDH,secp384r1,384bits secp384r1
| |
| 14 ECDHE-RSA-AES128-SHA TLSv1.2 ECDH,secp384r1,384bits secp384r1
| |
| 15 DHE-RSA-AES128-GCM-SHA256 TLSv1.2 DH,2048bits None
| |
| 16 DHE-RSA-AES128-SHA256 TLSv1.2 DH,2048bits None
| |
| 17 DHE-RSA-AES128-SHA TLSv1.2 DH,2048bits None
| |
| 18 DHE-RSA-CAMELLIA128-SHA TLSv1.2 DH,2048bits None
| |
| 19 AES128-GCM-SHA256 TLSv1.2 None None
| |
| 20 AES128-SHA256 TLSv1.2 None None
| |
| 21 AES128-SHA TLSv1.2 None None
| |
| 22 CAMELLIA128-SHA TLSv1.2 None None
| |
| 23 ECDHE-RSA-DES-CBC3-SHA TLSv1.2 ECDH,secp384r1,384bits secp384r1
| |
| 24 EDH-RSA-DES-CBC3-SHA TLSv1.2 DH,2048bits None
| |
| 25 DES-CBC3-SHA TLSv1.2 None None
| |
|
| |
| Certificate: UNTRUSTED, 2048 bit, sha1WithRSAEncryption signature
| |
| TLS ticket lifetime hint: 300
| |
| OCSP stapling: not supported
| |
| Cipher ordering: server
| |
|
| |
| Die entsprechenden SSLv3 steht nun nicht mehr zur Verfügung sowie die TSL Version 1.0 sowie 1.1. Unsicher "ciphers" wurden ebenfalls entfernt. Anhand der Option "banned-cipher" kann nun weiter eingeschränkt werden wie zB:
| |
|
| |
| # set banned-cipher DH
| |
|
| |
| Wird dies durchgeführt wird DH (Diffie Hellman) ausgeschlossen und nur ECDH (Elliptic Curve Diffie Hellman) erlaubt. Dabei handelt es sich obwohl diese über eine kleinere "bits" Anzahl verfügt um eine höhere Verschlüsselung als dh. dazu siehe auch:
| |
|
| |
| https://de.wikipedia.org/wiki/Diffie-Hellman-Schl%C3%BCsselaustausch#Elliptic_Curve_Diffie-Hellman_.28ECDH.29
| |
|
| |
| Dies sollte jedoch nur in einem kontrollierten Umfeld durchgeführt werden. DH resp. Diffie Hellman benützt unter FortiOS 5.4 im Gegensatz zu FortiOS 5.2 die Bit Anzahl "2048". Möchte man diese Bit Anzahl für DH anpassen kann folgendes durchgeführt werden:
| |
|
| |
| # config firewall ssl settings
| |
| # set ssl-dh-bits [768 | 1024 | 1536 | 2048]
| |
| # end
| |
|
| |
| Um zu bestätigen, dass die unsicheren "cipher" wie zB "RC4" nicht mehr zur Verfügung stehen kann anhand "openssl" das auf jedem Linux System vorhanden ist folgender Test mit dem Client Teil ausgeführt werden:
| |
|
| |
| # openssl s_client -connect 198.18.0.1:443 -cipher "RC4"
| |
| CONNECTED(00000003)
| |
| 140687385839520:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert '''handshake failure''':s23_clnt.c:744:
| |
| ---
| |
| no peer certificate available
| |
| ---
| |
| No client certificate CA names sent
| |
| ---
| |
| SSL handshake has read 7 bytes and written 73 bytes
| |
| ---
| |
| '''New, (NONE), Cipher is (NONE)'''
| |
| Secure Renegotiation IS NOT supported
| |
| Compression: NONE
| |
| Expansion: NONE
| |
| ---
| |
|
| |
| Eine andere Variante dh. alle "RC4" "ciphers" zu durchsuchen und festzustellen ob anhand diesen eine Verbindung zustande kommt wäre folgender Befehl der auf den meisten Linux Distributionen funktionieren sollte:
| |
|
| |
| # for i in `openssl ciphers -v 'RC4' | awk '{print $1}'`; do echo -ne "$i\t" ; echo | openssl s_client -connect [FQDN des Hosts oder IPv4]:443 -cipher "$i" 2>&1 | grep New; done
| |
| ECDHE-RSA-RC4-SHA New, (NONE), Cipher is (NONE)
| |
| ECDHE-ECDSA-RC4-SHA New, (NONE), Cipher is (NONE)
| |
| AECDH-RC4-SHA New, (NONE), Cipher is (NONE)
| |
| ADH-RC4-MD5 New, (NONE), Cipher is (NONE)
| |
| ECDH-RSA-RC4-SHA New, (NONE), Cipher is (NONE)
| |
| ECDH-ECDSA-RC4-SHA New, (NONE), Cipher is (NONE)
| |
| RC4-SHA New, (NONE), Cipher is (NONE)
| |
| RC4-MD5 New, (NONE), Cipher is (NONE)
| |
|
| |
| Wie man sieht die Verbindung kommt nicht zustande dh. "handshake failure". Die relevante Position ist "New, (NONE), Cipher is (NONE)". Desweiteren wurde FortiOS 5.4.2 folgende Optionen zu den "vpn ssl settings" hinzugefügt:
| |
|
| |
| # config vpn ssl settings
| |
| # set http-request-header-timeout [1-60 Sekunden; Standard 20]
| |
| # set http-request-body timeout [1-60 Sekunden; Standard 30]
| |
| # end
| |
|
| |
| Diese zwei Optionen wurden hinzugefügt betreffend "Slowloris (CVE-2007-6750) und R-U-Dead-Yet Attacken. Die Option "http-request-header-timeout" schützt gegen "Slowloris" in dem das Maximum der Zeit definiert wird um einen HTTP Header zu lesen. Wenn eine Verbindung nicht innerhalb dieser Zeit abgeschlossen werden kann, wird die SSL-VPN Verbindung mit einem HTTP Code 408 beendet (Request Timeout). Die Option "http-request-body-timeout" schützt vor "R-U-Dead-Yet" (Are You Dead Yet) Attacken in dem das Maximum der Zeit definiert wird um einen HTTP Body zu lesen. Auch hier wird eine Verbindung beendet mit dem HTTP Code 408 (Request Timeout) wenn der HTTP Body innerhalb der definierten Zeit gelesen werden kann.
| |
|
| |
| === Wie kann ich auf einer Windows Workstation einen FortiSSLVPNclient Stoppen sowie Starten? ===
| |
|
| |
| Bei einem FortiSSLVPNclient handelt es sich um den SSL only Software Client für ein SSL-VPN Verbindung für Tunnel Mode. Diese Client Software darf nicht verwechselt werden mit der FortiClient Endpoint Security Software dh. die SSL only Funktion ist zwar im FortiClient Endpoint Security VPN-only Mode enthalten, jedoch sind die beiden Software Package grundsätzlich verschieden. Wir empfehlen Grundsätzlich die FortiClient Endpoint Security Software im VPN-only Mode einzusetzen da dieses Package über IPSec Mode und/oder SSL-VPN Mode verfügt. Diese Packages für den FortiClient Endpoint Security VPN-only Mode werden über folgenden Link zur Verfügung gestellt:
| |
|
| |
| [[FortiGate:KonfigExample#Typische_KMU_Konfiguration]]
| |
|
| |
| Beachte dabei folgendes: FortiClient Entpoint Security in der Version 5.0 kann nicht unter FortiOS 5.4 eingesetzt werden. Somit muss unter FortiOS 5.4 der FortiClient Endpoint Security in der Version 5.4 oder ab 5.2.5 eingesetzt werden. Wenn dennoch der FortiSSLVPNclient eingesetzt wird und dieser gestoppt und/oder neu gestartet werden soll, kann dies auf einer Windows Workstation in einer DoS Box durchgeführt werden:
| |
|
| |
| > FortiSSLVPNclient.exe [connect | disconnect]
| |
|
| |
| Für "FortiSSLVPNclient.exe" stehen zusätzliche folgende Optionen zur Verfügung:
| |
|
| |
| [[Datei:Fortinet-1596.jpg]]
| |
|
| |
| Wurde der FortiClient Endpoint Security VPN-only Mode installiert und man möchte verhindert das dieser automatisch startet siehe nachfolgenden Artikel:
| |
|
| |
| [[FortiClient:FAQ#Wie_kann_ich_verhindern_das_der_FortiClient_Endpoint_Security_auf_einer_Workstation_einen_automatischen_Start_ausf.C3.BChrt.3F]]
| |
|
| |
| === Wie kann ich unter FortiOS 5.4 für ein SSL-VPN für Portal/Tunnel Mode ein Troubleshooting/Debug ausführen? ===
| |
|
| |
| Wenn es bei einer SSL-VPN Konfiguration zu Problemen kommt und ein Troubleshooting resp. Debug muss durchgeführt werden kann dies folgendermassen ausgeführt werden:
| |
|
| |
| '''• <big>Ueberprüft werden ob die entsprechende IPv4 Adresse resp. der entsprechende SSL-VPN Port erreichbar ist (SYN/ACK):</big>'''
| |
|
| |
| # diagnose sniffer packet any "port [Gebe den entsprechenden Port an zB 443]" 4
| |
|
| |
| Um diesen Traffic resp. Flow genauer einzusehen kann ebenfalls folgendes ausgeführt werden:
| |
|
| |
| # diagnose debug disable
| |
| # diagnose debug reset
| |
| # diagnose debug flow trace stop
| |
| # diagnose debug flow filter clear
| |
| # diagnose debug flow filter port [Gebe den entsprechenden Port an zB "443"]
| |
| # diagnose debug flow filter daddr [Gebe die entsprechende Public IPv4 Adresse an zB "193.193.135.71"]
| |
| # diagnose debug flow show console enable
| |
| # diagnose debug flow show function-name enable
| |
| # diagnose debug flow trace start 10
| |
| # diagnose debug enable
| |
| # diagnose debug flow trace start
| |
|
| |
| '''• <big>Ueberprüfe die SSL-VPN Funktion selber inkl. der Authentifizierung:</big>'''
| |
|
| |
| 1. Konfiguriere "putty" für logging dh. alle Informationen werden in ein Log aufgezeichnet (Category > Session > Logging > All session output)
| |
| 2. Erstelle eine SSH Verbindung zur FortiGate.
| |
| 3. Führe ein Login durch und gebe folgendes ein:
| |
|
| |
| '''Setze alle Debug Filter zurück'''
| |
|
| |
| # diagnose debug reset
| |
|
| |
| '''Aktiviere für den debug "output" den "timestamp"'''
| |
|
| |
| # diagnose debug console timestamp enable
| |
|
| |
| '''Setze die verschiedenen Debug Filter für Two-Factor Authentication'''
| |
|
| |
| # diagnose debub application fnbamd -1
| |
| # diagnose debub application authd -1
| |
| # diagnose debub application sslvpn -1
| |
|
| |
| '''Aktiviere den Debug Modus mit dem gesetzen Debug Filter'''
| |
|
| |
| # diagnose debug enable
| |
|
| |
| Nach erfolgreichen Debug deaktiviere diesen wiederum und lösche die Filter:
| |
|
| |
| '''Dektiviere den Debug Modus mit dem gesetzen Debug Filter'''
| |
|
| |
| # diagnose debug disable
| |
|
| |
| '''Setze alle Debug Filter zurück'''
| |
|
| |
| # diagnose debug reset
| |
|
| |
| == IPSec / VPN ==
| |
|
| |
| === Wird unter FortiOS 5.4 für ein IPSec VPN auf einem FortiGate Device ein "Offloading" durchgeführt? ===
| |
|
| |
| Unter FortiOS 5.4 wird automatisch ein "Offloading" für IPSec VPN durchgeführt. Dabei ist zu beachten: Ein "Offloading" wird für "Diffie-Hellman Key" Austausch sowie für den "ESP Traffic" durchgeführt. Neu kann dieses "Offloading" im IPSec VPN Bereich auch deaktiviert werden:
| |
|
| |
| # config system global
| |
| # set ipsec-asic-offload [enable | disable]
| |
| # end
| |
|
| |
| Per Standard ist das "Offloading" aktiviert. Unter gewissen Umständen zB wenn ein "debug" durchgeführt wird ist es ratsam dieses "Offloading" vorübergehend zu daektivieren. Wenn ein IPSec VPN durch eine FortiGate konfiguriert wird dh. wenn dieses nicht terminiert wird auf der FortiGate dh. kein "unencrypt" durchgeführt wird, und sofern der FortiGate Device über einen NP6 Prozessor verfügt, wird ein "Offloading" für diesen Traffic des IPSec VPN's über den NP6 Prozessor durchgeführt.
| |
|
| |
| === Was sind die Unterschiede/Grundlagen eines IPSec Site2Site VPN Tunnels im "Main Mode" und "Aggressive Mode"? ===
| |
|
| |
| Wenn ein IPSec Site2Site VPN Tunnel sei es im "Main Mode" oder "Aggressive Mode" konfiguriert und später anhand eines Troubleshooting untersucht werden muessen, ist es Wichtig zu wissen wie ein IPSec Site2Site VPN Tunnel funktioniert in der Phase-1/2 um festzustellen in welchem Schritt der Aufbaus ein IPSec Site2Site VPN fehlschlägt. Bei der Wahl des Modes ist dabei folgendes festzuhalten: Eine Site2Site VPN Konfiguration sollte sofern möglich im "Main Mode" konfiguriert werden. Nur in Ausnahmefällen dh. zB für Fremdhersteller sollte der "Aggressive Mode" gewählt werden dh. wenn diese ein "Aggressive Mode" voraussetzen! Im Grundsatz für ein "Main Mode" oder "Aggressive Mode" wird ein Site2Site VPN Tunnel in 4 Schritten aufgebaut:
| |
|
| |
| Schritt 1: Ein Site2Site IPSec Tunnel wird dann aufgebaut, wenn lokaler Traffic initiert wird um eine Destination der Remote Seite zu erreichen!
| |
| Dadurch wird ein IPSec Site2Site VPN Tunnel aufgebaut um den Traffic durch den IPSec Site2Site VPN Tunnel (encrypted und encapsulated)
| |
| zur Remote Seite senden zu können!
| |
|
| |
| Schritt 2: In der Phase-1 wird eine einzelne IKE SA ausgetauscht. Dies stellt die "Security Association" dar!
| |
|
| |
| Schritt 3: In der Phase-2 werden zwei IKE SA ausgetauscht dh. der "Security Association" und zwar für jede Richtung des Traffics dh. in/out!
| |
|
| |
| Schritt 4: Traffic wird über den etablierten IPSec Tunnel gesendet (in/out)!
| |
|
| |
| Diese 4 Schritte stellen eine Grobübersicht dar des Aufbaus eines Site2Site VPN Tunnels. Somit ist in einem Troubleshooting Wichtig zu wissen, welcher Schritt konnte nicht durchgeführt werden um den Site2Site VPN Tunnel zu etablieren damit das Problem eingegrenzt werden kann! Dies bedeutet als Beispiel: Ist Phase-1 abgeschlossen ist das "Pre-Shared-Secret" nicht das Problem, denn dieser Schritt wurde bereits abgeschlossen. Zusätzlich zu diesen 4 Schritten ist es Wichtig zu wissen wie ein "Main Mode" oder "Aggressive Mode" funktioniert dh. welche detail Schritte werden für diese 2 Modi durchgeführt und wo liegen die Unterschiede! Nachfolgend werden diese zwei Mode mit den detail Schritten beschrieben:
| |
|
| |
| '''Main Mode Komunikation'''
| |
|
| |
| • Für die Etablierung des "Main Mode" werden 6 Packete für die Komunikation benutzt:
| |
|
| |
| [[Datei:Fortinet-1422.jpg]]
| |
|
| |
| Packet 1: Ein lokaler Client (Initiator) initiert Traffic für die Remote Seite der den IPSec Site2Site VPN Tunnel
| |
| und somit eine oder mehrere Sicherheitsrichtlinien benützt.
| |
| Packet 2: Der Responder selektiert seine Sicherheitsrichtlinien die er benützen will und antwortet.
| |
| Packet 3: Der Client der den Traffic initiert hat sendet seinen Key.
| |
| Packet 4: Der Responder antwortet ebenfalls mit seinem Key.
| |
| Packet 5: Der Client sendet Final seine Peer ID und den hash payload.
| |
| Packet 6: Der Responder antwortet ebenfalls mit der Peer ID und dem hash payload.
| |
|
| |
| Im Gegensatz zum "Aggressive Mode" sendet der Initiator im "Main Mode" seine Peer-ID nicht zu Beginn. Somit kann die FortiGate die IPSec
| |
| VPN Verbindung nicht mit dieser Information identifizieren. Als Identifikation wird die Source IPv4 Adresse benutzt! die Peer-ID wird im
| |
| "Main Mode" zu einem späteren Zeitpunkt übermittelt und kann somit nicht verwendet werden für die Identifizierung der Verbindung. Aus
| |
| diesem Grund wird der "Main Mode" Hauptsächlich im Site2Site IPSec VPN Verfahren benutzt und um die einzelnen Client2Site IPSec VPN (Dial-Up)
| |
| eindeutig anhand der "Local-ID" zu Identifizieren der "Aggressive Mode" da die "Local-ID" zur Identifizierung der IPSec VPN Verbindung in
| |
| der Phase-1 übermittelt wird.
| |
|
| |
| '''Aggressive Mode Komunikation'''
| |
|
| |
| • Für die Etablierung des "Aggressive Mode" werden 3 Packete für die Komunikation benutzt:
| |
|
| |
| [[Datei:Fortinet-1423.jpg]]
| |
|
| |
| Packet 1: Ein lokaler Client (Initiator) initiert Traffic für die Remote Seite der den IPSec Site2Site VPN Tunnel
| |
| und somit eine oder mehrere Sicherheitsrichtlinien benützt. Die Key-ID sowie Peer ID (Local-ID) werden in
| |
| diesem Schritt zur Remote Seite gesendet.
| |
| Packet 2: Der Responder antwortet mit den gleichen Informtionen plus sendet dieser seinen "hash".
| |
| Packet 3: Der Initiator sendet dem Responder den "hash payload".
| |
|
| |
| Die "Peer-ID" zur Identifizierung der IPSec VPN Verbindung wird in der Phase-1 im "Aggressive Mode" als "Local-ID" konfiguriert und
| |
| übermittelt. Im "Main Mode" wird die Source IPv4 Adresse benutzt um die IPSec Verbindung zu identifizieren, denn die "Local-ID"
| |
| (Peer-ID) wird im "Main Mode" zu einem späteren Zeitpunkt übermittelt. Somit kann diese "Local-ID" im "Aggressive Mode" benutzt
| |
| werden um verschiedenen gleichzeitige IPSec VPN Phase-1 Verbindungen zu unterscheiden! Aus diesem Grund wird der "Aggressive Mode"
| |
| Hauptsächlich benutzt für Client2Site IPSec VPN (Dial-Up) um die einzelnen verschiedenen existierenden Phase-1 für die verschiedenen
| |
| Devices anhand der "Local-ID" in der Phase-1 zu identifizieren.
| |
|
| |
| Desweiteren ist zu berücksichtigen, wenn auf einem FortiOS mehrere Phase-1 Konfigurationen existieren diese nach folgenden Kriterien selektiert werden:
| |
|
| |
| • Für alle eingehenden IPSec VPN Verbindungen selektiert das FortiOS die IPSec VPN Verbindung in "Alphabetischer Reihenfolge"
| |
| nach folgenden Kriterien:
| |
|
| |
| 1. Local Gateway
| |
| 2. Mode (Main Mode oder Aggressive Mode)
| |
| 3. Peer ID (Local ID) sofern Aggressive Mode
| |
| 4. Authentication Methode (Pre-Shared Key or PKI)
| |
| 5. Zertifikats Informationen sofern PKI
| |
|
| |
| Ein Site2Site IPSec VPN wird durch die Lokale IPv4 Adresse definiert sowie der Remote Gateway IPv4 Adresse und im "Main Mode" stellt dies keine Probleme dar. Existieren jedoch mehrere Phase-1 für Client2Site VPN (Dial-UP) sollte für die Identifizierung der "Aggressive Mode" benützt werden denn durch die konfigurierte "Local-ID" (Peer-ID) in der Phase-1 sowie auf der Client Seite kann die IPSec Client2Site VPN Verbindung eindeutig identifiziert werden. Dabei ist auch zu berücksichtigen, das der "Pre-Shared-Key" kein selektierungs Kriterium für eine IPSec VPN Verbindung ist.
| |
|
| |
| === Wie kann ich unter FortiOS 5.4 für eine IPSec VPN Verbindung ein Troubleshooting (Debug) durchführen? ===
| |
|
| |
| Wenn eine IPSec VPN Verbindung sei es für Client2Site und/oder Site2Site in der Phase-1 und/oder Phase-2 ein Troubleshooting durchgeführt werden soll, kann dies anhand des Debug Kommandos durchgeführt werden. Dabei ist folgendes zu berücksichtigen: Dieses Troubleshooting anhand des Debug Kommandos zeigt nur den Traffic resp. die Etablierung der Phase-1 und/oder Phase-2. Der Traffic eines Hosts/Clients als Initiator und/oder Responders wird nicht aufgezeigt. Das Debug Kommando für die Phase-1 und 2 basiert auf folgenden Befehl:
| |
|
| |
| # diagnose debug application ike [Debug Level]
| |
|
| |
| Im Grundsatz kann der tiefste Debug Level benützt werden um alle Nachrichten im Debug auszugeben dh. "-1". Es stehen jedoch verschiedenen dezidierte Debug Level zu Verfügung um nur spezifische Informationen der Phase-1 und 2 im Debug auszugeben. Es sind dies die folgenden Debug Level:
| |
|
| |
| -1 Alle Debug Informationen werden ausgegeben
| |
| 1 Nur die Wichtigsten Error Meldungen werden angezeigt
| |
| 2 Zeige nur Konfigurations Aenderungen
| |
| 4 Zeige nur Verbindungsversuche
| |
| 8 Zeige nur Phase-1 sowie Phase-2 Komunikations Meldungen
| |
| 16 Zeige nur NAT-T Meldungen (Nat-Traversal)
| |
| 32 Zeige nur DPD Meldungen an
| |
| 64 Zeige nur Encryption/Decryption Key's an
| |
| 128 Zeige nur den Encryption Traffic payload
| |
|
| |
| Speziell wenn mehrere IPSec VPN Verbindungen auf einem FortiOS konfiguriert wurden, ist es wichtig einen Filter zu konfigurieren/anzuwenden um zB nur den Output einer spezifische IPSec Verbindung anzeigen zu lassen. Dazu steht folgender Befehl zur Verfügung:
| |
|
| |
| # diagnose vpn ike log-filter ?
| |
|
| |
| list Display the current filter.
| |
| clear Erase the current filter.
| |
| name Phase1 name to filter by.
| |
| src-addr4 IPv4 source address range to filter by.
| |
| dst-addr4 IPv4 destination address range to filter by.
| |
| src-addr6 IPv6 source address range to filter by.
| |
| dst-addr6 IPv6 destination address range to filter by.
| |
| src-port Source port range to filter by.
| |
| dst-port Destination port range to filter by.
| |
| vd Index of virtual domain. -1 matches all.
| |
| interface Interface that IKE connection is negotiated over.
| |
| negate Negate the specified filter parameter.
| |
|
| |
| Somit kann anhand dieses Befehls zB die Phase-1 anhand des "name" ein Filter gesetzt werden:
| |
|
| |
| # diagnose vpn ike log-filter name [Name der Phase-1]
| |
|
| |
| Danach kann nachträglich nach Konfiguration des Filters dieser mit folgendem Befehl kontrolliert werden:
| |
|
| |
| # diagnose vpn ike log-filter list
| |
| vd: any
| |
| name: [Name der Phase-1]
| |
| interface: any
| |
| IPv4 source: any
| |
| IPv4 dest: any
| |
| IPv6 source: any
| |
| IPv6 dest: any
| |
| source port: any
| |
| dest port: any
| |
|
| |
| Der Filter kann modifziert und nach Gebrauch mit folgenden Befehl gelöscht werden:
| |
|
| |
| # diagnose vpn ike log-filter clear
| |
|
| |
| Zusätzlich um sich über ein IPSec VPN Tunnel den Ueberblick zu verschaffen, steht folgendes Kommando zur Verfügung das jedoch nur Informationen ausgiebt, wenn ein IPSec VPN Tunnel etabliert resp. aktiv ist:
| |
|
| |
| # get vpn ipsec tunnel [details | name | summary]
| |
|
| |
| details List all IPSec tunnels in details.
| |
| name List IPSec tunnel by name.
| |
| summary List all IPSec tunnels in summary.
| |
|
| |
| # get vpn ipsec stats [crypto | tunnel]
| |
|
| |
| crypto IPSec crypto statistic
| |
| tunnel IPSec tunnel statistic
| |
|
| |
| Die Grundlagen resp. Informationen und Möglichkeiten für ein Troubleshooting sind nun bekannt und somit kann ein Debug anhand dieser Informationen ausgeführt werden. Dabei ist folgendes zu berücksichtigen: Ein Debug kann sehr viele Informationen enthalten und sollte deshalb nicht über eine RS-232 Mgmt. Console des FortiGate Devices ausgeführt werden (Buffer Limitierung). Ebenso ist es zu empfehlen die Debug Informationen in ein Log File zu schreiben, damit die Informationen für eine Analyse später zur Verfügung stehen. Ein Debug für IPSec VPN Phase-1 und/oder Phase-2 sollte somit folgendermassen durchgeführt werden:
| |
|
| |
| '''Verbinde dich anhand SSH zum FortiGate Device'''
| |
|
| |
| Wenn anhand "putty" eine SSH Verbindung zu einem FortiGate Device etabliert wird, kann vorgängig ein Log
| |
| File über folgende Position innerhalb der "putty" Konfiguration aktiviert/konfiguriert werden:
| |
|
| |
| Category > Session > Logging > All Session output
| |
|
| |
| '''Setze den "debug" Filter zurück'''
| |
|
| |
| # diagnose debug reset
| |
|
| |
| '''Aktiviere für den debug "output" den "timestamp"'''
| |
|
| |
| # diagnose debug console timestamp enable
| |
|
| |
| '''Aktiviere für "application ike" einen entsprechenden Filter'''
| |
|
| |
| # diagnose vpn ike log-filter [Setze eine entsprechende Filter zB "name [Name Phase-1]"]
| |
|
| |
| '''Kontrolliere für "application ike" den gesetzen Filter'''
| |
|
| |
| # diagnose vpn ike log-filter list
| |
|
| |
| '''Aktiviere den entsprechenden Debug Level für "ike"'''
| |
|
| |
| # diagnose debug application ike [Aktiviere den entsprechenden "ike" Debug Level zB "-1"]
| |
|
| |
| '''Aktiviere den Debug Modus'''
| |
|
| |
| # diagnose debug enable
| |
|
| |
| Damit nun ein entsprechender Debug Output generiert wird, muss Traffic eines CLients/Hosts für die Remote Seite initiert werden damit Phase-1 und Phase-2 etabliert werden. Dies kann zB anhand eines "icmp" Traffic vom Initiator zur Remote Seite erreicht werden wobei darauf zu achten ist, dass der entsprechende Traffic durch eine Firewall Policy Rule erlaubt ist! Nun wird ein entsprechender Output der Phase-1 und 2 durch diesen Traffic aufgezeichnet. Nachfolgendes Dokument von Fortinet zeigt anhand eines Beispiel für eine Site2Site IPSec VPN Verbindung zweier FortiGate Devices auf welche Fehler resp. Fehlermeldungen entstehen können und was deren Bedeutung ist:
| |
|
| |
| [[Datei:Fortigate-IPSEC-Debugging.pdf]]
| |
|
| |
| Um den Debug Mode zu beenden kann nachfolgender Befehl in die SSH Console kopiert werden gefolgt von [ENTER]. Dieser Befehl deaktiviert den laufenden Debug Mode:
| |
|
| |
| '''Deaktiviere die Debug Funktion'''
| |
|
| |
| # diagnose debug disable
| |
|
| |
| Nachdem der Output erfolgreich erzeugt wurde resp. das Troubleshooting beendet wurde und nicht mehr benötigt wird, sollten alle Filter und Debug Level zurückgesetzt werden:
| |
|
| |
| '''Dektiviere für den debug "output" den "timestamp"'''
| |
|
| |
| # diagnose debug console timestamp disable
| |
|
| |
| '''Setze den "ike log-filter" Filter zurück'''
| |
|
| |
| # diagnose vpn ike log-filter clear
| |
|
| |
| '''Setze alle Debug Filter zurück'''
| |
|
| |
| # diagnose debug reset
| |
|
| |
| Wenn ein IPSec Site2Site VPN in der Phase-1 und 2 erfolgreich etabliert wurde, jedoch kein Traffic durch den VPN Tunnel gesendet werden kann, so muss ein tiefergreifendes Troubleshooting durchgeführt werden. Das nachfolgendes Textfile zeigt wie so ein Troubleshooting durchgeführt wird um die entsprechenden Debug Informationen zu erhalten und diese nachträglich anhand eines Tickets im Support Level P3 Fortinet zu übermitteln:
| |
|
| |
| [[Datei:FGT-Site2Site-Full-Debug-VPN-Up.txt]]
| |
|
| |
| === Wie kann ich unter FortiOS 5.4 eine Konfigurierte IPSec VPN Verbindung von Grundauf neu Starten/Initieren? ===
| |
|
| |
| Wenn eine IPSec VPN Verbindung speziell für Site2Site VPN Konfiguriert wurde und nachträglich an dieser Konfiguration Aenderungen durchführt werden wie zB Encryption, Routing usw. Ist es wichtig, dass dieses Site2Site VPN auf beiden Seiten neu gestartet wird resp. Routing Informationen auf den neusten Stand gebracht werden sowie die Konfigurationsänderungen. Dabei steht unter FortiOS 5.4 auf dem Mgmt. Web Interface die Möglichkeit zur Verfügung über die folgende Position ein IPSec mit "up/down" neu zu starten:
| |
|
| |
| Monitor > IPsec Monitor [Markiere einen entsprechenden VPN Tunnel] > [Rechte Maustaste wähle "up/down"]
| |
|
| |
| Um Routing Informationen auf einem FortiGate Device vollumfänglich neu zu initieren führe folgenden Befehl auf der CLI aus:
| |
|
| |
| # execute router restart
| |
|
| |
| Diese Möglichkeit über Mgmt. Web Interface anhand "up/down" eine IPSec VPN Verbindung neu zu starten stellt zwar eine Möglichkeit dar, jedoch wird dadurch der entsprechenden IPSec VPN Tunnel nicht von Grundauf neu etabliert! Dies bedeutet: Die "Security Association" der Phase-1 wird dadurch nicht gelöscht und neu initiert. Diese Möglichkeit über Mgmt. Web Interface entspricht den folgenden Kommandos in der CLI die ausschliesslich im Zusammenhang stehen mit der Phase-2 und somit bestätigen das die Phase-1 resp. die "Security Association" nicht beeinflusst wird:
| |
|
| |
| # diagnose vpn tunnel down [Name Phase-2]
| |
| # diagnose vpn tunnel up [Name Phase-2]
| |
|
| |
| Um die Phase-2 zu beinflussen dh. zB ein "reset" durchzuführen stehen für das Kommando "diagnose vpn tunnel" weitere Optionen zur Verfügung:
| |
|
| |
| # diagnose vpn tunnel ?
| |
| down Shut down tunnel
| |
| up Activate tunnel
| |
| list List all tunnel
| |
| dialup-list Lit dialup tunnel
| |
| reset Flush tunnel SAs and reset NT-T and DPD configuration
| |
| flush Flush tunnel SAs
| |
| delinbsa Remove tunnel sa
| |
| deloutbsa Remove tunnel sa
| |
| dumpsa Dump all sa
| |
| Stat Tunnel statistic info
| |
|
| |
| Wenn ein Neustart der Phase-2 nicht den gewünschten Erfolg bringt, wird oft als letzte Alternative ein Neustart des FortiGate Devices durchgeführt, was natürlich den gewünschten Erfol bringt jedoch nicht in jeder Situation möglich ist resp. sinnvoll ist da ein Unterbruch durch den Neustart des FortiGate Devices verursacht wird! Somit sollen IPSec VPN Verbindung auf einem FortiGate Device von Grundauf neu gestartet werden, kann damit die Informationen und Konfigurationsaenderungen in der Phase-1 komplett erneuert werden folgender Befehl ausgeführt werden:
| |
|
| |
| # diagnose debug reset
| |
| # diagnose debug application ike 2
| |
| # diagnose debug enable
| |
| # diagnose vpn ike restart
| |
|
| |
| Das Komando "application ike 2" wird durchgeführt um die Konfigurtionsaenderungen anzuzeigen und mit "diagnose debug enable" zu kontrollieren ob die Phase-1 sowie 2 korrekt etabliert wurden! Dabei ist jedoch zu berücksichtigen, dass durch "diagnose vpn ike restart" alle IPSec VPN Verbindungen auf einem FortiOS neu gestartet werden und somit für alle Konfigurierten IPSec VPN Verbindungen ein Unterbruch stattfindet. Soll nur eine bestimmte IPSec VPN Verbindung neu gestartet werden, kann folgender Befehl benutzt werden:
| |
|
| |
| # diagnose debug reset
| |
| # diagnose debug application ike 2
| |
| # diagnose debug enable
| |
| # diagnose vpn ike gateway flush [name Phase 1]
| |
|
| |
| == IPSec / L2TP ==
| |
|
| |
| === Wie wird unter FortiOS 5.4 für einen FortiGate Device eine IPSec VPN basierend auf L2TP konfiguriert? ===
| |
|
| |
| Unter FortiOS 5.4 kann neu eine IPSec VPN basierende L2TP Verbindung für Windows auf Interface Based VPN konfiguriert werden. Unter FortiOS 5.2 sind IPSec VPN Verbindungen basierend auf L2TP nur als Policy Based VPN konfigurierbar. Der Vorteil einer Policy Based IPSec VPN Verbindung basierend auf L2TP, ist das verschiedenen Devices diese benutzen können dh. IOS Devices, Android usw. Damit ein Policy Based VPN konfigiert werden kann muss im Mgmt. Web Interface die Funktion für Software Based VPN's in der CLI aktiviert werden. Dazu muss folgendes ausgeführt werden:
| |
|
| |
| # config system settings
| |
| # set gui-policy-based-ipsec [enable | disable]
| |
| # end
| |
|
| |
| In den nachfolgenden Schritten wird erklärt wie ein Interface Based VPN für IPSec VPN L2TP sowie ein Policy Based VPN für IPSec VPN L2TP konfiguriert wird. Die einfachste Art und Weise ist dies über CLI zu konfigurieren. Führe folgendes aus:
| |
|
| |
| '''IPSec VPN L2TP Phase-1 und Phase-2 Interface Based'''
| |
|
| |
| # config vpn ipsec phase1-interface
| |
| # edit [Name der Phase-1 zB "hard-l2tp"]
| |
| # set comments "Interface Based IPSec Phase1 L2TP"
| |
| # set type dynamic
| |
| # set interface [Name des Interfaces für die Verbindung zB "wan1"]
| |
| # set ip-version 4
| |
| # set ike-version 1
| |
| # set local-gw 0.0.0.0
| |
| # set keylife 86400
| |
| # set authmethod psk
| |
| # set mode main
| |
| # set peertype any
| |
| # set mode-cfg disable
| |
| # set proposal aes256-md5 3des-sha1 aes192-sha1
| |
| # set add-route enable
| |
| # set exchange-interface-ip disable
| |
| # set localid [Name der Local-ID zB "hard-l2tp"]
| |
| # set localid-type auto
| |
| # set negotiate-timeout 30
| |
| # set fragmentation enable
| |
| # set dpd on-demand
| |
| # set forticlient-enforcement disable
| |
| # set npu-offload enable
| |
| # set dhgrp 2
| |
| # set suite-b disable
| |
| # set wizard-type custom
| |
| # set xauthtype disable
| |
| # set idle-timeout disable
| |
| # set ha-sync-esp-seqno enable
| |
| # set auto-discovery-sender disable
| |
| # set auto-discovery-receiver disable
| |
| # set auto-discovery-forwarder disable
| |
| # set nattraversal enable
| |
| # set default-gw 0.0.0.0
| |
| # set default-gw-priority 0
| |
| # set psksecret [Vergebe ein Pre-Shared Secrete]
| |
| # set keepalive 10
| |
| # set distance 15
| |
| # set priority 0
| |
| # set dpd-retrycount 3
| |
| # set dpd-retryinterval 20
| |
| # end
| |
|
| |
| # config vpn ipsec phase2-interface
| |
| # edit [Name der Phase-2 zB "hard-l2tp"]
| |
| # set comments "Interface Based IPSec Phase2 L2TP"
| |
| # set phase1name [Name der Phase1 zB "hard-l2tp"]
| |
| # set proposal aes256-md5 3des-sha1 aes192-sha1
| |
| # set pfs disable
| |
| # set replay enable
| |
| # set keepalive disable
| |
| # set add-route phase1
| |
| # set auto-discovery-sender phase1
| |
| # set auto-discovery-forwarder phase1
| |
| # set keylife-type seconds
| |
| # set encapsulation transport-mode
| |
| # set l2tp enable
| |
| # set protocol 0
| |
| # set src-port 0
| |
| # set dst-port 0
| |
| # set dhcp-ipsec disable
| |
| # set keylifeseconds 3600
| |
| # end
| |
|
| |
| '''IPSec VPN L2TP Phase-1 und Phase-2 Policy Based'''
| |
|
| |
| # config vpn ipsec phase1
| |
| # edit [Name der Phase-1 zB "soft-l2tp"]
| |
| # set comments "Policy Based IPSec Phase1 L2TP"
| |
| # set type dynamic
| |
| # set interface [Name des Interfaces für die Verbindung zB "wan1"]
| |
| # set ike-version 1
| |
| # set local-gw 0.0.0.0
| |
| # set keylife 28800
| |
| # set authmethod psk
| |
| # set mode main
| |
| # set peertype any
| |
| # set mode-cfg disable
| |
| # set proposal aes256-md5 3des-sha1 aes128-sha1 aes192-sha1
| |
| # set add-route disable
| |
| # set exchange-interface-ip disable
| |
| # set localid [Name der Local-ID zB "soft-l2tp"]
| |
| # set localid-type auto
| |
| # set negotiate-timeout 30
| |
| # set fragmentation enable
| |
| # set dpd on-idle
| |
| # set forticlient-enforcement disable
| |
| # set npu-offload enable
| |
| # set dhgrp 1 2 5
| |
| # set suite-b disable
| |
| # set wizard-type custom
| |
| # set xauthtype disable
| |
| # set idle-timeout disable
| |
| # set ha-sync-esp-seqno enable
| |
| # set nattraversal enable
| |
| # set psksecret [Vergebe ein Pre-Shared Secrete]
| |
| # set keepalive 10
| |
| # set distance 1
| |
| # set priority 0
| |
| # set dpd-retrycount 3
| |
| # set dpd-retryinterval 5
| |
| # end
| |
|
| |
| # config vpn ipsec phase2
| |
| # edit [Name der Phase-2 zB "soft-l2tp"]
| |
| # set comments "Policy Based IPSec Phase1 L2TP"
| |
| # set phase1name [Name der Phase1 zB "soft-l2tp"]
| |
| # set use-natip enable
| |
| # set proposal aes256-md5 3des-sha1 aes128-sha1 aes192-sha1
| |
| # set pfs disable
| |
| # set replay enable
| |
| # set keepalive enable
| |
| # set add-route disable
| |
| # set keylife-type both
| |
| # set encapsulation transport-mode
| |
| # set l2tp enable
| |
| # set protocol 0
| |
| # set src-port 0
| |
| # set dst-port 0
| |
| # set dhcp-ipsec disable
| |
| # set keylifeseconds 3600
| |
| # set keylifekbs 250000
| |
| # end
| |
|
| |
| Die Phase-1 und 2 wurden konfiguriert. Fuer die Authentifizierung der User muss nun eine Gruppe konfiguriert werden die zur L2TP Funktion hinzugefügt wird. In dieser Konfiguration muss ebenfalls ein IP-Pool definiert werden dh. dieser IP-Pool stellt ein IPv4 Subnet dar aus diesem dem User nach erfolgreicher Authentifizierung eine IPv4 Adresse auf dem Host/Workstation zugewiesen wird. Konfiguriere ein IP-Pool Objekt sowie eine entsprechende Gruppe für die Authentifizierung und füge diese Informationen der L2TP Funktion hinzu:
| |
|
| |
| '''Konfiguriere ein IP-Pool Objekt'''
| |
|
| |
| # config firewall address
| |
| # edit "net-ip-pool-ipsec-l2tp-vpn-198.18.4.128-25"
| |
| # set comment "IPSec L2TP VPN IP-Pool"
| |
| # set subnet 198.18.4.128 255.255.255.128
| |
| # next
| |
| # end
| |
|
| |
| '''Konfiguriere ein LAN Objekt'''
| |
|
| |
| # config firewall address
| |
| # edit "net-local-lan-198.18.0.0-24"
| |
| # set comment "Net LAN local"
| |
| # set subnet 198.18.0.0 255.255.255.0
| |
| # next
| |
| # end
| |
|
| |
| '''Konfiguriere ein User Objekt'''
| |
|
| |
| # config user local
| |
| # edit "local-0.intra"
| |
| # set type password
| |
| # set passwd "[Password]"
| |
| # next
| |
| # end
| |
|
| |
| '''Konfiguriere ein Gruppen Objekt'''
| |
|
| |
| # config user group
| |
| # edit "gr-ipsec-l2tp-vpn"
| |
| # set group-type firewall
| |
| # set member "local-0.intra"
| |
| # next
| |
| # end
| |
|
| |
| Nun kann diese Information der L2TP Funktion hinzugefügt werden:
| |
|
| |
| # config vpn l2tp
| |
| # set eip [IPv4 Start IP des Ranges für IP Pool zB "198.18.4.129"]
| |
| # set sip [IPv4 End IP des Ranges für IP Pool zB "198.18.04.254"]
| |
| # set status enable
| |
| # set usrgrp [Name der entsprechenden User Gruppe für L2TP zB "gr-ipsec-l2tp-vpn"]
| |
| # end
| |
|
| |
| Nun können die entsprechenden Firewall Policy Rules erstellt werden. Dabei ist zu folgendes zu beachten: Die Firewall Policy Rules sei es für Policy Based VPN und/oder Interface Based VPN bestehen aus 2 Firewall Policy Rules. Die erste Firewall Policy Rule definiert den Zugriff auf die L2TP Funktion sowie auf das WAN Interface für die Authentifizierung und die zweite Firewall Policy Rule erlaubt den Zugriff in das interne LAN Segment. Für die Definition der Firewall Policy Rule Authentication Rule benötigt man den Service L2TP (TCP/UDP Port 1701). Dieser wird folgendermassen konfiguriert:
| |
|
| |
| Policy & Objects > Services > Create New
| |
|
| |
| [[Datei:Fortinet-2103.jpg]]
| |
|
| |
| Konfiguriere nun die Firewall Policy Rules für IPSec VPN L2TP Interface Based und/oder Policy Based:
| |
|
| |
| Policy & Objects > IPv4 Policy
| |
|
| |
| '''IPSec VPN L2TP Interface Based'''
| |
|
| |
| [[Datei:Fortinet-2100.jpg]]
| |
|
| |
| [[Datei:Fortinet-2101.jpg]]
| |
|
| |
| '''IPSec VPN L2TP Policy Based'''
| |
|
| |
| [[Datei:Fortinet-2102.jpg]]
| |
|
| |
| [[Datei:Fortinet-2101.jpg]]
| |
|
| |
| Die Konfiguration ist abgeschlossen und ein entsprechender Host/Workstation kann basierend auf IPSec VPN L2TP für einen Test konfiguriert werden. Wie ein Windows 10 Host/Workstation basierend auf IPSec VPN L2TP konfiguriert wird siehe nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.4-5.6:FAQ#Wie_wird_unter_Windows_10_f.C3.BCr_ein_FortiOS_5.4_eine_IPSec_VPN_basierend_Verbindung_auf_L2TP_konfiguriert.3F]]
| |
|
| |
| === Wie wird unter Windows 10 für ein FortiOS 5.4 eine IPSec VPN basierend Verbindung auf L2TP konfiguriert? ===
| |
|
| |
| Der nachfolgende Artikel erklärt wie unter FortiOS 5.4 eine IPSec VPN L2TP Verbindung auf einem FortiGate Device konfiguriert wird:
| |
|
| |
| [[FortiGate-5.4-5.6:FAQ#Wie_wird_unter_FortiOS_5.4_f.C3.BCr_einen_FortiGate_Device_eine_IPSec_VPN_basierend_auf_L2TP_konfiguriert.3F]]
| |
|
| |
| Wenn auf einem Host/Workstation basierend auf Windows 10 eine solche IPsec VPN L2TP Verbindung zu einem FortiGate Device sei es Interface Based und/oder Policy Based konfiguriert werden solll muss folgendes durchgeführt werden:
| |
|
| |
| Start > Einstellungen > Netzwerk und Internet > VPN > VPN-Verbindung hinzufügen
| |
|
| |
| [[Datei:Fortinet-2104.jpg]]
| |
|
| |
| Diese Informationen können nachträglich jederzeit geändert werden:
| |
|
| |
| [[Datei:Fortinet-2105.jpg]]
| |
|
| |
| Nun kann bereits ein erster Verbindungstest durchgeführt werden! Obwohl man davon ausgeht, dass über "Erweiterte Optionen" die L2TP Verbindung in den Details konfiguriert werden kann ist dies nicht möglich. Wenn eine L2TP Verbindung konfiguriert wird so wird im Hintergrund unter den Netzwerk Adaptern ein Hybrid Adapter (WAN Miniport) erstellt der die neu konfigurierte L2TP Verbindung darstellt. Um die L2TP Verbindung in deren Details zu konfigurieren muss dies über diesen Netzwerk Adapter über dessen Eigenschaften durchgeführt werden:
| |
|
| |
| Start > Windows Durchsuchen "ncpa.cpl" > Enter
| |
|
| |
| Wähle nun den "soft-hard-l2tp" WAN Miniport (L2TP) Adapter und führen eine Rechten Mausklick aus sowie wähle Eigenschaften:
| |
|
| |
| [[Datei:Fortinet-2106.jpg]]
| |
|
| |
| [[Datei:Fortinet-2107.jpg]]
| |
|
| |
| [[Datei:Fortinet-2108.jpg]]
| |
|
| |
| [[Datei:Fortinet-2109.jpg]]
| |
|
| |
| Wenn die Position unter den "Erweiterten TCP/IP Einstellung" betreffend "Standardgateway für das Remotenetzwerk verwenden" aktiviert ist so wird ein "Splitt Tunneling" durchgeführt!
| |
|
| |
| === Wie kann ich unter FortiOS 5.4 für eine IPSec VPN basierend auf L2TP Konfiguration ein Debug ausführen? ===
| |
|
| |
| Wenn man eine IPSec VPN Verbindung basierend auf L2TP konfiguriert und es später bei der Verbindung zu Problemen kommt kann mit nachfolgenden Befehl für diese Verbindung ein Debug ausgeführt werden. Da in diesem Output einige Informationen ausgegeben wird, sollte eine SSH Verbindung für den Debug erstellt werden sowie die Informationen des Outputs in ein Log File geschrieben werden zur späteren Analyse:
| |
|
| |
| 1. Konfiguriere "putty" für logging dh. alle Informationen werden in ein Log aufgezeichnet (Category > Session > Logging > All session output)
| |
| 2. Erstelle eine Consolen Verbindung zur FortiGate (RS232 basierend resp. Seriell)
| |
| 3. Führe ein Login durch und gebe folgendes ein:
| |
|
| |
| '''Setze alle Debug Filter zurück'''
| |
|
| |
| # diagnose debug reset
| |
|
| |
| '''Aktiviere den L2TP Debug Filter'''
| |
|
| |
| # diagnose debug application l2tp -1
| |
|
| |
| '''Aktiviere den Debug Modus mit dem gesetzen Debug Filter'''
| |
|
| |
| # diagnose debug enable
| |
|
| |
| Nun kann eine Verbindung erstellt werden:
| |
|
| |
| create_new_tunnel()-100: Allocated new Tunnel id=1, total count = 1
| |
| handle_control_packet()-549:
| |
| check_control_hdr()-173: check_control_hdr: control, peer_call_id = 0, Ns = 0, Nr = 0
| |
| check_control_hdr()-185: Updated control rec seqno. Value is now 1
| |
| __avp_protocol_version()-233: peer is using version 8, revision 128.
| |
| __avp_framing_caps()-248: supported peer framing:
| |
| __avp_bearer_caps()-264: supported peer bearers:
| |
| __avp_firmware_rev()-279: peer's firmware version 2048
| |
| _avp_hostname()-295: Peer's hostname is 'DESKTOP-HSEH6HM'
| |
| __avp_vendor()-310: peer's vendor 'Microsoft'
| |
| __avp_assigned_tunnel()-339: peer's tunnel 1
| |
| avp_receive_window_size()-359: peer's RWS 8.
| |
| run_ctrl_state_machine()-91: run_ctrl_state_machine: message type is (1). Tunnel is 1, call is 0.
| |
| run_ctrl_state_machine()-97: ** run_ctrl_state_machine - SCCRQ **
| |
| run_ctrl_state_machine()-108: Rule 193.193.135.65 to 193.193.135.65avp_put_hostname()-84: Sent the host name = 193.1
| |
| run_ctrl_state_machine()-166: Sending SCCRP
| |
| schedule_event()-94:
| |
| schedule_event()-100: Message due 11066, now = 10966
| |
| handle_control_packet()-549:
| |
| check_control_hdr()-173: check_control_hdr: control, peer_call_id = 0, Ns = 1, Nr = 1
| |
| check_control_hdr()-185: Updated control rec seqno. Value is now 2
| |
| run_ctrl_state_machine()-91: run_ctrl_state_machine: message type is (3). Tunnel is 1, call is 0.
| |
| run_ctrl_state_machine()-175: ** run_ctrl_state_machine - SCCCN **
| |
| L2TPD 97: 180:Connection established to 193.193.135.65, 1701. Local: 1, Remote: 1.
| |
| start_hello_timer()-59: L2TP: starting Hello timer for tunnel 1, next in 60 seconds.
| |
| schedule_event()-94:
| |
| schedule_event()-100: Message due 16967, now = 10967
| |
| handle_network_packet()-271: Sending a ZLB to acknowledge last message
| |
| send_zlb()-73: ** send_zlb **
| |
| handle_control_packet()-549:
| |
| check_control_hdr()-173: check_control_hdr: control, peer_call_id = 0, Ns = 2, Nr = 1
| |
| check_control_hdr()-185: Updated control rec seqno. Value is now 3
| |
| __avp_assigned_call()-392: Parsed new call id of 1
| |
| __avp_call_serno()-418: serial number is 0
| |
| __avp_bearer_type()-445: peer's bears anamylog
| |
| avp_handler()-723: AVP 1 was ignored
| |
| run_ctrl_state_machine()-91: run_ctrl_state_machine: message type is (10). Tunnel is 1, call is 1.
| |
| run_ctrl_state_machine()-225: ** run_ctrl_state_machine - ICRQ **
| |
| run_ctrl_state_machine()-235: New call was created for tunnel 1, call id = 1
| |
| run_ctrl_state_machine()-290: This call is the master_call, its peer_call_id = 2
| |
| run_ctrl_state_machine()-298: run_ctrl_state_machine: sending ICRP
| |
| schedule_event()-94:
| |
| schedule_event()-100: Message due 11067, now = 10967
| |
| handle_control_packet()-549:
| |
| check_control_hdr()-173: check_control_hdr: control, peer_call_id = 1, Ns = 3, Nr = 2
| |
| check_control_hdr()-185: Updated control rec seqno. Value is now 4
| |
| __avp_tx_speed()-495: TX is 100000000
| |
| __avp_frame_type()-474: peer's framing sync
| |
| avp_handler()-723: AVP 29 was ignored
| |
| run_ctrl_state_machine()-91: run_ctrl_state_machine: message type is (12). Tunnel is 1, call is 1.
| |
| run_ctrl_state_machine()-307: ** run_ctrl_state_machine - ICCN **
| |
| start_pppd()-180: Starting pppd
| |
| L2TPD 29: 181:Starting call (launching pppd, opening GRE)
| |
| run_ctrl_state_machine()-327: Call established with 193.193.135.65, Local: 2, Remote: 1, Serial: 0
| |
| handle_network_packet()-271: Sending a ZLB to acknowledge last message
| |
| send_zlb()-73: ** send_zlb **
| |
| L2TPD 25: 454:Client 193.193.135.65 control connection started (id 1), assigned ip 198.18.4.130
| |
| start_pppd()-466: /bin/pppd start_pppd()-466: 0 start_pppd()-466: l2tp start_pppd()-466: hard-l2tp start_pppd()-466: nodetach start_pppd()-466: 198.18.4.129:198.18.4.130 start_pppd()-466: +pap start_pppd()-466: +chap start_pppd()-466: peer-remote start_pppd()-466: 193.193.135.65 start_pppd()-466: lcp-echo-interval start_pppd()-466: 5 start_pppd()-466: lcp-echo-failure start_pppd()-466: 3 start_pppd()-466: dns-addr start_pppd()-466: 193.193.135.65 start_pppd()-468:
| |
| monitor_ctrl_pkt_xmit()-94:
| |
| monitor_ctrl_pkt_xmit()-116: L2TP: Peer ack'ed control packet.
| |
| monitor_ctrl_pkt_xmit()-94:
| |
| monitor_ctrl_pkt_xmit()-116: L2TP: Peer ack'ed control packet.
| |
|
| |
| Dazwischen sieht man immer wieder sogenannte Keepalive Nachrichten:
| |
|
| |
| send_hello()-33: L2TP: send Hello for tunnel 1
| |
| schedule_event()-94:
| |
| schedule_event()-100: Message due 35604, now = 35504
| |
| start_hello_timer()-59: L2TP: starting Hello timer for tunnel 1, next in 60 seconds.
| |
| schedule_event()-94:
| |
| schedule_event()-100: Message due 41504, now = 35504
| |
| handle_control_packet()-549:
| |
| handle_control_packet()-578: L2TP received control ZLB.
| |
| monitor_ctrl_pkt_xmit()-94:
| |
| monitor_ctrl_pkt_xmit()-116: L2TP: Peer ack'ed control packet.
| |
|
| |
| Wenn eine L2TP Verbindung beendet wird so wird folgendes ausgegeben:
| |
|
| |
| handle_control_packet()-549:
| |
| check_control_hdr()-173: check_control_hdr: control, peer_call_id = 1, Ns = 4, Nr = 6
| |
| check_control_hdr()-185: Updated control rec seqno. Value is now 5
| |
| __avp_assigned_call()-381: close call id 1
| |
| run_ctrl_state_machine()-91: run_ctrl_state_machine: message type is (14). Tunnel is 1, call is 1.
| |
| run_ctrl_state_machine()-332: ** run_ctrl_state_machine - CDN **
| |
| run_ctrl_state_machine()-373: Connection closed to 193.193.135.65, serial 0 ()
| |
| handle_network_packet()-271: Sending a ZLB to acknowledge last message
| |
| send_zlb()-73: ** send_zlb **
| |
| l2tp_handle_calls()-309: closing The master call
| |
| close_call()-409: ** close_call **
| |
| close_call()-424: Closing call 2
| |
| free_call()-227: ** free_call **
| |
| l2tp_vdbind_msg_handler()-86: del_vdbind message:vd=root 0 devindex=77 ppp1
| |
| handle_control_packet()-549:
| |
| check_control_hdr()-173: check_control_hdr: control, peer_call_id = 1, Ns = 5, Nr = 6
| |
| check_control_hdr()-185: Updated control rec seqno. Value is now 6
| |
| __avp_assigned_tunnel()-339: peer's tunnel 1
| |
| avp_result_code()-581: peer closing for reason 6, error = 0 ()
| |
| run_ctrl_state_machine()-91: run_ctrl_state_machine: message type is (4). Tunnel is 1, call is 1.
| |
| run_ctrl_state_machine()-187: ** run_ctrl_state_machine - StopCCN **
| |
| run_ctrl_state_machine()-218: Connection closed to 193.193.135.65, port 1701 (), Local: 1, Remote: 1
| |
| handle_network_packet()-271: Sending a ZLB to acknowledge last message
| |
| send_zlb()-73: ** send_zlb **
| |
| send_to_tunnel()-708: send packet to tunnel (id=1) failed (No such device)l2tp_handle_calls()-296: closing down tunnel 1
| |
| close_tunnel()-445: ** close_tunnel **
| |
| close_tunnel()-458: Closing and destroying tunnel 1
| |
| L2TPD 26: 460:Client 193.193.135.65 control connection (id 1) finished
| |
| close_calls_for_tunnel()-109:
| |
| free_call()-227: ** free_call **
| |
| free_tunnel()-126: Done close_calls_for_tunnel
| |
| l2tp_vdbind_msg_handler()-86: del_vdbind message:vd=root 0 devindex=76 hard-l2tp_0
| |
|
| |
| Nach einem Debug sollte dieser wieder deaktiviert werden:
| |
|
| |
| '''Deaktiviere den Debug Modus mit dem gesetzen Debug Filter'''
| |
|
| |
| # diagnose debug disable
| |
|
| |
| Da eine L2TP Verbindung auf IPSec IKE 500 basiert kann diese Verbindung ebenfalls im IKE Debug Mode überprüft werden:
| |
|
| |
| '''Setze alle Debug Filter zurück'''
| |
|
| |
| # diagnose debug reset
| |
|
| |
| '''Aktiviere den IKE Debug Filter'''
| |
|
| |
| # diagnose debug application ike -1
| |
|
| |
| '''Aktiviere den Debug Modus mit dem gesetzen Debug Filter'''
| |
|
| |
| # diagnose debug enable
| |
|
| |
| Nun kann eine L2TP Verbindung erstellt werden:
| |
|
| |
| ike shrank heap by 131072 bytes
| |
| ike 0: comes 193.193.135.65:500->193.193.135.66:500,ifindex=5....
| |
| ike 0: IKEv1 exchange=Identity Protection id=aa4d18c090210beb/0000000000000000 len=408
| |
| ike 0: in AA4D18C090210BEB00000000000000000110020000000000000001980D0000D40000000100000001000000C801010005030000280101000080010007800E0100800200028004001480030001800B0001000C000400007080030000280201000080010007800E0080800200028004001380030001800B0001000C000400007080030000280301000080010007800E0100800200028004000E80030001800B0001000C000400007080030000240401000080010005800200028004000E80030001800B0001000C000400007080000000240501000080010005800200028004000280030001800B0001000C0004000070800D00001801528BBBC00696121849AB9A1C5B2A51000000010D0000181E2B516905991C7D7C96FCBFB587E461000000090D0000144A131C81070358455C5728F20E95452F0D00001490CB80913EBB696E086381B5EC427B1F0D0000144048B7D56EBCE88525E7DE7F00D6C2D30D000014FB1DE3CDF341B7EA16B7E5BE0855F1200D00001426244D38EDDB61B3172A36E3D0CFB81900000014E3A5966A76379FE707228231E5CE8652
| |
| ike 0:aa4d18c090210beb/0000000000000000:1: responder: main mode get 1st message...
| |
| ike 0:aa4d18c090210beb/0000000000000000:1: VID unknown (20): 01528BBBC00696121849AB9A1C5B2A5100000001
| |
| ike 0:aa4d18c090210beb/0000000000000000:1: VID MS NT5 ISAKMPOAKLEY 1E2B516905991C7D7C96FCBFB587E46100000009
| |
| ike 0:aa4d18c090210beb/0000000000000000:1: VID RFC 3947 4A131C81070358455C5728F20E95452F
| |
| ike 0:aa4d18c090210beb/0000000000000000:1: VID draft-ietf-ipsec-nat-t-ike-02\n 90CB80913EBB696E086381B5EC427B1F
| |
| ike 0:aa4d18c090210beb/0000000000000000:1: VID FRAGMENTATION 4048B7D56EBCE88525E7DE7F00D6C2D3
| |
| ike 0:aa4d18c090210beb/0000000000000000:1: VID unknown (16): FB1DE3CDF341B7EA16B7E5BE0855F120
| |
| ike 0:aa4d18c090210beb/0000000000000000:1: VID unknown (16): 26244D38EDDB61B3172A36E3D0CFB819
| |
| ike 0:aa4d18c090210beb/0000000000000000:1: VID unknown (16): E3A5966A76379FE707228231E5CE8652
| |
| ike 0: cache rebuild start
| |
| ike 0:hard-l2tp: cached as dynamic
| |
| ike 0:ipsec-cisco: cached as dynamic
| |
| ike 0:ipsec-fc: cached as dynamic
| |
| ike 0:ipsec-ios: cached as dynamic
| |
| ike 0:soft-l2tp: cached as dynamic
| |
| ike 0: cache rebuild done
| |
| ike 0:aa4d18c090210beb/0000000000000000:1: negotiation result
| |
| ike 0:aa4d18c090210beb/0000000000000000:1: proposal id = 1:
| |
| ike 0:aa4d18c090210beb/0000000000000000:1: protocol id = ISAKMP:
| |
| ike 0:aa4d18c090210beb/0000000000000000:1: trans_id = KEY_IKE.
| |
| ike 0:aa4d18c090210beb/0000000000000000:1: encapsulation = IKE/none
| |
| ike 0:aa4d18c090210beb/0000000000000000:1: type=OAKLEY_ENCRYPT_ALG, val=3DES_CBC.
| |
| ike 0:aa4d18c090210beb/0000000000000000:1: type=OAKLEY_HASH_ALG, val=SHA.
| |
| ike 0:aa4d18c090210beb/0000000000000000:1: type=AUTH_METHOD, val=PRESHARED_KEY.
| |
| ike 0:aa4d18c090210beb/0000000000000000:1: type=OAKLEY_GROUP, val=MODP1024.
| |
| ike 0:aa4d18c090210beb/0000000000000000:1: ISAKMP SA lifetime=86400
| |
| ike 0:aa4d18c090210beb/0000000000000000:1: SA proposal chosen, matched gateway hard-l2tp
| |
| ike 0:hard-l2tp: created connection: 0x282d5d8 5 193.193.135.66->193.193.135.65:500.
| |
| ike 0:hard-l2tp:1: selected NAT-T version: RFC 3947
| |
| ike 0:hard-l2tp:1: cookie aa4d18c090210beb/aa460884c9a5fe4a
| |
| ike 0:hard-l2tp:1: out AA4D18C090210BEBAA460884C9A5FE4A0110020000000000000000BC0D00003800000001000000010000002C01010001000000240501000080010005800200028004000280030001800B0001000C0004000070800D0000144A131C81070358455C5728F20E95452F0D000014AFCAD71368A1F1C96B8696FC775701000D0000148299031757A36082C6A621DE000503F30D0000144048B7D56EBCE88525E7DE7F00D6C2D3000000184048B7D56EBCE88525E7DE7F00D6C2D3C0000000
| |
| ike 0:hard-l2tp:1: sent IKE msg (ident_r1send): 193.193.135.66:500->193.193.135.65:500, len=188, id=aa4d18c090210beb/aa460884c9a5fe4a
| |
| ike 0: comes 193.193.135.65:500->193.193.135.66:500,ifindex=5....
| |
| ike 0: IKEv1 exchange=Identity Protection id=aa4d18c090210beb/aa460884c9a5fe4a len=260
| |
| ike 0: in AA4D18C090210BEBAA460884C9A5FE4A0410020000000000000001040A000084D99329CD327B8970838CA205A0D5307B49B5A0C18A7F3F8C71394C32BB4492D791D618C1485CE08FF5B40B95C9F8DADE7E9144546DC28EDBADBEE66718F9FA1F7C3AAB8B77E070F1A69F625C0EC2BC3A41CA3BB187623E698577D59BEC1444DEB2652BF8F4F34C0D2BA0ECB40E0E8CFB946CDB83FA67F48C7C18D53269EF714140000344876B5805539226D8FB6263DFC82CFC1141327CCC4FC24DC4DF2A5854856BFF6DD8FE365166AE4959FFFE5E36ED1A97414000018C3CB105F2081C65ABC507A6360B420BD6C63A504000000186E3667290C70AF03888129732489F98C2F2008F1
| |
| ike 0:hard-l2tp:1: responder:main mode get 2nd message...
| |
| ike 0:hard-l2tp:1: NAT not detected
| |
| ike 0:hard-l2tp:1: out AA4D18C090210BEBAA460884C9A5FE4A0410020000000000000000E40A0000841F28ABB22B649D97C001F6E6612A4F6F188F62B588094828060FECB6BA59E4FAD2F5A9BC6C9FA77801B35ECD8EB56DF560F3F0BAE9399D274AA0CB525299B012E89F553F46C810DE2FDD3A404F562A59A8E7C3B6713D2908B97C2504B3DD273D2D3D896E6315BC2E7D626E9B8086277F1E512729C800D5A802A51A39A79A16A01400001432115D76A5E09AE02500AC02F8C49809140000186E3667290C70AF03888129732489F98C2F2008F100000018C3CB105F2081C65ABC507A6360B420BD6C63A504
| |
| ike 0:hard-l2tp:1: sent IKE msg (ident_r2send): 193.193.135.66:500->193.193.135.65:500, len=228, id=aa4d18c090210beb/aa460884c9a5fe4a
| |
| ike 0:hard-l2tp:1: ISAKMP SA aa4d18c090210beb/aa460884c9a5fe4a key 24:EF2D0070A61A6C8EB939A82DCE075EB1C9A070E8829BA92B
| |
| ike 0: comes 193.193.135.65:500->193.193.135.66:500,ifindex=5....
| |
| ike 0: IKEv1 exchange=Identity Protection id=aa4d18c090210beb/aa460884c9a5fe4a len=68
| |
| ike 0: in AA4D18C090210BEBAA460884C9A5FE4A0510020100000000000000440065EB6A84C809391146CD1777FE42557EFDF98F26BA183E2AB1BE971A452F6B60D81286CABBDB9D
| |
| ike 0:hard-l2tp:1: responder: main mode get 3rd message...
| |
| ike 0:hard-l2tp:1: dec AA4D18C090210BEBAA460884C9A5FE4A0510020100000000000000440800000C01000000C1C187410000001819096E5122DC4ABADA92067C7F4DC42A2F1CC50100000000
| |
| ike 0:hard-l2tp:1: peer identifier IPV4_ADDR 193.193.135.65
| |
| ike 0:hard-l2tp:1: PSK authentication succeeded
| |
| ike 0:hard-l2tp:1: authentication OK
| |
| ike 0:hard-l2tp:1: enc AA4D18C090210BEBAA460884C9A5FE4A0510020100000000000000450800001102000000686172642D6C3274700000001886098E8AED21AF61BAB552DBB9569262FD04D41A
| |
| ike 0:hard-l2tp:1: out AA4D18C090210BEBAA460884C9A5FE4A05100201000000000000004CEF653FA7AE0CB6D675FE349D124EFA7E37373798AF9C9A18E48754FAA77BB95D4771603A1BAA34CF2140219EB4DA8D95
| |
| ike 0:hard-l2tp:1: sent IKE msg (ident_r3send): 193.193.135.66:500->193.193.135.65:500, len=76, id=aa4d18c090210beb/aa460884c9a5fe4a
| |
| ike 0:hard-l2tp: adding new dynamic tunnel for 193.193.135.65:500
| |
| ike 0:hard-l2tp_0: added new dynamic tunnel for 193.193.135.65:500
| |
| ike 0:hard-l2tp_0:1: established IKE SA aa4d18c090210beb/aa460884c9a5fe4a
| |
| ike 0:hard-l2tp_0: DPD disabled, not negotiated
| |
| ike 0:hard-l2tp_0:1: no pending Quick-Mode negotiations
| |
| ike 0: comes 193.193.135.65:500->193.193.135.66:500,ifindex=5....
| |
| ike 0: IKEv1 exchange=Quick id=aa4d18c090210beb/aa460884c9a5fe4a:00000001 len=468
| |
| ike 0: in AA4D18C090210BEBAA460884C9A5FE4A0810200100000001000001D432F0F9FCBD2C46118A392716D67F4C136C97AC63BCC60BBE53F566DBD3B7D5B68C1FB3108F5577D7830F30904245D2BCA5F670FFCC961CF0B6C3DEFBE5365AA7BA96C7353BCCA7A0E3C9DC2459C416EF5607CBF56C547F229F4DFF1866042D7B693635F6109417312373D569E974567485C281FFCACE6895DF2422C645EF70AA03309958AA0C587B8AF18AD11D6393E6D1584122964EE63B3459F2D42F2714459C116744DFC2804F56398BBA315963709D79C84AA30841C9DDAD5930ACBF2EB96DC0E0FE621DFD7D4902921C403DC1880CEB89801D55A0F4E062F2D80CEE16761A7DAD6939F98D76F9880BC75BEBF4BA298D876330CDAFFC84CADD184E5B53CD26AC3520BD6C021EA8F9152CE7B83DF3D974CB212E8EE66FFEA7213715C51A41F527BCA12094958DF3CA8A0D2EEBD5F1CFBAD68F778EE90D2618726224B4AF6F86770FAEBCDA09545CF60F67BFCF8F6D8618107ECD32A4254E14C40CB08A943B9DBED98432C400C589B918EC535099E19AED2AA3F9807FBC6AC12C8C998049AC7E6E9C99A002B75B23AEA4E53AA483DF6C5B5131305BEBF895A3D88E3AB7EF49C92B2F8255570314F4BA6E3EC7D9CB3D8AB0225DB20427D4
| |
| ike 0:hard-l2tp_0:1:1: responder received first quick-mode message
| |
| ike 0:hard-l2tp_0:1: dec AA4D18C090210BEBAA460884C9A5FE4A0810200100000001000001D401000018A0A03E654E031396EADA663B7EDD0C07050619C60A00014C000000010000000102000038010304018E16AE560000002C010C0000800400028006010080050002800100010002000400000E1080010002000200040003D09002000038020304018E16AE560000002C010C0000800400028006008080050002800100010002000400000E1080010002000200040003D09002000034030304018E16AE5600000028010300008004000280050002800100010002000400000E1080010002000200040003D09002000034040304018E16AE5600000028010200008004000280050002800100010002000400000E1080010002000200040003D09002000034050304018E16AE5600000028010B00008004000280050002800100010002000400000E1080010002000200040003D09000000034060204018E16AE5600000028010300008004000280050002800100010002000400000E1080010002000200040003D09005000034840342D236C88544D55B7B99D07D9E34612A31304D65B32E1D6015A37DBDCA32C2C6730E89B702175EFF83F3F7937E650500000C011106A5C1C187410000000C011106A5C1C187420000000000000000
| |
| ike 0:hard-l2tp_0:1:1: peer proposal is: peer:17:193.193.135.65-193.193.135.65:1701, me:17:193.193.135.66-193.193.135.66:1701
| |
| ike 0:hard-l2tp_0:1:hard-l2tp:1: trying
| |
| ike 0:hard-l2tp_0:1:1: transport mode, override with 17:193.193.135.66-193.193.135.66:1701 -> 17:193.193.135.65-193.193.135.65:0
| |
| ike 0:hard-l2tp_0:1:hard-l2tp:1: matched phase2
| |
| ike 0:hard-l2tp_0:1:hard-l2tp:1: dynamic client
| |
| ike 0:hard-l2tp_0:1:hard-l2tp:1: my proposal:
| |
| ike 0:hard-l2tp_0:1:hard-l2tp:1: proposal id = 1:
| |
| ike 0:hard-l2tp_0:1:hard-l2tp:1: protocol id = IPSEC_ESP:
| |
| ike 0:hard-l2tp_0:1:hard-l2tp:1: trans_id = ESP_AES_CBC (key_len = 256)
| |
| ike 0:hard-l2tp_0:1:hard-l2tp:1: encapsulation = ENCAPSULATION_MODE_TRANSPORT
| |
| ike 0:hard-l2tp_0:1:hard-l2tp:1: type = AUTH_ALG, val=MD5
| |
| ike 0:hard-l2tp_0:1:hard-l2tp:1: trans_id = ESP_3DES
| |
| ike 0:hard-l2tp_0:1:hard-l2tp:1: encapsulation = ENCAPSULATION_MODE_TRANSPORT
| |
| ike 0:hard-l2tp_0:1:hard-l2tp:1: type = AUTH_ALG, val=SHA1
| |
| ike 0:hard-l2tp_0:1:hard-l2tp:1: trans_id = ESP_AES_CBC (key_len = 192)
| |
| ike 0:hard-l2tp_0:1:hard-l2tp:1: encapsulation = ENCAPSULATION_MODE_TRANSPORT
| |
| ike 0:hard-l2tp_0:1:hard-l2tp:1: type = AUTH_ALG, val=SHA1
| |
| ike 0:hard-l2tp_0:1:hard-l2tp:1: incoming proposal:
| |
| ike 0:hard-l2tp_0:1:hard-l2tp:1: proposal id = 1:
| |
| ike 0:hard-l2tp_0:1:hard-l2tp:1: protocol id = IPSEC_ESP:
| |
| ike 0:hard-l2tp_0:1:hard-l2tp:1: trans_id = ESP_AES_CBC (key_len = 256)
| |
| ike 0:hard-l2tp_0:1:hard-l2tp:1: encapsulation = ENCAPSULATION_MODE_TRANSPORT
| |
| ike 0:hard-l2tp_0:1:hard-l2tp:1: type = AUTH_ALG, val=SHA1
| |
| ike 0:hard-l2tp_0:1:hard-l2tp:1: incoming proposal:
| |
| ike 0:hard-l2tp_0:1:hard-l2tp:1: proposal id = 2:
| |
| ike 0:hard-l2tp_0:1:hard-l2tp:1: protocol id = IPSEC_ESP:
| |
| ike 0:hard-l2tp_0:1:hard-l2tp:1: trans_id = ESP_AES_CBC (key_len = 128)
| |
| ike 0:hard-l2tp_0:1:hard-l2tp:1: encapsulation = ENCAPSULATION_MODE_TRANSPORT
| |
| ike 0:hard-l2tp_0:1:hard-l2tp:1: type = AUTH_ALG, val=SHA1
| |
| ike 0:hard-l2tp_0:1:hard-l2tp:1: incoming proposal:
| |
| ike 0:hard-l2tp_0:1:hard-l2tp:1: proposal id = 3:
| |
| ike 0:hard-l2tp_0:1:hard-l2tp:1: protocol id = IPSEC_ESP:
| |
| ike 0:hard-l2tp_0:1:hard-l2tp:1: trans_id = ESP_3DES
| |
| ike 0:hard-l2tp_0:1:hard-l2tp:1: encapsulation = ENCAPSULATION_MODE_TRANSPORT
| |
| ike 0:hard-l2tp_0:1:hard-l2tp:1: type = AUTH_ALG, val=SHA1
| |
| ike 0:hard-l2tp_0:1:hard-l2tp:1: negotiation result
| |
| ike 0:hard-l2tp_0:1:hard-l2tp:1: proposal id = 3:
| |
| ike 0:hard-l2tp_0:1:hard-l2tp:1: protocol id = IPSEC_ESP:
| |
| ike 0:hard-l2tp_0:1:hard-l2tp:1: trans_id = ESP_3DES
| |
| ike 0:hard-l2tp_0:1:hard-l2tp:1: encapsulation = ENCAPSULATION_MODE_TRANSPORT
| |
| ike 0:hard-l2tp_0:1:hard-l2tp:1: type = AUTH_ALG, val=SHA1
| |
| ike 0:hard-l2tp_0:1:hard-l2tp:1: using transport mode.
| |
| ike 0:hard-l2tp_0:1:hard-l2tp:1: replay protection enabled
| |
| ike 0:hard-l2tp_0:1:hard-l2tp:1: SA life soft seconds=3586.
| |
| ike 0:hard-l2tp_0:1:hard-l2tp:1: SA life hard seconds=3600.
| |
| ike 0:hard-l2tp_0:1:hard-l2tp:1: IPsec SA selectors #src=1 #dst=1
| |
| ike 0:hard-l2tp_0:1:hard-l2tp:1: src 0 7 17:193.193.135.66-193.193.135.66:1701
| |
| ike 0:hard-l2tp_0:1:hard-l2tp:1: dst 0 7 17:193.193.135.65-193.193.135.65:0
| |
| ike 0:hard-l2tp_0:1:hard-l2tp:1: add dynamic IPsec SA selectors
| |
| ike 0:hard-l2tp_0:1: add route 193.193.135.65/255.255.255.255 oif hard-l2tp_0(78) metric 15 priority 0
| |
| ike 0:hard-l2tp_0:1:hard-l2tp:1: tunnel 1 of VDOM limit 0/0
| |
| ike 0:hard-l2tp_0:1:hard-l2tp:1: add IPsec SA: SPIs=050b610b/8e16ae56
| |
| ike 0:hard-l2tp_0:1:hard-l2tp:1: IPsec SA dec spi 050b610b key 24:CECD897C1D6CEA9445C7CB218B1F308591B79CF14AFF8ED9 auth 20:F799C64C21DF1F50B9EA765625FE356DEFF8B2AF
| |
| ike 0:hard-l2tp_0:1:hard-l2tp:1: IPsec SA enc spi 8e16ae56 key 24:F810F84E22FDFB2C0FD865039F21B338D7A040DAF26A4010 auth 20:E6690E6A422F4F252232280A0352CCD5D9613595
| |
| ike 0:hard-l2tp_0:1:hard-l2tp:1: transport mode encapsulation is enabled
| |
| ike 0:hard-l2tp_0:1:hard-l2tp:1: added IPsec SA: SPIs=050b610b/8e16ae56
| |
| ike 0:hard-l2tp_0:1:hard-l2tp:1: sending SNMP tunnel UP trap
| |
| ike 0:hard-l2tp_0:1: enc AA4D18C090210BEBAA460884C9A5FE4A0810200100000001000000A0010000186F56BECBF32164E50F7E3C99A1BFA94AB531936F0A00004000000001000000010000003403030401050B610B00000028010300008004000280050002800100010002000400000E1080010002000200040003D09005000014BBE04D5BEEE0A28771BFF7A8646EF79C0500000C011106A5C1C187410000000C011106A5C1C18742
| |
| ike 0:hard-l2tp_0:1: out AA4D18C090210BEBAA460884C9A5FE4A0810200100000001000000A436DA1BBE5DCD1822EFFBA4C5CBD4002E4EBA549B603DDBD4FEDEA1AB0E4DD12093BE8EC9C3A00687353EAADF5ACF357FEBD217403E01FB93EC91A931DF78905791473F33B11AE78C5A34ABEA4AEE22CC3E9BBA7502964D009611B721896DAC8E90E9343B93E419CE5D65DCDFB430BA72E5BA65E74BD6B5752E1D3AB4EFA835CA1EFE8F581712192D
| |
| ike 0:hard-l2tp_0:1: sent IKE msg (quick_r1send): 193.193.135.66:500->193.193.135.65:500, len=164, id=aa4d18c090210beb/aa460884c9a5fe4a:00000001
| |
| ike 0: comes 193.193.135.65:500->193.193.135.66:500,ifindex=5....
| |
| ike 0: IKEv1 exchange=Quick id=aa4d18c090210beb/aa460884c9a5fe4a:00000001 len=60
| |
| ike 0: in AA4D18C090210BEBAA460884C9A5FE4A08102001000000010000003CF7762C20EDCE39718739F6CA9090C9541F4B52C64B0C5F8AFD6F259E3958B849
| |
| ike 0:hard-l2tp_0:1: dec AA4D18C090210BEBAA460884C9A5FE4A08102001000000010000003C0000001814ABFDB8D0724DADF789C2FE776B54C96CA5AF200000000000000000
| |
| ike 0:hard-l2tp_0:hard-l2tp:1: send SA_DONE SPI 0x8e16ae56
| |
| ike 0:hard-l2tp: IP 198.18.4.129 added
| |
| ike 0:hard-l2tp: IP 198.18.4.129 removed
| |
| ike 0:hard-l2tp: IP 198.18.4.129 added
| |
| ike shrank heap by 122880 bytes
| |
|
| |
| Wenn eine Verbindung beendet wird so wird folgendes ausgegeben:
| |
|
| |
| ike 0:hard-l2tp: IP 198.18.4.129 removed
| |
| ike 0: comes 193.193.135.65:500->193.193.135.66:500,ifindex=5....
| |
| ike 0: IKEv1 exchange=Informational id=aa4d18c090210beb/aa460884c9a5fe4a:1cf649be len=76
| |
| ike 0: in AA4D18C090210BEBAA460884C9A5FE4A081005011CF649BE0000004CD31698F8D44776ACCE84EAD31BFCB734D1C2B1AFE9D363C2957B6B9E23CC83BA9F3952F01FCD9723A29DEAEFE52FF559
| |
| ike 0:hard-l2tp_0:1: dec AA4D18C090210BEBAA460884C9A5FE4A081005011CF649BE0000004C0C000018BAA486A10C0011F351DC7B67F6962DD85BD6E2840000001000000001030400018E16AE560000000000000000
| |
| ike 0:hard-l2tp_0:1: recv IPsec SA delete, spi count 1
| |
| ike 0:hard-l2tp_0: deleting IPsec SA with SPI 8e16ae56
| |
| ike 0:hard-l2tp_0:hard-l2tp: deleted IPsec SA with SPI 8e16ae56, SA count: 0
| |
| ike 0:hard-l2tp_0: sending SNMP tunnel DOWN trap for hard-l2tp
| |
| ike 0:hard-l2tp_0:1: del route 193.193.135.65/255.255.255.255 oif hard-l2tp_0(78) metric 15 priority 0
| |
| ike 0:hard-l2tp_0:hard-l2tp: delete
| |
| ike 0: comes 193.193.135.65:500->193.193.135.66:500,ifindex=5....
| |
| ike 0: IKEv1 exchange=Informational id=aa4d18c090210beb/aa460884c9a5fe4a:d067794b len=84
| |
| ike 0: in AA4D18C090210BEBAA460884C9A5FE4A08100501D067794B00000054D4E69E9BAA9C908F4F57CD39D1124581CC953A68AECACF09047E627775B79959051814136840D0CEE26E25790FD32F61CE8ACAABD2625ECA
| |
| ike 0:hard-l2tp_0:1: dec AA4D18C090210BEBAA460884C9A5FE4A08100501D067794B000000540C000018101526418B5431D9C02B4DF551019E33EBA220200000001C0000000101100001AA4D18C090210BEBAA460884C9A5FE4A00000000
| |
| ike 0:hard-l2tp_0:1: recv ISAKMP SA delete aa4d18c090210beb/aa460884c9a5fe4a
| |
| ike 0:hard-l2tp_0: deleting
| |
| ike 0:hard-l2tp_0: flushing
| |
| ike 0:hard-l2tp_0: sending SNMP tunnel DOWN trap
| |
| ike 0:hard-l2tp_0: flushed
| |
| ike 0:hard-l2tp_0: delete dynamic
| |
| ike 0:hard-l2tp_0: deleted
| |
|
| |
| Nach erfolgreichen Debug Mode sollte dieser wieder deaktiviert sowie zurück gesetzt werden:
| |
|
| |
| '''Deaktiviere den Debug Modus mit dem gesetzen Debug Filter'''
| |
|
| |
| # diagnose debug disable
| |
|
| |
| '''Setze alle Debug Filter zurück'''
| |
|
| |
| # diagnose debug reset
| |
|
| |
| == DDoS ==
| |
|
| |
| === Wie kann ich unter FortiOS 5.4 eine DDos Policy Konfigurieren und was muss ich berücksichtigen? ===
| |
|
| |
| Neu steht unter FortiOS 5.4 die Konfiguration der DDos Policy auch für kleinere Devices wieder im Mgmt. Web Interface zur Verfügung. Dabei stellt die DDoS Policy neu unter FortiOS 5.4 ein klassische Policy dar in der "top down first match wins" gilt. Die entsprechende Menüposition befindet sich unter:
| |
|
| |
| Policy & Objects > IPv4 Policy
| |
|
| |
| Ist diese Menüposition nicht vorhanden muss dieses Feature aktiviert werden. Wie dies durchgeführt wird siehe nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.4-5.6:FAQ#Unter_FortiOS_5.4_sehe_ich_.C3.BCber_das_Web_Gui_nicht_alle_Features_wie_kann_ich_diese_aktivieren.2Fdeaktivieren.3F]]
| |
|
| |
| Für eine DDoS Policy Konfiguration muss in erster Linie folgendes berücksichtigt werden: Eine DDoS Policy auf einem FortiOS wird nicht innerhalb der Stateful Inspection Firewall Policy abgearbeitet sondern diese wird vor der Stateful Inspection Firewall Policy abgearbeitet! Dies bedeutet wiederum: Möchte man einen Host im internen Bereich vor einer DDos Attake schützen und dieser Host wurde in der Stateful Inspection Firewall Policy anhand eines VIP Objekts für Destination NAT konfiguriert, muss in der DDos Policy die externe Public IPv4 Adresse des Host benutzt werden und nicht die interne IPv4 Adresse des Hosts da die DDos Policy vor der Stateful Inspection Firewal Policy abgearbeitet wird! Somit kann anhand einer explizit konfigurierten DDoS Policy ein spezifischer Service wie zB SMTP anhand "tcp_src_session" und/oder "tcp_dst_session" geschützt werden. Dies bedeutet: Wenn ein SMTP MX Server auf dem TCP Port 25 geschützt werden soll um zu verhindern das durch ein SMTP Denial of Service Attacke versucht wird von einer bestimmten Source eine Vielzahl von SMTP Verbindung aufzubauen, können diese SMTP Verbindungen anhand "tcp_src_session" für den SMTP Server limitiert werden und somit eine Denial of Service Attacke für den SMTP Service verhindert werden. Dabei spielt der definierte "threshold" eine wichtige Rolle denn durch diese Definition wird die maximal Anzahl möglicher Verbindungen definiert. Für einige Anomalien gilt eine spezifische Zeit dh. wenn innerhalb dieser Zeit der "thresold" überschritten wird so wird die definierte Aktion ausgeführt. In den verschiedenen Anomalien gilt deshalb betreffend "thresold" folgende Definition:
| |
|
| |
| • Flooding Anomaly Wenn die Anzahl der Session für eine einzelne Destination innerhalb einer Sekunden den "threshold"
| |
| erreicht, wird für die Destination ein "Flooding Anomaly" ausgelöst!
| |
|
| |
| • Scan Anomaly Wenn die Anzahl der Sessions von einer einzelnen Source innerhalb einer Sekunden den "threshold"
| |
| erreicht, wird für die Source eine "Scan Anomaly" ausgelöst!
| |
|
| |
| • Source Session Limit Wenn die Anzahl gleichzeitiger Session von einer einzelnen Source den "thresold" erreicht, ist die
| |
| Limite für diese einzelne Source erreicht und es wird eine "Source Session Limit Anomaly" ausgelöst!
| |
|
| |
| • Destination Session Limit Wenn die Anzahl gleichzeitiger Session für eine einzelne Destination den "thresold" erreicht, ist
| |
| die Limite für diese einzelne Destination ereicht und es wird eine "Destination Limit Anomaly"
| |
| ausgelöst!
| |
|
| |
| Nachfolgendes Beispiel zeigt wie eine DDoS Policy konfiguriert wird anhand "tcp_src_session" und einem "thresold 100" sowie dem Service TCP Port 25. Dieses Beispiel limitiert somit eine Source IPv4 Adresse die für eine Verbindung auf den SMTP MX Server benutzt wird auf 100 maximale Verbindungen. Werden diese maximalen Verbindungen durch eine Source IPv4 Adresse überschritten (thresold), wird die Source IPv4 Adresse zB für eine bestimmte Zeit geblockt resp. in "quarantine" gesetzt:
| |
|
| |
| # config firewall DoS-policy
| |
| # edit [Vergebe eine entsprechende Policy ID zB "1"]
| |
| # set interface [Definiere ein entsprechendes Interface zB "wan1"]
| |
| # set srcaddr "all"
| |
| # set dstaddr [Name des Adress Objekts für den SMTP Server zB "host-local-198.18.0.92-32"]
| |
| # set service [Name des Service Objekts für den SMTP Service zB "SMTP"]
| |
| # config anomaly
| |
| # edit [Name der Anomaly zB für Source IPv4 Adressen "tcp_src_session"]
| |
| # set status enable
| |
| # set log enable
| |
| # set action block
| |
| # set quarantine attacker
| |
| # set quarantine-expiry [Definition der Zeitdauer für Quarantine des Attackers; 0-365d für Tage; 0-24h für Stunden; 0-1440m für Minuten; Minimum 0d0h1m]
| |
| # set quarantine-log enable
| |
| # set threshold [Definiere Maximal Anzahl Möglicher Verbindungen für Source IPv4 Adresse 0-2147483647; Beispiel 100]
| |
| # end
| |
| # end
| |
|
| |
| Diese Konfiguration kann zwar über Mgmt. Web Interface durchgeführt werden jedoch ist die "quarantine" Konfiguration nur über CLI verfügbar:
| |
|
| |
| Policy & Objects > IPv4 Policy > Create New
| |
|
| |
| [[Datei:Fortinet-2055.jpg]]
| |
|
| |
| Wir empfehlen Grundsätzlich nach den spezifischen DDoS Policy Rules eine generelle DDoS Policy Rule zu implementieren um einen generellen grundsätzlichen Schutz zu bieten. Diese kann über CLI wie folgt konfiguriert werden:
| |
|
| |
| # config firewall DoS-policy
| |
| # edit [Vergebe eine entsprechende Policy ID zB "1"]
| |
| # set interface [Definiere ein entsprechendes Interface zB "wan1"]
| |
| # set srcaddr "all"
| |
| # set service "ALL"
| |
| # config anomaly
| |
| # edit "tcp_syn_flood"
| |
| # set status enable
| |
| # set log enable
| |
| # set action block
| |
| # set threshold 2000
| |
| # next
| |
| # edit "tcp_port_scan"
| |
| # set status enable
| |
| # set threshold 1000
| |
| # next
| |
| # edit "tcp_src_session"
| |
| # set status enable
| |
| # set threshold 5000
| |
| # next
| |
| # edit "tcp_dst_session"
| |
| # set status enable
| |
| # set threshold 5000
| |
| # next
| |
| # edit "udp_flood"
| |
| # set status enable
| |
| # set log enable
| |
| # set action block
| |
| # set threshold 2000
| |
| # next
| |
| # edit "udp_scan"
| |
| # set status enable
| |
| # set threshold 2000
| |
| # next
| |
| # edit "udp_src_session"
| |
| # set status enable
| |
| # set threshold 5000
| |
| # next
| |
| # edit "udp_dst_session"
| |
| # set status enable
| |
| # set threshold 5000
| |
| # next
| |
| # edit "icmp_flood"
| |
| # set status enable
| |
| # set log enable
| |
| # set action block
| |
| # set threshold 250
| |
| # next
| |
| # edit "icmp_sweep"
| |
| # set status enable
| |
| # set threshold 100
| |
| # next
| |
| # edit "icmp_src_session"
| |
| # set status enable
| |
| # set threshold 300
| |
| # next
| |
| # edit "icmp_dst_session"
| |
| # set status enable
| |
| # set threshold 1000
| |
| # next
| |
| # edit "ip_src_session"
| |
| # set threshold 5000
| |
| # next
| |
| # edit "ip_dst_session"
| |
| # set threshold 5000
| |
| # next
| |
| # edit "sctp_flood"
| |
| # set threshold 2000
| |
| # next
| |
| # edit "sctp_scan"
| |
| # set threshold 1000
| |
| # next
| |
| # edit "sctp_src_session"
| |
| # set threshold 5000
| |
| # next
| |
| # edit "sctp_dst_session"
| |
| # set threshold 5000
| |
| # next
| |
| # end
| |
| # next
| |
| # end
| |
|
| |
| Möchte man diese DDoS Policy über Mgmt. Web Interface konfigurieren muss folgendes konfiguriert werden:
| |
|
| |
| Policy & Objects > IPv4 Policy > Create New
| |
|
| |
| [[Datei:Fortinet-2056.jpg]]
| |
|
| |
| Diese DDoS Policy die einen generellen Schutz bietet jedoch nicht Service spezifisch ist kann auf kleineren FortiGate Devices ohne Probleme angewendet werden! Wie schon erwähnt gilt unter FortiOS 5.4 für die DDoS Policy "top down first match wins". Aus diesem Grund muss auf die Rheienfolge der DDoS Policy Rules geachtet werden dh. in unserem Beispiel ist die spezifischen DDoS Policy Rules an erster Stelle und die generelle DDoS Policy am Ende. Muss die Reihenfolge verändert werden kann anhand eines Drag & Drop in der Spalte Seq# über Mgmt. Web Interface die durchgeführt werden. Dies wird folgendermassen durchgeführt:
| |
|
| |
| # config firewall DoS-policy
| |
| # get
| |
| == [ 1 ]
| |
| policyid: 1
| |
| == [ 2 ]
| |
| policyid: 2
| |
|
| |
| # move [Gebe die entsprechende Policy ID an] [after | before] [Gebe die entsprechende Policy ID an]
| |
|
| |
| Für unsere Beispiel ergiebt sich folgende Konfiguration betreffend der Reihenfolge:
| |
|
| |
| [[Datei:Fortinet-2057.jpg]]
| |
|
| |
| === Wie finde ich unter FortiOS 5.4 für eine DDos Policy heraus welche Werte ich in einer Anomaly benutzen soll? ===
| |
|
| |
| Wenn eine DDoS Policy konfguriert wird im generellen dh. nicht für einen spezifischen Service können die Standard "threshold" verwendet werden sofern keine speziellen Bedürfnisse resp. Topology existiert. Wie diese generelle DDoS Policy zu konfigurieren ist siehe nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.4-5.6:FAQ#Wie_kann_ich_unter_FortiOS_5.4_eine_DDos_Policy_Konfigurieren_und_was_muss_ich_ber.C3.BCcksichtigen.3F]]
| |
|
| |
| Wenn jedoch spezielle Bedürfnisse existieren (Topology) und/oder für spezielle Services die geschützt werden sollen keine Anhaltspunkte existieren fragt sich wie ein "threshold" zu ermittelnt ist. Im obigen Link wird anhand eines SMTP MX Servers gezeigt wie der SMTP Service anhand "tcp_src_session" für maximale Verbindungen einer Source geschützt werden kann! Will man nun den "threshold" ermitteln kann die gleiche Konfiguration durchgeführt werden jedoch wir die "action" auf Pass gesetzt und das Log aktiviert. So kann nach einiger Zeit über die Logs eine Auswertung vollzogen werden um den maximalen "threshold" zu ermitteln. Für das Beispiel des SMTP MX Servers im vorhergehenden Link würde das folgende Konfiguration bedeuten:
| |
|
| |
| # config firewall DoS-policy
| |
| # edit [Vergebe eine entsprechende Policy ID zB "1"]
| |
| # set interface [Definiere ein entsprechendes Interface zB "wan1"]
| |
| # set srcaddr "all"
| |
| # set dstaddr [Name des Adress Objekts für den SMTP Server zB "host-local-198.18.0.92-32"]
| |
| # set service [Name des Service Objekts für den SMTP Service zB "SMTP"]
| |
| # config anomaly
| |
| # edit [Name der Anomaly zB für Source IPv4 Adressen "tcp_src_session"]
| |
| # set status enable
| |
| # set log enable
| |
| # set action '''pass'''
| |
| # set quarantine '''none'''
| |
| # set threshold [Definiere Maximal Anzahl Möglicher Verbindungen für Source IPv4 Adresse 0-2147483647; Beispiel 100]
| |
| # end
| |
| # end
| |
|
| |
| Dabei spielt der definiert "threshold" insofern nur eine Nebenrolle da die "action" auf "pass" gesetzt wurde dennoch sollte ein entsprechender "thresold" gesetzt werden. Wenn ein "threshold" erreicht wird so wird ein entsprechender Log Eintrag erstellt im "Anomaly" Log. Dieses findet man unter folgender Position:
| |
|
| |
| Log & Report > Anomaly
| |
|
| |
| [[Datei:Fortinet-2058.jpg]]
| |
|
| |
| Im diesem Beispiel wurde der "threshold" für "tcp_syn_flood" überschritten! Anhand dieser Informationen kann der "threshold" ermittelt werden! Betreffend Logs ist jedoch folgendes zur Berücksichtigen: Wenn zB eine "flood" Attacke durchgeführt wird so wird nicht für alle Verbindungen ein Log Eintrag erstellt da dieses Vorgehen Memory und/oder CPU des FortiGate Devices beeinträchtigen würde. Stattdessen werden die Logs periodisch korreliert resp. Zusammengezogen (1 Log Eintrag für jeden Incident über 50). Dies bedeutet wiederum: Es wird für alle Verbindungen betreffend einer IPv4 Adresse periodisch (ca. 1 Minute) 1 Log Eintrag erstellt. Diese Funktion wird in den Logs anhand "count" indiziert. Zusätzlich steht über CLI anhand "diagnose" weitere Befehle zur Verfügung. Weitere Informationen dazu siehe nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.4-5.6:FAQ#Wie_kann_ich_unter_FortiOS_5.4_f.C3.BCr_eine_DDos_Policy_weitere_Informationen_auflisten_f.C3.BCr_einen_Analyse.3F]]
| |
|
| |
| === Wie kann ich unter FortiOS 5.4 für eine DDos Policy weitere Informationen auflisten für einen Analyse? ===
| |
|
| |
| Dieser Artikel wurde in das 6.0|6.2 FAQ verschoben:
| |
| [[FortiGate:FAQ#Wie_kann_ich_f.C3.BCr_eine_DoS_Policy_weitere_Informationen_auflisten_f.C3.BCr_einen_Analyse.3F]]
| |
|
| |
| == Botnet ==
| |
|
| |
| === Wie kann ich unter FortiOS 5.4 für eine FortiGate Verbindungen zu "botnet" Servern blocken oder überwachen? ===
| |
|
| |
| Unter FortiOS 5.2 wurde die "botnet" Funktion innerhalb des Antivirus Profiles konfiguriert. Dies steht unter FortiOS 5.4 nicht mehr zur Verfügung. Neu steht die "botnet" Funktion Hauptsächlich für ein Interface zur Verfügung und kann über das Mgmt. Web Interface konfiguriert werden:
| |
|
| |
| Network > Interfaces > [Markiere das entsprechende Interface zB "wan1"] > Edit > Scan Outgoing Connections to Botnet Sites > [Disable | Block | Monitor]
| |
|
| |
| [[Datei:Fortinet-1665.jpg]]
| |
|
| |
| [[Datei:Fortinet-1666.jpg]]
| |
|
| |
| Wenn die Konfiguration für ein entsprechendes Interface auf der CLI durchgeführt werden möchte, muss folgendes durchgeführt werden:
| |
|
| |
| # config system interface
| |
| # edit [Name des entsprechende Interface zB "wan1"]
| |
| # set scan-botnet-connections [disable | block | monitor]
| |
| # end
| |
|
| |
| Durch diese Konfiguration wird der "outgoing" Traffic zB für "wan2" betreffend "botnet" Server kontrolliert dh. werden IP's betreffend "botnet" Server angegangen, werden diese gemäss Konfiguration geblockt und ein Log Eintrag geschrieben oder durch Monitor ein Log Eintrag geschrieben. Wenn Die Funktion aktiviert wird erscheint ein Hinweis, dass sich zB 9 "botnet" Server in der Liste befindet. Diese "botnet" Server Liste wird von der FortiGuard Funktion (FortiGuard Mobile Security oder FortiGuard Enterprise Bundle) auf den neusten Stand gebracht. Somit muss FortiGuard Mobile Security oder FortiGuard Enterprise Bundle lizensiert werden damit diese Funktion der "botnet" Server zur Verfügung steht (Neu ab 1. Oktober 2016). Um die aktive "botnet" Server Liste einzusehen steht auf dem Mgmt. Web Interface folgende Position zur Verfügung:
| |
|
| |
| System > FortiGuard > License Information > Botnet Definitions > View List
| |
|
| |
| [[Datei:Fortinet-1667.jpg]]
| |
|
| |
| [[Datei:Fortinet-1668.jpg]]
| |
|
| |
| Wird die Funktion auf einem Interface zB "wan2" aktiviert kann diese nachträglich getestet werden. Dazu öffne einen Browser und gebe gemäss "botnet" Liste zB folgendes ein:
| |
|
| |
| http://46.166.135.177
| |
|
| |
| Diese IP ist in der "botnet" Liste aufgeführt für Port 80. Ausgehend davon, dass für den Traffic und die entsprechende Firewall Policy das "log" aktiviert ist, wird im Antivirus Log ein entsprechender Eintrag geschrieben:
| |
|
| |
| Log & Report > Antivirus
| |
|
| |
| [[Datei:Fortinet-1669.jpg]]
| |
|
| |
| Diese "botnet" Server Liste kann über CLI und "diagnose" Kommando eingesehen sowie manipuliert werden. Weitere Informationen dazu siehe nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.4-5.6:FAQ#Wie_kann_ich_unter_FortiOS_5.4_die_.22botnet.22_Informationen_auf_einer_FortiGate_auflisten.2C_suchen_usw.3F]]
| |
|
| |
| Diese Liste wird innerhalb der Autoupdate Funktion von FortiGuard auf den neusten Stand gehalten. Um diese Liste manuell auf den neusten Stand zu bringen kann folgender Befehl auf der CLI ausgeführt werden:
| |
|
| |
| # execute update-now
| |
|
| |
| Wie schon erwähnt wurde die "botnet" Funktion aus dem Antivirus Profile verschoben und als Funktion auf den Interfaces implementiert. Zusätzlich jedoch kann die Funktion, wenn diese nicht auf den Interfaces aktiviert werden kann, auf einer Firewall Policy, Explizit Proxy, Interface Policy oder Sniffer aktiviert werden um eine granularere Konfiguration zu erreichen. Dies kann über CLI konfiguriert werden:
| |
|
| |
| # config firewall policy
| |
| # edit [Gebe eine entsprechende Policy ID an]
| |
| # set scan-botnet-connections [disable | block | monitor]
| |
| # end
| |
|
| |
| # config firewall explicit-proxy-policy
| |
| # edit [Gebe eine entsprechende Policy ID an]
| |
| # set scan-botnet-connections [disable | block | monitor]
| |
| # end
| |
|
| |
| # Firewall interface policy
| |
| # config firewall interface-policy
| |
| # edit [Gebe eine entsprechende Policy ID an]
| |
| # set scan-botnet-connections [disable | block | monitor]
| |
| # end
| |
|
| |
| # Firewall sniffer
| |
| # config firewall sniffer
| |
| # edit [Gebe eine entsprechende Policy ID an]
| |
| # set scan-botnet-connections [disable | block | monitor]
| |
| # end
| |
|
| |
| === Wie kann ich unter FortiOS 5.4 die "botnet" Informationen auf einer FortiGate auflisten, suchen usw? ===
| |
|
| |
| Wenn die "botnet" Server Liste auf einem FortiOS 5.4 aufgelistet werden soll, kann dies über Mgmt. Web Interface durchgeführt werden. Dazu wähle folgendes:
| |
|
| |
| System > FortiGuard > License Information > Botnet Definitions > View List
| |
|
| |
| [[Datei:Fortinet-1667.jpg]]
| |
|
| |
| [[Datei:Fortinet-1668.jpg]]
| |
|
| |
| Ueber Mgmt. Web Interface ist es jedoch nicht möglich weitere Manipulationen betreffend dieser "botnet" Liste auszuführen. Neu unter FortiOS 5.4 steht ein entsprechendes "diagnose" Kommando auf der CLI zur verfügung das dies ermöglich:
| |
|
| |
| # diagnose sys botnet [stat | list | find | flush | reload | file]
| |
|
| |
| Dies verschiedenen zur Verfügung stehenden Optionen haben folgende Bedeutung:
| |
|
| |
| • stat the number of botnet entries in the kernel.
| |
| • list list the botnet entries.
| |
| • find find a botnet entry by ip address, port number, protocol etc.
| |
| • flush flush botnet entries from the kernel.
| |
| • reload reload botnet file into the kernel
| |
| • file botnet file diagnostics.
| |
|
| |
| Somit wenn die Liste der "botnet" Server auf einem FortiOS für eine FortiGate eingesehen werden möchte kann folgendes ausgeführt werden:
| |
|
| |
| # diagnose sys botnet stat
| |
| The amount of botnet entries in kernel is: 9
| |
|
| |
| # diagnose sys botnet list
| |
| Read 9 botnet entry:
| |
| 0. proto=UDP ip=24.5.5.251, port=16471, name_id=2, rule_id=32
| |
| 1. proto=TCP ip=46.166.135.177, port=80, name_id=0, rule_id=12
| |
| 2. proto=UDP ip=67.190.137.250, port=16471, name_id=2, rule_id=32
| |
| 3. proto=UDP ip=75.74.227.4, port=16471, name_id=2, rule_id=32
| |
| 4. proto=UDP ip=108.131.43.62, port=27697, name_id=1, rule_id=2
| |
| 5. proto=TCP ip=113.38.129.254, port=16471, name_id=2, rule_id=4
| |
| 6. proto=UDP ip=113.38.129.254, port=16471, name_id=2, rule_id=32
| |
| 7. proto=UDP ip=160.79.57.246, port=16471, name_id=2, rule_id=32
| |
| 8. proto=TCP ip=178.162.183.185, port=80, name_id=0, rule_id=1
| |
|
| |
| Möchte man diese "botnet" Liste komplett löschen resp. ein Flush durchführen, kann folgendes ausgeführt werden:
| |
|
| |
| # diagnose sys botnet flush
| |
|
| |
| Danach erscheint in der "botnet" Liste kein Eintrag mehr:
| |
|
| |
| # diagnose sys botnet list
| |
|
| |
| Um die aktuelle "botnet" Liste neu zu laden gebe folgendes ein:
| |
|
| |
| # diagnose sys botnet reload
| |
|
| |
| Danach ist die "botnet" Liste wieder aktuell:
| |
|
| |
| # diagnose sys botnet list
| |
| Read 9 botnet entry:
| |
| 0. proto=UDP ip=24.5.5.251, port=16471, name_id=2, rule_id=32
| |
| 1. proto=TCP ip=46.166.135.177, port=80, name_id=0, rule_id=12
| |
| 2. proto=UDP ip=67.190.137.250, port=16471, name_id=2, rule_id=32
| |
| 3. proto=UDP ip=75.74.227.4, port=16471, name_id=2, rule_id=32
| |
| 4. proto=UDP ip=108.131.43.62, port=27697, name_id=1, rule_id=2
| |
| 5. proto=TCP ip=113.38.129.254, port=16471, name_id=2, rule_id=4
| |
| 6. proto=UDP ip=113.38.129.254, port=16471, name_id=2, rule_id=32
| |
| 7. proto=UDP ip=160.79.57.246, port=16471, name_id=2, rule_id=32
| |
| 8. proto=TCP ip=178.162.183.185, port=80, name_id=0, rule_id=1
| |
|
| |
| Anhand der "find" Option kann in der "botnet" Liste nach einem entsprechenden Eintrag gesucht werden:
| |
|
| |
| # diagnose sys botnet find [Entsprechende IPv4 Adresse "46.166.135.177"] [Botnet Port zB "80"] [Botnet Protokoll zB "6"]
| |
| Read 1 botnet entry:
| |
| 0. proto=TCP ip=46.166.135.177, port=80, name_id=0, rule_id=12
| |
|
| |
| Um zusätzliche Informationen über die verschiedenen "botnet" Einträge zu erhalten kann "file" benützt werden zB mit nachfolgenden Kommando kann das "botnet" File das als Grundlage dient für die Liste ausgelesen werden:
| |
|
| |
| # diagnose sys botnet file stat
| |
| File name: /etc/idsbot.rules
| |
| File format: Compressed(ZIP)
| |
| File compressed size: 141
| |
| File decompressed size: 204
| |
| BOTNET version=01.000 2012-05-28 22:51:00
| |
| Botnet name table id: 0x1
| |
| Botnet name number: 3
| |
| Botnet name size: 47(0x2f)
| |
| Botnet TCP table id: 0x10002
| |
| Botnet TCP entry number: 3
| |
| Botnet TCP entry size: 36(0x24)
| |
| Botnet UDP table id: 0x10003
| |
| Botnet UDP entry number: 6
| |
| Botnet UDP entry size: 72(0x48)
| |
|
| |
| Für die verschiedenen "botnet" Einträge im "output" für "diagnose sys botnet list" werden "name_id's" vergeben. Diese "name_id" gibt Auskunft um welche Art es sich handelt. Um diese "name_id" auszulsen kann folgendes Kommando benutzt werden:
| |
|
| |
| # diagnose sys botnet list
| |
| Read 9 botnet entry:
| |
| 0. proto=UDP ip=24.5.5.251, port=16471, name_id=2, rule_id=32
| |
| 1. proto=TCP ip=46.166.135.177, port=80, '''name_id=0''', rule_id=12
| |
| 2. proto=UDP ip=67.190.137.250, port=16471, name_id=2, rule_id=32
| |
| 3. proto=UDP ip=75.74.227.4, port=16471, name_id=2, rule_id=32
| |
| 4. proto=UDP ip=108.131.43.62, port=27697, '''name_id=1''', rule_id=2
| |
| 5. proto=TCP ip=113.38.129.254, port=16471, name_id=2, rule_id=4
| |
| 6. proto=UDP ip=113.38.129.254, port=16471, name_id=2, rule_id=32
| |
| 7. proto=UDP ip=160.79.57.246, port=16471, name_id=2, rule_id=32
| |
| 8. proto=TCP ip=178.162.183.185, port=80, '''name_id=0''', rule_id=1
| |
|
| |
| # diagnose sys botnet file botnet-name [Gebe eine entsprechende "name_id" an zB "1"]
| |
| Botnet name (ID:1): zbot_udp
| |
|
| |
| # diagnose sys botnet file botnet-name [Gebe eine entsprechende "name_id" an zB "0"]
| |
| Botnet name (ID:0): Spyeye
| |
|
| |
| == Antivirus ==
| |
|
| |
| === Wie kann ich unter FortiOS 5.4 die Antivirus Database/Engine auf den neusten Stand bringen? ===
| |
|
| |
| Alle UTM Databases werden auf einem FortiOS anhand der "autoupdate" Funktion auf den neusten Stand gebracht. Weitere Informationen dazu wie diese Funktion "autoupdate" zu konfigurieren ist und was dabei beachtet werden muss siehe nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.4-5.6:FAQ#Wie_konfiguriere_ich_unter_FortiOS_5.4_die_.22autoupdate.22_Funktion_f.C3.BCr_UTM_Databases.3F]]
| |
|
| |
| Um die Antivirus Database sowie Engine versions Informationen zu überprüfen siehe nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.4-5.6:FAQ#Wie_kann_ich_unter_FortiOS_5.4_f.C3.BCr_die_einzelnen_UTM_Databases_die_Versions_Informationen_.C3.BCberpr.C3.BCfen.3F]]
| |
|
| |
| Für eine Antivirus Database kann ebenfalls ein Downgrade durchgeführt werden. Wie dies durchzuführen ist siehe nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.4-5.6:FAQ#Wie_kann_ich_unter_FortiOS_5.4_f.C3.BCr_die_einzelnen_UTM_Databases_ein_Downgrade_durchf.C3.BChren.3F]]
| |
|
| |
| === Wo finde ich auf der FortiGuard Support Seite mehr Informationen betreffend Antivirus Database Inhalte? ===
| |
|
| |
| Die Antivirus Definition Database von Fortinet resp. FortiGuard beinhaltet unzählig Virus Signaturen und deren Variationen. Um festzustellen ob eine bestimmte Virus Signature in der Antivirus Definition Database enthalten ist oder dessen Variationen gebe auf der folgende Seite den Namen der Virussignatur ein:
| |
|
| |
| http://www.fortiguard.com/encyclopedia/
| |
|
| |
| Danach kann auf den entsprechenden Eintrag ein Mausklick ausgeführt werden und die Beschreibung über den angewählten Eintrag erscheint sowie Zusatzinformationen. Um festzustellen was einer Antivirus Database Version hinzugefügt worden ist kann folgendes durchgeführt werden:
| |
|
| |
| http://www.fortiguard.com/antivirus
| |
|
| |
| Danach wähle oben Rechts die Position "Latest AV Database:". Danach werden die Antivirus Database Versionen unter "AntiVirus Service Updates" aufgelistet und können einzeln angewählt werden. Wenn eine Antivirus Database Version angwählt wird, sieht man welche Virus Signaturen hinzugefügt wurden! Die einzelnen Virus Signaturen können angewählt werden und es werden detaillierte Informationen zu diesem Eintrag aufgelistet. Zusätzlich kann über diese Seite ein entsprechendes File überprüft werden anhand eines "Online Virenscanners". Dazu wähle auf der Seite die Position "Online Virus Scan" oder wähle den folgenden Link:
| |
|
| |
| http://www.fortiguard.com/virusscanner
| |
|
| |
| === Wie kann ich unter FortiOS 5.4 für die Antivirus Engine die Maximale Filegrösse konfigurieren? ===
| |
|
| |
| Die Maximale Filegrösse gibt die maximale Grösse an eines Files das durch die Antivirus Engine benutzt wird um dieses zu Scannen dh. grössere Files werden ignoriert und nicht gescannt! Diese Maximale Filegrösse steht im direkten Zusammenhang mit der Performance auf einer FortiGate dh. die Scan Funktion der Antivirus Engine wird direkt im Memory durchgeführt. Wird die Maximale Filegrösse erhöht, wird somit das Memory durch eine grösser Filegrösse bei Scans zusätzlich belastet. Aus diesem Grund ist es gut zu überlegen ob die Maximale Filegrösse höher gesetzt werden soll als per Standard definiert. Per Standard gilt auf kleineren Devices eine Maximale Filegrösse von 10 MB und auf grösseren Device eine Maximale Filegrösse von 15 MB. Der Unterschied des gefahren Potential zwischen 5 MB und zB 10 MB sind Minimal. Dies wird im nachfolgenden Dokument aufgezeigt:
| |
|
| |
| [[Datei:MalwareFileSize.pdf]]
| |
|
| |
| Die Maximale Filegrösse der Antivirus Engine wird nicht im Antivirus Profile konfiguriert sondern innerhalb des Protocol Options. Die Konfiguration kann für jeden Service wie zB http, ftp usw. einzeln konfiguriert werden und steht nur unter CLI zur Verfügung:
| |
|
| |
| # config firewall profile-protocol-options
| |
| # edit [Name des entsprechenden Profiles]
| |
| # config [http | ftp | imap | mapi | pop3 | smtp | nntp ]
| |
| # set oversize-limit [Maximale Grösse in Memory in MB; Standard 10]
| |
| # set uncompressed-oversize-limit [Maximale Grösse in Memory in MB eines entpackten Archives; Standard 10]
| |
| # set uncompressed-nest-limit [Maximale Tiefe von Archiven 2 - 100; Standard 12]
| |
| # set scan-bzip2 [enable | disable]
| |
| # set block-page-status-code [Setzt den Return Code für HTTP; Standard 200]
| |
| # end
| |
| # end
| |
|
| |
| Grundsätzlich steht für "oversize-limit" auf einem FortiGate Device max. 10% des Memory zur Verfügung. Dies bedeutet: Um die Maximale Grösse von "oversize-limit" auf einem FortiGate Device abhängig vom zur Verfügung stehenden Memory zu ermitteln, kann folgendes durchgeführt werden:
| |
|
| |
| # config firewall profile-protocol-options
| |
| # edit [Name des entsprechenden Profiles]
| |
| # config [http | ftp | imap | mapi | pop3 | smtp | nntp ]
| |
| # set oversize-limit ?
| |
| <ingeger> please input integer value (1-183)
| |
|
| |
| Bei der Option "uncompressed-oversize-limit" handelt es sich um die Maximale Filegrösse im Memory eines entpackten Archives zB zip Files das durch die Antivirus Engine gescannt wird. Grundsätzlich kann dieser Konfigurationspunkt mit 0 = unlimited konfiguriert werden, was jedoch explizit durch Fortinet nicht empfohlen wird. Per Standard gilt hier die gleiche Maximale Filegrösse wie für "oversize-limit" konfiguriert dh. 10 MB! Bei der Option "uncompressed-nest-limit" handelt es sich um die maximale Tiefe eines Archives für ein File das durch die Antivirus Engine gescannt wird. Dabei wird als Archiv betreffend "uncompressed-nest-limit" folgendes Archive definiert:
| |
|
| |
| arj, bzip2, cab, gzip, lha, lzh, msc, rar, tar, zip. bzip2 (sofern aktiviert)
| |
|
| |
| Die Option "block-page-status-code" definiert den HTTP Status Code der dem User über den Browser zurück gegeben wird sofern ein File geblockt wird. Wenn ein Maximale File Grösse überschritten wird gemäss Konfiguration "oversize-limit", kann dieses geblockt oder zugelassen werden. Diese Funktion wird gesteuert über die Option "options" innerhalb des Services der Konfiguriert wird für die Protocol Options:
| |
|
| |
| # config firewall profile-protocol-options
| |
| # edit [Name des entsprechenden Profiles]
| |
| # set oversize-log [enable | disable]
| |
| # config [http | ftp | imap | mapi | pop3 | smtp | nntp ]
| |
| # set options [Block Files grösser als Maximale Filegrösse "oversize"]
| |
| # end
| |
| # end
| |
|
| |
| Möchte man die Files zulassen die grösser sind als "oversize-limit" kann folgendes konfiguriert werden:
| |
|
| |
| # config firewall profile-protocol-options
| |
| # edit [Name des entsprechenden Profiles]
| |
| # set oversize-log [enable | disable]
| |
| # config [http | ftp | imap | mapi | pop3 | smtp | nntp ]
| |
| # set options [Allow Files grösser als Maximale Filegrösse "clientcomfort"]
| |
| # set comfort-interval [Zeit in Sekunden nachdem "clientcomfort" gestartet wird 1 - 900; Standard 10]
| |
| # set comfort-amount [Bytes für "comfort-interval" 1 - 10240 Bytes; Standard 1]
| |
| # end
| |
| # end
| |
|
| |
| === Welche "compressed" Formate werden unter FortiOS 5.4 für die Antivirus Engine unterstützt? ===
| |
|
| |
| Wenn auf einem FortOS die Antivirus Engine konfiguriert wird, fragt man sich welche "compressed" Formate die Antivirus Engine auf einem FortiOS unterstützt. Nachfolgendes offizielle Dokument von Fortinet zeigt welche "compressed" Formate in der Antivirus Engine unterstützt werden und liefert Wichtig Zusatzinformationen:
| |
|
| |
| [[Datei:fortios-scanning-of-archive-compressed-files.pdf]]
| |
|
| |
| Nachfolgend ein Kurzüberblick über die unterstützten Formate:
| |
|
| |
| '''Archive / Compression Formats'''
| |
| • ZIP
| |
| • ZIPX (BZIP2, INFLATE64, LZMA, LZMA2)
| |
| • JAR
| |
| • RAR
| |
| • 7Z
| |
| • BZIP2
| |
| • CAB
| |
| • TAR
| |
| • GZIP
| |
| • ARJ
| |
| • LZH
| |
| • MSC (Microsoft Compress)
| |
| • SIS (Symbian Installer Package)
| |
| • SISX (Symbian Installer Package for 9.x)
| |
| • SWF
| |
| • NSIS (Nullsoft Installer Package)
| |
| • E32Image (Symbian 9.x, compressed with custom LZW algorithm)
| |
| • XZ (starting with AV engine v4.3)
| |
| • CPIO (starting with AV engine v4.3)
| |
| • AutoIt (starting with AV engine 5.0)
| |
| • TNEF ( starting with AV engine 5.1)
| |
|
| |
| '''Self Extracting Formats'''
| |
| • SFX ZIP
| |
| • SFX RAR
| |
| • SFX LZH
| |
| • SFX ARJ
| |
| • SFX CAB
| |
| • SFX 7Z
| |
|
| |
| '''Static Packers'''
| |
| • UPX
| |
| • ASPACK
| |
| • PETITE
| |
| • FSG
| |
|
| |
| '''Generic/Custom Packers'''
| |
| • UPACK
| |
| • Mew
| |
| • PECompact
| |
| • ASProtect
| |
| • PecBundle
| |
| • PEncrypt
| |
| • ACProtect
| |
|
| |
| '''Document Formats'''
| |
| • PDF
| |
| • MS OFFICE
| |
| • RTF
| |
| • WORDML
| |
| • MIME
| |
|
| |
| === Welche Database und Funktionen können unter FortiOS 5.4 für die Antivirus Engine Aktiviert werden? ===
| |
|
| |
| Für die Antivirus Engine stehen auf einem FortiOS folgende Databases und Funktionen zur Verfügung:
| |
|
| |
| • Normal Database Beinhaltet die "Wild Virus" sowie die "Ueblichen Virus". Für eine normale Absicherung resp.
| |
| Abdeckung gegen Virus sollte diese Database benutzt werden!
| |
|
| |
| • Extended Database Beinhaltet "Wild Virus" sowie eine umfanggreiche Definition der "Zoo Virus". "Zoo Viruses"
| |
| sind in den normalen Studien nicht mehr aufgeführt da sehr selten. Dies bedeutet: diese
| |
| Database sollte nur in High Security Umgebungen benutzt werden!
| |
|
| |
| • Extrem Database Beinhaltet "Wild Virus" sowie der "Zoo Virus". "Zoo-Viruses" sind in den normalen Studien
| |
| nicht mehr aufgeführt da sehr selten. Der Unterschied zum "extended" Modus ist, dass in
| |
| der "extrem" alle "Zoo Virus" enthalten sind. Diese Database sollte nur in High Security
| |
| Umgebungen benutzt werden!
| |
|
| |
| • Mobile Malware Database Beinhaltet Mobile Malware for Android!
| |
|
| |
| • Grayware Funktion Grayware binhaltet die Definitionen für Adware oder auch Dialer genannt!
| |
|
| |
| • Heuristic Verhaltensbasierende Analytische Antivirus Ueberprüfung!
| |
|
| |
| • Scan Mode (Flow Mode) Benützt Flow-Mode mit kompakter Antivirus Database sowie Erweiterte Technik für Antivirus
| |
| Scan!
| |
|
| |
| • Block Executables (Email) Im Antivirus Profile können Executables Files (.exe) für IMAP, POP3, SMTP und MAPI geblockt
| |
| werden!
| |
|
| |
| Um die entsprechende Database für Antivirus Engine zu konfigurieren kann über CLI folgendes durchgeführt werden:
| |
|
| |
| # config antivirus settings
| |
| # set default-db [extended | extreme | normal]
| |
| # set grayware [enable oder disable]
| |
| # end
| |
|
| |
| Dabei ist zu berücksichtigen, dass die "extreme" Database nicht auf kleineren FortiGate Devices zur Verfügung steht. Um die Heuristic zu konfigurieren kann folgendes auf CLI durchgeführt werden:
| |
|
| |
| # config antivirus heuristic
| |
| # set mode [pass | block | disable]
| |
| # end
| |
|
| |
| Die zusätzliche Database für Mobile Malware kann über das entsprechende Antivirus Profile aktiviert werden. Dabei ist zu berücksichtigen, dass diese Database nur Mobile Malware für Android enthält:
| |
|
| |
| # config antivirus profile
| |
| # edit [Name des entsprechenden Antivirus Profile]
| |
| # set mobile-malware-db [enable | disable]
| |
| # end
| |
|
| |
| Beim Quick Mode handelt es sich um einen Antivirus Scan im Flow-Mode analog FortiOS 5.2. Dabei wird aber um die Performance im Antivirus Scan zu steigern eine kompakte Antivirus Database verwendet sowie eine erweiterte Technik im Antivirus Scan selber. Dieser Mode sollte nur dann genutzt werden, wenn Performance Probleme auftreten und der Flow-Mode bereits benutzt wird. Um den Quick Mode zu benutzen muss im entsprechenden Antivirus Profile die Funktion aktiviert werden:
| |
|
| |
| # config antivirus profile
| |
| # edit [Name des entsprechenden Antivirus Profile]
| |
| # set scan-mode [quick | full]
| |
| # end
| |
|
| |
| Möchte man im Antivirus Profile im Zusammenhang mit Email Attachement resp. mit den Services IMAP, POP3, SMTP und MAPI alle Executables dh. .exe Files per Standard blocken, kann diese Funktion für diese Services aktiviert werden dh. durch die Option "virus" wird ein Executable als Virus erkannt. Per Standard ist die Funktion "executables" als "default" konfiguriert dh. Executables werde nicht als Virus erkannt. Executables für andere Services wie zB HTTP zu blocken steht im Antivirus Profile nicht zur Verfügung:
| |
|
| |
| # config antivirus profile
| |
| # edit [Name des entsprechenden Antivirus Profile]
| |
| # config [imap | pop3 | smtp | mapi]
| |
| # set executables [default | virus]
| |
| # end
| |
| # end
| |
|
| |
| Per Standard ist die Heuristic auf "pass" konfiguriert dh. die Heuristic ist aktiviert jedoch wird kein File geblockt! Nachdem die Konfiguration durchgeführt wurde müssen die zusätzlichen Informationen resp. Database auf den neusten Stand gebracht werden. Dies kann anhand folgenden Kommandos durchgeführt werden:
| |
|
| |
| # execute update-now
| |
|
| |
| Nachträglich können die verschiedenen Databases mit deren Versions Informationen überprüft werden. Wie dies durchzuführen ist siehe nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.4-5.6:FAQ#Wie_kann_ich_unter_FortiOS_5.4_f.C3.BCr_die_einzelnen_UTM_Databases_die_Versions_Informationen_.C3.BCberpr.C3.BCfen.3F]]
| |
|
| |
| Ab FortiOS 5.4.1 steht nachfolgendes Kommando zusätzlich zur Verfügung das die einzelnen Antivirus Datenbanken auflistet sowie dessen Inhalt resp. Einträge:
| |
|
| |
| # diagnose antivirus database-info
| |
|
| |
| === Wie kann ich unter FortiOS 5.4 für einen FortiGate Device die Antivirus Funktion konfigurieren? ===
| |
|
| |
| Wenn unter FortiOS 5.4 die Antivirus Funktion konfiguriert ist die Basis dazu folgende Profiles:
| |
|
| |
| • Proxy Options Profile (Unverschlüsselter Traffic für HTTP, SMTP, POP3, IMAP, MAPI, FTP, DNS sowie NNTP)
| |
| • SSL Inspection Profile (Verschlüsselter Traffic für HTTPS, SMTPS, POP3S, IMAPS sowie FTPS)
| |
| • Antivirus Profile (Unverschlüsselter Traffic für HTTP, SMTP, POP3, IMAP, MAPI, FTP sowie NNTP)
| |
|
| |
| Somit muss zu Beginn verifiziert werden ob verschlüsselter Traffic benutzt werden soll für die Antivirus Funktion. Ist dies der Fall, muss eine "Deep Inspection" konfiguriert werden anhand des SSL Inspection Profiles sowie das Fortinet_CA_SSLProxy Zertifikat des FortiGate Devices muss auf den Host/Clients als "Vertrauenswürdige Stammzertifikat" eingespielt werden. Damit ist gewährleistet das eine "Deep Inspection" angewendet werden kann. Ebenfalls als Grundvoraussetzung muss gewährleistet werden das eine "Deep Inspection" auf einem entsprechenden FortiGate Device betreffend Perfomance benutzt werden kann. Die "Deep Inspection" Funktion sollte aus Performance Gründen nicht für FortiGate Devices kleiner FG-90D konfiguriert resp. angewendet werden! Somit muss als Grundlage für die Antivirus Funktion im ersten Schritt ein Proxy Options Profile und/oder ein SSL Inspection Profile konfiguriert werden. In diesen Profiles sollten nur Services/Porst aktiviert werden für die die Antivirus Funktion aktiviert wird resp. in einer Firewall Policy Rule konfiguriert wird:
| |
|
| |
| '''Proxy Options Profile Konfiguration'''
| |
|
| |
| Security Profiles > Proxy Options > Create New
| |
|
| |
| [[Datei:Fortinet-2049.jpg]]
| |
|
| |
| # config firewall profile-protocol-options
| |
| # edit [Name des entsprechenden Proxy Options Profile zB "local-default.intra"]
| |
| # set comment [Gebe einen Kommentar ein zB "Unencrypted default profile local-sg0e0"]
| |
| # unset replacemsg-group
| |
| # set oversize-log enable
| |
| # set switching-protocols-log enable
| |
| # config http
| |
| # set ports 80
| |
| # set status enable
| |
| # set inspect-all disable
| |
| # set options clientcomfort
| |
| # set comfort-interval 10
| |
| # set comfort-amount 1
| |
| # set range-block disable
| |
| # unset post-lang
| |
| # set fortinet-bar disable
| |
| # set streaming-content-bypass enable
| |
| # set switching-protocols bypass
| |
| # set oversize-limit 10
| |
| # set uncompressed-oversize-limit 10
| |
| # set uncompressed-nest-limit 12
| |
| # set scan-bzip2 disable
| |
| # set block-page-status-code 200
| |
| # set retry-count 0
| |
| # end
| |
| # config ftp
| |
| # set ports 21
| |
| # set status enable
| |
| # set inspect-all disable
| |
| # set options clientcomfort
| |
| # set comfort-interval 10
| |
| # set comfort-amount 1
| |
| # set oversize-limit 10
| |
| # set uncompressed-oversize-limit 10
| |
| # set uncompressed-nest-limit 12
| |
| # set scan-bzip2 disable
| |
| # end
| |
| # config imap
| |
| # set ports 143
| |
| # set status enable
| |
| # set inspect-all disable
| |
| # set options fragmail
| |
| # set oversize-limit 10
| |
| # set uncompressed-oversize-limit 10
| |
| # set uncompressed-nest-limit 12
| |
| # set scan-bzip2 disable
| |
| # end
| |
| # config mapi
| |
| # set ports 135
| |
| # set status enable
| |
| # set options fragmail
| |
| # set oversize-limit 10
| |
| # set uncompressed-oversize-limit 10
| |
| # set uncompressed-nest-limit 12
| |
| # set scan-bzip2 disable
| |
| # end
| |
| # config pop3
| |
| # set ports 110
| |
| # set status enable
| |
| # set inspect-all disable
| |
| # set options fragmail
| |
| # set oversize-limit 10
| |
| # set uncompressed-oversize-limit 10
| |
| # set uncompressed-nest-limit 12
| |
| # set scan-bzip2 disable
| |
| # end
| |
| # config smtp
| |
| # set ports 25
| |
| # set status enable
| |
| # set inspect-all disable
| |
| # set options fragmail
| |
| # set oversize-limit 10
| |
| # set uncompressed-oversize-limit 10
| |
| # set uncompressed-nest-limit 12
| |
| # set scan-bzip2 disable
| |
| # set server-busy disable
| |
| # end
| |
| # config nntp
| |
| # set ports 119
| |
| # set status enable
| |
| # set inspect-all disable
| |
| # unset options
| |
| # set oversize-limit 10
| |
| # set uncompressed-oversize-limit 10
| |
| # set uncompressed-nest-limit 12
| |
| # set scan-bzip2 disable
| |
| # end
| |
| # config dns
| |
| # set ports 53
| |
| # set status enable
| |
| # end
| |
| # config mail-signature
| |
| # set status disable
| |
| # unset signature
| |
| # end
| |
| # set rpc-over-http enable
| |
| # end
| |
|
| |
| '''SSL Inspection Profile Konfiguration'''
| |
|
| |
| Security Profiles > SSL Inspection > Create New
| |
|
| |
| [[Datei:Fortinet-2050.jpg]]
| |
|
| |
| # config firewall ssl-ssh-profile
| |
| # edit [Wähle ein entsprechendes SSL Inspection Profile zB "local-default.intra"]
| |
| # set comment [Gebe einen Kommentar ein zB "Encrypted default profile local-sg0e0"]
| |
| # config ssl
| |
| # set inspect-all disable
| |
| # set allow-invalid-server-cert disable
| |
| # set untrusted-cert block
| |
| # end
| |
| # config https
| |
| # set ports 443
| |
| # set status deep-inspection
| |
| # set client-cert-request bypass
| |
| # set unsupported-ssl bypass
| |
| # set allow-invalid-server-cert disable
| |
| # set untrusted-cert block
| |
| # end
| |
| # config ftps
| |
| # set ports 990
| |
| # set status deep-inspection
| |
| # set client-cert-request bypass
| |
| # set unsupported-ssl bypass
| |
| # set allow-invalid-server-cert disable
| |
| # set untrusted-cert block
| |
| # end
| |
| # config imaps
| |
| # set ports 993
| |
| # set status deep-inspection
| |
| # set client-cert-request inspect
| |
| # set unsupported-ssl bypass
| |
| # set allow-invalid-server-cert disable
| |
| # set untrusted-cert block
| |
| # end
| |
| # config pop3s
| |
| # set ports 995
| |
| # set status deep-inspection
| |
| # set client-cert-request inspect
| |
| # set unsupported-ssl bypass
| |
| # set allow-invalid-server-cert disable
| |
| # set untrusted-cert block
| |
| # end
| |
| # config smtps
| |
| # set ports 465
| |
| # set status deep-inspection
| |
| # set client-cert-request inspect
| |
| # set unsupported-ssl bypass
| |
| # set allow-invalid-server-cert disable
| |
| # set untrusted-cert block
| |
| # set whitelist disable
| |
| # end
| |
| # config ssl-exempt
| |
| # end
| |
| # set server-cert-mode re-sign
| |
| # set caname Fortinet_CA_SSLProxy
| |
| # set untrusted-caname Fortinet_CA_Untrusted
| |
| # set certname Fortinet_CA_SSLProxy
| |
| # end
| |
| # config ssl-server
| |
| # end
| |
| # set ssl-invalid-server-cert-log enable
| |
| # set rpc-over-https enable
| |
| # set use-ssl-server disable
| |
| # end
| |
|
| |
| '''Antivirus Profile Konfiguration'''
| |
|
| |
| Zusätzlich zur Antivirus Profile Konfiguration ist nachfolgender Artikel zu berücksichtigen der die zur Verfügung stehenden Funktionen
| |
| der Antivirus Engine zeigt:
| |
|
| |
| [[FortiGate-5.4-5.6:FAQ#Welche_Database_und_Funktionen_k.C3.B6nnen_unter_FortiOS_5.4_f.C3.BCr_die_Antivirus_Engine_Aktiviert_werden.3F]]
| |
|
| |
| Security Profiles > AntiVirus > Create New
| |
|
| |
| [[Datei:Fortinet-2051.jpg]]
| |
|
| |
| # config antivirus profile
| |
| # edit [Wähle das entsprechende Antivirus Profile zB "local-default.intra"]
| |
| # set comment [Gebe einen Kommentar ein zB "Scan and delete default profile local-sg0e0"]
| |
| # unset replacemsg-group
| |
| # set inspection-mode proxy
| |
| # set mobile-malware-db enable
| |
| # config http
| |
| # set options scan
| |
| # unset archive-block
| |
| # set archive-log encrypted corrupted multipart nested mailbomb unhandled
| |
| # set emulator enable
| |
| # end
| |
| # config ftp
| |
| # set options scan
| |
| # unset archive-block
| |
| # set archive-log encrypted corrupted multipart nested mailbomb unhandled
| |
| # set emulator enable
| |
| # end
| |
| # config imap
| |
| # set options scan
| |
| # unset archive-block
| |
| # set archive-log encrypted corrupted multipart nested mailbomb unhandled
| |
| # set emulator enable
| |
| # set executables default
| |
| # end
| |
| # config pop3
| |
| # set options scan
| |
| # unset archive-block
| |
| # set archive-log encrypted corrupted multipart nested mailbomb unhandled
| |
| # set emulator enable
| |
| # set executables default
| |
| # end
| |
| # config smtp
| |
| # set options scan
| |
| # unset archive-block
| |
| # set archive-log encrypted corrupted multipart nested mailbomb unhandled
| |
| # set emulator enable
| |
| # set executables default
| |
| # end
| |
| # config mapi
| |
| # set options scan
| |
| # unset archive-block
| |
| # set archive-log encrypted corrupted multipart nested mailbomb unhandled
| |
| # set emulator enable
| |
| # set executables default
| |
| # end
| |
| # config nntp
| |
| # set options scan
| |
| # unset archive-block
| |
| # set archive-log encrypted corrupted multipart nested mailbomb unhandled
| |
| # set emulator enable
| |
| # end
| |
| # config nac-quar
| |
| # set infected none
| |
| # set log enable
| |
| # end
| |
| # set av-virus-log enable
| |
| # set av-block-log enable
| |
| # end
| |
|
| |
| Die entsprechenden Profiles sind nur konfiguriert und diese können nun zu einer entsprechenden Firewall Policy Rule hinzugefügt werden. Dabei ist folgendes zu beachten: In der Firewall Policy Rule sollten die entsprechenden Services/Ports explizit definiert werden dh. es sollte auf Service "All" verzichtet werden. Nachfolgendes Beispiel zeigt eine Firewall Policy Rule für HTTP/HTTPS in der für Unverschlüsselter Traffic (Proxy Options Profile) sowie Verschlüsselter Traffic (SSL Inspection Profile) für das Antivirus Profile aktiviert wurde:
| |
|
| |
| Policy & Objects > IPv4 Policy > Create New
| |
|
| |
| [[Datei:Fortinet-2052.jpg]]
| |
|
| |
| Nachträglich sollte die Konfiguration getestet werden dh. über folgende Seite kann anhand der EICAR Informationen getestet werden ob ein Virus über die Konfiguration erkannt wird:
| |
|
| |
| http://www.eicar.org/85-0-Download.html
| |
|
| |
| Ist die der Fall wird über den Web Browser folgende Meldung angezeigt:
| |
|
| |
| [[Datei:Fortinet-2053.jpg]]
| |
|
| |
| === Wie kann ich verhindern das unter FortiOS 5.4 für HTTP "Streaming Content" die Antivirus Funktion benützt wird? ===
| |
|
| |
| Wenn über HTTP Streaming Content aufgerufen wird so versucht die Antivirus Engine diesen Streaming Content zu scannen sofern ein Antivirus Profile für HTTP in einer entsprechenden Firewall Policy Rule konfiguriert wurde. Möchte man dies verhindern so kann das Protocol Options Profile, das zusammen mit dem Antivirus Profile in der entsprechenden Firewall Policy Rule benutzt wird, durch folgende Konfiguration ein Antivirus Scan verhindert werden:
| |
|
| |
| # config firewall profile-protocol-options
| |
| # edit [Name des entsprechenden Profiles]
| |
| # config http
| |
| # set streaming-contentbypass [enable | disable]
| |
| # end
| |
| # end
| |
|
| |
| Diese Konfiguration gilt jedoch nur für HTTP und nicht für andere Protokolle resp. Services wie zB HTTPS. Eine andere Möglichkeit ein Scanning durch die Antivirus Engine zu verhindern ist den MIME Header heranzuziehen um einen Scan zu verhindern. Die Funktion ein Scan über MIME Header zu verhindern steht jedoch innerhalb der Antivirus Funktion nicht zur Verfügung. Ein MIME Header kann stattdessen über die "content-header" Funktion des WebFilter konfiguriert werden. Um die Konfiguration durchzuführen muss als erster Schritt der MIME Header des Content eruiert werden. Dies kann zB über WireShark durchgeführt werden. Nachfolgend die MIME Header Informationen aus WireShark betreffend YouTube:
| |
|
| |
| Hypertext Transfer Protocol
| |
| HTTP/1.0 200 OK\r\n
| |
| Request Version: HTTP/1.0
| |
| Response Code: 200
| |
| Server: DCLK-AdSvr\r\n
| |
| '''Content-Type: video/x-ms-asf\r\n'''
| |
| X-Google-Inred-Content-Type: video/x-ms-asf\r\n
| |
| Content-Length: 410\r\n
| |
| Content-Encoding: gzip\r\n
| |
|
| |
| Hypertext Transfer Protocol
| |
| HTTP/1.1 200 OK\r\n
| |
| Request Version: HTTP/1.1
| |
| Response Code: 200
| |
| Last-Modified: Mon, 14 Sep 2009 00:40:51 GMT\r\n
| |
| '''Content-Type: video/x-flv\r\n'''
| |
| Content-Length: 200994\r\n
| |
| Connection: close\r\n
| |
| Content-Disposition: attachment; filename="video.flv"\r\n
| |
| Expires: Thu, 29 Oct 2009 09:06:24 GMT\r\n
| |
| Cache-Control: public,max-age=3600\r\n
| |
| Date: Thu, 29 Oct 2009 08:06:24 GMT\r\n
| |
| Server: gvs 1.0\r\n
| |
|
| |
| Die relevanten Informationen um einen "content-header" Konfiguration durchzuführen, sind die "Content-Type" Informationen. In unserem Beispiel sind das die folgenden Positionen:
| |
|
| |
| Content-Type: video/x-ms-asf\r\n
| |
| Content-Type: video/x-flv\r\n
| |
|
| |
| In der "content-header" Konfiguration muss anhand "Regex" die nötigen Informationen betreffend dem MIME Header der konfiguriert werden soll definiert werden. Möchte man alle video sowie audio MIME Header definieren so muss folgendes definiert werden:
| |
|
| |
| video\\/.*
| |
| audio\\/.*
| |
|
| |
| Das Zeichen "/" stellt im RegEx ein Sonderzeichen dar. Dadurch kann nicht einfach "video/" definiert werden da Sonderzeichen mit "\\" escaped werden müssen! Nun kann die "content-header" Konfiguration durchgeführt werden:
| |
|
| |
| # config webfilter content-header
| |
| # edit [Gebe einen Integer an zB "1"]
| |
| # set comment [Setze einen Kommentar zB "Exclude Video Audio Antivirus"]
| |
| # config entries
| |
| # edit "video\\/.*"
| |
| # set action [allow | block | exempt]
| |
| # next
| |
| # edit "audio\\/.*"
| |
| # set action [allow | block | exempt]
| |
| # next
| |
| # end
| |
| # set name [Setze einen Namen für den "content-header" zB "video-audio-exempt"]
| |
| # next
| |
| # end
| |
|
| |
| Durch die Konfiguration "exempt" wird der definierte MIME Header resp. "content-header" vom Antivirus Scan ausgeschlossen. Nun kan dieser "content-header" innerhalb eines WebFilters konfiguriert werden:
| |
|
| |
| # config webfilter profile
| |
| # edit [Wähle den Namen des entsprechenden WebFilter Profiles]
| |
| # config web
| |
| # set content-header-list [Gebe den entsprechenden Integer an für "content-header"]
| |
| # end
| |
| # next
| |
| # end
| |
|
| |
| Nun kann der entsprechende WebFilter zu der entsprechenden Firewall Policy Rule hinzugefügt werden!
| |
|
| |
| === Wie kann ich unter FortiOS 5.4 für einen FortiGate Device eine Antivirus Quarantine konfigurieren? ===
| |
|
| |
| Ausgehend davon das ein FortiGate Device über eine Disk verfügt für die ein "disk" Logging aktiviert werden kann oder die Logs zu einem FortiAnalyzer übermittelt werden, kann eine Quarantine für Antivirus konfiguriert werden. Die Quarantine Funktion wird innerhalb des Antivirus Profiles für die verschiedenen Services/Ports mit folgenden Befehl aktiviert:
| |
|
| |
| # config antivirus profile
| |
| # edit [Name des entsprechenden Antivirus Profile]
| |
| # config [http | ftp | imap | pop3 | smtp | mapi | nntp]
| |
| # set options [avmonitor | quarantine | scan]
| |
| # end
| |
| # end
| |
|
| |
| Um eine Quarantine zu aktivieren muss "quarantine" für die Option "options" aktiviert werden wobei dies nur ermöglicht wird, wenn "disk" Logging aktiviert wird für den FortiGate Device und/oder ein Logging für FortiAnalyzer. Danach kann die Qurantine über folgende Kommandos in der CLI konfiguriert werden:
| |
|
| |
| # config antivirus quarantine
| |
| # set agelimit [Maximale Zeitdauer in Stunden für Quarantine Files wenn "destination" NULL ist; 0 - 479]
| |
| # set maxfilesize [Setze Maximale Filegrösse für Quarantine in MB 0 - 500 MB; 0 = Unlimited]
| |
| # set quarantine-quota [Quota Space in MB 0 - 17599427]
| |
| # set drop-infected [imap | smtp | pop3 | http | ftp | im | nntp | imaps | smtps | pop3s | https | ftps | mapi | mm1 | mm3 | mm4 | mm7]
| |
| # set store-infected [imap | smtp | pop3 | http | ftp | im | nntp | imaps | smtps | pop3s | https | ftps | mapi | mm1 | mm3 | mm4 | mm7]
| |
| # set drop-blocked [imap | smtp | pop3 | http | ftp | nntp | imaps | smtps | pop3s | ftps | mapi | mm1 | mm3 | mm4 | mm7]
| |
| # set store-blocked [imap | smtp | pop3 | http | ftp | nntp | imaps | smtps | pop3s| ftps | mapi | mm1 | mm3 | mm4 | mm7]
| |
| # set drop-heuristic [imap | smtp | pop3 | http | ftp | im | nntp | imaps | smtps | pop3s | https | ftps | mapi | mm1 | mm3 | mm4 | mm7]
| |
| # set store-heuristic [imap | smtp | pop3 | http | ftp | im | nntp | imaps | smtps | pop3s | https | ftps | mapi | mm1 | mm3 | mm4 | mm7]
| |
| # set lowspace [drop-new | ovrw-old]
| |
| # set destination [NULL | disk | FortiAnalyzer]
| |
| # end
| |
|
| |
| Für die Konfigurtion "destination" gilt: NULL deaktiviert die Quarantine. Die Option "disk" steht nur dann zur Verfügung wenn der FortiGate Device für Logging die "disk" aktiviert werden kann. FortiAnalyzer steht dann zur Verfügung wenn Logging über FortiAnalyzer konfiguriert wurde.
| |
|
| |
| === Wie kann ich unter FortiOS 5.4 für einen FortiGate Device die Antivirus Funktion vorübergehend deaktivieren? ===
| |
|
| |
| Wenn aus irgendwelchen Gründen die konfigurierte Antivirus Funktion deaktiviert werden soll kann dies anhand folgenden CLI Kommandos durchgeführt werden:
| |
|
| |
| # diagnose antivirus bypass [on | off]
| |
|
| |
| Durch dieses Kommando wird somit auf globaler Ebene einen Bypass für die Antivirus Funktion aktiviert resp. deaktiviert ohne die Konfiguration der Antivirus Funktion zu verändern!
| |
|
| |
| == WebFilter ==
| |
|
| |
| === Was muss ich unter FortiOS 5.4 als Grundlage für eine WebFilter Konfiguration beachten? ===
| |
|
| |
| Wenn ein WebFilter auf einem FortiOS 5.4 konfiguriert werden soll, muss zu Beginn die korrekte Zeitzone konfiguriert werden. Wenn die Zeitzone nicht korrekt konfiguriert wurde so benützt die WebFilter Funktion in FortiGuard die falsche Datenbank dh. zB US anstelle der Europäischen Datenbank. Um die korrekte Zeitzone zu konfigurieren siehe nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.4-5.6:FAQ#Wie_kann_ich_auf_einer_FortiGate_unter_FortiOS_5.4_die_Zeitzone_konfigurieren.3F]]
| |
|
| |
| Ebenso gilt als Grundlage für die WebFilter Funktion einwanfrei konfigurierte DNS Server für das FortiOS um die entsprechenden FortiGuard Abfragen durchzuführen. Wie diese FortiOS DNS Server konfiguriert werden siehe nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.4-5.6:FAQ#Wie_konfiguriere_unter_FortiOS_5.4_auf_einer_FortiGate_die_System_DNS_Server.3F]]
| |
|
| |
| Die WebFilter Funktion eines FortiOS basiert auf einer Online Abfrage betreffend Kategorien für FortiGuard dh. es werden Informationen zu FortiGuard gesendet um die Kategorisierung zu überprüfen. Dabei werden vom FortiOS folgende Informationen zu FortiGuard für die Kategorisierung gesendet:
| |
|
| |
| • FortiGate Serien Nummer
| |
| • FortiGate Source IP Adresse
| |
| • Website Komplette URL, inkl. Schema, Hostname und Pfad
| |
|
| |
| Das Resultat der Abfrage dh. die Kategorisierung wird lokal auf dem FortiOS in einen Cache geschrieben. Die zuständige Position die dieses Verhalten steuert ist:
| |
|
| |
| # config system fortiguard
| |
| # set webfilter-force-off [enable | disable]
| |
| # set webfilter-cache-ttl [TTL für WebFilter Cache in Sekunden 300 - 86400; Standard 3600]
| |
| # set webfilter-cache [enable | disable]
| |
| # set webfilter-timeout [Timout in Sekunden für FortiGuard Abfrage 1 - 30; Standard 15]
| |
| # set
| |
| # end
| |
|
| |
| Wenn die WebFilter Abfrage zu FortiGuard aus irgendwelchen Gründen gestoppt werden soll, kann die Option "webfilter-force-off" auf "enable" gesetzt werden. Die Konfiguration "webfilter-cache" steht ebenfalls in Zusammenhang mit der folgenden Konfiguration:
| |
|
| |
| # config webfilter fortiguard
| |
| # set cache-mode [ db-ver | ttl; Standard ttl]
| |
| # set cache-mem-percent [Prozent vom Memory 1 - 15; Standard 2]
| |
| # set cache-prefix-match [enable | disable]
| |
| # set ovrd-auth-port-http [Port für FortiGuard Web Filter HTTP override; Standard 8008]
| |
| # set ovrd-auth-port-https [Port für FortiGuard Web Filter HTTPS override; Standard 8010]
| |
| # set ovrd-auth-port-warning [Port für FortiGuard Web Filter Warning override; Standard 8020]
| |
| # set ovrd-auth-https [enable | disable]
| |
| # set warn-auth-https [enable | disable]
| |
| # set close-ports [enable | disable]
| |
| # set request-packet-size-limit [Maximum Packet Size in bytes für FortiGuard 576 - 10 000; Standard 0 = 1100 bytes]
| |
| # end
| |
|
| |
| Der "cache-mode" ist per Standard auf "ttl" gesetzt was wiederum dem Standard innerhalb der Konfiguration von "system fortiguard" entspricht. Dabei gilt folgendes: Ein entsprechender Eintrag im WebFilter Cache wird gelöscht nach Ablauf des Wertes "ttl" das unter FortiGuard gesetzt wird! Wird der "cache-mode" auf "db-ver" gesetzt anstelle "ttl", wird für den WebFilter Cache eine Datenbank im Memory angelegt in der Grösse des Werts "cache-mem-percent". Die WebFilter Cache Einträge verbleiben in der Datenbank, bis ein entsprechender Eintrag in der Datenbank durch FortiGuard geändert wird oder über FortiGuard verändert wird (force).
| |
|
| |
| === Wie kann ich für FortiOS 5.4 für WebFilter Funktion eine URL/Site bei Fortinet Re-Kategoriesieren lassen? ===
| |
|
| |
| Wenn in einer entsprechenden Firewall Policy ein WebFilter aktiviert ist und ein Host/Client eine Site/URL aufruft, wird diese Site/URL über FortiGuard überprüft. Handelt es sich um eine Site/URL die nicht Kategorisiert wurde fällt diese innerhalb der FortiGate Kategorien unter "Unrated". Wenn nun diese Site/URL Kategorisiert werden möchte in FortiGuard oder eine Site/URL Re-Kategorisiert werden soll da diese falsch Kategorisiert wurde, wähle folgenden Link:
| |
|
| |
| http://www.fortiguard.com/static/webfiltering.html
| |
|
| |
| Gebe auf dieser Seite Rechts Oben unter "URL/IP Rating & Info" die entsprechende Site/URL ein mit dessen FQDN (Fully Qualified Domain Name):
| |
|
| |
| [[Datei:Fortinet-1124.jpg]]
| |
|
| |
| Nachdem die Eingabe bestätigt wurde, wird das entsprechende Resultat angezeigt dh. in welcher Kategorie sich die Site/URL befindet sowie die Statistik der Abfragen in FortiGuard für diese Site/URL. Möchte man nun einen Anfrage für eine Kategorisierung/Re-Kategorisierung absetzen wähle am ende der Seite die endsprechenden Felder aus und bestätige anhand des Captcha:
| |
|
| |
| [[Datei:Fortinet-1125.jpg]]
| |
|
| |
| Jede Anfrage sollte innerhalb von 24 Stunden von Fortinet beantwortet werden. Als Bestätigung erhält man von Fortinet folgendes Email:
| |
|
| |
| -------------- email outpout --------------
| |
|
| |
| Von: FortiGuard Web Filtering Service [mailto:fgweb@fortinet.com]
| |
|
| |
| Dear Fortinet customer,
| |
|
| |
| The website(s) you submitted below has been reviewed and updated:
| |
|
| |
| Submission Date: Thu, 5 Apr 2012 12:08:11 -0700
| |
| URL: http://baeurer.de/
| |
| Suggested Category: Information Technology
| |
| Customer Comment: Baeurer is a ERP wending company and not developing freeware downloads to the internet. Please re-categorize.
| |
| Updated Category: Information Technology
| |
| Update Date: Thu, 5 Apr 2012 19:21:01 -0700
| |
|
| |
| If the suggested category does not meet your expectation, kindly contact us through http://www.fortiguard.com/contactus.html, our Web
| |
| Filtering team would be happy to assist you.
| |
|
| |
| Note that FortiGuard Web Filtering Service categorizes websites, but it is your IT manager who decides what categories to block or allow.
| |
| Therefore, if you would like access to the site, please contact your IT manager.
| |
|
| |
| The rating update may not be effective immediately on your network because of the Web filtering cache. If you would like to have the
| |
| update effective immediately, please contact your network administrator.
| |
|
| |
| Thank you for using FortiGuard Web Filtering Service.
| |
|
| |
| Regards,
| |
|
| |
| FortiGuard Web Filtering Service
| |
| Fortinet Inc.
| |
|
| |
| -------------- email outpout --------------
| |
