|
|
| Zeile 36: |
Zeile 36: |
|
| |
|
| </pre> | | </pre> |
|
| |
| = BLOCKER 1 =
| |
| == IPSEC VPN ==
| |
|
| |
| === Was sind die Grundlagen eines IPSec Tunnels sei es Main Mode oder Aggressive Mode? ===
| |
|
| |
| Wenn ein IPSec Tunnel sei es im Main Mode und/oder Aggressive Mode konfiguriert und später event. anhand eines Troubleshooting untersucht werden muss, ist es Wichtig zu wissen wie ein IPSec Tunnel funktioniert um festzustellen in welchem Schritt des Aufbaus ein IPSec fehlschlägt. Grundsätzlich wird ein IPSec Tunnel in 4 Schritten aufgebaut:
| |
|
| |
| 1. Ein IPSec Tunnel wird dann aufgebaut wenn lokal Traffic initiert wird um als Destination die Remote Seite zu erreichen und
| |
| dadurch ein IPSec Tunnel dazu aufgebaut werden muss um diesen Traffic duch den IPSec Tunnel (encrypted und encapsulated)
| |
| auf die Remote Seite senden zu können.
| |
|
| |
| 2. Phase-1: In der Phase-1 wird eine einzelne IKE SA ausgetauscht (Security Association)
| |
|
| |
| 3. Phase-2: In der Phase-2 werden zwei IKE SA ausgetauscht (Security Association) und zwar je eine für jede Traffic Richtung (in/out)
| |
|
| |
| 4. Traffic wird über den etablierten IPSec Tunnel gesendet (in/out)
| |
|
| |
| Somit in einem Troubleshooting ist es Wichtig zu wissen welcher Schritt konnte nicht durchgeführt werden um das Problem einzugrenzen. Bedeutet wiederum: Ist Phase-1 abgeschlossen ist das Pre-Shared Secret nicht das Problem denn dieser Schritt wurde bereits abgeschlossen. Desweiteren ist es Wichtig zu wissen wie ein Main Mode IPSec funktioniert und ein Aggressive Mode IPSec. Nachfolgend eine Aufstellung betreffend Main/Aggresive Mode:
| |
|
| |
| '''Main Mode Komunikation'''
| |
|
| |
| Für die etablierung des Main Mode werden 6 Packete für die Komunikation benutzt:
| |
|
| |
| [[Datei:Fortinet-1422.jpg]]
| |
|
| |
| 1. Der Client initiert Traffic und der IPSec Tunnel benützt eine oder mehrere Sicherheitsrichtlinien.
| |
| 2. Der Responder selektiert seine Sicherheitsrichtlinien die er benützen will und antwortet.
| |
| 3. Der Client der den Traffic initiert hat sendet seinen Key.
| |
| 4. Der Responder antwortet ebenfalls mit seinem Key.
| |
| 5. Der Client sendet Final seine Peer ID und den hash payload.
| |
| 6. Der Responder antwortet ebenfalls mit der Peer ID und dem hash payload.
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Im Gegensatz zum Aggressive Mode sendet der Initiator seine Peer ID nicht zu Beginn somit kann die FortiGate die IPSec
| |
| Verbindung nicht mit dieser Information identifizieren. Als Identifikation wird die Source IP benutzt. Unter normalen
| |
| Umständen stellt dies kein Problem dar jedoch wenn mehrer Dial-Up Verbindung benutzt werden kann dies Probleme verursachen.
| |
| Weitere Informationen über diese Problematik findet man unter folgenden Artikel:
| |
|
| |
| [[FortiClient:FAQ#Kann_ich_mehrer_Client2Site_IPSec_VPN_.28Dial-Up.29_auf_.22einer.22_FortiGate_konfigurieren_sei_es_f.C3.BCr_FortiClient.2C_iOS_und_Android.3F]]
| |
|
| |
|
| |
| '''Aggressive Mode Komunikation'''
| |
|
| |
| Für die etablierung des Main Mode werden 3 Packete für die Komunikation benutzt:
| |
|
| |
| [[Datei:Fortinet-1423.jpg]]
| |
|
| |
| 1. Der Client initiert Traffic und der IPSec Tunnel benützt eine oder mehrer Sicherheitsrichtlinien und der Key sowie Peer ID (Local ID) werden gesendet.
| |
| 2. Der Responder antwortet mit den gleichen Informtionen plus sendet dieser den hash.
| |
| 3. Der Client sendet dem Responder den hash payload.
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Die "Peer ID" zur Identifizierung der VPN Verbindung wird in der Phase-1 als "Local ID" konfiguriert im Gegensatz
| |
| zum Main Mode dh. im Main Mode benutzt die FortiGate die Source IP um die IPSec Verbindung zu identifizieren denn die
| |
| Peer ID wird im Main Mode zu einem späteren Zeitpunkt übermittelt. Aus diesem Grund - wenn mehrere Dial-UP - IPSec
| |
| Verbindungen konfiguriert werden ist Aggressive Mode zu bevorzugen und für die Identifizierung der verschiedenen
| |
| Verbindungen ist die Peer ID in der Phase-1 zu konfigurieren (Local ID).
| |
|
| |
| Desweiteren ist auf einer FortiGate für "Eingehende" IPSec Verbindung folgendes zu berücksichtigen:
| |
|
| |
| Für alle Eingehenden IPSec Verbindungen selektiert eine FortiGate die erste konfigurierte
| |
| IPSec 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
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Der "Pre-Shared Key" ist kein Selektierungs Kriterium. Wie schon vorgängig erwähnt wenn mehrer Dial-Up IPSec Verbindungen
| |
| konfiguriert werden und da "Pre-Shared Key" kein Selektierungs Kriterium ist sollte Aggressive Mode mit Peer ID (Local ID)
| |
| benutzt werden. Weiter Informationen betreffend diesem Thema siehe auch:
| |
|
| |
| [[FortiClient:FAQ#Kann_ich_mehrer_Client2Site_IPSec_VPN_.28Dial-Up.29_auf_.22einer.22_FortiGate_konfigurieren_sei_es_f.C3.BCr_FortiClient.2C_iOS_und_Android.3F]]
| |
|
| |
| === Wie sieht der "Output" für ein IPSec VPN im Debugging Mode aus? ===
| |
|
| |
| Das nachfolgende Dokument zeigt wie ein Debugging für ein IPSec VPN betreffend Phase-1 und/oder 2 ausgeführt wird. Grundsätzlich benötigt man für das Debugging folgende Befehle:
| |
|
| |
| # diagnose debug reset
| |
| # diagnose debug application ike -1
| |
| # diagnose vpn ike log-filter
| |
| # diagnose debug info
| |
| # diagnose debug enable
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Um den Debugging Mode "diagnose debug enable" zu stoppen muss folgender Befehl abgesetzt werden:
| |
|
| |
| # diagnose debug disable
| |
|
| |
| Wenn es sehr viel "output" kommt im Debugging Mode kann der Befehl einfach in die Console kopiert werden
| |
| gefolgt von einem "Enter". Damit lässt sich der Debugging Mode beenden. Weiter ausführliche Informationen
| |
| betreffend "diagnose debug appplication" sowie "diagnose vpn ike" findet man im nachfolgenden Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_kann_ich_f.C3.BCr_ein_IPSec_VPN_f.C3.BCr_Phase-1_und.2Foder_2_ein_Debugging_ausf.C3.BChren.3F]]
| |
|
| |
| Wie schon erwähnt zeigt das nachfolgende Dokument alle Aspekte eines Debugging für IPSec in der Phase-1 und/oder 2. Dies bedeutet anhand eines Beispiels zeigt das Dokument jeden möglichen Fehler mit seinen Fehlermeldungen. Somit kann dieses Dokument auch benützt werden als Referenz für mögliche Fehler:
| |
|
| |
| [[Datei:Fortigate-IPSEC-Debugging.pdf]]
| |
|
| |
| === Wie kann ich für ein IPSec VPN für Phase-1 und/oder 2 ein Debugging ausführen? ===
| |
|
| |
| Ein Debug für IPSec VPN Phase-1 und/oder 2 kann anhand der Debugging Funktion (diagnose debug) auf einer Fortiate durchgeführt werden:
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Das relativ Schwierige bei einem Debug für IPSec ist den Output dieses Debug's korrekt zu intepretieren.
| |
| Der nachfolgende Artikel enhält ein Dokument von Fortinet das die verschienen Output's resp. Fehlermeldungen
| |
| aufzeigt. Dieses Dokument soll helfen die Meldungen in der Phase-1 und/oder 2 korrekt zu intepretieren und
| |
| Fehler zu beseitigen:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_sieht_der_.22Output.22_f.C3.BCr_ein_IPSec_VPN_im_Debugging_Mode_aus.3F]]
| |
|
| |
| Desweitern sollte dem Initial Traffic dh. IKE 500 sowie ESP Aufmerksamkeit geschenkt werden dh. wenn der
| |
| initiale Traffic nicht funktioniert sprich die Gateways nicht miteinander komunizieren können kann kein
| |
| IPSec etabliert werden. Um den initial Traffic zu Sniffen kann "diagnose sniffer packet" benutzt werden.
| |
| Weitere Informationen dazu siehe nachfolgenden Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Sniffe_Packete_f.C3.BCr_IPSec_betreffend_IKE_sowie_ESP_Traffic_.28NAT_.2F_NAT-T.29.3F]]
| |
|
| |
| '''Setze den Debug Filter zurück:'''
| |
|
| |
| # diagnose debug reset
| |
|
| |
| '''Setze einen neuen Debug Filter:'''
| |
|
| |
| # diagnose debug application ike -l
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Die gebräuchlichste Art den "ike" Debug durchzuführen ist mit der Angabe "-1" was wiederum bedeutet: Maximaler
| |
| "debug level". Ebenso wird des öfteren "debug level" "63" benutzt um die Phase-1 zu überprüfen im Main/Aggresive
| |
| Mode. Nichts desto trotz stehen zusätzlich folgende "debug level" für "ike" zur Verfügung:
| |
|
| |
| 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
| |
|
| |
| # diagnose vpn ike log-filter [Log Filter zB Phase1 Name "name"]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Als "log-filter" stehen verschiedene Möglichkeiten zur Verfügung. Dies bedeutet: Ist auf einer Fortigate mehr
| |
| als ein IPSec VPN konfiguriert ist es Sinnvoll nur den Output eines VPN's anzuzeigen anstelle allen VPN's. Der
| |
| folgende Befehl listet die verschiedenen Möglichkeiten des Filters auf:
| |
|
| |
| # diagnose vpn ike log-filter list
| |
|
| |
| vd: any
| |
| name: any
| |
| interface: any
| |
| IPv4 source: any
| |
| IPv4 dest: any
| |
| IPv6 source: any
| |
| IPv6 dest: any
| |
| source port: any
| |
| dest port: any
| |
| autoconf type: any
| |
| autoconf status: any
| |
|
| |
| Nachfolgender Befehl listet alle Möglichkeiten mit deren Kurzbeschreibung auf:
| |
|
| |
| # diagnose vpn ike log-filter ?
| |
|
| |
| clear Erase the current filter.
| |
| dst-addr4 IPv4 destination address range to filter by.
| |
| dst-addr6 IPv6 destination address range to filter by.
| |
| dst-port Destination port range to filter by.
| |
| interface Interface that IKE connection is negotiated over.
| |
| list Display the current filter.
| |
| name Phase1 name to filter by.
| |
| negate Negate the specified filter parameter.
| |
| src-addr4 IPv4 source address range to filter by.
| |
| src-addr6 IPv6 source address range to filter by.
| |
| src-port Source port range to filter by.
| |
| vd Index of virtual domain. -1 matches all.
| |
|
| |
| '''Aktiviere den Debug Modus mit dem gesetzen Debug Filter:'''
| |
|
| |
| # diagnose debug enable
| |
|
| |
| '''Deaktiviere den Debug Modus:'''
| |
|
| |
| # diagnose debug disable
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Es kann zu Situationen kommen in dem der Output des laufenden Debug Mode verhindert einen Befehl in der
| |
| Console einzugeben. Wenn dies der Fall ist, kopiere den Befehl einfach in die Console gefolgt durch
| |
| "Enter"!
| |
|
| |
| '''Setze den Debug Filter zurück:'''
| |
|
| |
| # diagnose debug reset
| |
|
| |
| '''Kontrolliere den Debug Filter ob dieser zurückgesetzt wurde:'''
| |
|
| |
| # diagnose debug info
| |
|
| |
| '''Setze den IKE "log-filter" zurück und kontrolliere diesen:'''
| |
|
| |
| # diagnose vpn ike log-filter clear
| |
| # diagnose vpn ike log-filter list
| |
|
| |
| Das Debug Kommando "diagnose debug application ike -1" zeigt Detailiert Informationen auf betreffend Kommunikation in der Phase-1/2. Zusätzlich zu diesem Kommando stehen für IPSec VPN's zusätzliche Kommandos zur Verfügung:
| |
|
| |
| # get vpn ipsec state tunnel
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Dieses Kommando zeigt die Anzahl VPN's auf einer FortiGate im Gesamten. Zusammen mit nachfolgenden Befehlen kann ein
| |
| Gesamtüberblick erreicht werden der IPSec VPN Konfiguration auf einer FortiGate im Gesamten:
| |
|
| |
| # get vpn ipsec tunnel summary
| |
| # get ipsec tunnel list
| |
|
| |
| Wenn für die einzelnen "aktiven" IPSec Tunnels Detailinformationen angezeigt werden sollen kann nachfolgender Befehl
| |
| benutzt werden:
| |
|
| |
| # get vpn ipsec tunnel detail
| |
|
| |
| === Wie kann ich einen IPSec VPN Tunnel Manuell Stoppen und Starten? ===
| |
|
| |
| Um einen IPSec VPN Tunnel Manuell zu stoppen/starten kann über das Web Mgmt. Interface folgendes durchgeführt werden:
| |
|
| |
| VPN > Monitor > IPsec Monitor > [Markiere den entsprechenden Eintrag] > [Status bring-up/down]
| |
|
| |
| Diese vorgehensweise über das Web Mgmt. Interface entspricht auf der Kommandozeile folgenden Befehl:
| |
|
| |
| # diagnose vpn tunnel down [Name Phase-2]
| |
| # diagnose vpn tunnel up [Name Phase-2]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Das Kommando "diagnose vpn tunel" steht im Zusammenhang mit der Phase-2 und beeinflusst nicht die Phase-1.
| |
| Zusätzlich zu "down/up" stehen folgende 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
| |
|
| |
| Das Problem bei der Anwendung -sei es über Web Mgmt. Interface- und/oder Kommandozeile ist das Restinformationen der SA nicht von grundauf Erneuert werden da wie schon erwähnt das hier gezeigte Kommando nur die Phase-2 beeinflusst. Dies bedeutet wenn kleinere Aenderungen an einem IPSec VPN durchgeführt werden sollte diese Vorgehensweise genügen. Sollte ein VPN IPSec von Grundauf neu gestartet werden mit sämtlichen Informationen sollte die vorgehensweise im nachfolgenden Artikel durchgeführt werden:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_kann_ich_ein_IPSec_VPN_neu_Initieren_.28Starten.29_damit_von_Grundauf_neue_Informationen_.28SA.29_aktiv_werden.3F]]
| |
|
| |
| === Spielt die Zeichenanzahl des Namens für ein IPSec in der Phase-1 und/oder 2 eine Rolle? ===
| |
|
| |
| Der Name (Zeichenanzahl) für eine IPSec Konfiguration in der Phase-1 und/oder 2 sollte 15 Zeichen nicht übersteigen. In einem Site2Site VPN indem nur "ein" Tunnel geöffnet wird ist dies kein Problem. In einem Dial-UP VPN bei dem für zusätzliche Verbindungen zusätzliche VPN-Tunnels geöffnet werden, kann dies zu einem Problem führen, denn für jeden Tunnel wird ein "_#" (# steht für 0-9) angehängt. Dies bedeutet werden 10 zusätzliche Verbindunge geöffnet wird an jedem Tunnel "_##" (# steht für 10-99) angehängt. Sobald die Länge des Namens 15 übersteigt kommt es zu Problemen. Aus diesem Grund sollte eine IPSec in der Phase-1 und/oder 2 nie mehr als 12 Zeichen enthalten damit noch genug Zeichen noch vorhanden sind um "_##" (0-99) anzuhängen und somit 100 Gleichzeitige Verbindungen geöffnet werden können.
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Unter FortiOS 5.2 wird diesem Umstand "visuell" über Web Mgmt. Interface Rechnung getragen wenn ein
| |
| Dialup VPN konfiguriert wird. Wenn der Name eine bestimmte Länge überschreitet wird ein entsprechender
| |
| Hinweis angezeigt und die Zahl möglicher Gleichzeitiger Verbindungen!
| |
|
| |
| [[Datei:Fortinet-1209.jpg]]
| |
|
| |
| === Wie kann ich ein IPSec VPN neu Initieren (Starten) damit von Grundauf neue Informationen (SA) aktiv werden? ===
| |
|
| |
| Wenn eine IPSec Verbindung Konfiguriert wurde und nachträglich an dieser Konfiguration Aenderungen durchführt (event. auf beiden Seiten) kann es vorkommen, dass die neuen Informationen nicht übernommen/aktiv werden. Oft wird als letzte Alternative ein Neustart des Gerätes durchgeführtt. Nach einem Neustart werden die neuen Informatione sofort aktiv. Die Vorgehensweise einen Device neu zu starten ist zwar eine Möglichkeit aber nicht in jedem Fall machbar da event. mehrere IPSec Tunnel auf dem Device konfguriert wurden und durch dieses Vorgehen ein Unterbruch in den IPSec VPN Verbindungen stattfindet. Speziell wenn grundlegende Konfigurationsänderungen durchgeführt wurden in der IPSec Konfiguration, sei es betreffend Subnets oder in der Phase-1/2, kann folgendermassen vorgegangen werden um ein IPSec von grundauf neu zu Initieren (inkl. SA Informationen; Security Association):
| |
|
| |
| '''"Erneuerung der Routing Table"'''
| |
|
| |
| # execute router restart
| |
|
| |
| '''"Erneuerung der SA (Security Associations ) für ALLE VDom's"'''
| |
|
| |
| # diagnose debug application ike 2
| |
| # diagnose debug enable
| |
| # diagnose vpn ike restart
| |
|
| |
| oder
| |
|
| |
| # diagnose vpn ike gateway flush [name Phase 1]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Wenn ein "diagnose vpn ike restart" durchgeführt wird so wird der IKE Deamon der FortiGate neu gestartet. Dies bedeutet:
| |
| Sämtliche konfigurierten IPSec VPN's auf der FortiGate erfahren einen Neustart und somit wird ein Unterbruch stattfinden
| |
| auf sämtlichen IPSec Verbindung die auf der FortiGate konfiguriet wurden. Wenn dies nicht möglich ist, kann ein "diagnose
| |
| vpn ike gateway flush [name Phase 1]" durchgeführt werden. Zusätzlich steht der Befehl "diagnose vpn tunnel" zur Verfügung
| |
| um ein IPSec VPN neu zu starten etc. jedoch steht dieses Kommando nur im Zusammenhang mit der Phase-2 und beeinflusst somit
| |
| nicht die Phase-1 sprich die SA der Phase-1 kann mit diesem Befehl nicht erneuert werden. Mehr Informationen zum Kommando
| |
| "diagnose vpn tunnel" siehe nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_kann_ich_einen_IPSec_VPN_Tunnel_Manuell_Stoppen_und_Starten.3F]]
| |
|
| |
| Danach sollte das Debug wieder abgeschaltet werden:
| |
|
| |
| '''Deaktiviere den Debug Modus:'''
| |
|
| |
| # diagnose debug disable
| |
|
| |
| '''Setze den Debug Filter zurück:'''
| |
|
| |
| # diagnose debug reset
| |
|
| |
| '''Kontrolliere den Debug Filter ob dieser zurückgesetzt wurde:'''
| |
|
| |
| # diagnose debug info
| |
|
| |
| Wenn die vorhergehende Ausführen keine Lösung bringt so sollte zu Troubleshooting Zwecken (Support) - und vor dem Reboot- folgendes durchgeführt werden:
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Um das nachfolgende Scenario und Befehle besser zu verstehen gehen wir von folgenden Scenario aus:
| |
|
| |
| _________________________ ___________ __________ ____________ _________________________
| |
| | | | | 1.1.1.1 | | 2.2.2.2 | | | |
| |
| | LAN Env. 10.1.1.0/24 |----- LAN ------| Forti I |------ WAN1 ------| IPSec |------ WAN 1 ------| Forti II |------ LAN -----| LAN Env. 10.2.2.0/24 |
| |
| |_________________________| |___________| |__________| |____________| |_________________________|
| |
|
| |
| Phase-1 Interface auf der Forti I ist benannt: "toFGT2"
| |
| Phase-1 Interface auf der Forti II ist benannt: "toFGT1"
| |
|
| |
| Folgende Symptome treten auf:
| |
|
| |
| --> Der Tunnel ist "up" und wird dementsprechenden auch so im WebGui angezeigt.
| |
| --> Wenn ein ICMP Echo Request von 1.1.1.1 zu 2.2.2.2 gesendet wird dann:
| |
|
| |
| . Ich sehe die ICMP Packet auf dem Forti I "internal" Intercace
| |
| . Ich sehe die ICMP Packet auf dem Forti I "toFGT2" Interface
| |
| . Ich sehe keinen Traffic auf der Forti II "toFGT1" Interface
| |
|
| |
| Ausgehend von diesen Vorraussetzungen führe folgendes aus (Logge alles in ein File):
| |
|
| |
| '''AUF DER FORTI I'''
| |
|
| |
| '''Oeffne eine CLI Session 1''' (IKE Debug und Debug Flow für ICMP Traffic
| |
|
| |
| # diagnose debug reset
| |
| # diagnose debug console timestamp en
| |
| # diagnose vpn ike log-filter clear
| |
| # diagnose vpn ike log-filter dst-addr4 [Public IP Forti I dh. 2.2.2.2]
| |
| # diagnose debug application ike -1
| |
| # diagnose debug flow filter clear
| |
| # diagnose debug flow show console enable
| |
| # diagnose debug flow filter proto 1
| |
| # diagnose debug flow filter addr [Client IP Forti I Local Env. der den ICMP ausführt dh. 10.2.2.2]
| |
| # diagnose debug flow trace start 10000
| |
| # diagnose debug enable
| |
|
| |
| '''Oeffne eine CLI Session 2''' (Capture ICMP Traffic) ==
| |
|
| |
| # diagnose sniffer packet any 'host [Client IP Forti II Local Env. nachdem der ICMP ausführt wird dh. 10.2.2.2] and icmp' 6 0 a
| |
|
| |
| '''Oeffne eine CLI Session 3''' (Capture IPSec Traffic) ==
| |
|
| |
| # diagnose sniffer packet any 'host [Forti II WAN-1 2.2.2.2] and [esp oder UDP Port 4500]' 6 0 a
| |
|
| |
| '''Oeffne eine CLI Session 4''' (Capture IPSec Traffic) ==
| |
|
| |
| # get sys status
| |
| # get ro info ro dat
| |
| # fnsysctl ps
| |
| # diagnose vpn ike status summary
| |
| # diagnose vpn ike status detailed
| |
| # get vpn ipsec tunnel summary
| |
| # diagnose vpn tunnel stat
| |
| # diagnose vpn ike crypto stats
| |
| # diagnose vpn ipsec status
| |
| # diagnose vpn ike gateway list
| |
| # diagnose netlink interface list [Name der Phase 1 auf Forti I dh. toFGT2]
| |
| # diagnose vpn ike routes
| |
| # diagnose vpn tunnel list
| |
| # diagnose vpn ike errors
| |
| # diagnose vpn ike counts
| |
| # diagnose hardware deviceinfo nic [Physical Interface über dessen IPSec läuft dh. wan1]
| |
|
| |
| # fnsysctl cat /proc/net/ipsec0
| |
| # fnsysctl cat /proc/cp6kxp/kxp0/brief
| |
| # fnsysctl cat /proc/cp6kxp/kxp0/cmdq
| |
| # fnsysctl cat /proc/cp6kxp/kxp0/cmdqdis
| |
| # fnsysctl cat /proc/cp6kxp/kxp0/rng
| |
| # fnsysctl cat /proc/cp6kxp/kxp0/task
| |
| # fnsysctl cat /proc/cp7/vpn0/brief
| |
| # fnsysctl cat /proc/cp7/vpn0/registers
| |
| # fnsysctl cat /proc/cp8/vpn0/brief
| |
| # fnsysctl cat /proc/cp8/vpn0/registers
| |
| # fnsysctl cat /proc/fsoc/cp7/vpn0/brief
| |
| # fnsysctl cat /proc/fsoc/cp7/vpn0/registers
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Der "fnsysctl" Befehl schreibt die CP6/CP7/CP8/SoC Statistik Informationen in die CLI Session.
| |
| Einige der Kommandos werden nicht funktionieren (file does not exist) da diese Kommandos alle ASIC's
| |
| abdecken resp. überprüft. NP2/NP4/SP Hardware Offload Informationen sind nicht enthalten das diese
| |
| Informationen auf dem FortiGate Modell basiert (Einige haben ein Chip, andere Zwei oder auch Vier).
| |
|
| |
| '''AUF DER FORTI II'''
| |
|
| |
| '''Oeffne eine CLI Session 1''' (IKE Debug und Debug Flow für ICMP Traffic
| |
|
| |
| # diagnose debug reset
| |
| # diagnose debug console timestamp en
| |
| # diagnose vpn ike log-filter clear
| |
| # diagnose vpn ike log-filter dst-addr4 [Public IP Forti I dh. 1.1.1.1]
| |
| # diagnose debug application ike -1
| |
| # diagnose debug flow filter clear
| |
| # diagnose debug flow show console enable
| |
| # diagnose debug flow filter proto 1
| |
| # diagnose debug flow filter addr [Client IP Forti I Local Env. der den ICMP ausführt dh. 10.1.1.1]
| |
| # diagnose debug flow trace start 10000
| |
| # diagnose debug enable
| |
|
| |
| '''Oeffne eine CLI Session 2''' (Capture ICMP Traffic) ==
| |
|
| |
| # diagnose sniffer packet any 'host [Client IP Forti II Local Env. nachdem der ICMP ausführt wird dh. 10.1.1.1] and icmp' 6 0 a
| |
|
| |
| '''Oeffne eine CLI Session 3''' (Capture IPSec Traffic) ==
| |
|
| |
| # diagnose sniffer packet any 'host [Forti II WAN-1 1.1.1.1] and [esp oder UDP Port 4500]' 6 0 a
| |
|
| |
| '''Oeffne eine CLI Session 4''' (Capture IPSec Traffic) ==
| |
|
| |
| # get sys status
| |
| # get ro info ro dat
| |
| # fnsysctl ps
| |
| # diagnose vpn ike status summary
| |
| # diagnose vpn ike status detailed
| |
| # get vpn ipsec tunnel summary
| |
| # diagnose vpn tunnel stat
| |
| # diagnose vpn ike crypto stats
| |
| # diagnose vpn ipsec status
| |
| # diagnose vpn ike gateway list
| |
| # diagnose netlink interface list [Name der Phase 1 auf Forti II dh. toFGT1]
| |
| # diagnose vpn ike routes
| |
| # diagnose vpn tunnel list
| |
| # diagnose vpn ike errors
| |
| # diagnose vpn ike counts
| |
| # diagnose hardware deviceinfo nic [Physical Interface über dessen IPSec läuft dh. wan1]
| |
|
| |
| # fnsysctl cat /proc/net/ipsec0
| |
| # fnsysctl cat /proc/cp6kxp/kxp0/brief
| |
| # fnsysctl cat /proc/cp6kxp/kxp0/cmdq
| |
| # fnsysctl cat /proc/cp6kxp/kxp0/cmdqdis
| |
| # fnsysctl cat /proc/cp6kxp/kxp0/rng
| |
| # fnsysctl cat /proc/cp6kxp/kxp0/task
| |
| # fnsysctl cat /proc/cp7/vpn0/brief
| |
| # fnsysctl cat /proc/cp7/vpn0/registers
| |
| # fnsysctl cat /proc/cp8/vpn0/brief
| |
| # fnsysctl cat /proc/cp8/vpn0/registers
| |
| # fnsysctl cat /proc/fsoc/cp7/vpn0/brief
| |
| # fnsysctl cat /proc/fsoc/cp7/vpn0/registers
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Der "fnsysctl" Befehl schreibt die CP6/CP7/CP8/SoC Statistik Informationen in die CLI Session.
| |
| Einige der Kommandos werden nicht funktionieren (file does not exist) da diese Kommandos alle ASIC's
| |
| abdecken resp. überprüft. NP2/NP4/SP Hardware Offload Informationen sind nicht enthalten das diese
| |
| Informationen auf dem FortiGate Modell basiert (Einige haben ein Chip, andere Zwei oder auch Vier).
| |
|
| |
| Nun Oeffne auf "Forti I" auf dem Client 10.1.1.1 ein DOS Box (cmd) und versuche den Client auf "Forti II" zu erreichen dh. 10.2.2.2!
| |
|
| |
| C:\> ping 10.2.2.2
| |
|
| |
| Sobald ersichtlich ist, dass der Ping den Client 10.2.2.2 auf "Forti II" nicht erreichen kann führe die Kommandos in der "ClI Session 4" auf '''Forti I''' und '''Forti II''' erneut aus:
| |
|
| |
| '''Oeffne eine CLI Session 4''' (Capture IPSec Traffic) ==
| |
|
| |
| # get sys status
| |
| # get ro info ro dat
| |
| # fnsysctl ps
| |
| # diagnose vpn ike status summary
| |
| # diagnose vpn ike status detailed
| |
| # get vpn ipsec tunnel summary
| |
| # diagnose vpn tunnel stat
| |
| # diagnose vpn ike crypto stats
| |
| # diagnose vpn ipsec status
| |
| # diagnose vpn ike gateway list
| |
| # diagnose netlink interface list [Name der Phase 1 auf Forti II dh. toFGT1]
| |
| # diagnose vpn ike routes
| |
| # diagnose vpn tunnel list
| |
| # diagnose vpn ike errors
| |
| # diagnose vpn ike counts
| |
| # diagnose hardware deviceinfo nic [Physical Interface über dessen IPSec läuft dh. wan1]
| |
|
| |
| # fnsysctl cat /proc/net/ipsec0
| |
| # fnsysctl cat /proc/cp6kxp/kxp0/brief
| |
| # fnsysctl cat /proc/cp6kxp/kxp0/cmdq
| |
| # fnsysctl cat /proc/cp6kxp/kxp0/cmdqdis
| |
| # fnsysctl cat /proc/cp6kxp/kxp0/rng
| |
| # fnsysctl cat /proc/cp6kxp/kxp0/task
| |
| # fnsysctl cat /proc/cp7/vpn0/brief
| |
| # fnsysctl cat /proc/cp7/vpn0/registers
| |
| # fnsysctl cat /proc/cp8/vpn0/brief
| |
| # fnsysctl cat /proc/cp8/vpn0/registers
| |
| # fnsysctl cat /proc/fsoc/cp7/vpn0/brief
| |
| # fnsysctl cat /proc/fsoc/cp7/vpn0/registers
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Diese Kommandos in "CLI Session 4" erstellen einen Snapshot bevor der ICMP ausgeführt wird sowie nachträglich.
| |
| Das ist der Grund wieso die Kommands zweimal ausgeführt werden müssen.
| |
|
| |
| Danach müssen alle "CLI Sessions" sauber abgespeichert werden sowie dem Support übermittelt werden. Mit diesen Informationen die vollumfänglich sind kann der Support eine tiefgreifenden Analyse durchführen!
| |
|
| |
| === Wie kann ich für ein IPSec VPN den Status der Security Association (SA) abfragen? ===
| |
|
| |
| Die "Security Association" ist das Herzstück eines IPSec VPN's dh. diese wird erstellt zu Beginn eines IPSec VPN Aufbaus in der Phase-1 sowie diese wird nach gesetzer Keylifetime erneuert. Aus nachfolgenden Kommando können mehrere Wichtige Informationen gezogen werden betreffend Phase-1 SA:
| |
|
| |
| # diagnose vpn ike gateway list
| |
| vd: root/0
| |
| version: 1
| |
| interface: port1 2
| |
| addr: 10.200.1.1:500 -> 10.200.3.1:500
| |
| created: 8683s ago
| |
| IKE SA: created 1/2 established 1/1 time 10/10/10 ms
| |
| IPSec SA: created 1/3 established 1/3 time 10/10/10 ms
| |
|
| |
| id/spi: 2 a08fc739780e405b/cbb5f7ea30af294d
| |
| direction: responder
| |
| status: established 8660-8660s ago = 10ms
| |
| proposal: des-md5
| |
| key: b85e222c41ee9909
| |
| lifetime/rekey 86400/77469
| |
| DPD sent/recv: 000005d2/0000005b0
| |
|
| |
| In diesem Output sieht man verschiedenen Informationen wie zB:
| |
|
| |
| version: - Welche Version von IKE wird benutzt
| |
| interface: - Für das VPN wird welches Interface benutzt
| |
| created: - Wann wurde die Phase-1 erstellt
| |
| direction: - Welcher Gateway/IP hat das VPN initiert
| |
| proposal: - Welche Proposal werden benutzt für Phase-1
| |
| lifetime: - Welche lifetime wird benutzt
| |
| DPD sent/recv: - Letzet DPD sent/recv
| |
|
| |
| Das Gleiche kann für die Phase-2 SA durchgeführt werden dh.:
| |
|
| |
| # diagnose vpn tunnel list
| |
|
| |
| name=Remote ver=1 serial=1 10.200.1.1:0->10.200.3.1:0
| |
| lgwy=static tun=intf mode=auto bound if=2
| |
| proxyid_num=2 child num=0 refcnt=7 ilast=0 olast=0
| |
| stat: rxp=0 txp=0 rxb=0 txb=0
| |
| dpd: mode=active on=1 idle=5000ms retry=3 count=0 seqno=1490
| |
| natt: mode=none draft=0 interval=0 remote_port=0
| |
| proxyid=Remote proto=0 sa0 ref=1 serial=1
| |
| src:0:10.0.1.0/255.255.255.0:0
| |
| dst:0:10.0.2.0/255.255.255.0:0
| |
| SA: ref=3 options=000000e type=00 soft=0 mtu=1446
| |
| expire=39766 replaywin=2048 seqno=1
| |
| life: type=01 bytes=0/0 timeout=43152/43200
| |
| dec: spi=bee75e37 esp=des key=8 af138cd415c7e900
| |
| ah=md5 key=16 47090e94d4fa026b652af1fea8d4d228
| |
| enc: spi=352f0146 esp=des key=8 faff7973e50093f0
| |
| ah=md5 key=16 97dff98d0aa7df779db5a7fib116905ff
| |
| npu_flag=00 npu_rgwy=10.200.3.1 npu_lgwy=10.200.1.1
| |
| npu selid=1
| |
| dec:pkts/bytes=0/0, enc:pkts/bytes=0/0
| |
|
| |
| In diesem Output sind auch Wichtige Information die herausgelesen werden könnnen wie zB:
| |
|
| |
| name=Remote ver=1 serial=1 10.200.1.1:0->10.200.3.1:0 - IP's der Gateways
| |
| natt: mode=none - Wird NAT-T (Nat Traversal) benutzt oder nicht. "silent" indiziert es wird NAT-T benutzt
| |
| dpd: mode=active on=1 idle=5000ms retry=3 count=0 - Die Position "count=0" indiziert ob DPD Fehler aufgetreten sind.
| |
| dec: - Indiziert die SPI dh. Austausch der Encryption sowie Authentication und zeigt den "key"
| |
| für den Traffic in beide Richtungen
| |
| dec:pkts/bytes=0/0, enc:pkts/bytes=0/0 - Stellt den Traffic counter dar für das IPSec VPN
| |
|
| |
| Wenn man nun diese "SA" eines VPN von Grundauf erneuern möchte muss das IPSec VPN neu gestartet werden. Nachträglich kann wiederum mit den hier gezeigten Kommandos die Informationen kontrolliert werden. Wie ein IPSec VPN zur Erneuerung der SA neu gestartet wird siehe nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_kann_ich_ein_IPSec_VPN_neu_Initieren_.28Starten.29_damit_von_Grundauf_neue_Informationen_.28SA.29_aktiv_werden.3F]]
| |
|
| |
| === Wann sollte ich den "Quick MOde Selector" benutzen, was muss ich berücksichtigen und welche Funktion hat dieser? ===
| |
|
| |
| Wenn zwischen FortiGate's ein Site2Site VPN aufgebaut werden soll und/oder zwischen Interoperability Devices (Fremdprodukte) stellt sich die Frage ob die Netze/Subnet's in der Phase2 unter "Quick Mode" Selektor definiert werden sollen. In der Phase2 von IKE wird der "Quick Mode" verwendet (Schutz durch die IKE SA). Die gesamte Kommunikation in dieser Phase2 erfolgt verschlüsselt. Wie in der Phase1 wird zunächst ein Vorschlag (Proposal) gemacht und zusammen mit einem "Hashwert" und dem "Nonce" übertragen. Später werden die Schlüssel neu berechnet, und es fließen keinerlei Informationen aus den zuvor generierten SA's (Security Association) ein. Dies stellt sicher, dass niemand von den zuvor generierten Schlüsseln auf die neuen schließen kann (Perfect Forward Secrecy). Dies wird erreicht, indem ein zusätzlicher Diffie-Hellman-Austausch stattfindet. Die Geheimnisse zur Schlüsselbildung werden verworfen, sobald der Austausch abgeschlossen ist. Nun wenn man das liest fällt einem folgender Satz auf:
| |
|
| |
| "In der Phase2 von IKE wird der "Quick Mode" verwendet...."
| |
|
| |
| Dies ist "Die" relevante Aussage dh. durch die Konfiguration eines VPN's kann nicht gewählt werden ob der "Quick Mode Selector" benutzt werden soll oder nicht, denn dieser wird in der Phase2 immer benutzt! Die Frage ist nur "Wie" wird der "Quick Mode Selector" benutzt dh. folgende Varianten sind möglich:
| |
|
| |
| -> In der Phase2 werden die Netze/Subnet's unter Quick Mode Selektor definiert
| |
| -> In der Phase2 werden die Netze/Subnet's unter Quick Mode Selektor als "wildcard" definiert dh. "0.0.0.0/0"
| |
|
| |
| Aus diesen zwei Varianten fragt man sich "wo" die Vor- und Nachteile der Varianten sind? Nachfolgend die zwei Varianten mit dessen Vor- und Nachteile:
| |
|
| |
| '''In der Phase2 werden die Netze/Subnet's unter Quick Mode Selektor definiert'''
| |
|
| |
| Werden die Netze/Subnet's in der Phase2 definiert so werden diese zwischen dem Remote Gateway ausgetauscht und müssen
| |
| gegenüber dem Gateway 100% übereinstimmen in der Source und Destination. Dies bedeutet die Source als Netz/Subnet muss
| |
| auf dem Remote Gateway 100% betreffend Subnetting übereinstimmen mit dessen Definition der Destination. Das gleiche gilt
| |
| für die Destination muss auf dem Remote Gateway mit dessen Source 100% übereinstimmen. Werden falsche oder unterschiedliche
| |
| Netze/Subnet's definiert wird die betreffend Phase2 verworfen. Wenn mehrer Netze/Subnet's in der gleichen Phase2 konfiguriert
| |
| werden müssen ist das nicht auf jedem Interoperability Device möglich. Ist dies nicht möglich können "mehrere" Phase2 dafür
| |
| zur Phase1 definiert werden. Jede Phase2 beinhaltet dann die einzelne Definition der einzelnen Netze/Subnet's. Für einige
| |
| Interoperability Devices können in der Phase2 unter "Quick Mode Selector" Gruppen definiert werden. Diese Gruppen beinhalten
| |
| die einzelnen Netze/Subnet's (Unter FortiOS 5.2.1 möglich). Dies wird wiederum nicht für alle Interoperability Device's
| |
| unterstützt (zB Cisco ASA).
| |
|
| |
| '''In der Phase2 werden die Netze/Subnet's unter Quick Mode Selektor als "wildcard" definiert dh. "0.0.0.0/0"'''
| |
|
| |
| Wird in der Phase2 unter dem "Quick Mode Selector" "Wildcards" definiert dh. "0.0.0.0/0" sind potentiell "alle" Netze
| |
| erlaubt dh. im Austausch in der Phase2 mit dem Remote Gateway und ebenfalls durch dessen Konfiguration im "Quick Mode
| |
| Selector" durch "wildcards" wird potentiell vereinbart, dass alle Netze/Subnet's akzeptiert werden! Dies kommt jedoch
| |
| nur Zustande, wenn der Remote Gateway ebenfalls im "Quick Mode Selektor" die Konfiguration der "wildcards" benutzt. Nicht
| |
| alle Interoperability Devices unterstützen dies. Wie schon erwähnt -durch die "wildcard" Konfiguration "0.0.0.0/0"- ist
| |
| jedes Netz/Subnet in der Phase2 erlaubt. Somit fällt die Problematik von mehreren Netzen/Subnet's weg und die Definiton
| |
| einer Phase2 reicht für jede Konfiguration aus. Die Zugriffe werden nun gesteuert über "statische" Routen sowie über
| |
| entsprechende Firewall Policy Rules. In dieser Konfiguration anhand der "wildcards" ist es nicht ratsam in der Firewall
| |
| Policy Rule "all" zur Definition der Destination resp. Source zu benutzen da durch die "wildcards" potentiell sämtlicher
| |
| Traffic erlaubt ist.
| |
|
| |
| '''Fazit'''
| |
|
| |
| Die Konfiguration für den "Quick Mode Selector" durch "wildcards" ist einfacher und Transparenter auch für spätere Erweiterungen
| |
| da die Phase2 nur einmal konfiguriert werden muss. Sämtliche Konfiguration in einem späteren zeitpunkt werden über "statische
| |
| Routen" sowie "Firewall Policy Rules" gesteuert. Aus diesem Grund sollten Konfigurationen in einem Site2Site VPN in der zwischen
| |
| FortiGate's ein IPSec etabliert werden soll im "Quick Mode Selector" die Konfiguration von "wildcards" benutzt werden. Für
| |
| Interoperability Device's (Fremdprodukten) sollte dies Konfiguration in Betracht gezogen werden. Ist dies nicht möglich müssen
| |
| die Netze/Subnets im "Quick Mode Selector" definiert werden. Wenn mehrere Netze/Subnet's für Interoperability Devices definiert
| |
| werden müssen und "wildcard" ist nicht möglich können diese im "Quick Mode Selector" als Gruppen definiert werden die diese
| |
| verschiedenen Netze/Subnets beinhalten. Ist dies nicht möglich da der Interoperability Device dies nicht unterstützt können die
| |
| einzelnen Netze/Subnets einzel anhand verschiedenen Phase2 zur Phase1 hinzugefügt werden.
| |
|
| |
| Aus den vorhergehnder Erklärung ergiebt sich folgede Fragestellung, auch dann wenn nur FortiGate Devices involviert sind:
| |
|
| |
| • Welche Netze/Subnets werden benützt um ein Site2Site VPN aufzubauen (Wenn gleiche Netze/Subnet's benützt werden = Ovelapping Encryption Domain)?
| |
|
| |
| • Wenn gleiche Netze/Subnets benutzt werden muss ein NAT (Network Address Translation) konfiguriert werden. Welche Netze/Subnets werden dazu benützt?
| |
|
| |
| • Können beide Seiten für die Phase2 "wildcard" (0.0.0.0/0) im "Quick Mode" Selector benutzen?
| |
|
| |
| • Welche Einstellungen sollen benutzt werden für die Phase1/2 die da sind:
| |
|
| |
| '''Network'''
| |
| Interface based VPN (kein Policy based VPN)
| |
| IP Version: 4
| |
| Remote Gateway IP: ? (Statische Public IP / DDNS Name)
| |
| Mode Config: None
| |
| NAT Traversal: Activate
| |
| NAT Traversal Keepalive Frequency: 10
| |
| DPD (Dead Peer Detection): Activate
| |
|
| |
| '''Authentication'''
| |
| Method: PSK (Preshared Key sollte über SMS und/oder Teleon ausgetauscht werden)
| |
| IKE: Version 1
| |
| Mode: Main-Mode (Für Site2Site VPN nur in Ausnahmefällen "Aggressive Mode" benutzen)
| |
|
| |
| '''Phase1 Proposal'''
| |
| Encryption: AES256
| |
| Authentication: MD5
| |
| Fallback Encryption: AES256
| |
| Fallback Authentication: SHA1
| |
| DH Group (Diffie-Hellmann Group): 5
| |
| Key Lifetime (seconds): 86400
| |
| Local ID: None
| |
| XAUTH: None
| |
|
| |
| '''Phase2 Proposal'''
| |
| Encryption: AES256
| |
| Authentication: MD5
| |
| Fallback Encryption: AES256
| |
| Fallback Authentication: SHA1
| |
| Enable Replay Detection: Activate
| |
| PFS (Perfect Forward Secret): Activate
| |
| DH Group (Diffie-Hellmann Group): 5
| |
| Autokey Keep Alive: Activate
| |
| Auto-negotiate: Activate
| |
| Key Lifetime (seconds): 43200
| |
|
| |
| Quick Mode Selector Local Address: 0.0.0.0/0
| |
| Quick Mode Selector Remote Address: 0.0.0.0/0
| |
|
| |
| • Beide Seiten des Site2Site VPN's müssen sich über die Angaben resp. Konfiguration einigen!
| |
|
| |
| • Konfiguriere Phase1/2 anhand der ausgehandelten Angaben!
| |
|
| |
| • Konfiguriere für Remote Address (Netz/Subnet) "Statische Routen" (als Interface wird Phase1 Name benutzt)
| |
|
| |
| • Konfiguriere Firewall Policy Rule Netze/Subnet (nicht "all") für Incoming und/oder Outgoing Traffic (als Interface wird Phase1 benutzt)
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Sobald beide Seiten das VPN ordnungsgemäss konfiguriert haben und sich auf das PSK (Preshared Key) geeinigt haben kann
| |
| das VPN getestet werden. Dabei ist es Hilfreich einen Server freizugeben im entsprechenden Netz (Firewall Policy Rule)
| |
| der über ICMP erreichbar ist (vorgängig testen). Für einen Test sollte nich das interne Interface der Firewall benutzt
| |
| werden sondern die effektive Destination (Routing!). Dabei sollte bei Problem folgendes berücksichtigt werden:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_sieht_der_.22Output.22_f.C3.BCr_ein_IPSec_VPN_im_Debugging_Mode_aus.3F |Wie sieht der "Output" für ein IPSec VPN im Debugging Mode aus?]]
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_kann_ich_f.C3.BCr_ein_IPSec_VPN_f.C3.BCr_Phase-1_und.2Foder_2_ein_Debugging_ausf.C3.BChren.3F |Wie kann ich für ein IPSec VPN für Phase-1 und/oder 2 ein Debugging ausführen?]]
| |
|
| |
| Desweiteren wenn ein Site2site VPN verändert wird dh. für Routing und/oder zB für neue Netz/Subnet's sollte die Erneuerung
| |
| des Routing (Routing Tabelle) sowie die Erneuerung der SA (Security Association) berücksichtigt werden:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_kann_ich_ein_IPSec_VPN_neu_Initieren_.28Starten.29_damit_von_Grundauf_neue_Informationen_.28SA.29_aktiv_werden.3F |Wie kann ich ein IPSec VPN neu Initieren (Starten) damit von Grundauf neue Informationen (SA) aktiv werden?]]
| |
|
| |
| === Kann man mit Fortigate eine IPSec VPN Verbindungen (Site2Site) mit Fremdanbietern herstellen (Interoperability Device)? ===
| |
|
| |
| Fortigate's folgen betreffend IPSec einem IPSec Standard und somit gegenüber Fremdanbietern (Interoperability Device's) Kompatibel. Die offenen Fragen die sich ergeben in solchen Situationen/Konfigurationen betreffen Hauptsächlich die Phase-1 und/oder 2. Dies bedeutet beide Seiten müssen über die gleiche Konfiguration verfügen. Nur so komunizieren die unterschiedlichen Device's einwandfrei. Zu diesen Fragen sollten die in der Phase-1 und/oder 2 verwendeten Konfigurationspunkte gehören. Nachfolgend ein Beispiel um welche Konfigurationspunkte es sich handelt:
| |
|
| |
| [[Datei:Fortinet-1165.jpg]]
| |
| [[Datei:Fortinet-1166.jpg]]
| |
| [[Datei:Fortinet-1167.jpg]]
| |
|
| |
| Wenn die nötigen Informationen ausgetauscht sind, ist es Sinnvoll über bestimmte Sonderheiten betreffend dem Fremdanbieter kurz zu recherchieren. Folgende Seite von Fortinet gibt einige Hinweise über Fremdanbietern sowie gewissen Konfigurationspunkte. Dabei spielt jedoch Firmewarestand etc. event. eine Rolle;
| |
|
| |
| http://kb.fortinet.com/kb/microsites/microsite.do?cmd=displayKC&externalId=FD30603
| |
|
| |
| Nach der Konfiguration ist es Sinnvoll die Phase-1 und/oder 2 näher über den Debugging Mode zu kontrollieren um event. Fehlermeldungen zu verhindern:
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Wenn es zu Problemen kommt sollte auf beiden Seiten ein Debug Mode ausgeführt werden. Nur in Kooperation kann die
| |
| Konfiguration vervollständigt werden um einen zukünftig einwandfreien Betrieb zu gewährleisten!
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_sieht_der_.22Output.22_f.C3.BCr_ein_IPSec_VPN_im_Debugging_Mode_aus.3F]]
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_kann_ich_f.C3.BCr_ein_IPSec_VPN_f.C3.BCr_Phase-1_und.2Foder_2_ein_Debugging_ausf.C3.BChren.3F]]
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_kann_ich_ein_IPSec_VPN_neu_Initieren_.28Starten.29_damit_von_Grundauf_neue_Informationen_.28SA.29_aktiv_werden.3F]]
| |
|
| |
| Nachfolgend einige Informationen betreffend Fremdanbietern (Interoperability Device):
| |
|
| |
| <big>'''IPSEC MICROSOFT AZURE <--> FORTIGATE''':</big>
| |
|
| |
| [[Datei:IPsec-VPN-FGT-Microsoft-Azure.pdf]]
| |
|
| |
| Fortinet Unterstützt AZURE betreffend FortiOS Site2Site VPN ab folgenden Versionen:
| |
|
| |
| Ab 5.2.7 oder höher
| |
| Ab 5.4.x oder höher
| |
|
| |
| Wenn FortiOS eingesetzt werden zB 5.2.6 oder tiefer kommt es nach einiger Zeit in der Phase2 zu Problemen (random failures).
| |
| Ebenfalls wird über folgenden Link aufgelistet betreffend AZURE welche Devices/OS für AZURE unterstützt werden:
| |
|
| |
| https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-vpn-devices
| |
| https://azure.microsoft.com/en-us/documentation/articles/vpn-gateway-about-vpn-devices/
| |
|
| |
| <big>'''IPSEC CISCO ASA <--> FORTIGATE''':</big>
| |
|
| |
| [[Datei:Configuring-IPsec-VPN-with-a-FortiGate-and-a-Cisco-ASA.pdf]]
| |
|
| |
| <big>'''IPSEC ASTARO/SOPHOS V8 <--> FORTIGATE''':</big>
| |
|
| |
| http://www.sophos.com/de-de/support/knowledgebase/116130.aspx
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Unter Astaro/Sophos im Zusammenhang mit Fortigate muss die Encryption "3DES" benutzt werden ansonsten kommt
| |
| es zu Problemen (Error INVALID-MESSAGE-ID)! Der Grund liegt in der Implementierung von "AES" seitens Sophos. Dies
| |
| gilt für FortiOS 4.x sowie 5.x basierend auf Astaro 8.x:
| |
|
| |
| '''Astaro/Sophos Konfiguration 8.x'''
| |
|
| |
| [[Datei:Fortinet-777.jpg]]
| |
|
| |
| '''Fortigate Konfiguration 4.x / 5.x'''
| |
|
| |
| [[Datei:Fortinet-778.jpg]]
| |
|
| |
| <big>'''IPSEC SOPHOS V9 <--> FORTIGATE''':</big>
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Unter Sophos Version 9.x hat sich die Limitierung betreffend "3DES" geändert dh. folgende Konfiguration wurde getestet
| |
| und läuft einwandfrei:
| |
|
| |
| '''Sophos Konfiguration 9.x'''
| |
|
| |
| [[Datei:Fortinet-1342.jpg]]
| |
|
| |
| [[Datei:Fortinet-1343.jpg]]
| |
|
| |
| [[Datei:Fortinet-1344.jpg]]
| |
|
| |
| '''Fortigate Konfiguration 5.x'''
| |
|
| |
| [[Datei:Fortinet-1340.jpg]]
| |
|
| |
| [[Datei:Fortinet-1341.jpg]]
| |
|
| |
| === Gibt es eine Möglichkeit mit einem Android über IPSec eine Verbindung aufzubauen zu einer Fortigate? ===
| |
|
| |
| Die beiden offiziellen Apps von Fortinet für IPhone und/oder Android unterstützen in der 5.0 Version ausschliesslich das Browsen dh. wenn man verbunden ist mit dem APP kann der aufgebaute VPN Tunnel nur für das Browsen benutzt werden deshalb wird dieser Client auch "SSL proxy VPN connection agent" genannt. Neu unter FortiOS 5.2 unterstützt - im Gegensatz zu IOS - Android ebenfalls eine IPSec Verbindung. Will man eine klassische IPSec Verbindung anhand eines IOS Gerätes durchführen so ist das mit dem Cisco Client (Unity Client) möglich sowie mit der eingebauten VPN Funktion eines IPhones. Nachfolgende Links geben Auskunft wie so eine Verbindung zu konfigurieren ist auf Android:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Gibt_es_f.C3.BCr_IOS_und_Android_einen_SSL_VPN_Client.3F]]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Für die Konfiguration eines IOS Devices anhand des "build-in" Cisco Client's siehe nachfolgenden Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Gibt_es_eine_M.C3.B6glichkeit_mit_einem_IPhone.2FIPad_.C3.BCber_IPSec_eine_Verbindung_aufzubauen_zu_einer_Fortigate.3F]]
| |
|
| |
| === Gibt es eine Möglichkeit mit einem IPhone/IPad über IPSec eine Verbindung aufzubauen zu einer Fortigate? ===
| |
|
| |
| Ab FortiOS 5.0.2 ist es möglich den "build-in" Cisco VPN Client anhand des "iPhone Configuration Utility" für Windows und/oder MAC zu konfigurieren anhand eines Profiles (.mobileconfig) und dieses wiederum auf der FortiGate unter "Endpoint Profile" einzulesen damit dieses Profile den IPhone/IPad Devices (min. IOS V5.1.1) zugewiesen wird. Dies geschieht über das "FortiClient" App. Folgendes Dokument beschreibt diesen Vorgang sowie dessen Konfiguration:
| |
|
| |
| [[Datei:mobile-configuration-profiles-technical-note.pdf]] (Mobile Configuration Profiles for iOS Devices Technical Note)
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Wenn die IPSec Konfiguration durchgeführt wird speziell mit dem Cisco Client muss Split Tunneling
| |
| deaktiviert werden ansonsten kommt es zu Problemen! Das Tool das im vorhergehenden Dokument erwähnt ist
| |
| um die VPN Konfiguration unter Windows als File .mobileconfig vorzukonfigurieren wird durch Apple unter
| |
| Windows "nicht" mehr zur Verfügung gestellt. Nachfolgend wird dieses Tool unter Windows hier zur Verfügung
| |
| gestellt jedoch ohne Gewähr:
| |
|
| |
| [[Datei:iPhoneConfigUtilitySetup_3.6.2.zip]] Windows 7 32bit/64bit
| |
|
| |
| Damit diese Konfiguration anhand .mobileconfig durchgeführt werden kann muss die SSL-VPN Konfiguration (Web Portal) auf der FortiGate durchgeführt werden. Wie ein SSl-VPN auf einer FortiGate konfiguriert wird siehe nachfolgenden Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_konfiguriere_ich_unter_FortiOS_5.0_ein_SSL-VPN_Portal.2FTunnel_auf_einer_Fortigate.3F]]
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_konfiguriere_ich_unter_FortiOS_5.2_ein_SSL-VPN_Portal.2FTunnel_auf_einer_Fortigate.3F]]
| |
|
| |
| Desweiteren stellt sich immer wieder die Frage "wie ein Zertifikat für iOS auf einer FortiGate zu erstellen ist sowie auf dem iOS Device zu installieren ist". Folgender Artikel gibt Auskunft über diese Thematik:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_installiere_ich_f.C3.BCr_FortiClient_f.C3.BCr_iOS_.28Apple.29_ein_Zertifikat_auf_den_entsprechenden_Device.3F]]
| |
|
| |
| Nachfolgend einige Links mit zusätzlichen Informationen:
| |
|
| |
| '''Support Notes für IPhone und IPad:'''
| |
| http://kb.fortinet.com/kb/documentLink.do?popup=true&externalID=FD30893&languageId=
| |
|
| |
| '''Cisco Client (Unity Client):'''
| |
| http://kb.fortinet.com/kb/documentLink.do?popup=true&externalID=FD33376&languageId=
| |
|
| |
| '''IPhone IPsec VPN Setup:'''
| |
| [[Datei:FortiGate-iPhone_VPN_Setup-Guide_v1.0_English_2010210.pdf]]
| |
|
| |
| http://kb.fortinet.com/kb/microsites/search.do?cmd=displayKC&docType=kc&externalId=FD31619
| |
|
| |
| === Wie wird unter FortiOS 5.0 ein IPSec basierende Site2Site VPN Verbindung aufgebaut (Interface Based)? ===
| |
|
| |
| In den nachfolgenden Schritten wird gezeigt wie eine Site2Site IPSec VPN Verbindung unter FortiOS 5.0 zwischen zwei Fortigate's konfiguriert wird. Für die Konfiguration gehen wir von folgender Situation aus:
| |
|
| |
| _________________________ ___________ __________ ____________ _________________________
| |
| | | 192.168.2.99| |212.59.153.114/29 | | 193.193.135.66/29| |192.168.1.99 | |
| |
| | LAN Env. 192.168.2.0/24 |----- LAN ------| Forti I |------ WAN1 ------| Internet |------ WAN 1 ------| Forti II |------ LAN -----| LAN Env. 192.168.1.0/24 |
| |
| |_________________________| |___________| |__________| |____________| |_________________________|
| |
|
| |
| Als Erstes konfigurieren wir die "Forti I" dh. erstelle zuerst eine IPSec Phase-1 und 2 für das IPSec basierende site2site VPN zur "Forti II":
| |
|
| |
| VPN > IPsec > AutoKey (IKE) > Create Phase 1
| |
|
| |
| [[Datei:Fortinet-143.jpg]]
| |
|
| |
| [[Datei:Fortinet-144.jpg]]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Ab FortiOS 5.0.4 wird ein VPN in der Phase-1 automatisch "Interface Based" konfiguriert und nicht mehr "Policy Based".
| |
| Der entsprechende Konfigurationspunkt im Web Mgmt. Interface "Enable IPSec Interface Mode" steht nicht mehr zur Verfügung. Dies
| |
| bedeutet im Hintergrund wird folgendes Kommando ausgeführt:
| |
|
| |
| # config vpn ipsec phase1-interface
| |
|
| |
| Grundsätzlich sollte kein IPSec VPN "Policy Based" mehr konfiguriert werden da diese Art von VPN's nicht beschleunigt wird.
| |
| Ein "Interface Based" VPN wird per Standard beschleunigt (Acceleration). Wenn aus "Interoperability" Gründen eine "Policy
| |
| Based" Konfiguration durchgeführt werden soll zeigt nachfolgender Artikel die nötigen Konfigurations Schritte:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_konfiguriere_ich_eine_IPSec_VPN_in_der_Phase-1.2F2_als_.22Policy_Based.22_VPN.3F]]
| |
|
| |
| Erstelle nun auf der "Forti I" die Phase-1 für die "Forti II":
| |
|
| |
| VPN > IPsec > AutoKey (IKE) > Create Phase 2
| |
|
| |
| [[Datei:Fortinet-145.jpg]]
| |
|
| |
| [[Datei:Fortinet-146.jpg]]
| |
|
| |
| Nun die "Forti II" hat einen LAN Segment von "192.168.1.0/24". Diese LAN Segment muss auf der "Forti I" bekannt gemacht werden dh. Routing Technisch so definiert werden, damit die "Forti I" weiss wohin dieser IP Range geroutet werden muss! Da dieser IP Range der "Forti II" über das entsprechende IPSec Interface auf der "Forti I" erreichbar ist, muss dieser IP Range anhand eines statischen Route Eintrages auf das entsprechende IPSec Interface auf der "Forti I" geroutet werden. Dieser statische Route Eintrag kommt der "Encryption Domain" gleich. Die Encryption Domain ist per Definition der Bereich der verschlüsselt/entschlüsselt werden soll. Wenn mehrere IP Ranges im Spiel sind ist dabei zu beachten, dass die Definiton korrekt sind dh. die Subnet's übereinstimmen! Erstelle deshalb auf der "Forti I" einen statische Route für "192.168.1.0/24":
| |
|
| |
| Router > Static > Static Route
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Dieser Menüpunkt steht unter FortiOS 5.0 nur zur Verfügung wenn der entsprechende Menüpunkt unter
| |
| folgender Position aktiviert wurde:
| |
|
| |
| System > Config > Feature > Advanced Routing
| |
|
| |
| Danach muss kurz ausgeloggt sowie ein erneutes Login durchgeführt werden. Wurde das entsprechende
| |
| Feature nicht aktiviert steht der Menüpunkt für das "Static Route" unter folgenden Punkt zur Verfügung:
| |
|
| |
| System > Network > Routing
| |
|
| |
| [[Datei:Fortinet-147.jpg]]
| |
|
| |
| [[Datei:Fortinet-148.jpg]]
| |
|
| |
| Nun da es sich um einen neue Seite/Interface handelt auf der "Forti-I" kann für Policy Zwecken einen neue Zone erstellt werden:
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Ab FortiOS 5.0.3 kann in einer Firewall Policy mehrere Interfaces definiert werden was in den vorhergehenden
| |
| Versionen nicht möglich war. Aus diesem Grund wurde oft mit Zonen gearbeitet. Da die Definition in der Firewall
| |
| Policy von mehreren Interface ab FortiOS 5.0.3 möglich ist sind Zonen nicht mehr zu empfehlen da diese gegenüber
| |
| der Firewall Policy Abhängigkeiten schaffen
| |
|
| |
| System > Network > Interface > Create New > Zone
| |
|
| |
| [[Datei:Fortinet-149.jpg]]
| |
|
| |
| [[Datei:Fortinet-150.jpg]]
| |
|
| |
| Die Zone ist nun bekannt jedoch benötigen wir noch die entsprechenden Firewall Policy Rules die den Traffic von oder zu "Forti-II" erlauben:
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Anstelle der Zone kann auch direkt das entsprechende VPN Interface in der Firewall Policy benutzt werden!
| |
|
| |
| [[Datei:Fortinet-151.jpg]]
| |
|
| |
| [[Datei:Fortinet-152.jpg]]
| |
|
| |
| [[Datei:Fortinet-153.jpg]]
| |
|
| |
| [[Datei:Fortinet-154.jpg]]
| |
|
| |
| Diese Firewall Policy Rules erlauben sämtlichen Traffic "Von" und "Zur" Encryption Domain. Auch hier ist zu empfehlen den Traffic einzuschränken und die effektiven IP Ranges klar zu definieren da diese als Definition der "Encryption Domain" gelten. Es sollte dem Grunsatz gefolgt werden:
| |
|
| |
| Statischer Route Eintrag = Firewall Policy Destination
| |
|
| |
| Die Konfiguration auf der "Forti-I" ist somit abgeschlossen. Führe auf der "Forti-II" exakt die gleiche Konfiguration durch wie für die "Forti-I" jedoch mit den entsprechenden Anpassungen des Segments. Danach kann ein Test ausgeführt werden. Bei diesem Test zB auf der Fortigate selber (über Console) ist zu berücksichtigen, dass wenn ein Ping abgesetzt wird sollte dieser mit der korrekten Source durchgeführt werden. Die Source in einem Ping kann folgendermassen ausgeführt werden:
| |
|
| |
| # exec ping-options source [IP der gewünschten Source zB LAN Interface .99]
| |
| # exec ping [Destination LAN Env Forti-I oder Forti-II]
| |
|
| |
| Wenn die Verbindung Probleme bereitet und ein Debug nötig wird so sollten folgende Artikel berücksichtigt werden:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_sieht_der_.22Output.22_f.C3.BCr_ein_IPSec_VPN_im_Debugging_Mode_aus.3F]]
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_kann_ich_f.C3.BCr_ein_IPSec_VPN_f.C3.BCr_Phase-1_und.2Foder_2_ein_Debugging_ausf.C3.BChren.3F]]
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_kann_ich_ein_IPSec_VPN_neu_Initieren_.28Starten.29_damit_von_Grundauf_neue_Informationen_.28SA.29_aktiv_werden.3F]]
| |
|
| |
| Wenn der IPSec VPN Tunnel etabliert wurde jedoch der Traffic nicht auf der anderen Seite ankommt, muessen die Firewall Policy Rules angeschaut werden. Um zu sehen ob ein Packet abgesendet wird etc. kann der Sniffer benutzt werden. Anhand dieses Sniffer's kann jedes einzelne Interface überprüft werden ob der entsprechende Traffic das entsprechende Interface erreicht.
| |
|
| |
| # diagnose sniffer packet [Interface Name zB wan1 oder internal] icmp
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Weitere Informationen zur Verwendung der "sniffer" Funktion siehe nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_benutze_ich_das_Sniffer_Kommando_.22diagnose_sniffer_packet.22.3F]]
| |
|
| |
| === Wie wird unter FortiOS 5.2 ein IPSec basierende Site2Site VPN Verbindung aufgebaut (Interface Based)? ===
| |
|
| |
| In den nachfolgenden Schritten wird gezeigt wie eine Site2Site IPSec VPN Verbindung unter FortiOS 5.2 zwischen zwei Fortigate's konfiguriert wird. Für die Konfiguration gehen wir von folgender Situation aus:
| |
|
| |
| _________________________ ___________ __________ ____________ _________________________
| |
| | | 192.168.2.99| |212.59.153.114/29 | | 193.193.135.66/29| |192.168.1.99 | |
| |
| | LAN Env. 192.168.2.0/24 |----- LAN ------| Forti-I |------ WAN1 ------| Internet |------ WAN 1 ------| Forti-II |------ LAN -----| LAN Env. 192.168.1.0/24 |
| |
| |_________________________| |___________| |__________| |____________| |_________________________|
| |
|
| |
| Unter FortiOS 5.2 wurde die Art und Weise wie ein VPN konfiguriert wird grundlegend modifiziert. Dies bedeutet: Unter FortiOS 5.2 stehen sogenannte "Template's" (Vorlagen) zur Verfügung zB:
| |
|
| |
| Dialup - FortiClient (Windows, Mac, OS, Androis)
| |
| Site to Site - FortiGate
| |
| Dialup - iOS (Native)
| |
| Dialup - Android (Native L2TP/IPSec)
| |
| Dialup - Cisco Firewall
| |
| Site to Site - Cisco
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Alle diese "Template's" haben eines Gemeinsam denn diese "Template's" erstellen/konfigurieren
| |
| im Hintrgrund automatisch die Konfiguration inkl. Firewall Policy und event. Routing. Diese
| |
| "Template's" heranzuziehen um eine Konfiguration zu erstellen ist Sinnvoll bei Dialup Verbindungen
| |
| wie FortiClient, iOS, Android jedoch nicht für klassische IPSec Site2Site Verbindungen. Für
| |
| Site2Site Verbindungen sind diese "Template's" zu wenig Transparent in der Konfiguration. Egal
| |
| Ob diese "Template's" benutzt werden oder nicht sollte immer im Auge behalten werden, dass für
| |
| eine VPN Verbindung folgende Aspekte zu berücksichtigen sind:
| |
|
| |
| • Nach der Erstellung des IPSec VPN's kontrolliere Phase-1 und/oder 2!
| |
| • Kontrolliere ob die entsprechenden Routing Einträge für das IPSec erstellt wurden!
| |
| • Kontrolliere ob eine entsprechende Firewall Policy Rule erstellt wurde!
| |
|
| |
| Folgende Kommandos auf der CLI können benützt werden um die Kontrolle durchzuführen:
| |
|
| |
| # config vpn ipsec [phase1-interface | phase2-interface]
| |
| # config router static
| |
| # config firewall policy
| |
|
| |
| Wir empfehlen für eine Site2Site IPSec VPN Konfiguration diese ohne die Hilfe der "Template's" durchzuführen. Gemäss unserem Beispiel nachfolgend die Schritte für die Konfiguration auf der "Forti-I":
| |
|
| |
| <big>'''Konfiguration Phase-1/2 IPSec VPN'''</big>
| |
|
| |
| VPN > IPSec > Tunnels > Create New
| |
|
| |
| [[Datei:Fortinet-1185.jpg]]
| |
|
| |
| [[Datei:Fortinet-1186.jpg]]
| |
|
| |
| [[Datei:Fortinet-1187.jpg]]
| |
| [[Datei:Fortinet-1188.jpg]]
| |
| [[Datei:Fortinet-1189.jpg]]
| |
| [[Datei:Fortinet-1190.jpg]]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Die Position "Phase-2 Selectors" stellt die Funktion des "Quick-Mode Selectors" dar und ist unter normalen
| |
| Umständen nicht konfiguriert werden!
| |
|
| |
| <big>'''Erstellen der nötigen Adress Obejkte für Forti-I'''</big>
| |
|
| |
| VPN > IPSec > Tunnels > Create New
| |
|
| |
| [[Datei:Fortinet-1191.jpg]]
| |
|
| |
| [[Datei:Fortinet-1192.jpg]]
| |
|
| |
| [[Datei:Fortinet-1193.jpg]]
| |
|
| |
| <big>'''Konfigurieren des Routing für Destination Forti-II'''</big>
| |
|
| |
| System > Network > Routing > Create New
| |
|
| |
| [[Datei:Fortinet-1194.jpg]]
| |
|
| |
| [[Datei:Fortinet-1195.jpg]]
| |
|
| |
| <big>'''Erstellen der Firewall Policy für Forti-I Incoming/Outgoing'''</big>
| |
|
| |
| Policy > Policy > IPv4 > Create New
| |
|
| |
| [[Datei:Fortinet-1196.jpg]]
| |
|
| |
| '''Incoming'''
| |
| [[Datei:Fortinet-1197.jpg]]
| |
|
| |
| [[Datei:Fortinet-1196.jpg]]
| |
|
| |
| '''Outgoing'''
| |
| [[Datei:Fortinet-1198.jpg]]
| |
|
| |
| Die Konfiguration auf "Forti-I" ist abgeschlossen. Nun muss auf der "Forti-II" exakt die gleiche Phase-1/2 konfiguriert werden sowie das Routing und Firewall Policy im umgekehrten Sinne. Wenn das IPSec anhand eines Debugging Mode für Phase-1/2 verfiziert werden soll siehe nachfolgenden Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_sieht_der_.22Output.22_f.C3.BCr_ein_IPSec_VPN_im_Debugging_Mode_aus.3F]]
| |
|
| |
| Wenn Traffic für den IPSec Tunnel verifiziert werden soll kann anhand der Sniffer Funktion diese durchgeführt werden:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_benutze_ich_das_Sniffer_Kommando_.22diagnose_sniffer_packet.22.3F]]
| |
|
| |
| Wenn nach der Grundkonfiguration Modifikationen des IPSec VPN durchgeführt wurden sei es im Routing und/oder Phase-1/2 ist es Sinnvoll das VPN komplett runterzufahren um es erneut von Grundauf neu zu starten. Nachfolgender Artikel zeigt wie dies korrek durchgeführt wird:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_kann_ich_ein_IPSec_VPN_neu_Initieren_.28Starten.29_damit_von_Grundauf_neue_Informationen_.28SA.29_aktiv_werden.3F]]
| |
|
| |
| === Wie konfiguriere ich eine IPSec VPN in der Phase-1/2 als "Policy Based" VPN? ===
| |
|
| |
| Bis FortiOS 5.0.3 konnte man in der Phase-1 den Konfigurations Punkt "Enable IPSec Interface Mode" aktivieren. Wurde dieser aktiviert, wurde die entsprechende Phase-1/2 als "Interface Baed" VPN konfiguriert. Wurde dieser Punkt nicht aktiviert so wurde die entsprechende Phase-1/2 als "Policy Based" VPN konfiguriert. Da der Punkt "Enable IPSec Interface Mode" nicht per Standard aktiviert war wurden VPN's bis FortiOS 5.0.3 per Standard als "Policy Based" VPN konfiguriert. Ab FortiOS 5.0.3 existiert dieser Konfigurationspunkt "Enable IPSec Interface Mode" nicht mehr. Ab FortiOS 5.0.3 wird bei der Konfiguration über das Web Mgmt. Interface einer Phase-1/2 automatisch folgender Befehl ausgeführt:
| |
|
| |
| config vpn ipsec phase1-interface
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Wenn unter FortiOS 5.2 ein IPSec VPN erstellt wird "ohne" Template so steht der Konfigurationspunkt
| |
| "Enable IPSec Interface Mode" wieder in der Phase-1 zur Verfügung!
| |
|
| |
| Somit ist der "Interface Mode" ab FortiOS 5.0.3 der Standard auf einer Fortigate. "Policy Based" VPN's sollten nicht mehr konfiguriert werden da diese Art der VPN's über keine Beschleunigung (Acceleration) verfügen. Es kann auf "Interoperability" (Fremdanbietern) Devices vorkommen, dass nur ein "Policy Based" VPN die Kompatiblität innerhalb eines VPN's gewährleistet. Ein "Policy Based" VPN wird im Web Mgmt. Interface innerhalb der Firewall Policy konfiguriert. Dieses Feature steht jedoch ab FortiOS 5.0.4 nur dann zur Verfügung, wenn dieses über folgende Position aktiviert wird:
| |
|
| |
| System > Config > Features > Show More > Policy-based IPsec VPN
| |
|
| |
| [[Datei:Fortinet-815.jpg]]
| |
|
| |
| Wird das Feature aktiviert kann ein Policy Based VPN in der Firewall Policy konfiguriert werden:
| |
|
| |
| '''FortiOS 5.0'''
| |
| [[Datei:Fortinet-1168.jpg]]
| |
|
| |
| '''FortiOS 5.2'''
| |
| [[Datei:Fortinet-1169.jpg]]
| |
|
| |
| Ueber Kommandozeile kann der "Policy Based" Mode folgendermassen konfiguriert werden:
| |
|
| |
| '''FortiOS 5.0'''
| |
| # config vpn ipsec phase1
| |
| # edit [Name der Phase1 Policy Based]
| |
| # get
| |
| name : [Name der Phase1]
| |
| type : static
| |
| interface :
| |
| ip-version : 4
| |
| ike-version : 1
| |
| local-gw : 0.0.0.0
| |
| nattraversal : enable
| |
| dhgrp : 5
| |
| keylife : 28800
| |
| authmethod : psk
| |
| peertype : any
| |
| xauthtype : disable
| |
| mode : main
| |
| mode-cfg : disable
| |
| proposal : 3des-sha1 aes128-sha1
| |
| localid :
| |
| localid-type : auto
| |
| negotiate-timeout : 30
| |
| fragmentation : enable
| |
| dpd : enable
| |
| forticlient-enforcement: disable
| |
| comments :
| |
| npu-offload : enable
| |
| remote-gw : 0.0.0.0
| |
| monitor :
| |
| add-gw-route : disable
| |
| psksecret : *
| |
| keepalive : 10
| |
| auto-negotiate : enable
| |
| dpd-retrycount : 3
| |
| dpd-retryinterval : 5
| |
|
| |
| # config vpn ipsec phase2
| |
| # edit [Name der Phase1 Policy Based]
| |
| # get
| |
| name : [Name der Phase2]
| |
| phase1name : [Name der Phase1]
| |
| use-natip : enable
| |
| selector-match : auto
| |
| proposal : 3des-sha1 aes128-sha1
| |
| pfs : enable
| |
| replay : enable
| |
| keepalive : disable
| |
| auto-negotiate : disable
| |
| keylife-type : seconds
| |
| encapsulation : tunnel-mode
| |
| comments :
| |
| dhgrp : 5
| |
| keylifeseconds : 1800
| |
|
| |
| '''FortiOS 5.2'''
| |
| # config vpn ipsec phase1
| |
| # edit [Name der Phase1 Policy Based]
| |
| # get
| |
| name : [Name der Phase1]
| |
| type : static
| |
| interface :
| |
| ike-version : 1
| |
| local-gw : 0.0.0.0
| |
| nattraversal : enable
| |
| keylife : 86400
| |
| authmethod : psk
| |
| mode : main
| |
| peertype : any
| |
| autoconfig : disable
| |
| proposal : aes128-sha256 aes256-sha256 3des-sha256 aes128-sha1 aes256-sha1 3des-sha1
| |
| localid :
| |
| localid-type : auto
| |
| fragmentation : enable
| |
| dpd : enable
| |
| forticlient-enforcement: disable
| |
| comments :
| |
| npu-offload : enable
| |
| dhgrp : 14 5
| |
| wizard-type : custom
| |
| xauthtype : disable
| |
| mesh-selector-type : disable
| |
| remote-gw : 0.0.0.0
| |
| psksecret : *
| |
| keepalive : 10
| |
| auto-negotiate : enable
| |
| dpd-retrycount : 3
| |
| dpd-retryinterval : 5
| |
|
| |
| # config vpn ipsec phase2
| |
| # edit [Name der Phase1 Policy Based]
| |
| # get
| |
| name : [Name der Phase2]
| |
| phase1name : [Name der Phase1]
| |
| use-natip : enable
| |
| selector-match : auto
| |
| proposal : aes128-sha1 aes256-sha1 3des-sha1 aes128-sha256 aes256-sha256 3des-sha256
| |
| pfs : enable
| |
| dhgrp : 14 5
| |
| replay : enable
| |
| keepalive : disable
| |
| auto-negotiate : disable
| |
| keylife-type : seconds
| |
| encapsulation : tunnel-mode
| |
| comments :
| |
| keylifeseconds : 43200
| |
|
| |
| Wenn ein "Policy Based" VPN konfiguriert wird stellt sich die Frage, auf welches Interface muss das IP Segment, dass erreicht werden soll über das "Policy Based" VPN, geroutet werden? Da in einem "Policy Based" VPN kein Interface zur Verfügung steht wie im "Interface Mode" muesste das entsprechende IP Segment auf den Default Gateway geroutet werden!
| |
|
| |
| === Wie implementiere ich für ein IPSec VPN ein NAT (Source/Destination) für "Overlapping Encryption Domain)? ===
| |
|
| |
| Wenn ein IPSec zwischen zwei Fortigate's konfiguriert wird ist zu beachten, dass auf beiden Seiten unterschiedliche IP Sgemente existieren. Dies bedeutet: Beide Fortigates dürfen in deren IP Sgementen nicht den gleichen IP Range/Subnet benutzen. Ist dies der Fall spricht man von einer "Overlapping Encryption Domain". In so einer Situation kann/muss ein Source/Destination NAT implementiert werden. Nachfolgendes Beispiel zeigt eine Situation auf, in der auf beiden Seiten das gleiceh IP Segment existiert 192.168.1.0/24:
| |
|
| |
| _________________________ ___________ __________ ____________ _________________________
| |
| | | 192.168.1.99| |212.59.153.114/29 | | 193.193.135.66/29| |192.168.1.99 | |
| |
| | LAN Env. 192.168.1.0/24 |----- LAN ------| Forti-I |------ WAN1 ------| Internet |------ WAN 1 ------| Forti-II |------ LAN -----| LAN Env. 192.168.1.0/24 |
| |
| |_________________________| |___________| |__________| |____________| |_________________________|
| |
|
| |
| Die nachfolgende Konfiguration zeigt auf, wie auf der Seite von "Forti-I" aussehen würde. Da "Forti-I" als Destination für "Forti-II" nicht 192.168.1.0/24 benützen kann muss ein IP Range definiert werden. Dieser IP Range muss mit Forti-II abgesprochen werden, denn dieser darf ebenfalls nicht auf "Forti-II" existieren. Die Ausgangslage ist folgende:
| |
|
| |
| '''Overlapping Encryption Domain Forti-I --> Forti-II:'''
| |
|
| |
| Source: 192.168.1.0/24
| |
| Destination: 192.168.1.0/24
| |
|
| |
| '''Source/Destination NAT Forti-I <--> Forti-II:'''
| |
|
| |
| Source: 192.168.1.0/24 (Source NAT 10.10.10.0/24)
| |
| Destination: 192.168.1.0/24 (Destination 192.168.100.0/24)
| |
|
| |
| '''Source/Destination NAT Forti-II <--> Forti-I:'''
| |
|
| |
| Source: 192.168.1.0/24 (Source NAT 192.168.100.0/24)
| |
| Destination: 192.168.1.0/24 (Destination 10.10.10.0/24)
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Bei der Konfiguration von Source/Destination NAT ist folgendes betreffend NAT/Routing zu berücksichtigen:
| |
|
| |
| Es gilt = "NAT vor Routing"
| |
|
| |
| Nachfolgend die Konfiguration der Outgoing Firewall Policy Rule für "Forti-I" in der die Source translated wird auf 10.10.10.0/24 und als Destination für "Forti-II" 192.168.100.0/24 benutzt:
| |
|
| |
| <big>'''Outgoing Forti-I --> Forti-II'''</big>
| |
| **********************************
| |
|
| |
| Source Destination
| |
| 192.168.1.0/24 192.168.100.0/24
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Auf der Fortigate innerhalb einer Firewall Policy wird exakt diese Rule für das IPSec VPN konfiguriert. Dabei
| |
| muss auf der "Forti-I" beachtet werden, dass der IP Range/Subnet "192.168.100.0/24" der benutzt wird durch die
| |
| User auf der "Forti-I" um die Destinationen auf der "Forti-II" zu erreichen im Netz der "Forti-I" zur Fortigate
| |
| geroutet wird. Gleichzeitig muss der IP Range den wir benutzen für die Destintion auf das IPSec der "Forti-II"
| |
| geroutet werden. In dieser Firewall Policy wird "Source NAT" aktiviert und der IP Range/Subnet 192.168.1.0/24
| |
| translated 1:1 NAT anhand des IP Range/Subnet 10.10.10.0/24!
| |
|
| |
| <big>'''Aktiviere Central NAT Table'''</big>
| |
|
| |
| System > Config > Features > Show More > Central NAT Table
| |
|
| |
| [[Datei:Fortinet-1170.jpg]]
| |
|
| |
| <big>'''Destination Routing IPSec Forti-II'''</big>
| |
|
| |
| [[Datei:Fortinet-1171.jpg]]
| |
|
| |
| [[Datei:Fortinet-1172.jpg]]
| |
|
| |
| <big>'''Erstellen des Source NAT Objekts (VIP IP-Pool)'''</big>
| |
|
| |
| '''FortiOS 5.0'''
| |
| Firewall Objects > Virtual IP > IP Pools > Create New
| |
|
| |
| '''FortiOS 5.2'''
| |
| Policy & Objects > Objects > IP Pools > Create New
| |
|
| |
| [[Datei:Fortinet-1173.jpg]]
| |
|
| |
| [[Datei:Fortinet-1174.jpg]]
| |
|
| |
| <big>'''Erstellen der Adress Objekte für Forti-I/II'''</big>
| |
|
| |
| '''FortiOS 5.0'''
| |
| Firewall Objects > Address > Address > Create New
| |
|
| |
| '''FortiOS 5.2'''
| |
| Policy & Objects > Objects > Addresses > Create New
| |
|
| |
| [[Datei:Fortinet-1175.jpg]]
| |
|
| |
| [[Datei:Fortinet-1176.jpg]]
| |
|
| |
| [[Datei:Fortinet-1175.jpg]]
| |
|
| |
| [[Datei:Fortinet-1177.jpg]]
| |
|
| |
| <big>'''Konfiguration des Source NAT in der Central NAT Table'''</big>
| |
|
| |
| Policy & Objects > Policy > Central NAT Table > Create New
| |
|
| |
| [[Datei:Fortinet-1178.jpg]]
| |
|
| |
| [[Datei:Fortinet-1179.jpg]]
| |
|
| |
| <big>'''Konfiguration der Firewall Policy Outgoing (Forti-I --> Forti-II)'''</big>
| |
|
| |
| '''FortiOS 5.0'''
| |
| Policy > Policy > Policy > Create New
| |
|
| |
| '''FortiOS 5.2'''
| |
| Policy > Policy > IPv4 > Create New
| |
|
| |
| [[Datei:Fortinet-1180.jpg]]
| |
|
| |
| [[Datei:Fortinet-1181.jpg]]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Durch die Aktivierung der Position NAT wird die Funktion des Source NAT aktiviert. Inerhalb
| |
| dieser Position wird Central NAT Table aktiviert. Aus diesem Grund wird diese Central NAT
| |
| Table benutzt um das Source NAT durchzuführen.
| |
|
| |
| Nachfolgend die Konfiguration der Incoming Firewall Policy Rule für "Forti-I" in der die Destination 10.10.10.0/24 -die durch "Forti-II" benutzt wird- translated wird auf 192.168.1.0/24 und "Forti-II" als Source 192.168.100.0/24 benutzt:
| |
|
| |
| <big>'''Incoming Forti-II --> Forti-I'''</big>
| |
| **********************************
| |
|
| |
| Source Destination
| |
| 192.168.100.0/24 10.10.10.0/24 (vip)
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Auf der Fortigate innerhalb einer Firewall Policy wird exakt diese Rule für das IPSec VPN konfiguriert.
| |
| In dieser Firewall Policy wird "Destination NAT" 1:1 NAT konfiguriert dh. anhand eines VIP Objektes auf dem
| |
| Destination Interface "Forti-II"!
| |
|
| |
| <big>'''Erstellen des Destination NAT Objekts (VIP)'''</big>
| |
|
| |
| '''FortiOS 5.0'''
| |
| Firewall Objects > Virtual IP > Virtual IPs > Create New
| |
|
| |
| '''FortiOS 5.2'''
| |
| Policy & Objects > Objects > Virtual IPs > Create New
| |
|
| |
| [[Datei:Fortinet-1182.jpg]]
| |
|
| |
| [[Datei:Fortinet-1183.jpg]]
| |
|
| |
| <big>'''Konfiguration der Firewall Policy Incoming (Forti-II --> Forti-I)'''</big>
| |
|
| |
| '''FortiOS 5.0'''
| |
| Policy > Policy > Policy > Create New
| |
|
| |
| '''FortiOS 5.2'''
| |
| Policy > Policy > IPv4 > Create New
| |
|
| |
| [[Datei:Fortinet-1180.jpg]]
| |
|
| |
| [[Datei:Fortinet-1184.jpg]]
| |
|
| |
| Die Konfiguration auf der "Forti-I" ist nun abgeschlossen. Nun muss auf der "Forti-II" exakt die gleiche Konfiguration durchgeführt werden jedoch mit der umgekehrten Konstellation! Wenn die Konfiguration mehrmals geändert wird durch zB Troubleshooting sollte das IPSec komplett neu gestartet werden. Nähere Informationen dazu siehe nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_kann_ich_ein_IPSec_VPN_neu_Initieren_.28Starten.29_damit_von_Grundauf_neue_Informationen_.28SA.29_aktiv_werden.3F]]
| |
|
| |
| === Wie konfiguriere/erlaube ich für einen IPSec VPN Tunnel ein "netbios forward"? ===
| |
|
| |
| "Netbios" Anfragen werden auf einer Fortigate per Standard nicht über andere IP Range's/Segmente/Interface's weitergeleitet sondern geblockt. Wenn jedoch zB eine "Active Directory" Replizierung benutzt wird in einem IPSec VPN Tunnel muss "netbios foward" erlaubt werden ansonsten funktioniert die "Active Directory" Replizierung nicht. Die Konfiguration "netbios forward" in einem IPSec VPN Tunnel zu erlauben ist identisch wie die Konfiguration "netbios forward" über verschieden Interface's zu erlauben. Die Konfiguration die durchgeführt werden muss anhand "netbios-forward" ist basierend auf den Interface's. Wie das auf einem Interface konfiguriert wird zeigt nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Eine_.22Active_Directory.22_Replizierung_funktioniert_nicht_.C3.BCber_ein_VPN_Tunnel_.28netbios_forward.29.3F]]
| |
|
| |
| === Wie überprüft man ob eine IPSec VPN Verbindung die Hardware Acceleration benutzt (encrypt/decrypt)? ===
| |
|
| |
| Wenn eine IPSec VPN Verbindung konfiguriert wird, steht die Frage im Raum "ob die Verbindung Beschleunigt wird" resp. decrypt/encrypt (Offloding) benutzt wird? Ob eine Beschleunigung resp. die Hardware Acceleration benutzt wird oder nicht hängt vom verwendeten Mode ab (Interface/Policy Based), eingesetzen ASIC sowie FortiOS Version dh. somti spielt der Remote Peer (Interoperability Device) auch eine Rolle. Um festzustellen ob die Hardware Beschleunigung (ASIC) oder die Software benutzt wird, kann folgender Befehl abgesetzt werden:
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Je nach FortiGate Device gestaltet sich die Darstellung anderst dh. neuere Versionen des CP Prozessors oder
| |
| zusätzliche NP Prozessoren. Wichtig dabei ist das die entsprechenden Einträge nicht unter "Software" erscheinen
| |
| da dies bestätigen würde das "keine" Beschleunigung über die Hardware stattfindet (Offloading):
| |
|
| |
| # diagnose vpn ipsec status
| |
| All ipsec crypto devices in use:
| |
| CP6
| |
| null: 0 0
| |
| des: 0 0
| |
| 3des: 0 0
| |
| aes: 11342694 118453159
| |
| null: 0 0
| |
| md5: 0 0
| |
| sha1: 11342694 118453159
| |
| sha256: 0 0
| |
| sha384: 0 0
| |
| sha512: 0 0
| |
|
| |
| SOFTWARE:
| |
| null: 0 0
| |
| des: 0 0
| |
| 3des: 0 0
| |
| aes: 0 0
| |
| null: 0 0
| |
| md5: 0 0
| |
| sha1: 0 0
| |
| sha256: 0 0
| |
| sha384: 0 0
| |
| sha512: 0 0
| |
|
| |
| Aus diesem Output geht hervor das der "Content Prozessor" dh. CP eine Beschleunigung durchführt für das IPSec VPN. Daraus resultiert die Frage wieso der CP resp. "Content Prozessor" dies durchführt und nicht der NP resp. "Network Prozessor". Auf einer FortiGate ist der CP grundsätzlich zuständig im UTM Bereich eine Beschleuningung durchzuführen. Zusätzlich übernimmt jedoch auf einer FortiGate der CP die Beschleuningung des IPSec VPN's. Dies wird jedoch nur zur Beginn eine IPSec VPN durchgeführt dh für den Aufbau und zur Unterstützung für die Performance. Ausgehend von FortiOS 5.0 sowie bis FortiOS 5.2.2 muss dies explizit konfiguriert werden was wiederum bedeutet:
| |
|
| |
| '''Für NP2 und NP4 bis FortiOS 5.2.2'''
| |
|
| |
| # config system npu
| |
| # set dec-offload-antireplay enable
| |
| # set enc-offload-antireplay enable
| |
| # set offload-ipsec-host enable
| |
| # end
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Für NP6, NP4lite sowie ab FortiOS 5.2.3 ist dies nicht mehr nötig und wird automatisch durchgführt!
| |
|
| |
| Somit um die nötige Performance im IPSec VPN Bereich zu erreichen sollte auf sämtliche Software basierende IPSec VPN's verzichtet werden. Dazu gehören zB:
| |
|
| |
| -> Policy Based VPN's
| |
| -> L2TP VPN's
| |
|
| |
| Wenn man die Beschleunigung für IPSec VPN in den Session Table überprüfen möchte kann das entsprechende Kommando dazu benutzt werden um die Session Table aufzulisten. Weitere Informationen dazu siehe nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_kann_ich_die_momentanen_einzelnen_Sessions_auf_einer_FortiGate_auflisten.3F]]
| |
|
| |
| Dabei ist von Wichtigkeit die "npu_flag" Informationen korrekt zu intepretieren was wiederum folgendes bedeutet:
| |
|
| |
| Solange kein Traffic nach dem Aufbau der Phase-2 durch den IPSec VPN Tunnel gesendet wird steht das Flag "npu_flag" auf "00".
| |
| Dies bedeutet wiederum die SA wird nicht zum NPU gesendet. Wenn aus kompatibilitätsgründen der Traffic nicht Beschleunigt
| |
| werden kann bleibt dieses Flag "npu_flag" auf "00". Wenn Traffic initiert wird für Outbound und das erste Packet Beschleunigt
| |
| werden kann für Outbound so wechselt das "npu_flag" auf "01". Wenn Traffic für Inbound die FortiGate erreich so wird das erste
| |
| Packet mit dem "npu_flag" mit "02" versehen resp. damit zum NPU gesendet sofern dieses Beschleunigt werden kann. Wenn beide
| |
| Richtungen Beschleunigt werden können resp. beide SA bereits für Inbound/Outbound zum NPU gesendet wurde wechselt das "npu_flag"
| |
| auf "03".
| |
|
| |
| === Auf was muss ich achten wenn ein IPSec VPN konfiguriert wurde und der IPSec Tunnel immer aktiv bleiben soll? ===
| |
|
| |
| Wenn ein IPSec VPN konfiguriert wird so wird per Standard Phase-1/2 nur dann abgearbeitet wenn Traffic transportiert werden soll. Dies bedeutet: die Phase-1/2 wird initiert wenn Traffic produziert wird zwischen den Peer's. Wenn der Tunnel nicht oft genutzt wird zB einmal im Tag wird Traffic übermittelt für eine kurze Zeit, ist die Standard Konfiguration ausreichend. Wird der Tunnel oft genutzt ist es besser den IPSec Tunnel "immer" aktiv zu halten da ansonsten Phase-1/2 bei jedem Traffic neu Initiert wird. Wenn der IPSec Tunnel "immer" aktiv ist, werden mehr Resourcen auf der Fortigate alloziertt um den IPSec Tunnel aktiv zu halten. Soll der IPSec Tunnel zwischen den Peer's immer aktiv bleiben müssen zwei Optionen aktiviert werden:
| |
|
| |
| '''FortiOS 5.0'''
| |
| VPN > IPsec > [Wähle die Phase2 des entsprechenden VPN] > Advanced
| |
|
| |
| '''FortiOS 5.2'''
| |
| VPN > IPsec > Tunnels > [Wähle die Phase2 des entsprechenden VPN] > Edit Phase 2 > Advanced
| |
|
| |
| Autokey Keep Alive
| |
| Auto-negotiate
| |
|
| |
| Diese zwei Optionen stehen über Web Mgmt. Interface in der Phase-2 für FortiOS 5.0 / 5.2 unter Advanced zu verfügung und müssen aktiviert werden. Unter FortiOS 4 steht über das Web Mgmt. Interface nur die Option "Auto-Negotiate" zur Verfügung und "Autokey Keep Alive" steht nur über Kommandozeile zur Verfügung und zwar über folgende Position:
| |
|
| |
| # config vpn ipsec phase2-interface
| |
| # edit [Name der Phase2]
| |
| # set auto-negotiate enable
| |
| # set keepalive enable
| |
| # end
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Wird ein Policy Based VPN benutzt muss folgender Befehl benutzt werden:
| |
|
| |
| # config vpn ipsec phase2
| |
|
| |
| Diese Optionen stehen zum Teil ebenfalls auf Interoperability Devices (Fremdprodukte) zur Verfügung und müssen auf diesen Devices auch aktiviert werden! Weitee Informationen wie der DPD Mechanismus funktioniert siehe nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_funktioniert_DPD_.28Dead_Peer_Detection.29_und_in_welchem_Zusammenhang_steht_DPD_mit_der_Option_.22keepalive.22.3F]]
| |
|
| |
| Nachdem die Konfiguration durchgeführt wurde sollte der VPN Tunnel neu gestartet werden:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_kann_ich_einen_IPSEC_VPN_Tunnel_Manuell_Stoppen_und_Starten.3F]]
| |
|
| |
| === Wie funktioniert DPD (Dead Peer Detection) und in welchem Zusammenhang steht DPD mit der Option "keepalive"? ===
| |
|
| |
| Eine FortiGate stellt im IPSec Bereich ein Mechanismus zur Verfügung der sich DPD nennt dh. "Dead Peer Detection". Dieser Mechanismus stellt bei Aktivierung sicher, dass ein IPSec Tunnel permanent etabliert bleibt/ist. DPD wird durch die folgende Option aktiviert/deaktiviert:
| |
|
| |
| # config vpn ipsec phase2-interface
| |
| # edit [Name der Phase2]
| |
| # set keepalive [enable | disable]
| |
| # end
| |
|
| |
| Wenn kein Datenverkehr stattfindet zwischen beiden Endpunkten (Peer's) dh. die Verbindung "Idle" ist, wird durch DPD gewährleistet das der IPSec Tunnel etabliert bleibt (alive). Ebenfalls werden sogenannte "dead IKE peers" durch DPD gelöscht (clean-up) da diese nicht mehr erreicht werden können (Dead Peer Detection). Dies bedeutet: Dieser Mechanismus im "IKE Verfahren" stellt fest ob ein "Peer" noch "up and running" ist sprich erreichbar ist (alive). Da es sich um ein einfaches Verfahren handelt, minimiert dies den Traffic zwischen den verschiednen "Peer's" um festzustellen ob diese noch erreichbar sind. Im diesen Verfahren wird kurz gesagt folgendes durchgeführt:
| |
|
| |
| Die IPSec Devices senden einen DPD "R_U-THERE" nur dann, wenn vor dem letzten DPD Interval Daten durch den IPSec Tunnel gesendet wurden und
| |
| dieser Traffic nicht beantwortet wurde (returning traffic). Wenn der Traffic "bi-directionaler" Natur ist, wird durch den DPD Meachanismus
| |
| "nie" ein Packet gesendet dh. ein DPD "R_U-THERE" auch dann wenn DPD explizit aktiviert ist! Dies entspricht keinem Fehlverhalten sondern
| |
| folgt dem RFC 3706 von IPSEC dh.:
| |
|
| |
| '''https://tools.ietf.org/html/draft-ietf-ipsec-dpd-04'''
| |
|
| |
| Siehe: DPD Protocol
| |
|
| |
| DPD befasst sich mit der Unzulänglichkeiten des IKE Keepalives- und Heartbeat-Systeme durch die Einführung einer vernünftiger Logik innerhalb
| |
| des Nachrichtenaustauschs. Im Wesentlichen: "Keepalives" und "Heartbeats" tauschen "HELLO's" unter normalen Umständen in regelmässigen Abständen
| |
| aus. Im Gegensatz zu einer IPSec Verbindung "mit" aktivierten DPD, ist jeder "Peer" DPD Zustand weitgehend unabhängig von dem anderen. Einem
| |
| "Peer" steht es somit frei den Nachweis zu erbringen ob dieser noch "up and running" ist sprich "alive". Dies bedeutet: es existieren keine
| |
| vorgeschriebenen Intervalle für diesen Mechanismus. Diese "asynchrone" Eigenschaft des DPD Mechanismus (Austausch) ermöglicht es möglichst wenig
| |
| Traffic resp. minimierte Nachrichten zu senden um somit eine höhere Skalierbarkeit zu erreichen.
| |
|
| |
| Dabei ist zu beachten "Wann" die Entscheidung getroffen wird ein DPD zu senden denn diese Entscheidung ist spezifizierter Natur:
| |
|
| |
| '''https://tools.ietf.org/html/draft-ietf-ipsec-dpd-04#section-6.4'''
| |
|
| |
| Siehe: DPD Protocol > Impetus for DPD Exchange
| |
|
| |
| Anstelle das DPD auf einem spezifizierten Zeitintervall basiert, kann der Austausch auf die Frage DPD "R_U-THERE" jederzeit erfolgen. Aus diesem
| |
| Grund sollte ein "IKE Peer" nur dann diese Anfragen DPD "R_U-THERE" stellen, wenn es Sinn ergiebt (kein "return traffic). Somit ist ein DPD Anfrage
| |
| zwischen den "Peer's" solange ein Datenaustausch stattfindet (inkl. bi-directional) unnötig und sollte nicht initiert werden.
| |
|
| |
| Ein "Peer" muss den den Zustand einer bestimmten DPD Austausches zwischen speichern. Das bedeutet: sobald eine "R-U-THERE" Abfrage von einem "Peer"
| |
| gesendet wird so wird innerhalb eines bestimmten implementierten Zeitintervalls ein "ACK" als Antwort erwartet. Nach einem bestimmten definierten
| |
| Zeitintervall sollte eine erneut Anfrage anhand "R-U-THERE" durchgeführt werden, wenn es nicht gelingt einen "ACK" als Antwort zu erhalten. Nach
| |
| einer bestimmten Anzahl von erneuten Anfragen - die nicht durch "ACK" beantwortet werden - sollte der "Peer" als "unreachable" deklariert werden
| |
| und somit die IPSec Verbdindung resp. die IKE SA (IKE Security Association) gelöscht werden.
| |
|
| |
| '''https://tools.ietf.org/html/draft-ietf-ipsec-dpd-04#section-6.4'''
| |
|
| |
| Siehe: DPD Protocol > Implementation Suggestion
| |
|
| |
| Ob ein "Peer" "up and running" (alive) ist wäre demnach nur dann fragllich, wenn "kein Datenverkehr" ausgestauscht wird. Eine mögliche Implementierung
| |
| wäre ein bestimmtes Monitoring um festzustellen ob Daten ausgestauscht wird. Dies würde jedoch wiederum zusätzlichen Traffic verursachen. Um festzustellen
| |
| ob ein "Peer" "up and running" (alive) ist wäre demnach nur dann "Wichtig" wenn der Datenverkehr ausgehend (Outbound) ist. Somit macht ein DPD Nachrichten
| |
| Austausch durch die Anfrage DPD "R_U-THERE" nur dann Sinn wenn für eine bestimmte Zeitspanne der Outbound Traffic "idle" ist und Outbound Traffic gesendet
| |
| werden soll. Somit kann auch ein DPD Austausch stattfinden, wenn zware Outbound Traffic stattfindet, jedoch auf diesen Traffic keine Antwort erhalten wird
| |
| (Inbound IPSec Packete). somit ist der DPD Austausch von Nachrichten dh. "R-U-THERE" und "R-U-THERE-ACK" als Nachweis zu sehen für ein "up and running"
| |
| einer IPSec Verbindung.
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Berücksichtige das ein DPD kein bestimmten Zeitintervall vorschreibt!. Diese "idle period" (Ruhezeit) die auch als "worry metric" verstanden wird
| |
| ist eine Implementierungsfrage des Produktes/Herstellers und nicht eine Frage der Definition eines ausgehandelten Wertes!
| |
|
| |
| === Wie kann ich ein IPSec Site2Site VPN im Interface Mode komplett auf Kommandozeile konfigurieren? ===
| |
|
| |
| Ausgehend davon, dass ein Site2Site VPN basierend im Interface Mode zwischen zwei "FortiGate" Device konfiguriert werden soll und zwar auf Kommandozeile (Ohne Wizard und/oder Web Mgmt. Interface) ist folgendes durchzuführen/zu konfigurieren:
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Die hier gezeigten Kommandos basieren auf FortiOS 5.2. Das Grundprinzip kann jedoch ebenfalls auf FortiOS 5.0
| |
| übertragen werden.
| |
|
| |
| '''Konfiguriere eine Phase1 für das Site2Site VPN Interface Mode'''
| |
|
| |
| # config vpn ipsec phase1-interface
| |
| # edit [Gebe einen entsprechenden Namen ein für Phase1 zB "site2site-ph1"]
| |
| # set type static
| |
| # set interface [Gebe das entsprechende Interface an der Public IP zB "wan1"]
| |
| # set ip-version 4
| |
| # set ike-version 1
| |
| # set local-gw [Gebe spezifische IPv4 Adresse an sofern gewünscht (wenn nicht "wan1" IP) ansonsten "0.0.0.0"]
| |
| # set nattraversal enable
| |
| # set keylife 86400
| |
| # set authmethod psk
| |
| # set mode main
| |
| # set peertype any
| |
| # set mode-cfg disable
| |
| # set proposal aes256-sha1 aes256-md5
| |
| # set localid [Gebe sofern gewünscht eine Local ID an zB Name Phase1 "site2site"]
| |
| # set localid-type auto
| |
| # set negotiate-timeout 30
| |
| # set fragmentation enable
| |
| # set dpd enable
| |
| # set forticlient-enforcement disable
| |
| # set comments [Gebe einen entsprechenden Comment ein sofern gewünscht zB "IPSec Phase1 site2site"]
| |
| # set npu-offload enable
| |
| # set dhgrp 5
| |
| # set wizard-type custom
| |
| # set xauthtype disable
| |
| # set mesh-selector-type disable
| |
| # set remote-gw [Gebe die entsprechende IPv4 Adresse an des Remote GW zB "212.59.153.125"]
| |
| # unset monitor
| |
| # set add-gw-route disable
| |
| # set psksecret [Gebe ein Preshared Key an für Phase1 zB "only4also!"]
| |
| # set keepalive 10
| |
| # set auto-negotiate enable
| |
| # set dpd-retrycount 3
| |
| # set dpd-retryinterval 5
| |
| # end
| |
|
| |
| '''Konfiguriere eine Phase2 für das Site2Site VPN Interface Mode'''
| |
|
| |
| # config vpn ipsec phase2-interface
| |
| # edit [Gebe einen entsprechenden Namen ein für Phase2 zB "site2site-ph2"]
| |
| # set phase1name [Gebe den entsprechenden Namen ein der Phase1 zB "site2site-ph1"]
| |
| # set proposal aes256-sha1 aes256-md5
| |
| # set pfs enable
| |
| # set dhgrp 5
| |
| # set replay enable
| |
| # set keepalive enable
| |
| # set auto-negotiate enable
| |
| # set keylife-type seconds
| |
| # set encapsulation tunnel-mode
| |
| # set comments [Gebe einen entsprechenden Comment ein sofern gewünscht zB "IPSec Phase2 site2site"] :
| |
| # set protocol 0
| |
| # set src-addr-type subnet
| |
| # set src-port 0
| |
| # set dst-addr-type subnet
| |
| # set dst-port 0
| |
| # set keylifeseconds 43200
| |
| # set src-subnet 0.0.0.0 0.0.0.0
| |
| # set dst-subnet 0.0.0.0 0.0.0.0
| |
| # end
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> In der Phase2 werden die "Quick Mode Selector" (src-subnet/dst-subnet) auf 0.0.0.0 gesetzt dh. potentiell ist in der Phase2
| |
| sämtlicher Traffic erlaubt. Weitere Informationen zum "Quick Mode Selector" findet man im nachfolgenden Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wann_sollte_ich_den_.22Quick_MOde_Selector.22_benutzen.2C_was_muss_ich_ber.C3.BCcksichtigen_und_welche_Funktion_hat_dieser.3F]]
| |
|
| |
| '''Konfiguriere ein statisches Routing damit der entsprechende Traffic in den Site2site VPN Tunnel gesendet wird'''
| |
|
| |
| Variante 1: Nur ein bestimmtes Netz/Netze soll durch den Site2Site VPN Tunnel gesendet werden (NOT "Route all Traffic through Gateway")
| |
|
| |
| # config router static
| |
| # edit [Gebe einen entsprechenden Integer an zB "2"]
| |
| # set device [Gebe das entsprechende Phase1 Interface an zB "site2site-ph1"]
| |
| # set dst [Gebe das Remote Network an zB "10.10.10.0/24]
| |
| # set comment [Gebe einen entsprechenden Kommentar ein zB "Route IPSec site2site-ph1"]
| |
| # end
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Wenn ein weiteres Netz konfiguriert werden soll muss einfach ein weiterer statischer Eintrag erstellt werden!
| |
|
| |
| Variante 2: Sämtlicher Traffic soll durch den Site2Site VPN Tunnel gesendet werden ("Route all Traffic through Gateway")
| |
|
| |
| # config router static
| |
| # edit [Gebe einen entsprechenden Integer an zB "2"]
| |
| # set device [Gebe das entsprechende Phase1 Interface an zB "site2site-ph1"]
| |
| # set dst 0.0.0.0 0.0.0.0
| |
| # set comment [Gebe einen entsprechenden Kommentar ein zB "Route All IPSec site2site-ph1"]
| |
| # end
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Diese Konfiguration dh. dass sämtlicher Traffic durch den Site2Site VPN Tunnel geroutet wird muss gut überlegt sein und
| |
| der "Hub"(Star Topology Spoke/Hub) muss die entsprechende Bandbreite zB betreffend Internet bereitstellen da der "Spoke"
| |
| Gateway über den "Hub" das Internet erreicht.
| |
|
| |
| Wenn diese Konfiguration abgeschlossen ist kann nun der Hub und/oder Spoke konfiguriert werden dh. die Phase1 sowie Phase2 werden exact genau gleich Konfiguriert mit der Ausnahme des Konfigurationspunktes des "set remote-gw" IP. Es kann Grundsätzlich der gleiche Name der Phase1/2 auf beiden Devices resp. Hub/Spoke benutzt werden jedoch empfohlen wird dies nicht da das Troubleshooting schwieriger wird um Hub/Spoke zu unterscheiden. Bei dem Konfigurationspunkt "set localid" muss auf beiden Seiten die gleiche ID benutzt werden sofern diese überhaupt konfiguriert/benutzt wird. Wie schon erwähnt erlaubt diese Konfiguration durch die Definition im "Quick Mode Selector" 0.0.0.0 potentiell sämtlicher Traffic. Durch die entsprechende Konfiguration der statischen Routen werden jedoch die entsprechenden Netze in den Site2Site VPN Tunnel gesendet. Als letzen Schritt müssen nun die entsprechenden Firewall Policy definiert werden durch Source sowie Destination unter Benutzung der Phase1 Interfaces auf dem entsprechenden Device (Hub/Spoke). Dabei ist es "Wichtig" nicht mit Destinationen/Source "all" zu arbeiten sondern die Netze korrekt zu definieren in Destination und Source. Dabei sollte folgender Grundregel gefolgt werden. Firewall Policy = Routing und Routing = Firewall Policy. Dies bedeutet: Wenn im Routing ein Netz zB 192.168.0.0/24 auf das IPsec Phase1 geroutet wird so muss in der Firewall Policy dieses Netz als Destination für das Remote Netzwerk konfiguriert werden. Wie die Phase1 und 2 im Debug Modes zu Troubleshooten sind geben nachfolgende Artikel Auskunft:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_sieht_der_.22Output.22_f.C3.BCr_ein_IPSec_VPN_im_Debugging_Mode_aus.3F]]
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_kann_ich_f.C3.BCr_ein_IPSec_VPN_f.C3.BCr_Phase-1_und.2Foder_2_ein_Debugging_ausf.C3.BChren.3F]]
| |
|
| |
| == FortiClient ==
| |
|
| |
| === Wo finde ich Informationen über den FortiClient und wie ein Client2Site IPSec VPN zu konfigurieren ist? ===
| |
|
| |
| Weitere Informationen zu diesem Thema siehe nachfolgender Artikel:
| |
|
| |
| [[FortiClient:FAQ]]
| |
|
| |
| == L2TP ==
| |
|
| |
| === Gibt es eine Dokumentation die zeigt wie man ein L2TP IPSec auf einer Fortigate/Windows 7 konfiguriert? ===
| |
|
| |
| Folgende Dokumente geben Auskunft über die nötige Konfiguration einer L2TP IPSec Konfiguration auf einer Fortigate sowie einem Windows 7 Client/Workstation:
| |
|
| |
| [[Datei:Technical_Note+_L2TP_Windows7_IPSEC.pdf]]
| |
| [[Datei:configuring-a-FortiGate-unit-as-an-L2TP-IPsec-server.pdf]]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Das Dokument betreffend der Konfiguration eines Windows 7 Client/Workstaton stammt aus dem folgenden
| |
| Knowledge Base Artikel:
| |
|
| |
| http://kb.fortinet.com/kb/microsites/search.do?cmd=displayKC&docType=kc&externalId=FD33431&sliceId=1&docTypeID=DT_KCARTICLE_1_1&dialogID=50115989&stateId=0 0 50117406
| |
|
| |
| Eine "L2TP" Verbindung ist basierend auf "Policy Based VPN". Dieses Feature muss - damit die entsprechende Firewall Policy - über Web Mgmt. Interface konfiguriert werden kann über folgende Position aktiviert werden:
| |
|
| |
| # config system global
| |
| # set gui-policy-based-ipsec enable
| |
| # end
| |
|
| |
| Wenn man die "L2TP" Verbindung über Kommandozeile konfigurieren möchte müsste folgendes ausgeführt werden:
| |
|
| |
| # config vpn l2tp
| |
| # set eip [IPv4 Start IP des Ranges für IP Pool]
| |
| # set sip [IPv4 End IP des Ranges für IP Pool]
| |
| # set status enable
| |
| # set usrgrp [Name der entsprechenden User Gruppe für L2TP]
| |
| # end
| |
|
| |
| # config vpn ipsec phase1
| |
| # edit [Name der Phase1 des Policy Based VPN]
| |
| # set type dynamic
| |
| # set interface [Name des Interfaces auf dem verbunden wird zB "wan1"]
| |
| # set dhgrp 1 2 5 14
| |
| # set proposal 3des-sha1 aes128-sha1
| |
| # set localid [Name der LocalID zB Name der Phase1"
| |
| # set dpd disable
| |
| # set psksecret [Preshared Secret]
| |
| # next
| |
| # end
| |
|
| |
| # config vpn ipsec phase2
| |
| # edit [Name der Phase1 des Policy Based VPN]
| |
| # set phase1name [Name der Phase1 des Policy Based VPN]
| |
| # set proposal 3des-sha1 aes128-sha1
| |
| # set pfs disable
| |
| # set keylife-type both
| |
| # set encapsulation transport-mode
| |
| # set l2tp enable
| |
| # set keylifeseconds 3600
| |
| # set keylifekbs 250000
| |
| # next
| |
| # end
| |
|
| |
| === Wird L2TPv3 IPSec auf einer Fortigate unterstützt/supported? ===
| |
|
| |
| L2TPv3 wird auf einer FortiGate "nicht" unterstützt und ist eine Weiterentwicklung von L2TP, das eine Alternative zum MPLS Protokoll zur Verkapselung von verschiedenen Protokollen auf der Ebene 2 des OSI-Modells darstellt. Es arbeitet wie L2TPv2 über UDP oder andere PSNs (Packet Switched Networks), aber kann auch direkt IP nutzen. Außerdem können auch andere Protokolle der Sicherungsschicht als PPP getunnelt werden. Die Spezifikation ist in RFC-3931 definiert. L2TPv3 kann als eine abgespeckte Version von MPLS angesehen werden. Ein nicht eingebautes Feature stellt z.B. das Traffic Engineering dar. Weitere Informationen findet man unter folgendem Link:
| |
|
| |
| https://de.wikipedia.org/wiki/Layer_2_Tunneling_Protocol#L2TP_Version_3
| |
|
| |
| === Wie kann ich ein Debugging für eine L2TP IPSec Verbindung auf einer FortiGate ausführen? ===
| |
|
| |
| Wenn für eine "L2TP" Verbindung resp. Phase1 und 2 eine Debugging Mode ausgeführt werden soll muss folgendes durchgeführt werden:
| |
|
| |
| '''Setze den Debug Filter zurück:'''
| |
|
| |
| # diagnose debug reset
| |
|
| |
| '''Setze einen neuen Debug Filter:'''
| |
|
| |
| # diagnose debug application l2tp -1
| |
|
| |
| '''Aktiviere den Debug Modus mit dem gesetzen Debug Filter:'''
| |
|
| |
| # diagnose debug enable
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Wenn der Deamon für "L2TP" neu gestartet werdensoll da eine Modifikatione in der Konfiguration
| |
| durchgeführt wurde kann folgendes ausgeführt werden:
| |
|
| |
| # diagnose test application l2tpcd 99
| |
|
| |
| Der "diagnose debug" Befehl ist "persistent" dh. auch wenn ausgeloggt wird läuft dieser im Hintergrund weiter und belastet -je nach Debugging- den Device im hohen Masse. Aus diesem Grund ist es wichtig den Debug wiederum zu "disablen" dh. führe folgendes aus:
| |
|
| |
| '''Deaktiviere den Debug Modus:'''
| |
|
| |
| # diagnose debug disable
| |
|
| |
| '''Setze den Debug Filter zurück:'''
| |
|
| |
| # diagnose debug reset
| |
|
| |
| '''Kontrolliere den Debug Filter ob dieser zurückgesetzt wurde:'''
| |
|
| |
| # diagnose debug info
| |
|
| |
| Nachfolgend ein Beispiel einer erfolgreichen "L2TP" Verbindung anhand des Debugging für "l2tp" sowie "ike":
| |
|
| |
| '''VERBINDUNG STARTEN'''
| |
|
| |
| # diagnose debug reset
| |
|
| |
| # diagnose debug application l2tp -1
| |
| # diagnose debug enable
| |
|
| |
| ike 0: comes 193.193.135.67:500->193.193.135.66:500,ifindex=5....
| |
| ike 0: IKEv1 exchange=Identity Protection id=3bd31e3b4c673fb4/0000000000000000 len=384
| |
| ike 0: in 3BD31E3B4C673FB400000000000000000110020000000000000001800D0000D40000000100000001000000C801010005030000280101000080010007800E0100800200028004001480030001800B0001000000400007080030000280201000080010007800E0080800200028004001380030001800B0001000C000400007080030000280301000080010007800E0100800200028004000E80030001800B0001000000400007080030000240401000080010005800200028004000E80030001800B0001000C000400007080000000240501000080010005800200028004000280030001800B0001000C0004000070800D0000181E2B516905991C7D7C96FCBFB587E461000000080D0000144A131C81070358455C5728F20E95452F0D00001490CB80913EBB696E086381B5EC427B1F0D0000144048B7D56EBCE88525E7DE7F00D6C2D30D000014FB1DE3CDF341B7EA16B7E5BE0855F1200D00001426244D38EDDB61B3172A36E3D0CFB81900000014E3A5966A76379FE707228231E5CE8652
| |
| ike 0:3bd31e3b4c673fb4/0000000000000000:13: responder: main mode get 1st message...
| |
| ike 0:3bd31e3b4c673fb4/0000000000000000:13: VID MS NT5 ISAKMPOAKLEY 1E2B516905991C7D7C96FCBFB587E46100000008
| |
| ike 0:3bd31e3b4c673fb4/0000000000000000:13: VID RFC 3947 4A131C81070358455C5728F20E95452F
| |
| ike 0:3bd31e3b4c673fb4/0000000000000000:13: VID draft-ietf-ipsec-nat-t-ike-02\n 90CB80913EBB696E086381B5EC427B1F
| |
| ike 0:3bd31e3b4c673fb4/0000000000000000:13: VID FRAGMENTATION 4048B7D56EBCE88525E7DE7F00D6C2D3
| |
| ike 0:3bd31e3b4c673fb4/0000000000000000:13: VID unknown (16): FB1DE3CDF341B7EA16B7E5BE0855F120
| |
| ike 0:3bd31e3b4c673fb4/0000000000000000:13: VID unknown (16): 26244D38EDDB61B3172A36E3D0CFB819
| |
| ike 0:3bd31e3b4c673fb4/0000000000000000:13: VID unknown (16): E3A5966A76379FE707228231E5CE8652
| |
| ike 0:3bd31e3b4c673fb4/0000000000000000:13: negotiation result
| |
| ike 0:3bd31e3b4c673fb4/0000000000000000:13: proposal id = 1:
| |
| ike 0:3bd31e3b4c673fb4/0000000000000000:13: protocol id = ISAKMP:
| |
| ike 0:3bd31e3b4c673fb4/0000000000000000:13: trans_id = KEY_IKE.
| |
| ike 0:3bd31e3b4c673fb4/0000000000000000:13: encapsulation = IKE/none
| |
| ike 0:3bd31e3b4c673fb4/0000000000000000:13: type=OAKLEY_ENCRYPT_ALG, val=3DES_CBC.
| |
| ike 0:3bd31e3b4c673fb4/0000000000000000:13: type=OAKLEY_HASH_ALG, val=SHA.
| |
| ike 0:3bd31e3b4c673fb4/0000000000000000:13: type=AUTH_METHOD, val=PRESHARED_KEY.
| |
| ike 0:3bd31e3b4c673fb4/0000000000000000:13: type=OAKLEY_GROUP, val=2048.
| |
| ike 0:3bd31e3b4c673fb4/0000000000000000:13: ISAKMP SA lifetime=28800
| |
| ike 0:3bd31e3b4c673fb4/0000000000000000:13: SA proposal chosen, matched gateway ipsec-l2tp
| |
| ike 0:ipsec-l2tp:13: selected NAT-T version: RFC 3947
| |
| ike 0:ipsec-l2tp:13: cookie 3bd31e3b4c673fb4/6d049cce9a23138a
| |
| ike 0:ipsec-l2tp:13: out 3BD31E3B4C673FB46D049CCE9A23138A0110020000000000000000A40D00003800000001000000010000002C01010001000000240401000080010005800200028004000E80030001800B0001000C0004000070800D0000144A131C81070358455C5728F20E95452F0D000014AFCAD71368A1F1C96B8696FC775701000D0000148299031757A36082C6A621DE00050124000000144048B7D56EBCE88525E7DE7F00D6C2D3
| |
| ike 0:ipsec-l2tp:13: sent IKE msg (ident_r1send): 193.193.135.66:500->193.193.135.67:500, len=164, id=3bd31e3b4c673fb4/6d049cce9a23138a
| |
| ike 0: comes 193.193.135.67:500->193.193.135.66:500,ifindex=5....
| |
| ike 0: IKEv1 exchange=Identity Protection id=3bd31e3b4c673fb4/6d049cce9a23138a len=388
| |
| ike 0: in 3BD31E3B4C673FB46D049CCE9A23138A0410020000000000000001840A00010437C4B027AF9F64B86B474DD68F8CDCB55B6054AD2BC62B232EED3178776F11BDDE3A5504E34FA05266B6F957725CFAB67EC8C3D0C45ECCAAAF1C735E42AC3D5878290323F7E602CCB760CE09F68CDA5F0C541F5C373126E4E0AAD2E29D00A3C92391AE0809504E883D68D9B57070D5C9D2000762934EA79473EA88E3B5BA722AC4F0004E6337E8F79CDBC0FBDCA0D02C91F8E29B8037C6856B8C4E84B6C9438692344AB46F6EB0858070FE3B68E126F3E6315269A76921D11460BB1EE0EA10EE4FD058B0E01DB3F8893071C5299BCE7425AA27E417FD0FA821B8EBA727BB2FA3524391630D64EFA0123EE336C978037D901EC2019F623DB881AD2BD7006B6782140000341FFDAB9C35462A582B3ECBC1DD8BEAE250C7469F509CB0AA9A446E2DC2814350F4C3322A2A3E67F68235D0CED120D0D8140000187EA7844D04FABC1D8FD254A28D4F00E72218511000000018A7C95E50A591EFEB864404BDAFF514FE7FE62851
| |
| ike 0:ipsec-l2tp:13: responder:main mode get 2nd message...
| |
| ike 0:ipsec-l2tp:13: NAT not detected
| |
| ike 0:ipsec-l2tp:13: out 3BD31E3B4C673FB46D049CCE9A23138A0410020000000000000001640A000104020D3831C433A61449E89ADC6839CCA74E0D650117189F912BD1AE6BA225CE8F1C8C50786DD85111F7B1FC3334C5BF6C502396949B5461824D440111C38CB160E2B2264B359E03612AFCF5B09482DB9210025D7B45B298D6A4DF9263B788844F0065CE66B943C1C4D9BC9B41AA5BBB20449BAB03AF8A322DE6EBFD02D77F7920A6C6C1245C713E2DC8F91036CBE0DB8DC567F3329FAD8FEBDD9C0B85935779E1ACDC9631032BD66DA780A32AEEC1904003CBBC05B2013F4D27B10CF32E9F8E5FCD774384ED00F3FC2201C552606DF6D0E88F6D645F3ABA8DDDEA41B535E63CB16150BFDDB438516E8B707BC8094BC813C68B8BDEA2CA6CC9FE5F5C1A6920600C14000014764821B32E0D83B4D7B82BEA3246D8B914000018A7C95E50A591EFEB864404BDAFF514FE7FE62851000000187EA7844D04FABC1D8FD254A28D4F00E722185110
| |
| ike 0:ipsec-l2tp:13: sent IKE msg (ident_r2send): 193.193.135.66:500->193.193.135.67:500, len=356, id=3bd31e3b4c673fb4/6d049cce9a23138a
| |
| ike 0:ipsec-l2tp:13: ISAKMP SA 3bd31e3b4c673fb4/6d049cce9a23138a key 24:9573946379AAC144B11098E29A3CFBBE477437AA288B4BD1
| |
| ike 0: comes 193.193.135.67:500->193.193.135.66:500,ifindex=5....
| |
| ike 0: IKEv1 exchange=Identity Protection id=3bd31e3b4c673fb4/6d049cce9a23138a len=68
| |
| ike 0: in 3BD31E3B4C673FB46D049CCE9A23138A0510020100000000000000445AC59A20DF5B43DEFBA2E1BA4BEDD20583ABF72F94416546411A9926820A5974D4A5BEACDCAA1F25
| |
| ike 0:ipsec-l2tp:13: responder: main mode get 3rd message...
| |
| ike 0:ipsec-l2tp:13: dec 3BD31E3B4C673FB46D049CCE9A23138A0510020100000000000000440800000C01000000C1C187430000001845C9FB9F09E42AF4E1BE1AD73D32421566BB977800000000
| |
| ike 0:ipsec-l2tp:13: PSK authentication succeeded
| |
| ike 0:ipsec-l2tp:13: authentication OK
| |
| ike 0:ipsec-l2tp:13: enc 3BD31E3B4C673FB46D049CCE9A23138A051002010000000000000046080000120200000069707365632D6C32747000000018B0F445E77B4277AD162C7835D6F4CE9A3536139C
| |
| ike 0:ipsec-l2tp:13: out 3BD31E3B4C673FB46D049CCE9A23138A05100201000000000000004C21B4D86F53FAEBD7E2F7480469ACF3055333D64FED11E4B6F0C803D4A5AA490B304E0A0556E4418973F37F2DAE29852E
| |
| ike 0:ipsec-l2tp:13: sent IKE msg (ident_r3send): 193.193.135.66:500->193.193.135.67:500, len=76, id=3bd31e3b4c673fb4/6d049cce9a23138a
| |
| ike 0:ipsec-l2tp:13: established IKE SA 3bd31e3b4c673fb4/6d049cce9a23138a
| |
| ike 0:ipsec-l2tp: adding new dynamic tunnel for 193.193.135.67:500
| |
| ike 0:ipsec-l2tp_0: added new dynamic tunnel for 193.193.135.67:500
| |
| ike 0:ipsec-l2tp_0:13: no pending Quick-Mode negotiations
| |
| ike 0: comes 193.193.135.67:500->193.193.135.66:500,ifindex=5....
| |
| ike 0: IKEv1 exchange=Quick id=3bd31e3b4c673fb4/6d049cce9a23138a:00000001 len=308
| |
| ike 0: in 3BD31E3B4C673FB46D049CCE9A23138A0810200100000001000001343CC4ECDBF4BD68977AB494C9D038A9D1172FA1B228EF3DD766F1F5F192A541792443E698AA8709904CA642F31E469F64B46FD6D9F99A77214BF11290300AAD38702B1594AD36C1896D9D123D502560E2C1188D6A4EBAAE85ED98260DD2C406C72F7E854E23BDA04B35A447D534CD84DE1A2C0B738AF078281022C69DA5ABD49A16F0F9BC1C059FFB29F5476521E54B4BF04693B49D5AC8F0370990FEBF3FD26DBF9527DCBFCD75818F536C71B580F29772ADA3848FBA076BB6F1578998CDB02DFDBD8146B9D34D78CD9267926993C76673450378A88791E0B7A25824E2D565306167DBBE102CCB816C72450BD219D1BB9361A877C3A34FFC583E0BAD821AA1EB744C9F2E489560C3C82366D27D7A1AE43E60D001464D1230
| |
| ike 0:ipsec-l2tp_0:13:4: responder received first quick-mode message
| |
| ike 0:ipsec-l2tp_0:13: dec 3BD31E3B4C673FB46D049CCE9A23138A0810200100000001000001340100001811FDC78DFE2364F375B9602EB4ED71DB3C4391940A0000AC0000000100000001020000380103040118A94F220000002C010C0000800400028006008080050002800100010002000400000E1080010002000200040003D090020000340203040118A94F2200000028010300008004000280050002800100010002000400000E1080010002000200040003D090000000340303040118A94F2200000028010200008004000280050002800100010002000400000E1080010002000200040003D0900500003490AE6EE410F0B8A0F89CA4D38F6AD04222E24A23DD195F9251CE65F801C33B36E0FB6E9DE5E252D333EF4799B4045CDA0500000C011106A5C1C187430000000C011106A5C1C187420000000000000000
| |
| ike 0:ipsec-l2tp_0:13:4: peer proposal is: peer:17:193.193.135.67-193.193.135.67:1701, me:17:193.193.135.66-193.193.135.66:1701
| |
| ike 0:ipsec-l2tp_0:13:ipsec-l2tp:4: trying
| |
| ike 0:ipsec-l2tp_0:13:4: trancreate_new_tunnel()-91: Allocated new Tunnel id=9, total count = 1
| |
| handle_control_packet()-551:
| |
| 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 'SatellitePro770'
| |
| __avp_vendor()-310: peer's vendor 'Microsoft'
| |
| __avp_assigned_tunnel()-339: peer's tunnel 5
| |
| avp_receive_window_size()-359: peer's RWS 8.
| |
| run_ctrl_state_machine()-91: run_ctrl_state_machine: message type is (1). Tunnel is 5, call is 0.
| |
| run_ctrl_state_machine()-97: ** run_ctrl_state_machine - SCCRQ **
| |
| run_ctrl_state_machine()-108: Rule 193.193.135.67 to 193.193.135.67avp_put_hostname()-84: Sent the host name = 193.1
| |
| run_ctrlavp_handler()-72monitor_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.
| |
| sport mode, override with 17:193.193.135.66-193.193.135.66:1701 -> 17:193.193.135.67-193.193.135.67:0
| |
| ike 0:ipsec-l2tp_0:13:ipsec-l2tp:4: matched phase2
| |
| ike 0:ipsec-l2tp_0:13:ipsec-l2tp:4: dynamic client
| |
| ike 0:ipsec-l2tp_0:13:ipsec-l2tp:4: my proposal:
| |
| ike 0:ipsec-l2tp_0:13:ipsec-l2tp:4: proposal id = 1:
| |
| ike 0:ipsec-l2tp_0:13:ipsec-l2tp:4: protocol id = IPSEC_ESP:
| |
| ike 0:ipsec-l2tp_0:13:ipsec-l2tp:4: trans_id = ESP_3DES
| |
| ike 0:ipsec-l2tp_0:13:ipsec-l2tp:4: encapsulation = ENCAPSULATION_MODE_TRANSPORT
| |
| ike 0:ipsec-l2tp_0:13:ipsec-l2tp:4: type = AUTH_ALG, val=SHA1
| |
| ike 0:ipsec-l2tp_0:13:ipsec-l2tp:4: trans_id = ESP_AES (key_len = 128)
| |
| ike 0:ipsec-l2tp_0:13:ipsec-l2tp:4: encapsulation = ENCAPSULATION_MODE_TRANSPORT
| |
| ike 0:ipsec-l2tp_0:13:ipsec-l2tp:4: type = AUTH_ALG, val=SHA1
| |
| ike 0:ipsec-l2tp_0:13:ipsec-l2tp:4: incoming proposal:
| |
| ike 0:ipsec-l2tp_0:13:ipsec-l2tp:4: proposal id = 1:
| |
| ike 0:ipsec-l2tp_0:13:ipsec-l2tp:4: protocol id = IPSEC_ESP:
| |
| ike 0:ipsec-l2tp_0:13:ipsec-l2tp:4: trans_id = ESP_AES (key_len = 128)
| |
| ike 0:ipsec-l2tp_0:13:ipsec-l2tp:4: encapsulation = ENCAPSULATION_MODE_TRANSPORT
| |
| ike 0:ipsec-l2tp_0:13:ipsec-l2tp:4: type = AUTH_ALG, val=SHA1
| |
| ike 0:ipsec-l2tp_0:13:ipsec-l2tp:4: negotiation result
| |
| ike 0:ipsec-l2tp_0:13:ipsec-l2tp:4: proposal id = 1:
| |
| ike 0:ipsec-l2tp_0:13:ipsec-l2tp:4: protocol id = IPSEC_ESP:
| |
| ike 0:ipsec-l2tp_0:13:ipsec-l2tp:4: trans_id = ESP_AES (key_len = 128)
| |
| ike 0:ipsec-l2tp_0:13:ipsec-l2tp:4: encapsulation = ENCAPSULATION_MODE_TRANSPORT
| |
| ike 0:ipsec-l2tp_0:13:ipsec-l2tp:4: type = AUTH_ALG, val=SHA1
| |
| ike 0:ipsec-l2tp_0:13:ipsec-l2tp:4: using transport mode.
| |
| ike 0:ipsec-l2tp_0:13: enc 3BD31E3B4C673FB46D049CCE9A23138A0810200100000001000000A4010000185624D8349FF1B2CF42B23112A0F59C05444C30310A00004400000001000000010000003801030401658C806F0000002C010C0000800400028006008080050002800100010002000400000E1080010002000200040003D09005000014D456FBE1630773A0B30A30E4358DFBAD0500000C011106A5C1C187430000000C011106A5C1C18742
| |
| ike 0:ipsec-l2tp_0:13: out 3BD31E3B4C673FB46D049CCE9A23138A0810200100000001000000AC2E3A6CF7C38C9C6A35518A7AAC801CC9D13D630A238309E0B4A5B278A296B15A5892FAC8D7CFBBF4CD13B627156111FE9ED171396D5CE64A0E01F88A497DECFD6D7C14B1EC09305BD919228EB6C9BDB02D384DA32D7C33BF19E00ACAA81B72D47F4020415DF10B9991DA114857605B874604C10DE75BBA9A0B9AC6BA20E43A13840892F249EAB7ED4C1121C7A99B3B00
| |
| ike 0:ipsec-l2tp_0:13: sent IKE msg (quick_r1send): 193.193.135.66:500->193.193.135.67:500, len=172, id=3bd31e3b4c673fb4/6d049cce9a23138a:00000001
| |
| ike 0: comes 193.193.135.67:500->193.193.135.66:500,ifindex=5....
| |
| ike 0: IKEv1 exchange=Quick id=3bd31e3b4c673fb4/6d049cce9a23138a:00000001 len=60
| |
| ike 0: in 3BD31E3B4C673FB46D049CCE9A23138A08102001000000010000003CA771E1353C0D69A77799E0B70C8A0D72D4C9E6454706A61EF7B450B883DA644F
| |
| ike 0:ipsec-l2tp_0:13: dec 3BD31E3B4C673FB46D049CCE9A23138A08102001000000010000003C00000018A89375EB213244A17A91AE6937F082FCF6DB40AF0000000000000000
| |
| ike 0:ipsec-l2tp_0:13:ipsec-l2tp:4: replay protection enabled
| |
| ike 0:ipsec-l2tp_0:13:ipsec-l2tp:4: SA life soft seconds=3585.
| |
| ike 0:ipsec-l2tp_0:13:ipsec-l2tp:4: SA life hard seconds=3600.
| |
| ike 0:ipsec-l2tp_0:13:ipsec-l2tp:4: set sa life soft/hard kbytes=249488/250000.
| |
| ike 0:ipsec-l2tp_0:13:ipsec-l2tp:4: IPsec SA selectors #src=1 #dst=1
| |
| ike 0:ipsec-l2tp_0:13:ipsec-l2tp:4: src 0 7 17:193.193.135.66-193.193.135.66:1701
| |
| ike 0:ipsec-l2tp_0:13:ipsec-l2tp:4: dst 0 7 17:193.193.135.67-193.193.135.67:0
| |
| ike 0:ipsec-l2tp_0:13:ipsec-l2tp:4: add dynamic IPsec SA selectors
| |
| ike 0:ipsec-l2tp_0:13:ipsec-l2tp:4: tunnel 1 of VDOM limit 0/0
| |
| ike 0:ipsec-l2tp_0:13:ipsec-l2tp:4: add IPsec SA: SPIs=658c806f/18a94f22
| |
| ike 0:ipsec-l2tp_0:13:ipsec-l2tp:4: IPsec SA dec spi 658c806f key 16:FF99BC6BB64447317EB945EE89621FD8 auth 20:742DFE688B8A95D9C4415264AE9DC7D93FF9BFA8
| |
| ike 0:ipsec-l2tp_0:13:ipsec-l2tp:4: IPsec SA enc spi 18a94f22 key 16:00418CCFAA5F33B2636F969A43FFE559 auth 20:9ACEC891E841C6B8E258847655C8B79F1131E200
| |
| ike 0:ipsec-l2tp_0:13:ipsec-l2tp:4: transport mode encapsulation is enabled
| |
| ike 0:ipsec-l2tp_0:13:ipsec-l2tp:4: added IPsec SA: SPIs=658c806f/18a94f22
| |
| ike 0:ipsec-l2tp_0:13:ipsec-l2tp:4: sending SNMP tunnel UP trap
| |
| ike 0: unknown SPI 658c806f 5 193.193.135.67:0->193.193.135.66
| |
| ike 0: found ipsec-l2tp_0 193.193.135.66 5 -> 193.193.135.67:500
| |
| ike 0:ipsec-l2tp_0:13:ipsec-l2tp:4: ignoring invalid SPI 658c806f, IPsec SA just negotiated
| |
| ike 0: IP 198.18.4.129 (30) is down
| |
| ike shrank heap by 122880 bytes
| |
|
| |
| send_hello()-33: L2TP: send Hello for tunnel 5
| |
| schedule_event()-94:
| |
| schedule_event()-100: Message due 1237048, now = 1236948
| |
| start_hello_timer()-59: L2TP: starting Hello timer for tunnel 5, next in 60 seconds.
| |
| schedule_event()-94:
| |
| schedule_event()-100: Message due 1242948, now = 1236948
| |
| handle_control_packet()-551:
| |
| handle_control_packet()-580: L2TP received control ZLB.
| |
| monitor_ctrl_pkt_xmit()-94:
| |
| monitor_ctrl_pkt_xmit()-116: L2TP: Peer ack'ed control packet.
| |
|
| |
| send_hello()-33: L2TP: send Hello for tunnel 5
| |
| schedule_event()-94:
| |
| schedule_event()-100: Message due 1237048, now = 1236948
| |
| start_hello_timer()-59: L2TP: starting Hello timer for tunnel 5, next in 60 seconds.
| |
| schedule_event()-94:
| |
| schedule_event()-100: Message due 1242948, now = 1236948
| |
| handle_control_packet()-551:
| |
| handle_control_packet()-580: L2TP received control ZLB.
| |
| monitor_ctrl_pkt_xmit()-94:
| |
| monitor_ctrl_pkt_xmit()-116: L2TP: Peer ack'ed control packet.
| |
|
| |
| '''VERBINDUNG BEENDEN'''
| |
| ike 0: IP 198.18.4.129 (30) is down
| |
| handle_control_packet()-551:
| |
| check_control_hdr()-173: check_control_hdr: control, peer_call_id = 1, Ns = 4, Nr = 3
| |
| 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 5, call is 1.
| |
| run_ctrl_state_machine()-333: ** run_ctrl_state_machine - CDN **
| |
| run_ctrl_state_machine()-374: Connection closed to 193.193.135.67, serial 0 ()
| |
| handle_network_packet()-274: Sending a ZLB to acknowledge last message
| |
| send_zlb()-73: ** send_zlb **
| |
| l2tp_handle_calls()-312: closing The master call
| |
| close_call()-410: ** close_call **
| |
| close_call()-425: Closing call 10
| |
| free_call()-211: ** free_call **
| |
| l2tp_vdbind_msg_handler()-87: del_vdbind message:vd=root 0 devindex=30 ppp1
| |
| handle_control_packet()-551:
| |
| check_control_hdr()-173: check_control_hdr: control, peer_call_id = 1, Ns = 5, Nr = 3
| |
| check_control_hdr()-185: Updated control rec seqno. Value is now 6
| |
| __avp_assigned_tunnel()-339: peer's tunnel 5
| |
| 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 5, call is 1.
| |
| run_ctrl_state_machine()-187: ** run_ctrl_state_machine - StopCCN **
| |
| run_ctrl_state_machine()-218: Connection closed to 193.193.135.67, port 1701 (), Local: 9, Remote: 5
| |
| handle_network_packet()-274: Sending a ZLB to acknowledge last message
| |
| send_zlb()-73: ** send_zlb **
| |
| l2tp_handle_calls()-299: closing down tunnel 9
| |
| close_tunnel()-446: ** close_tunnel **
| |
| close_tunnel()-459: Closing and destroying tunnel 9
| |
| L2TPD 26: 461:Client 193.193.135.67 control connection (id 9) finished
| |
| close_calls_for_tunnel()-100:
| |
| free_call()-211: ** free_call **
| |
| free_tunnel()-117: Done close_calls_for_tunnel
| |
| ike 0: comes 193.193.135.67:500->193.193.135.66:500,ifindex=5....
| |
| ike 0: IKEv1 exchange=Informational id=3bd31e3b4c673fb4/6d049cce9a23138a:f43a1269 len=76
| |
| ike 0: in 3BD31E3B4C673FB46D049CCE9A23138A08100501F43A12690000004C9336FA63AEE33FC452C3458BDA9635882FA5C562512FE20B1817986F23B33AE3C36D1B1AE1A2CA73BD85EAA48BC3768D
| |
| ike 0:ipsec-l2tp_0:13: dec 3BD31E3B4C673FB46D049CCE9A23138A08100501F43A12690000004C0C000018368BC53A5E50D742437F395AAB12C5C560F21A8100000010000000010304000118A94F220000000000000000
| |
| ike 0:ipsec-l2tp_0:13: recv IPsec SA delete, spi count 1
| |
| ike 0:ipsec-l2tp_0: deleting IPsec SA with SPI 18a94f22
| |
| ike 0:ipsec-l2tp_0:ipsec-l2tp: deleted IPsec SA with SPI 18a94f22, SA count: 0
| |
| ike 0:ipsec-l2tp_0: sending SNMP tunnel DOWN trap for ipsec-l2tp
| |
| ike 0:ipsec-l2tp_0:ipsec-l2tp: delete
| |
| ike 0: comes 193.193.135.67:500->193.193.135.66:500,ifindex=5....
| |
| ike 0: IKEv1 exchange=Informational id=3bd31e3b4c673fb4/6d049cce9a23138a:022bd834 len=84
| |
| ike 0: in 3BD31E3B4C673FB46D049CCE9A23138A08100501022BD8340000005462DFFDD9EE8B3C5509C70B15F49A89D81B9617500F11FE2949C7D7D2462DFD7E73CDC9703621AFF3D60DED96A67FC2FFCF37B68D5DEB850B
| |
| ike 0:ipsec-l2tp_0:13: dec 3BD31E3B4C673FB46D049CCE9A23138A08100501022BD834000000540C000018CD2CC02F0F240B28E8BD4492D683D6E28604E2F10000001C00000001011000013BD31E3B4C673FB46D049CCEA23138A00000000
| |
| ike 0:ipsec-l2tp_0:13: recv ISAKMP SA delete 3bd31e3b4c673fb4/6d049cce9a23138a
| |
| ike 0:ipsec-l2tp_0: deleting
| |
| ike 0:ipsec-l2tp_0: flushing
| |
| ike 0:ipsec-l2tp_0: sending SNMP tunnel DOWN trap
| |
| ike 0:ipsec-l2tp_0: flushed
| |
| ike 0:ipsec-l2tp_0: delete dynamic
| |
| ike 0:ipsec-l2tp_0: deleted
| |
|
| |
| # diagnose debug disable
| |
| # diagnose debug reset
| |
|
| |
| '''VERBINDUNG STARTEN'''
| |
|
| |
| # diagnose debug reset
| |
| # diagnose debug application ike -1
| |
| # diagnose debug enable
| |
|
| |
| ike 0: comes 193.193.135.67:500->193.193.135.66:500,ifindex=5....
| |
| ike 0: IKEv1 exchange=Identity Protection id=622d112386920eab/0000000000000000 len=384
| |
| ike 0: in 622D112386920EAB00000000000000000110020000000000000001800D0000D40000000100000001000000C801010005030000280101000080010007800E0100800200028004001480030001800B0001000C000400007080030000280201000080010007800E0080800200028004001380030001800B0001000C000400007080030000280301000080010007800E0100800200028004000E80030001800B0001000C000400007080030000240401000080010005800200028004000E80030001800B0001000C000400007080000000240501000080010005800200028004000280030001800B0001000C0004000070800D0000181E2B516905991C7D7C96FCBFB587E461000000080D0000144A131C81070358455C5728F20E95452F0D00001490CB80913EBB696E086381B5EC427B1F0D0000144048B7D56EBCE88525E7DE7F00D6C2D30D000014FB1DE3CDF341B7EA16B7E5BE0855F1200D00001426244D38EDDB61B3172A36E3D0CFB81900000014E3A5966A76379FE707228231E5CE8652
| |
| ike 0:622d112386920eab/0000000000000000:12: responder: main mode get 1st message...
| |
| ike 0:622d112386920eab/0000000000000000:12: VID MS NT5 ISAKMPOAKLEY 1E2B516905991C7D7C96FCBFB587E46100000008
| |
| ike 0:622d112386920eab/0000000000000000:12: VID RFC 3947 4A131C81070358455C5728F20E95452F
| |
| ike 0:622d112386920eab/0000000000000000:12: VID draft-ietf-ipsec-nat-t-ike-02\n 90CB80913EBB696E086381B5EC427B1F
| |
| ike 0:622d112386920eab/0000000000000000:12: VID FRAGMENTATION 4048B7D56EBCE88525E7DE7F00D6C2D3
| |
| ike 0:622d112386920eab/0000000000000000:12: VID unknown (16): FB1DE3CDF341B7EA16B7E5BE0855F120
| |
| ike 0:622d112386920eab/0000000000000000:12: VID unknown (16): 26244D38EDDB61B3172A36E3D0CFB819
| |
| ike 0:622d112386920eab/0000000000000000:12: VID unknown (16): E3A5966A76379FE707228231E5CE8652
| |
| ike 0:622d112386920eab/0000000000000000:12: negotiation result
| |
| ike 0:622d112386920eab/0000000000000000:12: proposal id = 1:
| |
| ike 0:622d112386920eab/0000000000000000:12: protocol id = ISAKMP:
| |
| ike 0:622d112386920eab/0000000000000000:12: trans_id = KEY_IKE.
| |
| ike 0:622d112386920eab/0000000000000000:12: encapsulation = IKE/none
| |
| ike 0:622d112386920eab/0000000000000000:12: type=OAKLEY_ENCRYPT_ALG, val=3DES_CBC.
| |
| ike 0:622d112386920eab/0000000000000000:12: type=OAKLEY_HASH_ALG, val=SHA.
| |
| ike 0:622d112386920eab/0000000000000000:12: type=AUTH_METHOD, val=PRESHARED_KEY.
| |
| ike 0:622d112386920eab/0000000000000000:12: type=OAKLEY_GROUP, val=2048.
| |
| ike 0:622d112386920eab/0000000000000000:12: ISAKMP SA lifetime=28800
| |
| ike 0:622d112386920eab/0000000000000000:12: SA proposal chosen, matched gateway ipsec-l2tp
| |
| ike 0:ipsec-l2tp:12: selected NAT-T version: RFC 3947
| |
| ike 0:ipsec-l2tp:12: cookie 622d112386920eab/82890a11b0e6719a
| |
| ike 0:ipsec-l2tp:12: out 622D112386920EAB82890A11B0E6719A0110020000000000000000A40D00003800000001000000010000002C01010001000000240401000080010005800200028004000E80030001800B0001000C0004000070800D0000144A131C81070358455C5728F20E95452F0D000014AFCAD71368A1F1C96B8696FC775701000D0000148299031757A36082C6A621DE00050124000000144048B7D56EBCE88525E7DE7F00D6C2D3
| |
| ike 0:ipsec-l2tp:12: sent IKE msg (ident_r1send): 193.193.135.66:500->193.193.135.67:500, len=164, id=622d112386920eab/82890a11b0e6719a
| |
| ike 0: comes 193.193.135.67:500->193.193.135.66:500,ifindex=5....
| |
| ike 0: IKEv1 exchange=Identity Protection id=622d112386920eab/82890a11b0e6719a len=388
| |
| ike 0: in 622D112386920EAB82890A11B0E6719A0410020000000000000001840A00010400D2D361DFD71F79B84F457F482771727C31DF91846DE9A316369439E230769914E717897ABA5FCD637E50858C2C1C942438CB46425F0E2866CBDF5A5B83E3496ACA886EBB0315370474571D0848668BB31D52731630671BB0C67209FA02A9755B8BEC743F7A5224E87CA02E7F7AB0CF4A4499FABE449C7627F6B48B0ABCD7D870BF7831BB74AFB9318C516F89A0EE990CBAD996FB1B4CF99C9FA0085C1EF6C658B943F2459A6FB0DEF73070AC0D1F94CE2869021292410976942D38A5359D7D77A302DEE5236E1386558DEEDBFC0382CD59121D04AE63C83C98896D0780FE653F67AF7342FD62B0D8996D52DDD3AC9388FFC0F879152AE3B230B78B2A24356A14000034595D169F928B002D58CC3AF8860BC094A326A273113256D128690F5CE9351C32DA9C32F7D92AB125F4F2637D098D6861140000186D227FBE6C5B82736CD3B473F3B9BC67A93A833300000018A00F6ED1DF05508A27D3B1D79C71D707AEE56A6B
| |
| ike 0:ipsec-l2tp:12: responder:main mode get 2nd message...
| |
| ike 0:ipsec-l2tp:12: NAT not detected
| |
| ike 0:ipsec-l2tp:12: out 622D112386920EAB82890A11B0E6719A0410020000000000000001640A0001040BAF8E272033202823B8E9EB29F6EC26D28C6741616289DEA59301AE4204C31E3D28CA98AB064CBF8A9082C77B660AA845CDEF3891472A4921BCFE1A5D030ACAED376B5A93A1B5148A0FA60349BF3E221DC6F4C6C93935030AD7905756EA6B29E3998F511D49CA66D443C5B785956F5D2AEE09FACCA3E87F48561E49DB3842C2030EFAEA6028229DCFBBE66B8B46B7470AFB7D1A9BB1AB8E3155A71139058CFF9B6A2A47C4983E41CFD6891AD12E3D231B61A8C036397A3837ECABEB3320D2A1A32290E1F07C5819835107E57337336835372B647E3E2F6F0DCBB07354147305AC11D78EC93DEFBB6B6AF1695F3CB211643AC1B4B40E90FE7D7B396477ACC88F140000141A96B745FD3004E4FA1F3B7774688A8214000018A00F6ED1DF05508A27D3B1D79C71D707AEE56A6B000000186D227FBE6C5B82736CD3B473F3B9BC67A93A8333
| |
| ike 0:ipsec-l2tp:12: sent IKE msg (ident_r2send): 193.193.135.66:500->193.193.135.67:500, len=356, id=622d112386920eab/82890a11b0e6719a
| |
| ike 0:ipsec-l2tp:12: ISAKMP SA 622d112386920eab/82890a11b0e6719a key 24:8BB676EDAF67D6B1507AA56F79E8C76FAFBFCBC615BB6C57
| |
| ike 0: comes 193.193.135.67:500->193.193.135.66:500,ifindex=5....
| |
| ike 0: IKEv1 exchange=Identity Protection id=622d112386920eab/82890a11b0e6719a len=68
| |
| ike 0: in 622D112386920EAB82890A11B0E6719A051002010000000000000044CAE9716F333EF834B2C25392998B0BDF8117E7B4709D683C8586B6A167C2A637AE34BE5206F01D42
| |
| ike 0:ipsec-l2tp:12: responder: main mode get 3rd message...
| |
| ike 0:ipsec-l2tp:12: dec 622D112386920EAB82890A11B0E6719A0510020100000000000000440800000C01000000C1C1874300000018849275683995E0DAC92CFC23558FF836F6002A6E00000000
| |
| ike 0:ipsec-l2tp:12: PSK authentication succeeded
| |
| ike 0:ipsec-l2tp:12: authentication OK
| |
| ike 0:ipsec-l2tp:12: enc 622D112386920EAB82890A11B0E6719A051002010000000000000046080000120200000069707365632D6C32747000000018358811170A2C3B8E0FA0BCDBA685C073C45B5C0E
| |
| ike 0:ipsec-l2tp:12: out 622D112386920EAB82890A11B0E6719A05100201000000000000004C0B7C17447CF0E75452F13BE3B9DCB9602316AD0C23CDF55F2EBB96CDA0D75C95F5705AD7BB23C2E053B18D80BFE8BFF9
| |
| ike 0:ipsec-l2tp:12: sent IKE msg (ident_r3send): 193.193.135.66:500->193.193.135.67:500, len=76, id=622d112386920eab/82890a11b0e6719a
| |
| ike 0:ipsec-l2tp:12: established IKE SA 622d112386920eab/82890a11b0e6719a
| |
| ike 0:ipsec-l2tp: adding new dynamic tunnel for 193.193.135.67:500
| |
| ike 0:ipsec-l2tp_0: added new dynamic tunnel for 193.193.135.67:500
| |
| ike 0:ipsec-l2tp_0:12: no pending Quick-Mode negotiations
| |
| ike 0: comes 193.193.135.67:500->193.193.135.66:500,ifindex=5....
| |
| ike 0: IKEv1 exchange=Quick id=622d112386920eab/82890a11b0e6719a:00000001 len=308
| |
| ike 0: in 622D112386920EAB82890A11B0E6719A08102001000000010000013484FC3439E9C63DF19AE6EBB5B1A37180C3801539091C8E571B1EE1CD1E384EBA8ABE01AB78F2D537829D9FA5A553FBDEBCE35C51988E5C6214803A02881EE01F86C01F9823414C05C5546F1DCF15AA7E0FE7E68D9D8DA23EA3339F7FEF7B9050C6A487826E1987D91C5783EB4BEDC0760372693C4194B7C91212C016340694321C6CD8207FE0C9A8A95169E31BBAE1869DCD924223449C469760BD76FC536A995ABDBCAD6AA5E8ADD76BB61B40BCC6D66356CD1A169E5D663E37D78ACAD9BFD98A409589F9E374F668A073830E52FC846806AF811E09C1C97671EBCC346606127C6D024A1247032EB7FDAEC47AC8531093AD12EF8969010D54B247E8AD7567194DAD08C2B724663CBB949A822453CC1FC8F1AC01AE46A1CA
| |
| ike 0:ipsec-l2tp_0:12:3: responder received first quick-mode message
| |
| ike 0:ipsec-l2tp_0:12: dec 622D112386920EAB82890A11B0E6719A08102001000000010000013401000018839626BA24EFE558DB5D3DEE30F99C2B3DAE54A40A0000AC0000000100000001020000380103040179247F5D0000002C010C0000800400028006008080050002800100010002000400000E1080010002000200040003D090020000340203040179247F5D00000028010300008004000280050002800100010002000400000E1080010002000200040003D090000000340303040179247F5D00000028010200008004000280050002800100010002000400000E1080010002000200040003D090050000347E0F9F3465181420B56D51A1BF311AC839DAF8A3F2190C8F9F6713B0AA61E961D0E59C4732DF0B855D2527BDF9C8F25A0500000C011106A5C1C187430000000C011106A5C1C187420000000000000000
| |
| ike 0:ipsec-l2tp_0:12:3: peer proposal is: peer:17:193.193.135.67-193.193.135.67:1701, me:17:193.193.135.66-193.193.135.66:1701
| |
| ike 0:ipsec-l2tp_0:12:ipsec-l2tp:3: trying
| |
| ike 0:ipsec-l2tp_0:12:3: transport mode, override with 17:193.193.135.66-193.193.135.66:1701 -> 17:193.193.135.67-193.193.135.67:0
| |
| ike 0:ipsec-l2tp_0:12:ipsec-l2tp:3: matched phase2
| |
| ike 0:ipsec-l2tp_0:12:ipsec-l2tp:3: dynamic client
| |
| ike 0:ipsec-l2tp_0:12:ipsec-l2tp:3: my proposal:
| |
| ike 0:ipsec-l2tp_0:12:ipsec-l2tp:3: proposal id = 1:
| |
| ike 0:ipsec-l2tp_0:12:ipsec-l2tp:3: protocol id = IPSEC_ESP:
| |
| ike 0:ipsec-l2tp_0:12:ipsec-l2tp:3: trans_id = ESP_3DES
| |
| ike 0:ipsec-l2tp_0:12:ipsec-l2tp:3: encapsulation = ENCAPSULATION_MODE_TRANSPORT
| |
| ike 0:ipsec-l2tp_0:12:ipsec-l2tp:3: type = AUTH_ALG, val=SHA1
| |
| ike 0:ipsec-l2tp_0:12:ipsec-l2tp:3: trans_id = ESP_AES (key_len = 128)
| |
| ike 0:ipsec-l2tp_0:12:ipsec-l2tp:3: encapsulation = ENCAPSULATION_MODE_TRANSPORT
| |
| ike 0:ipsec-l2tp_0:12:ipsec-l2tp:3: type = AUTH_ALG, val=SHA1
| |
| ike 0:ipsec-l2tp_0:12:ipsec-l2tp:3: incoming proposal:
| |
| ike 0:ipsec-l2tp_0:12:ipsec-l2tp:3: proposal id = 1:
| |
| ike 0:ipsec-l2tp_0:12:ipsec-l2tp:3: protocol id = IPSEC_ESP:
| |
| ike 0:ipsec-l2tp_0:12:ipsec-l2tp:3: trans_id = ESP_AES (key_len = 128)
| |
| ike 0:ipsec-l2tp_0:12:ipsec-l2tp:3: encapsulation = ENCAPSULATION_MODE_TRANSPORT
| |
| ike 0:ipsec-l2tp_0:12:ipsec-l2tp:3: type = AUTH_ALG, val=SHA1
| |
| ike 0:ipsec-l2tp_0:12:ipsec-l2tp:3: negotiation result
| |
| ike 0:ipsec-l2tp_0:12:ipsec-l2tp:3: proposal id = 1:
| |
| ike 0:ipsec-l2tp_0:12:ipsec-l2tp:3: protocol id = IPSEC_ESP:
| |
| ike 0:ipsec-l2tp_0:12:ipsec-l2tp:3: trans_id = ESP_AES (key_len = 128)
| |
| ike 0:ipsec-l2tp_0:12:ipsec-l2tp:3: encapsulation = ENCAPSULATION_MODE_TRANSPORT
| |
| ike 0:ipsec-l2tp_0:12:ipsec-l2tp:3: type = AUTH_ALG, val=SHA1
| |
| ike 0:ipsec-l2tp_0:12:ipsec-l2tp:3: using transport mode.
| |
| ike 0:ipsec-l2tp_0:12: enc 622D112386920EAB82890A11B0E6719A0810200100000001000000A40100001821EE756AD2264F00CE6BA1632CEA93F8BE5777B10A00004400000001000000010000003801030401658C806E0000002C010C0000800400028006008080050002800100010002000400000E1080010002000200040003D090050000145B6484AE7D210E1E62B20D9ADDE1D05D0500000C011106A5C1C187430000000C011106A5C1C18742
| |
| ike 0:ipsec-l2tp_0:12: out 622D112386920EAB82890A11B0E6719A0810200100000001000000AC1B887C353B84B1FB5F65213F04F06EF1248E0D6CD1BE1BF02AA75B0FCC62DD5290794B80F063251AB3973AF200900AFFBE11F8343222B6F568074C6A97D3C8BC4C5E3F4CAF114C41EC48B28E0E4B11CE5CD4E993436826828C367026007004D207FC41AB2499B7EEB0C5AFB503AC63AE1623A29B6C274EF3E3A5544C5CC0822948791073A99038356FB79B73B7A2B5
| |
| ike 0:ipsec-l2tp_0:12: sent IKE msg (quick_r1send): 193.193.135.66:500->193.193.135.67:500, len=172, id=622d112386920eab/82890a11b0e6719a:00000001
| |
| ike 0: comes 193.193.135.67:500->193.193.135.66:500,ifindex=5....
| |
| ike 0: IKEv1 exchange=Quick id=622d112386920eab/82890a11b0e6719a:00000001 len=60
| |
| ike 0: in 622D112386920EAB82890A11B0E6719A08102001000000010000003CA487CA0980EAE54B3F4579661F3CCDEF664F9CB147AEC486899B4399C1302E0A
| |
| ike 0:ipsec-l2tp_0:12: dec 622D112386920EAB82890A11B0E6719A08102001000000010000003C0000001885D917E15AD341C16CE50A837320FFE2E871DAE20000000000000000
| |
| ike 0:ipsec-l2tp_0:12:ipsec-l2tp:3: replay protection enabled
| |
| ike 0:ipsec-l2tp_0:12:ipsec-l2tp:3: SA life soft seconds=3585.
| |
| ike 0:ipsec-l2tp_0:12:ipsec-l2tp:3: SA life hard seconds=3600.
| |
| ike 0:ipsec-l2tp_0:12:ipsec-l2tp:3: set sa life soft/hard kbytes=249488/250000.
| |
| ike 0:ipsec-l2tp_0:12:ipsec-l2tp:3: IPsec SA selectors #src=1 #dst=1
| |
| ike 0:ipsec-l2tp_0:12:ipsec-l2tp:3: src 0 7 17:193.193.135.66-193.193.135.66:1701
| |
| ike 0:ipsec-l2tp_0:12:ipsec-l2tp:3: dst 0 7 17:193.193.135.67-193.193.135.67:0
| |
| ike 0:ipsec-l2tp_0:12:ipsec-l2tp:3: add dynamic IPsec SA selectors
| |
| ike 0:ipsec-l2tp_0:12:ipsec-l2tp:3: tunnel 1 of VDOM limit 0/0
| |
| ike 0:ipsec-l2tp_0:12:ipsec-l2tp:3: add IPsec SA: SPIs=658c806e/79247f5d
| |
| ike 0:ipsec-l2tp_0:12:ipsec-l2tp:3: IPsec SA dec spi 658c806e key 16:2C3E30B183B935DB335E74AD5235B39F auth 20:8F0480B09EDD77D0043CE088253819CA96505506
| |
| ike 0:ipsec-l2tp_0:12:ipsec-l2tp:3: IPsec SA enc spi 79247f5d key 16:DF6DEFD6172238920E0FA7253CA488BA auth 20:5F024605CEA91B199E7454AA5CC753E126F30E2F
| |
| ike 0:ipsec-l2tp_0:12:ipsec-l2tp:3: transport mode encapsulation is enabled
| |
| ike 0:ipsec-l2tp_0:12:ipsec-l2tp:3: added IPsec SA: SPIs=658c806e/79247f5d
| |
| ike 0:ipsec-l2tp_0:12:ipsec-l2tp:3: sending SNMP tunnel UP trap
| |
| ike 0: unknown SPI 658c806e 5 193.193.135.67:0->193.193.135.66
| |
| ike 0: found ipsec-l2tp_0 193.193.135.66 5 -> 193.193.135.67:500
| |
| ike 0:ipsec-l2tp_0:12:ipsec-l2tp:3: ignoring invalid SPI 658c806e, IPsec SA just negotiated
| |
| ike 0: IP 198.18.4.129 (29) is down
| |
| ike shrank heap by 122880 bytes
| |
|
| |
| '''VERBINDUNG BBENDEN'''
| |
| ike 0: IP 198.18.4.129 (27) is down
| |
| ike 0: comes 193.193.135.67:500->193.193.135.66:500,ifindex=5....
| |
| ike 0: IKEv1 exchange=Informational id=139f97ee253792aa/fb41cf2ac6ea413a:f02e4234 len=76
| |
| ike 0: in 139F97EE253792AAFB41CF2AC6EA413A08100501F02E42340000004C0181DD9CA0EFB7237D82CB4A64EA5521A81B0680A8BC4A1B296616D9BDDF403403C183C4815A3F40A1EEFC869A60167B
| |
| ike 0:ipsec-l2tp_0:10: dec 139F97EE253792AAFB41CF2AC6EA413A08100501F02E42340000004C0C000018769ABD37E279BD4D0E10C79C78F0F660021369C5000000100000000103040001E06C12220000000000000000
| |
| ike 0:ipsec-l2tp_0:10: recv IPsec SA delete, spi count 1
| |
| ike 0:ipsec-l2tp_0: deleting IPsec SA with SPI e06c1222
| |
| ike 0:ipsec-l2tp_0:ipsec-l2tp: deleted IPsec SA with SPI e06c1222, SA count: 0
| |
| ike 0:ipsec-l2tp_0: sending SNMP tunnel DOWN trap for ipsec-l2tp
| |
| ike 0:ipsec-l2tp_0:ipsec-l2tp: delete
| |
| ike 0: comes 193.193.135.67:500->193.193.135.66:500,ifindex=5....
| |
| ike 0: IKEv1 exchange=Informational id=139f97ee253792aa/fb41cf2ac6ea413a:29cadd72 len=84
| |
| ike 0: in 139F97EE253792AAFB41CF2AC6EA413A0810050129CADD7200000054E57C377F515B71A3AA4C25BC781BC12A6FD34F4252399BB6D2A97619311FD64B2F4003BD78DE2848971B42BE23294DF4B3823E120D68B439
| |
| ike 0:ipsec-l2tp_0:10: dec 139F97EE253792AAFB41CF2AC6EA413A0810050129CADD72000000540C000018F44257616ED28299EB82CDBD53F4F56CF036E2DC0000001C0000000101100001139F97EE253792AAFB41CF2AC6EA413A00000000
| |
| ike 0:ipsec-l2tp_0:10: recv ISAKMP SA delete 139f97ee253792aa/fb41cf2ac6ea413a
| |
| ike 0:ipsec-l2tp_0: deleting
| |
| ike 0:ipsec-l2tp_0: flushing
| |
| ike 0:ipsec-l2tp_0: sending SNMP tunnel DOWN trap
| |
| ike 0:ipsec-l2tp_0: flushed
| |
| ike 0:ipsec-l2tp_0: delete dynamic
| |
| ike 0:ipsec-l2tp_0: deleted
| |
| ike shrank heap by 122880 bytes
| |
|
| |
| # diagnose debug disable
| |
| # diagnose debug reset
| |
|
| |
| === Wie kann ich auf Windows 7 eine L2TP IPSec Verbindung konfigurieren? ===
| |
|
| |
| Wenn auf Windows 7 ein "L2TP" Verbindung konfiguriert werden soll muss zu aller Erst kontrolliert werden ob folgende zwei Services aktiviert sind:
| |
|
| |
| IPSec Richtlinien Agent (IPsec Policy Agent)
| |
| IKE- und AuthIP IPsec-Schlüsselerstellungsmethode (IKE and AuthIP IPsec Keying Modules)
| |
|
| |
| Diese werden benötigt für den "L2TP" Service auf Windows 7. Danach muss folgendes ausgeführt werden:
| |
|
| |
| Start > Systemsteuerung > Netzwer und Internet > Netzwerk- und Freigabecener > Neue Verbindung oder neues Netzwerk einrichten
| |
|
| |
| [[Datei:Fortinet-1326.jpg]]
| |
|
| |
| [[Datei:Fortinet-1327.jpg]]
| |
|
| |
| [[Datei:Fortinet-1328.jpg]]
| |
|
| |
| [[Datei:Fortinet-1329.jpg]]
| |
|
| |
| [[Datei:Fortinet-1330.jpg]]
| |
|
| |
| [[Datei:Fortinet-1331.jpg]]
| |
|
| |
| Start > Systemsteuerung > Netzwer und Internet > Netzwerk- und Freigabecener > Adaptereinstellungen ändern > [Adapter markeren und rechte Maustaste > Eigenschaften]
| |
|
| |
| [[Datei:Fortinet-1332.jpg]]
| |
|
| |
| [[Datei:Fortinet-1333.jpg]]
| |
|
| |
| [[Datei:Fortinet-1334.jpg]]
| |
|
| |
| [[Datei:Fortinet-1335.jpg]]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Wenn bei der Authentifizierung "PAP" gewählt wird so wird die Authentifizierung "clear-text" übertragen. Wenn die
| |
| Authentifizierung "verschlüsselt" durchgeführt werden soll, so sollte "CHAP" gewählt werden. Wenn hohe Datenvolumen
| |
| übertragen werden in einer L2TP Verbindungen (zB RDP) und im Zusammenhang mit der Authentifizierung auf dem Client
| |
| "MS-CHAP v2" aktiviert wurde, kann es zu unerwartenden Unterbrüchen kommen. In so einem Fall, bei Benutzung von "MS-CHAP v2",
| |
| sollte dieser Punkt auf dem Client deaktiviert werden. Um diesem Umstand zu umgehen empfehlen wir "CHAP" zu wählen sofern
| |
| eine Verschlüsselung für die Authentifizierung gewünscht ist ansonsten kann "PAP" benutzt werden.
| |
|
| |
| [[Datei:Fortinet-1336.jpg]]
| |
|
| |
| [[Datei:Fortinet-1337.jpg]]
| |
|
| |
| [[Datei:Fortinet-1338.jpg]]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Die folgende Position "xxxxx" steht im Zusammenhang mit der "Split Tunneling" Funktion. Wenn "Split Tunneling"
| |
| aktiviert werden soll muss die folgende Position "deaktiviert" werden. Weitere Informationen dazu siehe Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_kann_ich_auf_Windows_7_f.C3.BCr_eine_L2TP_IPSec_Verbindung_ein_.22splitt_tunneling.22_konfigurieren.3F]]
| |
|
| |
| [[Datei:Fortinet-1339.jpg]]
| |
|
| |
| === Wie kann ich auf Windows 7 für eine L2TP IPSec Verbindung ein "splitt tunneling" konfigurieren? ===
| |
|
| |
| Wenn auf Windows 7 für "L2TP" ein "Split Tunneling" konfiguriert werden soll muss die folgende Position '''deaktiviert''' werden:
| |
|
| |
| Start > Systemsteuerung > Netzwer und Internet > Netzwerk- und Freigabecener > Adaptereinstellungen ändern > [Adapter markeren und rechte Maustaste > Eigenschaften]
| |
|
| |
| Register "Netzwerk" > Internet Protokoll 4 > Eigenschaften > Erweitert > [Aktivierte die nachfolgende Position]
| |
|
| |
| [[Datei:Fortinet-1339.jpg]]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Weitere Informationen um was es sich bei der "Split Tunneling" Funktion handelt siehe nachfolgenden Link:
| |
|
| |
| [[FortiClient:FAQ#Was_bedeutet_im_Client2Site_VPN_Bereich_der_Konfigurationspunkt_.22Split_Tunneling.22.3F]]
| |
|
| |
| === L2TP IPSec Implementierung/Fehlermeldung Windows 7 "Security layer encountered a processing error during initial negotiations"? ===
| |
|
| |
| Wenn eine L2TP IPSec Implementierung durchgführt wird und anhand eines Windows 7 Client/Workstation versucht wird zu zugreifen, kommt es zu einer Fehlermeldung auf dem Windows 7 Client/Workstation:
| |
|
| |
| '''security layer encountered a processing error during initial negotiations'''
| |
|
| |
| Der Grund dafür ist die IPSec Phase-2 dh. der Windows 7 Client/Workstation überprüft in der Phase-2 die "lifetime proposal" und wenn diese nicht übereinstimmt wird diese Fehlemeldung ausgegeben! Auf der Seite von Windows 7 ist diese "lifetime proposal" folgendermassen konfiguriert:
| |
|
| |
| 3600s/250000kbps
| |
|
| |
| Um die Konfiguration auf der Fortigate anzupassen führe folgendes durch:
| |
|
| |
| # config vpn ipsec phase2
| |
| # edit "[Name der Phase 2]"
| |
| # set keylife-type both
| |
| # set keylifekbs 250000
| |
| # set keylifeseconds 3600
| |
| # next
| |
| # end
| |
|
| |
| == SSL-VPN ==
| |
|
| |
| === Gibt es für SSL-VPN eine Limitation betreffend "Concurrent Sessions"? ===
| |
|
| |
| Nein so eine Limitierung betreffend Concurrent Sessions gibt es nicht. Dies bedeutet die "Concurrent Sessions" hängen von den zur Verfügung stehenden System Resourcen ab! Ein Anhaltspunkt betreffend der SSL-VPN Limitierung pro Device bietet das Datasheet des Devices. Diese findet man unter folgenden Artikel:
| |
|
| |
| [[Fortinet:ProduktInfo#FortiGate]]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> In den Datasheets unter "Specifications" findet man zwei Positionen die den Anhaltspunkt
| |
| liefert:
| |
|
| |
| SSL-VPN Throughput
| |
| Concurrent SSL-VPN Users (Recommended Max)
| |
|
| |
| === Wie kann ich den Access Port für die SSL-VPN Funktion konfigurieren? ===
| |
|
| |
| Die SSL-VPN Funktion läuft per Standard unter FortiOS 5.0 auf Port TCP 10443. Unter FortiOS 5.2 läuft dieser Port per Standard auf Port TCP 443. Dieser kann über WebGui und/oder CLI geändert werden. Ueber WebGui kann dies folgendermassen durchgeführt werden:
| |
|
| |
| '''FortiOS 5.0'''
| |
| VPN > SSL > Config > Login Port
| |
|
| |
| '''FortiOS 5.2'''
| |
| VPN > SSL > Settings > Listen on Port
| |
|
| |
| Wenn der SSL-VPN Port gesetzt wird, ist zu berücksichtigen, dass dieser nicht bereits anderweitig genutzt wird. Dies bedeutet: Unter FortiOS 5.0 ist der Admin Port für das Management der FortiGate per Standard auf Port TCP 443 gesetzt und wie schon erwähnt der Port für die SSL-VPN Funktion auf TCP 10443. Nun wenn der SSL-VPN Port auf TCP 443 verschoben werden will muss zuerst der Admin Port verschoben werden:
| |
|
| |
| '''Admin Port FortiOS 5.0 / 5.2'''
| |
| # config system global
| |
| # set admin-port [Setze die entsprechende Port Nummer]
| |
| # end
| |
|
| |
| '''SSL-VPN Port FortiOS 5.0'''
| |
| # config system global
| |
| # set sslvpn-sport 10443
| |
| # end
| |
|
| |
| '''SSL-VPN Port FortiOS 5.2'''
| |
| # config vpn ssl settings
| |
| # set port [Setze die entsprechende Port Nummer]
| |
| # end
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Unter FortiOS 5.0 wird kein Hinweis über das Web Mgmt. Interface angezeigt wenn der Port bereits
| |
| belegt ist. Ebenfalls konnte die Konfiguration unter FortiOS 5.0 ohne "Warnung" durchgeführt
| |
| werden. Unter FortiOS 5.2 wurde diesem Umstand Rechnung getragen und neu wird seitens Admin Port
| |
| und/oder SSL-VPN Port ein Hinweis angezeigt wenn der Port bereits belegt ist!
| |
|
| |
| [[Datei:Fortinet-1130.jpg]]
| |
|
| |
| [[Datei:Fortinet-1131.jpg]]
| |
|
| |
| === Welche Vorraussetzungen gelten wenn ich für das SSL-VPN und/oder den Adminstrative Access den gleiche Port vewenden möchte? ===
| |
|
| |
| Nun wenn eine Public IP auf dem externen Interface exisitert und die FortiGate von extern über den Administrativen Port erreichbar sein soll läuft dieser per Standard auf Port HTTPS 443. Nun möchte man die SSL-VPN Funktion ebenfalls auf diesen Port HTTPS 443 setze ist das technisch gesehen nicht möglich da eine IP und ein Port nur "einmalig" für einen Service vergeben werden kann. Auch wenn nun auf dem externen Interface eine zweite Public IP zB als "secondary" vergeben wird ändert dies nichts an der Situatuion denn der Administrative Access und der SSL-VPN Access stellen zwei System Services die sich "ein" Port nicht 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. Möchte man dies dennoch bewerkstelligen gilt folgende Grundvorraussetzung damit dies ermöglicht werden kann:
| |
|
| |
| Zwei Public IP's die zum "externen" Interface der FortiGate geroutet werden. Die einte IP wird als "main" IP auf dem
| |
| Interface konfiguriert und die zweite IP als "secondary" unter der "main" IP!
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> In dem nachfolgenden Beispiel wird nur gezeigt "wie" die Konfiguration betreffend HTTPS 443 für das SSL-VPN Portal durchzuführen ist.
| |
| Dies bedeutet das Beispiel geht davon aus, dass der Service des SSL-VPN mit allen Komponenten bereits existiert. Siehe auch Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_konfiguriere_ich_unter_FortiOS_5.0_ein_SSL-VPN_Portal.2FTunnel_auf_einer_Fortigate.3F]]
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_konfiguriere_ich_unter_FortiOS_5.2_ein_SSL-VPN_Portal.2FTunnel_auf_einer_Fortigate.3F]]
| |
|
| |
| Wenn die Grundvorraussetzungen gegeben sind, kann die Konfiguration im nachfolgenden Dokument durchgeführt werden. Dabei wird ein "Workaround" angewendet anhand eines "loopback" Interfaces. Auf diesem "loopback" Interface wird ein VIP (Destination NAT) Objekt konfiguriert, dass den Port HTTPS 443 von Extern auf HTTPS 10443 Intern (Port Forward) durchführt da das SSL-VPN nicht auf HTTPS 443 konfiguriert werden kann da es sich um "System Services" handelt und für diese nicht den "gleichen Port" vergeben werden kann:
| |
|
| |
| [[Datei:Using-Port-443-for-MGMT-Access-and-SSL-VPN.pdf]]
| |
|
| |
| === Wie kann ich ein SSL-VPN auf einer FortiGate per Kommandozeile (CLI) konfigurieren? ===
| |
|
| |
| Ausgehend vom nachfolgenden Artikel kann ein SSL-VPN sei es im Tunnel und/oder Web Mode per Mgmt. Web Interface eingerichtet werden:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_konfiguriere_ich_unter_FortiOS_5.0_ein_SSL-VPN_Portal.2FTunnel_auf_einer_Fortigate.3F]]
| |
|
| |
| Es kann jedoch durchaus Sinn ergeben die ganze Konfiguration per Kommandozeile (CLI) durchzuführen. Bei folgendem Beispiel wird ein Tunnel Mode sowie ein Web Portal Mode konfiguriert und zwar in dem Sinne, dass diese seperate gehalten werden. Diese Separierung ist für mehr Transparenz zu empfehlen:
| |
|
| |
| '''Konfiguration VPN-SSL Settings FortiOS 5.0'''
| |
| # config vpn ssl settings
| |
| # set sslvpn-enable enable
| |
| # set dns-server1 [IPv 4 Adresse]
| |
| # set dns-server2 [IPv 4 Adresse]
| |
| # set idle-timeout [Setze das Timeout in Sekunden für das SSL VPN zB "1800"; Standard 0]
| |
| # set tunnel-ip-pools [Definiere das Address Objekt für IPv4 Pool Adressen]
| |
| # set route-source-interface disable
| |
| # set port [Definiere den SSL-VPN TCP Access Port zB 10443]
| |
| # set port-precedence enable [Bei gleicher Port Belegung SSL-VPN hat höhere Presendence als HTTPS]
| |
| # set auto-tunnel-policy disable
| |
| # set auto-tunnel-static-route disable
| |
| # set source-interface disable
| |
| # end
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Ab FortiOS 5.0 gibt es die Optionen "auto-tunnel-policy und static". Diese zwei Optionen sind per
| |
| Standard aktiviert und ermöglichen eine Konfiguration OHNE eine Route sowie einer Policy. Aus diesem
| |
| Grund empfehlen wir diese Optionen zu deaktivieren. Unter FortiOS 5.2 gibt es nur noch die Option
| |
| "auto-tunnel-static". Weitere detaillierte Informationen findet man im folgenden Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wieso_funktioniert_ab_FortiOS_5_mein_SSL-VPN_auch_ohne_die_IP_Pool_Route_und.2Foder_Policy_zu_implementieren.3F]]
| |
|
| |
| '''Konfiguration VPN-SSL Settings FortiOS 5.2'''
| |
| # config vpn ssl settings
| |
| # set dns-server1 [IPv 4 Adresse]
| |
| # set dns-server2 [IPv 4 Adresse]
| |
| # set idle-timeout [Setze das Timeout in Sekunden für das SSL VPN zB "1800"; Standard 0]
| |
| # set tunnel-ip-pools [Definiere das Address Objekt für IPv4 Pool Adressen]
| |
| # set route-source-interface disable
| |
| # set port [Definiere den SSL-VPN TCP Access Port zB 10443]
| |
| # set port-precedence enable [Bei gleicher Port Belegung SSL-VPN hat höhere Presendence als HTTPS]
| |
| # set auto-tunnel-static-route disable
| |
| # set source-interface disable
| |
| # set source-adddress [Definiere ein entsprechendes Address Objekt oder "all"]
| |
| # set default-portal [Namen des entsprechenden Portals zB "web-acces-only"]
| |
| # config authentication-rule
| |
| # edit [Gebe einen entsprechenden Integer an]
| |
| # set users [Gebe einen entsprechenden User's an]
| |
| # set groups [Gebe eine entsprechende Gruppe an]
| |
| # set portal [Gebe ein entsprechendes Portal an]
| |
| # end
| |
| # end
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Wenn "authentication-rule" nicht konfiguriert wird so gilt folgendes: Per Standard benützen alle
| |
| User das Portal das über die Option "default-portal" definiert wird. Wenn andere Portale als das
| |
| "default-portal" benützt werden sollen müssen diese unter "authentication-rule" definiert werden!
| |
|
| |
| '''FortiOS 5.0 WebPortal Only'''
| |
| # config vpn ssl web portal
| |
| # edit [Name des Profile zB "web-acces-only"]
| |
| # set allow-access [Setze Global welche Funktionen erlaubt sind zB "web ftp smb telnet ssh vnc rdp ping citrix rdpnative portforward"]
| |
| # set heading [Gebe den Header an der "im" WebPortal angezeigt wird zB "Welcome to VPN-SSL Portal"]
| |
| # set page-layout [Setze das Layout dh. für Zweispaltig "double-column"]
| |
| # set allow-user-bookmark enable
| |
| # set mac-addr-check disable
| |
| # set auto-prompt-mobile-user-download disable
| |
| # set limit-user-logins enable
| |
| # set host-check none
| |
| # set virtual-desktop disable
| |
| # set os-check disable
| |
| # set cache-cleaner disable
| |
| # config widget
| |
| # edit 1
| |
| # set name "Session Information"
| |
| # set type info
| |
| # set column one
| |
| # set collapse disable
| |
| # next
| |
| # edit 2
| |
| # set name "Connection Tool"
| |
| # set type tool
| |
| # set column two
| |
| # set collapse disable
| |
| # set allow-apps [Gebe an WAS erlaubt ist im Connection Tool zB "web ftp smb telnet ssh vnc rdp ping citrix rdpnative portforward"]
| |
| # next
| |
| # edit 3
| |
| # set name Bookmarks
| |
| # set type bookmark
| |
| # set column one
| |
| # set collapse disable
| |
| # set allow-apps web ftp smb telnet ssh vnc rdp ping citrix rdpnative portforward
| |
| # config bookmarks
| |
| # edit TerminalServerRDPNative
| |
| # set apptyp rdpnative
| |
| # set description "TerminalServerRDPNative"
| |
| # set host [IPv 4 Adresse]
| |
| # set full-screen-mode disable
| |
| # set screen-height 900
| |
| # set screen-width 1600
| |
| # next
| |
| # edit TerminalServerRDP
| |
| # set apptyp rdp
| |
| # set description "TerminalServerRDP"
| |
| # set host [IPv 4 Adresse]
| |
| # set full-screen-mode disable
| |
| # set screen-height 900
| |
| # set screen-width 1600
| |
| # set keyboard-layout de-ch
| |
| # end
| |
| # next
| |
| # edit 5
| |
| # set name "Login History"
| |
| # set type history
| |
| # set column one
| |
| # set collapse disable
| |
| # set display-limit 5
| |
| # next
| |
| # end
| |
| # end
| |
|
| |
| '''FortiOS 5.2 WebPortal Only'''
| |
| # config vpn ssl web portal
| |
| # edit [Name des Profile zB "web-acces-only"]
| |
| # set web-mode enable
| |
| # set tunnel-mode disable
| |
| # set heading [Gebe den Header an der "im" WebPortal angezeigt wird zB "Welcome to VPN-SSL Portal"]
| |
| # set page-layout [Setze das Layout dh. für Zweispaltig "double-column"]
| |
| # set user-bookmark enable
| |
| # set mac-addr-check disable
| |
| # set display-connection-tools enable
| |
| # set display-forticlient-download disable
| |
| # set display-history enable
| |
| # set display-history-limit 10
| |
| # set auto-prompt-mobile-user-download disable
| |
| # set limit-user-logins enable
| |
| # set host-check none
| |
| # set virtual-desktop disable
| |
| # set os-check disable
| |
| # set cache-cleaner disable
| |
| # set display-status enable
| |
| # config bookmark-group
| |
| # edit [Name der Kategorie zB URL]
| |
| # config bookmarks
| |
| # edit [Name des Bookmark's]
| |
| # set description [Beschreibung des Bookmark's]
| |
| # set url "http://www.beispiel.ch"
| |
| # end
| |
| # config bookmark-group
| |
| # edit [Name der Kategorie zB RDP]
| |
| # config bookmarks
| |
| # edit [Name des Bookmark's zB RDP]
| |
| # set description [Beschreibung des Bookmark's]
| |
| # set apptype [Application zB rdp; Zur Auswahl stehen citrix, ftp, portforward, rdp, rdpnative, smb, ssh, telnet, vnc, web]
| |
| # set description [Beschreibung]
| |
| # set host [IPv4 Adresse oder FQDN]
| |
| # set screen-height 900
| |
| # set screen-width 1600
| |
| # set keyboard-layout [Keyboard Layout Code zB de-ch]
| |
| # set logon-user [Optional Username]
| |
| # set logon-password [Optional Passwort]
| |
| # end
| |
| # end
| |
| # config bookmark-group
| |
| # edit [Name der Kategorie zB SSH]
| |
| # config bookmarks
| |
| # edit [Name des Bookmark's zB SSH]
| |
| # set description [Beschreibung des Bookmark's]
| |
| # set apptype [Application zB ssh; Zur Auswahl stehen citrix, ftp, portforward, rdp, rdpnative, smb, ssh, telnet, vnc, web]
| |
| # set description [Beschreibung]
| |
| # set host [IPv4 Adresse oder FQDN]
| |
| # end
| |
| # end
| |
| # end
| |
|
| |
| '''FortiOS 5.0 / 5.2 TunnelMode Only'''
| |
|
| |
| Um den TunnelMode erfolgreich zu konfigurieren benötigen wir zwei Objekte dh. eines stellt das
| |
| LAN dar und das Andere den IPv4 IP Pool Range der dem User über DHCP bei der Verbindung zugeordnet
| |
| wird:
| |
|
| |
| '''Address Objekt FortiOS 5.0 / 5.2'''
| |
| # config firewall address
| |
| # edit [Name des IPv 4 IP Pool zB "net-ip-pool-ssl-vpn-198.18.1.0-25"]
| |
| # set type iprange
| |
| # set visibility enable
| |
| # set start-ip [198.18.1.1]
| |
| # set end-ip [198.18.1.127]
| |
| # next
| |
| # edit [Name des IPv 4 LAN IP Range zB "net-ip-pool-ssl-vpn-198.18.0.0-24"]
| |
| # set type iprange
| |
| # set visibility enable
| |
| # set start-ip [198.18.0.1]
| |
| # set end-ip [198.18.0.254]
| |
| # end
| |
| # end
| |
|
| |
| '''FortiOS 5.0 TunnelMode Only'''
| |
| # config vpn ssl web portal
| |
| # edit [Name des Profile zB "tunnel-acces-only"]
| |
| # set mac-addr-check disable
| |
| # set auto-prompt-mobile-user-download disable
| |
| # set limit-user-logins enable
| |
| # set host-check none
| |
| # set virtual-desktop disable
| |
| # set os-check disable
| |
| # set cache-cleaner disable
| |
| # config widget
| |
| # edit 4
| |
| # set name Tunnel Mode
| |
| # set type tunnel
| |
| # set column two
| |
| # set collapse disable
| |
| # set split-tunneling enable
| |
| # set dns-server1 [IPv4 Adresse]
| |
| # set dns-server2 [IPv4 Adresse]
| |
| # set ip-mode range
| |
| # set ip-pools [Bestehendes Objekt für die IP Pool IP Range zB "net-ip-pool-ssl-vpn-198.18.1.0-25"]
| |
| # set split-tunneling-routing-address [Bestehendes Objekt das die LAN Adresse darstellt zB "net-lan-198.18.0.0-24"]
| |
| # set save-password [enable | disable]
| |
| # set keep-alive disable [enable | disable]
| |
| # set auto-connect [enable | disable]
| |
| # next
| |
| # end
| |
| # end
| |
|
| |
| '''FortiOS 5.2 TunnelMode Only'''
| |
| # config vpn ssl web portal
| |
| # edit [Name des Profile zB "tunnel-acces-only"]
| |
| # set tunnel-mode enable
| |
| # set web-mode disable
| |
| # set cache-cleaner disable
| |
| # set host-check none
| |
| # set limit-user-logins enable
| |
| # set mac-addr-check disable
| |
| # set os-check disable
| |
| # set virtual-desktop disable
| |
| # set ip-mode range
| |
| # set auto-connect disable
| |
| # set keep-alive disable
| |
| # set save-password disable
| |
| # set ip-pools
| |
| # set ip-pools [Bestehendes Objekt für die IP Pool IP Range zB "net-ip-pool-ssl-vpn-198.18.1.0-25"]
| |
| # set split-tunneling-routing-address [Bestehendes Objekt das die LAN Adresse darstellt zB "net-lan-198.18.0.0-24"]
| |
| # set dns-server1 [IPv4 Adresse]
| |
| # set dns-server2 [IPv4 Adresse]
| |
| # end
| |
|
| |
| Als Letzteres muss der entsprechende IP Pool als statische Route eingetragen werden auf dem "ssl-root" Interface dh.:
| |
|
| |
| '''FortiOS 5.0 / 5.2 Routing'''
| |
| # config router static
| |
| # edit [Integer zB "2"]
| |
| # set comment "SSL-VPN IP-Pool Route]
| |
| # set device "ssl.root"
| |
| # set distance 10
| |
| # set dst [IPv4 IP-Pool Network Range zB "198.18.1.0/25]
| |
| # set priority 0
| |
| # end
| |
| # end
| |
|
| |
| Technisch gesehen ist der WebPortal und/oder TunnelMode bereit für den Gebrauch jedoch benötigen wir nun noch die entsprechenden Rules die den Gebrauch erlauben:
| |
|
| |
| '''FortiOS 5.0 Policy'''
| |
| # config firewall policy
| |
| # edit [Gebe einen Integer für die Policy zB "1"
| |
| # set comments "VPN TunnelMode Access"
| |
| # set srcintf "ssl.root"
| |
| # set dstintf [Setze die Destination die erlaubt ist im TunnelMode zB "internal1"]
| |
| # set srcaddr [Setze die Source resp. das Objekt das die IPv 4 IP Pool Netowrk Range darstellt zB "net-ip-pool-ssl-vpn-198.18.1.0-25"]
| |
| # set dstaddr [Setze die Destination resp. das Objekt das die IPv 4 LAN Network Range darstellt zB "net-lan-198.18.0.0-24"]
| |
| # set action accept
| |
| # set schedule "galways"
| |
| # set service [Setze die Service die erlaubt sind zB "ALL"]
| |
| # set logtraffic all
| |
| # next
| |
|
| |
| # edit [Gebe einen Integer für die Policy zB "2"
| |
| # set comments "VPN Portal Access"
| |
| # set srcintf [Setze das entsprechende Source Interface resp. Interne zB "wan1"]
| |
| # set dstintf [Setze das entsprechende Destination Interface zB "internal1"]
| |
| # set srcaddr [Setze das entsprechende Objekt das die Source darstellt zB "all"]
| |
| # set dstaddr [Setze das entsprechende Objekt das die Destination darstellt zB "net-192.168.1.0-24"]
| |
| # set action ssl-vpn
| |
| # set identity-based enable
| |
| # config identity-based-policy
| |
| # edit [Gebe einen entsprechenden Integer ein zB "1"]
| |
| # set schedule "always"
| |
| # set logtraffic all
| |
| # set groups [Gebe die entsprechende Gruppe an für die Authentifizierung zB "FortiGroup"]
| |
| # set service [Setze den entsprechenden Service der erlaubt ist zB "ALL"]
| |
| # set sslvpn-portal [Gebe das entsprechende WebPortal Profil an zB "web-access-only"]
| |
| # next
| |
| # end
| |
| # next
| |
|
| |
| '''FortiOS 5.2 Policy'''
| |
| # config firewall policy
| |
| # set comments "VPN TunnelMode Access"
| |
| # set srcintf [Setze das entsprechende Source Interface resp. Interne zB "ssl.root"]
| |
| # set dstintf [Setze das entsprechende Destination Interface zB "internal1"]
| |
| # set srcaddr [Setze das entsprechende Objekt das die Source darstellt zB "all"]
| |
| # set dstaddr [Setze das entsprechende Objekt das die Destination darstellt zB "net-192.168.1.0-24"]
| |
| # set action accept
| |
| # set schedule "always"
| |
| # set service "ALL"
| |
| # set logtraffic all
| |
| # set groups [Setze einen entsprechende Gruppe]
| |
| # set users [Setze einen entsprechende User]
| |
| # set devices [Setze einen entsprechenden Device]
| |
| # end
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Wenn User und/oder Gruppen definiert werden die nicht das unter "config vpn ssl settings" definierte
| |
| "default-portal" benützen, muss dies unter "config vpn ssl settings" unter "config authentication-rule"
| |
| definiert werden!
| |
|
| |
| Nun kann getestet werden. Wenn es zu Problemen kommt kann mit folgenden Befehl ein Debug ausgeführt werden:
| |
|
| |
| '''Setze den Debug Filter zurück:'''
| |
|
| |
| # diagnose debug reset
| |
|
| |
| '''Setze einen neuen Debug Filter:'''
| |
|
| |
| # diagnose debug application sslvpn -1
| |
|
| |
| '''Aktiviere den Debug Modus mit dem gesetzen Debug Filter:'''
| |
|
| |
| # diagnose debug enable
| |
|
| |
| Führe nun eine Zugriff über Portal oder TunnelMode durch und achte auf den Output! Nach der Benutzung des Debug sollte dieser wieder zurückgestellt und deaktiviert werden:
| |
|
| |
| '''Deaktiviere den Debug Modus:'''
| |
|
| |
| # diagnose debug disable
| |
|
| |
| '''Setze den Debug Filter zurück:'''
| |
|
| |
| # diagnose debug reset
| |
|
| |
| '''Kontrolliere den Debug Filter ob dieser zurückgesetzt wurde:'''
| |
|
| |
| # diagnose debug info
| |
|
| |
| === Wie konfiguriere ich unter FortiOS 5.0 ein SSL-VPN Portal/Tunnel auf einer Fortigate? ===
| |
|
| |
| Nachfolgende Dokumentation gibt Auskunft wie ein SSL-VPN unter FortiOS 5.0 -sei es im Portal und/oder Tunnel Mode- aufgebaut wird. In unserem Beispiel gehen wir davon aus, dass eine Fortigate über folgende Konstellation verfügt (Factory Defaults):
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Eine 40C unterstützt nur noch 1 VPN Portal dh. weitere VPN Portale können nicht erfasst werden. Versucht
| |
| man dies über CLI mit folgendem Befehl erscheint folgendes, was wiederum bestätigt, dass nur ein SSL-VPN Portal
| |
| möglich ist:
| |
|
| |
| # config vpn ssl web portal
| |
| # edit new
| |
|
| |
| Too many entries in all tables of .vpn.ssl.web.portal in vdom root: 1 / vdom-max = 1
| |
|
| |
| ____________ _________________________
| |
| 193.193.135.66/29| | 192.168.1.99 | |
| |
| ----- WAN 1 -----| Fortigate |------ LAN -----| LAN Env. 192.168.1.0/24 |
| |
| |____________| |_________________________|
| |
|
| |
| Als Erstes erfassen wir einen User sowie eine Gruppe. Der neu erfasste User wird Mitglied dieser neuen Gruppe:
| |
|
| |
| User & Device > User > User Definition
| |
|
| |
| [[Datei:Fortinet-68.jpg]]
| |
|
| |
| [[Datei:Fortinet-69.jpg]]
| |
|
| |
| [[Datei:Fortinet-1132.jpg]]
| |
|
| |
| [[Datei:Fortinet-1133.jpg]]
| |
|
| |
| [[Datei:Fortinet-1134.jpg]]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Wenn der User auf LDAP gesetzt wird so wird die Authentifizierung über Active Directory
| |
| verifiziert! Desweiteren kann für einen User eine Two Factor Authentication aktiviert werden dh.
| |
| sei es über Hard Token oder ODA. Weitere Informationen betreffend Einbinden eines Active Directory's
| |
| siehe folgender Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_binde_ich_ein_Active_Directory_.28LDAP.29_f.C3.BCr_eine_Authentifizierung_ein.3F]]
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_aktiviere_ich_f.C3.BCr_einen_lokalen_User_Two-Faktor_Authentication_anhand_ODA.3F]]
| |
|
| |
| User & Device > User > User Groups
| |
|
| |
| [[Datei:Fortinet-70.jpg]]
| |
|
| |
| [[Datei:Fortinet-71.jpg]]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Im Gegensatz zu FortiOS 4 MR3 wird unter FortiOS 5.0 das entsprechende Portal nicht mehr in der User Gruppe zugeordnet dh.
| |
| Unter FortiOS 5.0 wird der entsprechende User und/oder Gruppe in der "Identity Based Policy" dem entsprechenden Portal
| |
| zugeordnet! Für eine Active Directory Authentifizierung muss eine entsprechende Gruppe dementsprechend konfiguriert resp.
| |
| eingebunden werden.
| |
|
| |
| Anhand der SSL-VPN Funktion wird auf der Fortigate ein Portal und/oder ein Tunnel zur Verfügung gestellt. In unserem Beispiel gehen wir davon aus, dass wir einen internen WebServer (192.168.1.12) haben den wir erreichen möchten. Per Standard ist innerhalb der globalen Konfiguration der SSL-VPN Funktion die Option " sslvpn-enable" aktiviert. Dies bedeutet wiederum, dass die SSL-VPN Funktion zur Verfügung steht. Möchte man die komplette SSL-VPN Funktion deaktivieren so muss diese Option auf "disabled" (deaktiviert) gesetzt werden.
| |
|
| |
| # config vpn ssl settings
| |
| # set sslvpn-enable enable
| |
| # end
| |
|
| |
| Nun erstellen wir für den WebServer (192.168.1.12) ein Adress Objekt. Führe dazu folgendes aus:
| |
|
| |
| Firewall Objects > Address > Address
| |
|
| |
| [[Datei:Fortinet-94.jpg]]
| |
|
| |
| [[Datei:Fortinet-95.jpg]]
| |
|
| |
| Nun damit wir die Internal IP LAN Defintion in den Policy's benutzen können benötigen wir ein Adress Objekt das dieses darstellt:
| |
|
| |
| [[Datei:Fortinet-110.jpg]]
| |
|
| |
| [[Datei:Fortinet-111.jpg]]
| |
|
| |
| Für die SSL-VPN Funktion benötigt man einen IP-Pool dh. dieser IP-Pool weist den Usern nach erfolgreicher Authentifizierung eine IP zu. Somit kommt dieser IP-Pool einem DHCP Server gleich. Es kann der "vordefinierte" IP-Pool "SSLVPN_TUNNEL_ADDR1" benutzt werden oder einen eigenen definierten:
| |
|
| |
| Firewall Objects > Address > Address
| |
|
| |
| [[Datei:Fortinet-94.jpg]]
| |
|
| |
| [[Datei:Fortinet-1135.jpg]]
| |
|
| |
| Dieser IP-Pool der definierte wurde kann nun als "Globaler IP-Pool" definiert werden. Dies bedeutet er wird für "Alle" SSL-VPN Portale benutzt sofern im SSL-VPN Portal selber kein anderer definiert wird:
| |
|
| |
| VPN > SSL > Config
| |
|
| |
| [[Datei:Fortinet-96.jpg]]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Wie schon erwähnt wird unter "VPN > SSL > Config" die globale SSL-VPN Konfiguration durchgeführt. Dazu gehört
| |
| ebenfalls ein DNS Server der den SSL-VPN Client's zusätzlich zur IP-Pool Adresse nach erfolgreicher Authentifizierung
| |
| zugewisen wird. Wird im SSL-VPN Profile selber ein anderer IP-Pool definiert als unter der globalen Konfig so
| |
| überschreibt die Konfiguration im SSL-VPN Profile die globale Konfiguration!
| |
|
| |
| Im nächsten Schritt wird ein "SSL-VPN Priofile erstellt die den SSL-VPN Usern die verschiedenen Funktionen für SSL-VPN bereitstellt:
| |
|
| |
| VPN > SSL > Portal
| |
|
| |
| [[Datei:Fortinet-100.jpg]]
| |
|
| |
| [[Datei:Fortinet-379.jpg]]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Dem Punkt "Split Tunneling" kommt eine wichtige Funktion zu dh. Diese Konfiguration steuert welche Packet auf dem Client/
| |
| Workstation durch den SSL-VPN Tunnel gesendet werden. Weitere Informationen dazu siehe nachfolgender Artikel:
| |
|
| |
| [[FortiClient:FAQ#Was_bedeutet_im_Client2Site_VPN_Bereich_der_Konfigurationspunkt_.22Split_Tunneling.22.3F]]
| |
|
| |
| Nach der Konfiguration kann anhand der Position "View Portal" überprüft werden wie das SSL-VPN Portal nach einem erfolgreichen einloggen aussieht:
| |
|
| |
| [[Datei:Fortinet-102.jpg]]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Möchte man das Aussehen modifizieren zB die verschiedenen Positionen Zweispaltig anzeigen so muss
| |
| dies über Kommandozeile durchgeführt werden. Weitere Informationen dazu siehe nachfolgenden Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_kann_ich_ein_SSL-VPN_auf_einer_FortiGate_per_Kommandozeile_.28CLI.29_konfigurieren.3F ]]
| |
|
| |
| [[Datei:Fortinet-1136.jpg]]
| |
|
| |
| In den vorhergehenden Konfigurations Schritten haben wir einen IP-Pool erfasst. Dieser wird benutzt um dem Usern eine IP nach einer erfolgreichen Authentifizierung zu zuweisen. Damit die Fortigate weiss wo sich dieser SSL-VPN IP-Pool befindet, muss dieser geroutet werden dh. auf das Interface "ssl.root" das unser SSL-VPN Funktion darstellt:
| |
|
| |
| Router > Static > Static Route
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Ist dieser Menüpunkt nicht vorhanden muss/kann dieser über folgende Position aktiviert werden:
| |
|
| |
| System > Config > Feature > Advanced Routing
| |
|
| |
| Nach der Aktivierung dieses Features muss kurz ausgeloggt sowie wieder eingeloggt werden!
| |
|
| |
| [[Datei:Fortinet-108.jpg]]
| |
|
| |
| [[Datei:Fortinet-109.jpg]]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Dieser Routing Eintrag ist ab FortiOS 5.0 nicht mehr in jedem Fall nötig! Wir empfehlen "Dringend" den Routing
| |
| Eintrag dennoch durchzuführen! Weitere "wichtige" Informationen dazu siehe folgender Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wieso_funktioniert_ab_FortiOS_5_mein_SSL-VPN_auch_ohne_die_IP_Pool_Route_und.2Foder_Policy_zu_implementieren.3F]]
| |
|
| |
| Als letzen Schritt benötigen wir eine entsprechnenden Firewall Policy die den Traffic resp. die SSL-VPN Funktion erlaubt. Der nächste Schritt zeigt die Firewall Policy Rule für das WebPortal. Diese wird über eine "Identity Based Policy" erstellt:
| |
|
| |
| Policy > Policy > Policy > Create New
| |
|
| |
| [[Datei:Fortinet-112.jpg]]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Es darf/sollte für die Destination Adressen nicht "ALL" und/oder "ANY" definiert werden denn wird dies durchgeführt erscheint
| |
| eine Fehlermeldung "Destination address of Split Tunneling policy is invalid" sobald das Split Tunneling aktiviert wird!
| |
|
| |
| [[Datei:Fortinet-380.jpg]]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Ab FortiOS 5.0.5 fällt auf, dass in der "Identity Based Policy" im Mgmt. Gui kein Abschnitt mehr erscheint für "service".
| |
| Diese Position wurde vom Gui entfernt dh. wenn für SSL-VPN betreffend "service" eingeschränkt werden soll muss dies über CLI
| |
| konfiguriert werden. Per Standard steht die Positionen "service" in den "Identity Policy" auf "ALL". Um die Konfiguration über
| |
| CLI durchzuführen führe folgendes durch:
| |
|
| |
| # config firewall policy
| |
| # edit [Gebe die ID an der entsprechenden Policy in der SSL-VPN konfiguriert wurde]
| |
| # config identity-based-policy
| |
| # edit [Gebe die ID an für die entsprechende Policy unter der Identity Policy]
| |
| # set service [Gebe den entsprechenden Service an zB HTTP]
| |
| # end
| |
| # end
| |
|
| |
| Um die entsprechende Firewall Policy für SSL-VPN zu finden resp. die ID zu eruieren kann über CLI folgendes Kommando abgesetzt
| |
| werden:
| |
|
| |
| # show firewall policy
| |
|
| |
| Um eine Firewall Policy Rule für den Tunnel Mode zu erstellen führe folgendes aus:
| |
|
| |
| [[Datei:Fortinet-1137.jpg]]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Diese Firewall Policy ist ab FortiOS 5.0 nicht mehr in jedem Fall nötig! Wir empfehlen "Dringend" die Policy dennoch zu
| |
| implementieren! Weitere Informationen dazu siehe folgender Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wieso_funktioniert_ab_FortiOS_5_mein_SSL-VPN_auch_ohne_die_IP_Pool_Route_und.2Foder_Policy_zu_implementieren.3F]]
| |
|
| |
| Die Konfiguration der SSL-VPN Funktion ist nun abgeschlossen. Um diese zu testen kann folgendes durchgeführt werden:
| |
|
| |
| '''Teste WebPortal Zugriff https://[Public IP WAN Adresse]:[SSL-VPN Port]'''
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Unter FortiOS 5.0 sobald die VPN Funktion aktiviert ist und die Option "sslvpn-enable" Option unter der
| |
| global Konfiguration nicht auf "disabled" (deaktiviert) gesetzt ist, kann das WebPortal auf jedem Interface
| |
| der FortiGate erreicht werden. Möchte man dies verhindern und das WebPortal soll "nur" über "wan1" Interface
| |
| erreichbar sein siehe nachfolgenden Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Was_sind_.22Local_In_Policy.27s.22_und_wie_kann_ich_diese_manipulieren.3F]]
| |
|
| |
| '''Teste Tunnel Mode Zugriff über SSL-VPN Client'''
| |
|
| |
| Der dazu benötigte Client kann über https://support.fortinet.com runtergeladen werden. Der Download befindet sich
| |
| im entsprechenden Verzeichnis (SSL-VPN) des Image (Firmware) Downloads einer FortiGate. Desweiteren kann dieser
| |
| Tunnel Mode ebenfalls mit dem FortiClient getestet werden (IPSec-Only). Weitere Informationen dazu siehe nachfolgenden
| |
| Artikel:
| |
|
| |
| [[FortiClient:FAQ#Wie_kann_ich_ein_FortiClient_Endpoint_Security_Software_Package_mit_VPN_.28IPSec.2FSSL-VPN.29_only_erstellen.3F]]
| |
|
| |
| Um den Debug Modus auf der Console SSL-VPN Funktion auszuführen führe folgendes aus:
| |
|
| |
| '''Setze den Debug Filter zurück:'''
| |
|
| |
| # diagnose debug reset
| |
|
| |
| '''Setze einen neuen Debug Filter:'''
| |
|
| |
| # diagnose debug application sslvpn -1
| |
|
| |
| '''Aktiviere den Debug Modus mit dem gesetzen Debug Filter:'''
| |
|
| |
| # diagnose debug enable
| |
|
| |
| === Wie konfiguriere ich unter FortiOS 5.2 ein SSL-VPN Portal/Tunnel auf einer Fortigate? ===
| |
|
| |
| Unter FortiOS 5.2 wird ein SSL-VPN Portal/Tunnel anderst konfiguriert als unter FortiOS 5.0. Die Konfiguration ist im Hintrgrund mehr oder weniger dieselbe jedoch wird der Tunnel Mode und der Portal Mode völlig unterschiedlich gehandhabt. Wir gehen von folgenden Beispiel aus:
| |
|
| |
| ____________ _________________________
| |
| 193.193.135.66/29| | 192.168.1.99 | |
| |
| ----- WAN 1 -----| Fortigate |------ LAN -----| LAN Env. 192.168.1.0/24 |
| |
| |____________| |_________________________|
| |
|
| |
| Um den Tunnel und/oder Portal Mode korrekt zu konfigurieren benötigt man einige Adress Objekte sowie einen User/Gruppe wie:
| |
|
| |
| Adress Objekt des internen LAN net-lan-192.168.0.0-24
| |
| Adress Objekt des IP-Pool's net-ip-pool-10.10.0.0-24
| |
| User user-1 (Mitglied in gr-ssl-vpn-tunnel / gr-ssl-vpn-portal
| |
| Gruppe gr-ssl-vpn-tunnel
| |
| Gruppe gr-ssl-vpn-portal
| |
|
| |
| Um diese zu erstellen wähle folgendes:
| |
|
| |
| Policy & Objects > Objects > Addresses
| |
|
| |
| [[Datei:Fortinet-1138.jpg]]
| |
|
| |
| '''net-lan-192.168.0.0-24'''
| |
|
| |
| [[Datei:Fortinet-1139.jpg]]
| |
|
| |
| [[Datei:Fortinet-1138.jpg]]
| |
|
| |
| '''net-ip-pool-10.10.0.0-24'''
| |
|
| |
| [[Datei:Fortinet-1140.jpg]]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Der IP-Pool Bereich stellt nichts anderst dar als einen DHCP Server. Dies bedeutet: Wenn der SSL-VPN
| |
| User ein Login durchführt wird diesem nach erfolgreicher Authentifizierung aus diesem IP-Pool (DHCP)
| |
| eine Adresse zugewiesen!
| |
|
| |
| User & Device > User Definition
| |
|
| |
| [[Datei:Fortinet-1141.jpg]]
| |
|
| |
| '''user-1'''
| |
|
| |
| [[Datei:Fortinet-1142.jpg]]
| |
|
| |
| [[Datei:Fortinet-1143.jpg]]
| |
|
| |
| [[Datei:Fortinet-1144.jpg]]
| |
|
| |
| User & Device > User Groups
| |
|
| |
| [[Datei:Fortinet-1145.jpg]]
| |
|
| |
| '''gr-ssl-vpn-tunnel'''
| |
|
| |
| [[Datei:Fortinet-1146.jpg]]
| |
|
| |
| [[Datei:Fortinet-1145.jpg]]
| |
|
| |
| '''gr-ssl-vpn-portal'''
| |
|
| |
| [[Datei:Fortinet-1147.jpg]]
| |
|
| |
| In den nächsten Schritten konfigurieren wir einen Tunnel Mode dh. Zugriff auf die SSL-VPN Funktion anhand des Client's sei es der SSL-VPN Client und/oder FortiClient Endpoint Security im VPN-Only mode:
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Weitere Informationen zum FortiClient Endpoint Sercurity VPN-Only siehe nachfolgenden Artikel:
| |
|
| |
| [[FortiClient:FAQ#Wie_kann_ich_ein_FortiClient_Endpoint_Security_Software_Package_mit_VPN_.28IPSec.2FSSL-VPN.29_only_erstellen.3F]]
| |
|
| |
| '''Tunnel Mode Only Profile'''
| |
|
| |
| VPN > SSL > Portals
| |
|
| |
| [[Datei:Fortinet-1148.jpg]]
| |
|
| |
| [[Datei:Fortinet-1149.jpg]]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Weitere Informationen zur Funktion "Split Tunneling" siehe nachfolgender Artikel:
| |
|
| |
| [[FortiClient:FAQ#Was_bedeutet_im_Client2Site_VPN_Bereich_der_Konfigurationspunkt_.22Split_Tunneling.22.3F]]
| |
|
| |
| Viele der einzelnen Funktionen eines SSL-VPN Portal's sind nur über Kommandozeile konfigurierbar.
| |
| Nachfolgender Artikel zeigt wie ein SSL-VPN über die Kommandozeile konfiguriert wird:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_kann_ich_ein_SSL-VPN_auf_einer_FortiGate_per_Kommandozeile_.28CLI.29_konfigurieren.3F]]
| |
|
| |
| VPN > SSL > Settings
| |
|
| |
| [[Datei:Fortinet-1150.jpg]]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Unter FortiOS 5.0 wurde die SSL-VPN Funktion auf "allen" Interface's zur Verfügung gestellt. Um dies zu verhindern
| |
| musst unter FortiOS 5.0 eine "Local-In" Policy implementiert werden. Dies ist unter FortiOS 5.2 nicht mehr nötig da über
| |
| "Listen on Interface" die Interface's auf denen die SSL-VPN Funktion zur Verfügung gestellt wird über diese Position
| |
| konfiguriert werden kann. Desweiteren, wenn auf der Position "Listen on Port" ein Konflikt besteht da dieser Port bereits
| |
| besetzt ist, wird ein entsprechender Hinweis eingeblendet. Weitere Informationen dazu siehe nachfolgenden Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_kann_ich_den_Access_Port_f.C3.BCr_die_SSL-VPN_Funktion_konfigurieren.3F]]
| |
|
| |
| [[Datei:Fortinet-1151.jpg]]
| |
|
| |
| [[Datei:Fortinet-1152.jpg]]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Unter "All Other Users/Groups" muss ein entsprechendes SSL Portal definiert werden. Dieses Portal match sofern in der
| |
| oberen Zeilen kein "match" stattfindet. Es gilt "top down first match wins". Dabei sollte die Funktion "Realm" miteinbezogen
| |
| werden um zwischen den zwei Portalen zu unterscheiden!
| |
|
| |
| [[Datei:Fortinet-1153.jpg]]
| |
|
| |
| [[Datei:Fortinet-1154.jpg]]
| |
|
| |
| [[Datei:Fortinet-1155.jpg]]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Unter FortiOS 5.2 existiert keine "Identity Based Policy" mehr sondern die SSL-VPN Funktion mit der
| |
| entsprechenden Gruppe/User wird in der "regulären" Firewall Policy konfiguriert!
| |
|
| |
| Als letzter Schritt muss die IP-Pool Adresse für die SSL-VPN Funktion geroutet werden und zwar auf das Interface "ssl.root". Dieses Interface's tellt die SSL-VPN Funktion dar:
| |
|
| |
| [[Datei:Fortinet-1163.jpg]]
| |
|
| |
| [[Datei:Fortinet-1164.jpg]]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Diese Konfiguration des Routings ist nicht in allen Fällen notwendig da eine Option existiert unter
| |
| "vpn ssl settings" die diese Konfiguration Automatisiert. Weitere Informationen dazu siehe Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wieso_funktioniert_ab_FortiOS_5_mein_SSL-VPN_auch_ohne_die_IP_Pool_Route_und.2Foder_Policy_zu_implementieren.3F]]
| |
|
| |
| Die Tunnel Mode Konfiguration ist nun abgeschlossen. Als Naechstes konfigurieren wir einen Portal Mode dh. Zugriff auf die SSL-VPN Funktion anhand des Browser auf ein SSL-VPN Portal das vers. Funktionen zur Verfügung stellen kann:
| |
|
| |
| '''Portal Mode Only Profile'''
| |
|
| |
| VPN > SSL > Portals
| |
|
| |
| [[Datei:Fortinet-1148.jpg]]
| |
|
| |
| [[Datei:Fortinet-1156.jpg]]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Viele der einzelnen Funktionen eines SSL-VPN Portal's sind nur über Kommandozeile konfigurierbar. Nachfolgender
| |
| Artikel zeigt wie ein SSL-VPN über die Kommandozeile konfiguriert wird:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_kann_ich_ein_SSL-VPN_auf_einer_FortiGate_per_Kommandozeile_.28CLI.29_konfigurieren.3F]]
| |
|
| |
| [[Datei:Fortinet-1157.jpg]]
| |
|
| |
| [[Datei:Fortinet-1158.jpg]]
| |
|
| |
| [[Datei:Fortinet-1159.jpg]]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> In unserem Beispiel ist darauf zu achten -da wir mit zwei Portalen dh. tunnel-mode/portal-mode arbeiten- das dasjenige
| |
| des "portal-mode" zuerst gelistet ist und ann das "tunnel-mode" Portal. Es gilt für diesen Konfigurationspunkt "Authentication/
| |
| Portal Mapping" die Regel "top down first match wins":
| |
|
| |
| [[Datei:Fortinet-1162.jpg]]
| |
|
| |
| Wenn die Unterscheidung zwischen User/Gruppen sowie Portalen nicht ausreicht kann anhand der Funktion "realm" die Konfiguration
| |
| erweitert werden. Dies bedeutet: Wenn ein User in beiden Gruppen die vorkommt dh. für Tunnel und Web Mode kann die Evaluierung
| |
| zwischen Tunnel und Web Mode nicht mehr durchgeführt werden da der User in beiden Gruppen vorkommt. Die Einzige unterscheidungs
| |
| Möglichkeit liegt im "Realm". Dies bedeutet soll der Web Mode vom Tunnel Mode unterschieden werden kann ein Realm "Tunnel"
| |
| erstellt werden. Dieser wird dann dazu benutzt zwischen den Portalen sei es Web und/oder Tunnel zu unterscheiden! Das Feature
| |
| "realm" ist per Standard deaktiviert und wird über die folgende Position aktiviert:
| |
|
| |
| System > Config > Features > Show More > SSL-VPN Realms
| |
|
| |
| Nach Aktivierung des Features steht die Funktion "Realms" unter folgender Position zur Verfügung:
| |
|
| |
| VPN > SSL > Realms
| |
|
| |
| [[Datei:Fortinet-1160.jpg]]
| |
|
| |
| [[Datei:Fortinet-1161.jpg]]
| |
|
| |
| Um ein Web Mode und Tunnel Mode inkl. den VPN Settings komplett über Kommandozeile zu konfigurieren kann folgendes durchgeführt werden:
| |
|
| |
| '''VPN SSL Settings Web Portal'''
| |
|
| |
| # config vpn ssl web portal
| |
| # edit [Name des Web Portals zB "web-acces.local"]
| |
| # set tunnel-mode disable
| |
| # set ipv6-tunnel-mode disable
| |
| # set web-mode enable
| |
| # set cache-cleaner disable
| |
| # set host-check none
| |
| # set limit-user-logins enable
| |
| # set mac-addr-check disable
| |
| # set os-check disable
| |
| # set virtual-desktop disable
| |
| # set auto-prompt-mobile-user-download disable
| |
| # set display-bookmark enable
| |
| # set user-bookmark enable
| |
| # set config bookmark-group
| |
| # set edit "Intranet-Kategorie"
| |
| # set config bookmarks
| |
| # set edit "Intranet"
| |
| # set set description "Intranet Site"
| |
| # set set url "www.mydomain.intra"
| |
| # set end
| |
| # set display-connection-tools enable
| |
| # set display-forticlient-download disable
| |
| # set display-history enable
| |
| # set display-history-limit 10
| |
| # set display-status enable
| |
| # set heading "Welcome to mydomain.ch"
| |
| # set page-layout double-column
| |
| # unset redir-url
| |
| # set theme blue
| |
| # set custom-lang en
| |
| # end
| |
|
| |
| '''VPN SSL Settings Tunnel Mode'''
| |
|
| |
| # config vpn ssl web portal
| |
| # edit [Name des Web Portals zB "tunnel-acces.local"]
| |
| # set tunnel-mode enable
| |
| # set ipv6-tunnel-mode disable
| |
| # set web-mode disable
| |
| # set cache-cleaner disable
| |
| # set host-check none
| |
| # set limit-user-logins enable
| |
| # set mac-addr-check disable
| |
| # set os-check disable
| |
| # set virtual-desktop disable
| |
| # set ip-mode range
| |
| # set auto-connect disable
| |
| # set keep-alive enable
| |
| # set save-password enable
| |
| # set ip-pools [Adress Objekt für IP Pool SSL VPN zB "net-ip-pool-10.10.0.0-24"]
| |
| # set split-tunneling enable
| |
| # set split-tunneling-routing-address [Adress Objekt für Destination LAN zB "net-lan-192.168.0.0-24"]
| |
| # set dns-server1 [IPv4 Adresse für DNS Server]
| |
| # set dns-server2 0.0.0.0
| |
| # set wins-server1 0.0.0.0
| |
| # set wins-server2 0.0.0.0
| |
| # end
| |
|
| |
| '''VPN SSL Settings Realm'''
| |
|
| |
| # config vpn ssl web realm
| |
| # edit [Name des Realms zB "tunnel"]
| |
| # set max-concurrent-user 100
| |
| <nowiki># set login-page "<html>
| |
| <head>
| |
| <meta http-equiv=\"Content-Type\" content=\"text/html; charset=UTF-8\">
| |
| <title>
| |
| login
| |
| </title>
| |
| <meta http-equiv=\"Pragma\" content=\"no-cache\">
| |
| <meta http-equiv=\"cache-control\" content=\"no-cache\">
| |
| <meta http-equiv=\"cache-control\" content=\"must-revalidate\">
| |
| <link href=\"/sslvpn/css/login.css\" rel=\"stylesheet\" type=\"text/css\">
| |
| <script type=\"text/javascript\">
| |
| if (top && top.location != window.location) top.location = top.location;
| |
| if (window.opener && window.opener.top) {
| |
| window.opener.top.location = window.opener.top.location;
| |
| self.close();
| |
| }
| |
| </script>
| |
| </head>
| |
| <body class=\"main\">
| |
| <center>
| |
| <table width=\"100%\" height=\"100%\" align=\"center\" class=\"container\" valign=\"middle\" cellpadding=\"0\" cellspacing=\"0\">
| |
| <tr valign=middle>
| |
| <td>
| |
| <form action=\"%%SSL_ACT%%\" method=\"%%SSL_METHOD%%\" name=\"f\" autocomplete=\"off\">
| |
| <table class=\"list\" cellpadding=10 cellspacing=0 align=center width=400 height=180>
| |
| <tr class=\"dark\">
| |
| <td colspan=2>
| |
| <b>
| |
| <br>
| |
| WARNING:
| |
| <br>
| |
| <p style=\"text-align:justify; margin-left:0px; margin-right:0px\">
| |
| 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! </p>
| |
| <br>
| |
| </b>
| |
| </td>
| |
| </tr>
| |
| %%SSL_LOGIN%%
| |
| <tr>
| |
| <td>
| |
| </td>
| |
| <td id=login>
| |
| <input type=button name=login_button id=login_button value=\"Login\" onClick=\"try_login()\" border=0>
| |
| </td>
| |
| </tr>
| |
| </table>
| |
| %%SSL_HIDDEN%%
| |
| </form>
| |
| </td>
| |
| </tr>
| |
| </table>
| |
| </center>
| |
| </body>
| |
| <script>
| |
| document.forms[0].username.focus();
| |
| </script>
| |
| </html>"
| |
| # end </nowiki>
| |
|
| |
| '''VPN SSL Settings'''
| |
|
| |
| # config vpn ssl settings
| |
| # set reqclientcert disable
| |
| # set sslv2 disable
| |
| # set sslv3 enable
| |
| # set tlsv1-0 enable
| |
| # set tlsv1-1 enable
| |
| # set tlsv1-2 enable
| |
| # set ssl-big-buffer disable
| |
| # set ssl-insert-empty-fragment enable
| |
| # set ssl-client-renegotiation disable
| |
| # set force-two-factor-auth disable
| |
| # set servercert self-sign
| |
| # set algorithm default
| |
| # set idle-timeout 1800
| |
| # set auth-timeout 28800
| |
| # set auto-tunnel-static-route disable
| |
| # set tunnel-ip-pools [Adress Objekt für IP Pool SSL VPN zB "net-ip-pool-10.10.0.0-24"]
| |
| # set dns-server1 [IPv4 Adresse für DNS Server]
| |
| # set dns-server2 0.0.0.0
| |
| # set wins-server1 0.0.0.0
| |
| # set wins-server2 0.0.0.0
| |
| # set route-source-interface disable
| |
| # set url-obscuration disable
| |
| # set http-compression disable
| |
| # set http-only-cookie enable
| |
| # set port 10443
| |
| # set port-precedence enable
| |
| # set auto-tunnel-static-route disable
| |
| # set source-interface [Interface ISP zB "wan1"]
| |
| # set source-address [Adress Objekt oder "all"]
| |
| # set source-address-negate disable
| |
| # unset source-address6
| |
| # set default-portal "web-access.intra"
| |
| # config authentication-rule
| |
| # edit 1
| |
| # set source-interface [Interface ISP zB "wan1"]
| |
| # set source-address [Adress Objekt oder "all"]
| |
| # set source-address-negate disable
| |
| # unset source-address6
| |
| # set source-address6-negate disable
| |
| # set groups "gr-ssl-vpn-tunnel"
| |
| # set portal "tunnel-acces.local"
| |
| # set realm tunnel
| |
| # set client-cert disable
| |
| # set cipher any
| |
| # set auth local
| |
| # next
| |
| # edit 2
| |
| # set source-interface "wan1"
| |
| # set source-address "all"
| |
| # set source-address-negate disable
| |
| # unset source-address6
| |
| # set source-address6-negate disable
| |
| # set users local
| |
| # set groups "gr-ssl-vpn-portal"
| |
| # set portal "web-acces.local"
| |
| # unset realm
| |
| # set client-cert disable
| |
| # set cipher any
| |
| # set auth local
| |
| # next
| |
| # end
| |
| # end
| |
|
| |
| '''Firewall Policy""
| |
|
| |
| Nachträglich muss für die Konfiguation eine Firewall Policy implementiert werden:
| |
|
| |
| [[Datei:Fortinet-1161.jpg]]
| |
|
| |
| === Wie kann ich ein SSL-VPN Portal betreffend Authentifizierung anhand der Source einschränken? ===
| |
|
| |
| Unter FortiOS 5.0 kann ein SSL-VPN Portal anhand der definierten Source in der "Identity-Based Policy" eingeschränkt werden. Dazu folgendes Beispiel:
| |
|
| |
| [[Datei:Fortinet-380.jpg]]
| |
|
| |
| NOTE Soll die Source in diesem Beispiel eingeschränkt werden so muss unter "Remote Address" ein entsprechender IP Range definiert
| |
| werden. Wenn ein zweites Portal konfiguriert wird mit einer anderen Einschränkung dh. IP Range so muss einfach eine zusätzliche
| |
| "Identity Policy" erstellt werden mit der Einschränkung.
| |
|
| |
| Unter FortiOS 5.2 gibt es diese "Identity Based Policy" nicht mehr und ein SSL-VPN Portal wird nicht mehr über die Reguläre Policy definiert resp. konfiguriert. Neu wird das SSL-VPN Portal über folgende Position konfiguriert:
| |
|
| |
| VPN > SSL > Settings
| |
|
| |
| [[Datei:Fortinet-1150.jpg]]
| |
|
| |
| Die Authentication Rule resp. Portal Mapping wird im Abschnitt "Authentication/Portal Mapping" konfiguriert. In diesem Abschnitt wird das entsprechende "Web Portal" sowie die entsprechende "Gruppe" zueinander "gemappt". Möchte man nun eine Einschränkung anhand der Source Adressen durchführen kann dies anhand dieser Position auf Kommandozeile durchgeführt werden:
| |
|
| |
| Gruppe 1 "ssl-vpn-group-1" soll WebPortal benutzen "ssl-vpn-portal-1" und nur von der Source "net-ssl-vpn-group-1"
| |
| Gruppe 2 "ssl-vpn-group-2" soll WebPortal benutzen "ssl-vpn-portal-2" und nur von der Source "net-ssl-vpn-group-2"
| |
|
| |
| Der zuständige Befehl um die "Authentication/Portal Mapping" zu konfigurieren ist "config authentication rule". Durch diesen Befehl kann die Source anhand eines IP Ranges eingeschränkt werden. Dabei ist zu berücksichtigen, dass in der "Authentication/Portal Mapping" nach "top down first match winns" evaluiert wird.
| |
|
| |
| # config vpn ssl settings
| |
| # set reqclientcert disable
| |
| # set sslv2 disable
| |
| # set sslv3 enable
| |
| # set tlsv1-0 enable
| |
| # set tlsv1-1 enable
| |
| # set tlsv1-2 enable
| |
| # set ssl-big-buffer disable
| |
| # set ssl-insert-empty-fragment enable
| |
| # set ssl-client-renegotiation disable
| |
| # set force-two-factor-auth disable
| |
| # set servercert self-sign
| |
| # set algorithm default
| |
| # set idle-timeout 1800
| |
| # set auth-timeout 28800
| |
| # set auto-tunnel-static-route disable
| |
| # set tunnel-ip-pools "[Gebe den entsprechenden IP Range für IP Pool an für den Tunnel Mode]"
| |
| # set dns-suffix mydomain1.local
| |
| # set dns-server1 [IPv4 Adresse für den DNS Server]
| |
| # set dns-server2 [IPv4 Adresse für den DNS Server]
| |
| # set wins-server1 0.0.0.0
| |
| # set wins-server2 0.0.0.0
| |
| # set route-source-interface disable
| |
| # set url-obscuration disable
| |
| # set http-compression disable
| |
| # set http-only-cookie enable
| |
| # set port 10443
| |
| # set port-precedence enable
| |
| # set auto-tunnel-static-route disable
| |
| # set source-interface "[Interface auf dem das SSL-VPN Portal zur Verfügug gestellt werden soll zB wan1]"
| |
| # set source-address "all"
| |
| # set source-address-negate disable
| |
| # set source-address6 "all"
| |
| # set default-portal "[Name des Default SSL-VPN Portal"
| |
| # config authentication-rule
| |
| # edit 1
| |
| # set source-interface [Interface ISP zB "wan1"]
| |
| # set source-address [net-ssl-vpn-group-1]
| |
| # set source-address-negate disable
| |
| # unset source-address6
| |
| # set source-address6-negate disable
| |
| # set groups "ssl-vpn-group-1"
| |
| # set portal "ssl-vpn-portal-1"
| |
| # unset realm
| |
| # set client-cert disable
| |
| # set cipher any
| |
| # set auth local
| |
| # next
| |
| # edit 2
| |
| # set source-interface [Interface ISP zB "wan1"]
| |
| # set source-address [net-ssl-vpn-group-2]
| |
| # set source-address-negate disable
| |
| # unset source-address6
| |
| # set source-address6-negate disable
| |
| # set groups "ssl-vpn-group-2"
| |
| # set portal "ssl-vpn-portal-2"
| |
| # unset realm
| |
| # set client-cert disable
| |
| # set cipher any
| |
| # set auth local
| |
| # next
| |
| # end
| |
| # end
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Das Default SSL-VPN Portal wird in dem Abschnitt "Authentication/Portal Mapping" als letzte Position eingefügt und somit das in
| |
| diesem Abschnitt "top down first match wins" gilt dieses SSL-VPN Portal für alles das nicht evauluiert werden kann. Zusätzlich zur
| |
| Einschränkung der Source Adresse kann ein "realm" gesetzt werden. Diese Funktion ist jedoch per Standard deaktiviert und kann
| |
| folgendermassen im Web Mgmt. Interface aktiviert werden:
| |
|
| |
| System > Config > Features > Show More > SSL-VPN Realms
| |
|
| |
| Nach Aktivierung des Features steht die Funktion "Realms" unter folgender Position zur Verfügung:
| |
|
| |
| VPN > SSL > Realms
| |
|
| |
| === Wie kann ich ein SSL-VPN Portal zu einem "realm", zu einer bestimmten Gruppe sowie zu einem bestimmten Interface zuweisen? ===
| |
|
| |
| Diese Konfiguration ist unter FortiOS 5.0 nicht möglich und wird nur für FortiOS 5.2 unterstützt. Grundlage für diese
| |
| Konfiguration ist folgendes Beispiel:
| |
|
| |
| Gruppe 1 "ssl-vpn-group-1" soll WebPortal benutzen "ssl-vpn-portal-1" und nur von der Source "net-ssl-vpn-group-1" sowie realm "group-1" auf interface "wan1"
| |
| Gruppe 2 "ssl-vpn-group-2" soll WebPortal benutzen "ssl-vpn-portal-2" und nur von der Source "net-ssl-vpn-group-2" sowie realm "group-2" auf interface "wan2"
| |
|
| |
| Somit müssen folgende Schritte durchgeführt werden um diese Konfiguration durchzuführen:
| |
|
| |
| <big>'''Schritt 1:'''</big>
| |
|
| |
| Konfiguriere die zwei benötigten Gruppen:
| |
|
| |
| # config user group
| |
| # edit [Name der Gruppe "ssl-vpn-group-1"]
| |
| # set member [Name des/der User]
| |
| # end
| |
|
| |
| # config user group
| |
| # edit [Name der Gruppe "ssl-vpn-group-2"]
| |
| # set member [Name des/der User]
| |
| # end
| |
|
| |
| <big>'''Schritt 2:'''</big>
| |
|
| |
| Konfiguriere die zwei benötigten SSL-VPN Portale:
| |
|
| |
| # config vpn ssl web portal
| |
| # edit [Name des Web Portals zB "ssl-vpn-portal-1"]
| |
| # set tunnel-mode disable
| |
| # set ipv6-tunnel-mode disable
| |
| # set web-mode enable
| |
| # set cache-cleaner disable
| |
| # set host-check none
| |
| # set limit-user-logins enable
| |
| # set mac-addr-check disable
| |
| # set os-check disable
| |
| # set virtual-desktop disable
| |
| # set auto-prompt-mobile-user-download disable
| |
| # set display-bookmark enable
| |
| # set user-bookmark enable
| |
| # set config bookmark-group
| |
| # set edit "Intranet-Kategorie"
| |
| # set config bookmarks
| |
| # set edit "Intranet"
| |
| # set set description "Intranet Site"
| |
| # set set url "www.mydomain.intra"
| |
| # set end
| |
| # set display-connection-tools enable
| |
| # set display-forticlient-download disable
| |
| # set display-history enable
| |
| # set display-history-limit 10
| |
| # set display-status enable
| |
| # set heading "Welcome to mydomain.ch"
| |
| # set page-layout double-column
| |
| # unset redir-url
| |
| # set theme blue
| |
| # set custom-lang en
| |
| # end
| |
|
| |
| # config vpn ssl web portal
| |
| # edit [Name des Web Portals zB "ssl-vpn-portal-2"]
| |
| # set tunnel-mode disable
| |
| # set ipv6-tunnel-mode disable
| |
| # set web-mode enable
| |
| # set cache-cleaner disable
| |
| # set host-check none
| |
| # set limit-user-logins enable
| |
| # set mac-addr-check disable
| |
| # set os-check disable
| |
| # set virtual-desktop disable
| |
| # set auto-prompt-mobile-user-download disable
| |
| # set display-bookmark enable
| |
| # set user-bookmark enable
| |
| # set config bookmark-group
| |
| # set edit "Intranet-Kategorie"
| |
| # set config bookmarks
| |
| # set edit "Intranet"
| |
| # set set description "Intranet Site"
| |
| # set set url "www.mydomain.intra"
| |
| # set end
| |
| # set display-connection-tools enable
| |
| # set display-forticlient-download disable
| |
| # set display-history enable
| |
| # set display-history-limit 10
| |
| # set display-status enable
| |
| # set heading "Welcome to mydomain.ch"
| |
| # set page-layout double-column
| |
| # unset redir-url
| |
| # set theme blue
| |
| # set custom-lang en
| |
| # end
| |
|
| |
| <big>'''Schritt 3:'''</big>
| |
|
| |
| Erstelle die nötigen 2 "realms"
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Die Funktion "realm" ist per Standard auf dem Web Mgmt. Interface ausgeblendet kann jedoch aktiviert werden:
| |
|
| |
| System > Config > Features > Show More > SSL-VPN Realms
| |
|
| |
| Nach Aktivierung des Features steht die Funktion "Realms" unter folgender Position zur Verfügung:
| |
|
| |
| VPN > SSL > Realms
| |
|
| |
| # config vpn ssl web realm
| |
| # edit [Name des Realms zB "group-1"]
| |
| # set max-concurrent-user 100
| |
| <nowiki># set login-page "<html>
| |
| <head>
| |
| <meta http-equiv=\"Content-Type\" content=\"text/html; charset=UTF-8\">
| |
| <title>
| |
| login
| |
| </title>
| |
| <meta http-equiv=\"Pragma\" content=\"no-cache\">
| |
| <meta http-equiv=\"cache-control\" content=\"no-cache\">
| |
| <meta http-equiv=\"cache-control\" content=\"must-revalidate\">
| |
| <link href=\"/sslvpn/css/login.css\" rel=\"stylesheet\" type=\"text/css\">
| |
| <script type=\"text/javascript\">
| |
| if (top && top.location != window.location) top.location = top.location;
| |
| if (window.opener && window.opener.top) {
| |
| window.opener.top.location = window.opener.top.location;
| |
| self.close();
| |
| }
| |
| </script>
| |
| </head>
| |
| <body class=\"main\">
| |
| <center>
| |
| <table width=\"100%\" height=\"100%\" align=\"center\" class=\"container\" valign=\"middle\" cellpadding=\"0\" cellspacing=\"0\">
| |
| <tr valign=middle>
| |
| <td>
| |
| <form action=\"%%SSL_ACT%%\" method=\"%%SSL_METHOD%%\" name=\"f\" autocomplete=\"off\">
| |
| <table class=\"list\" cellpadding=10 cellspacing=0 align=center width=400 height=180>
| |
| <tr class=\"dark\">
| |
| <td colspan=2>
| |
| <b>
| |
| <br>
| |
| WARNING: REALM 1
| |
| <br>
| |
| <p style=\"text-align:justify; margin-left:0px; margin-right:0px\">
| |
| 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! </p>
| |
| <br>
| |
| </b>
| |
| </td>
| |
| </tr>
| |
| %%SSL_LOGIN%%
| |
| <tr>
| |
| <td>
| |
| </td>
| |
| <td id=login>
| |
| <input type=button name=login_button id=login_button value=\"Login\" onClick=\"try_login()\" border=0>
| |
| </td>
| |
| </tr>
| |
| </table>
| |
| %%SSL_HIDDEN%%
| |
| </form>
| |
| </td>
| |
| </tr>
| |
| </table>
| |
| </center>
| |
| </body>
| |
| <script>
| |
| document.forms[0].username.focus();
| |
| </script>
| |
| </html>"
| |
| </nowiki>
| |
| # end
| |
|
| |
| # config vpn ssl web realm
| |
| # edit [Name des Realms zB "group-2"]
| |
| # set max-concurrent-user 100
| |
| <nowiki># set login-page "<html>
| |
| <head>
| |
| <meta http-equiv=\"Content-Type\" content=\"text/html; charset=UTF-8\">
| |
| <title>
| |
| login
| |
| </title>
| |
| <meta http-equiv=\"Pragma\" content=\"no-cache\">
| |
| <meta http-equiv=\"cache-control\" content=\"no-cache\">
| |
| <meta http-equiv=\"cache-control\" content=\"must-revalidate\">
| |
| <link href=\"/sslvpn/css/login.css\" rel=\"stylesheet\" type=\"text/css\">
| |
| <script type=\"text/javascript\">
| |
| if (top && top.location != window.location) top.location = top.location;
| |
| if (window.opener && window.opener.top) {
| |
| window.opener.top.location = window.opener.top.location;
| |
| self.close();
| |
| }
| |
| </script>
| |
| </head>
| |
| <body class=\"main\">
| |
| <center>
| |
| <table width=\"100%\" height=\"100%\" align=\"center\" class=\"container\" valign=\"middle\" cellpadding=\"0\" cellspacing=\"0\">
| |
| <tr valign=middle>
| |
| <td>
| |
| <form action=\"%%SSL_ACT%%\" method=\"%%SSL_METHOD%%\" name=\"f\" autocomplete=\"off\">
| |
| <table class=\"list\" cellpadding=10 cellspacing=0 align=center width=400 height=180>
| |
| <tr class=\"dark\">
| |
| <td colspan=2>
| |
| <b>
| |
| <br>
| |
| WARNING: REALM 2
| |
| <br>
| |
| <p style=\"text-align:justify; margin-left:0px; margin-right:0px\">
| |
| 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! </p>
| |
| <br>
| |
| </b>
| |
| </td>
| |
| </tr>
| |
| %%SSL_LOGIN%%
| |
| <tr>
| |
| <td>
| |
| </td>
| |
| <td id=login>
| |
| <input type=button name=login_button id=login_button value=\"Login\" onClick=\"try_login()\" border=0>
| |
| </td>
| |
| </tr>
| |
| </table>
| |
| %%SSL_HIDDEN%%
| |
| </form>
| |
| </td>
| |
| </tr>
| |
| </table>
| |
| </center>
| |
| </body>
| |
| <script>
| |
| document.forms[0].username.focus();
| |
| </script>
| |
| </html>" </nowiki>
| |
| # end
| |
|
| |
| <big>'''Schritt 4:'''</big>
| |
|
| |
| Konfiguriere die IP-Pool Adressen für die jeweilige Gruppe:
| |
|
| |
| # config firewall address
| |
| # edit [Name des IP-Pools zB "net-ssl-vpn-group-1"]
| |
| # set type ipmask
| |
| # set subnet [IP Range IP Pool für "net-ssl-vpn-group-1" zB "192.18.1.0/24"]
| |
| # end
| |
|
| |
| # config firewall address
| |
| # edit [Name des IP-Pools zB "net-ssl-vpn-group-2"]
| |
| # set type ipmask
| |
| # set subnet [IP Range IP Pool für "net-ssl-vpn-group-2" zB "192.18.2.0/24"]
| |
| # end
| |
|
| |
| <big>'''Schritt 5:'''</big>
| |
|
| |
| Konfiguriere die SSL-VPN Settings:
| |
|
| |
| # config vpn ssl settings
| |
| # set reqclientcert disable
| |
| # set sslv2 disable
| |
| # set sslv3 enable
| |
| # set tlsv1-0 enable
| |
| # set tlsv1-1 enable
| |
| # set tlsv1-2 enable
| |
| # set ssl-big-buffer disable
| |
| # set ssl-insert-empty-fragment enable
| |
| # set ssl-client-renegotiation disable
| |
| # set force-two-factor-auth disable
| |
| # set servercert self-sign
| |
| # set algorithm default
| |
| # set idle-timeout 1800
| |
| # set auth-timeout 28800
| |
| # set auto-tunnel-static-route disable
| |
| # set tunnel-ip-pools "[Gebe den entsprechenden IP Range für IP Pool an für den Tunnel Mode oder "unset"]"
| |
| # set dns-suffix mydomain1.local
| |
| # set dns-server1 [IPv4 Adresse für den DNS Server]
| |
| # set dns-server2 [IPv4 Adresse für den DNS Server]
| |
| # set wins-server1 0.0.0.0
| |
| # set wins-server2 0.0.0.0
| |
| # set route-source-interface disable
| |
| # set url-obscuration disable
| |
| # set http-compression disable
| |
| # set http-only-cookie enable
| |
| # set port 10443
| |
| # set port-precedence enable
| |
| # set auto-tunnel-static-route disable
| |
| # set source-interface "[Interface auf dem das SSL-VPN Portal zur Verfügug gestellt werden soll zB "wan1" "wan2"]"
| |
| # set source-address "all"
| |
| # set source-address-negate disable
| |
| # set source-address6 "all"
| |
| # set default-portal "[Name des Default SSL-VPN Portal]"
| |
| # config authentication-rule
| |
| # edit 1
| |
| # set source-interface [Interface ISP zB "wan1"]
| |
| # set source-address [net-ssl-vpn-group-1]
| |
| # set source-address-negate disable
| |
| # unset source-address6
| |
| # set source-address6-negate disable
| |
| # set groups "ssl-vpn-group-1"
| |
| # set portal "ssl-vpn-portal-1"
| |
| # set realm "group-1"
| |
| # set client-cert disable
| |
| # set cipher any
| |
| # set auth local
| |
| # next
| |
| # edit 2
| |
| # set source-interface [Interface ISP zB "wan2"]
| |
| # set source-address [net-ssl-vpn-group-2]
| |
| # set source-address-negate disable
| |
| # unset source-address6
| |
| # set source-address6-negate disable
| |
| # set groups "ssl-vpn-group-2"
| |
| # set portal "ssl-vpn-portal-2"
| |
| # set realm group-2
| |
| # set client-cert disable
| |
| # set cipher any
| |
| # set auth local
| |
| # next
| |
| # end
| |
| # end
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Der Abschnitt "authentication-rule" überschreibt die globalen Settings für "config vpn ssl settings"!
| |
|
| |
| <big>'''Schritt 6:'''</big>
| |
|
| |
| Jetzt muss eine entsprechende Firewall Policy konfiguriert werden mit folgender Konfiguration:
| |
|
| |
| Source Interface: ssl.root
| |
| Source Address: net-ssl-vpn-group-1
| |
| net-ssl-vpn-group-2
| |
| Source User(s): net-ssl-vpn-group-1
| |
| net-ssl-vpn-group-2
| |
| Outgoing Interface: [Name des internen Interface zB "internal"]
| |
| Destination Address: [Subnet/Address Objekt des internen Interfaces]
| |
| Schedule: always
| |
| Service: [Das/die entsprechende/n Service Objekte oder auch "ALL"]
| |
|
| |
| Nun kann auf "wan1" verbunden werden anhand des "realms" und es wird das entsprechende SSL-VPN Portal "ssl-vpn-portal-1" zugewiesen sowie der entsprechende IP Pool "net-ssl-vpn-group-1". Ebenso muss mit einem User aus der Gruppe "net-ssl-vpn-group-1" ein Login durchgeführt werden.
| |
| Das gleiche gilt Analog für "wan2" jedoch mit seperatem SSL-VPN Portal, IP-Pool sowie Gruppe.
| |
|
| |
| === Wieso funktioniert ab FortiOS 5 mein SSL-VPN auch ohne die IP Pool Route und/oder Policy zu implementieren? ===
| |
|
| |
| Nun ab FortiOS 5.0 hat Fortinet zwei neue Optionen eingeführt dh. diese implementieren für SSL-VPN Funktion eine automatische Konfiguration in zwei Bereichen:
| |
|
| |
| --> Routen den IP Pool automatisch auf das ssl.root Interface
| |
| --> Implementieren automatisch eine "Local In Policy" damit der Traffic von ssl.root auf Internal erlaubt wird (Gilt nicht für FortiOS 5.2)
| |
|
| |
| Die zuständigen Optionen für die Automatisierung sind die folgenden:
| |
|
| |
| # config vpn ssl settings
| |
| # set auto-tunnel-policy [enable | disable]
| |
| # set auto-tunnel-static-route [enable | disable]
| |
| # end
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Die Option "auto-tunnel-policy" steht für FortiOS 5.2 nicht mehr zur Verfügung!
| |
|
| |
| Bedeutet somit folgendes:
| |
|
| |
| auto-tunnel-policy (Automatische Policy "source=ssl.root to destination=internal")
| |
| auto-tunnel-static-route (Automatische Route für den definierten IP-Pool)
| |
|
| |
| Das Unschöne an der ganzen Sache ist folgende:
| |
|
| |
| --> Ueber den Routing Monitor im Gui wird keine entsprechende Route angezeigt/gelistet!
| |
| --> In der Local In Policy wird kein entsprechender Eintrag angzeigt/gelistet für die Policy!
| |
|
| |
| Wir empfehlen diese beiden Optionen zu deaktivieren und wie bis anhin die Implementierung gemäss nachfolgenden Artikel durchzuführen. Der Grund liegt in der Transparenz sowie Granularität dh. mehrere Gruppen, IP Pools, restriktive Rules etc.:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_konfiguriere_ich_unter_FortiOS_5.0_ein_SSL-VPN_Portal.2FTunnel_auf_einer_Fortigate.3F]]
| |
|
| |
| === Wie kann ich für das Active Directory (LDAP) eine Passwort Expyring/Renewal Nachricht für SSL-VPN konfigurieren? ===
| |
|
| |
| Die Funktion des Active Directory Passwort Expyring/Renewal muss in der LDAP Konfiguration auf der Fortigate aktiviert werden (Per Standard deaktiviert). Für nähere Informationen siehe Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_kann_ich_f.C3.BCr_eine_Active_Directory_.28LDAP.29_Anbindung_ein_Passwort_Expyring_Renewal_Nachricht_konfigurieren.3F]]
| |
|
| |
| === Kann ich für ein SSL-VPN Portal innerhalb der "bookmarks" eine VIP (NAT) Adresse konfigurieren? ===
| |
|
| |
| Wenn man ein SSL-VPN Portal erstellt und den Usern die das SSL-VPN Portal benützen ein "bookmark" (Link zu einem Server) zur Verfügung stellen möchte zB für einen WebServer kann keine VIP (NAT) Adresse benützt werden. Dies ist für folgende FortiOS nicht möglich:
| |
|
| |
| FortiOS 4.x
| |
| FortiOS 5.0
| |
| FortiOS 5.2
| |
|
| |
| Der Workaround ist relativ einfach dh. man definiert die real IP des Servers als "bookmark". Eine weitere Möglichkeit ist anstelle des Portal Modes den Tunnel Mode zu benutzen. Dabei ist jedoch folgendes zu beachten:
| |
|
| |
| Ab FortiOS 5.2.2 kann ein VIP (NAT) Objekt nur dann in einer Firewall Policy Rule selektiert werden wenn für die definierte "Tunnel Mode"
| |
| Gruppe der User nicht zusätzlich der "Portal Mode" definiert wurde. Somit, wenn einer Gruppe "nur" der "Tunnel Mode" zugewiesen wurde ohne
| |
| "Portal Mode" kann in der entsprechenden Firewall Policy Rule für die entsprechende Gruppe für "Tunnel Mode" ein VIP (NAT) Objekt benutzt
| |
| werden!
| |
|
| |
| === Wie kann ich unter FortiOS 5.2 innerhalb des SSL-VPN Portal für das "connection tool" die verschiedenen Services FTP, RDP konfigurieren? ===
| |
|
| |
| Ausgehend von FortiOS 5.0 war es möglich innerhalb eines SSL-VPN Portals (nicht "Tunnel Mode") die Services wie FTP, RDP usw. für das "connection tool" zu definieren. Durch diese Konfiguration wurde definiert welche Services im "connection tool" für das entsprechene SSL-VPN Portal dem entsprechenden User zur Verfügung gestellt wird. Dies wurde folgendermassen durchgeführt:
| |
|
| |
| # config vpn ssl web portal
| |
| # edit [Name des entsprechenden SSL-VPN Portal Mode]
| |
| # set allow-access [Definiertr Global für die "bookmarks" die Services wie zB web ftp smb telnet ssh vnc rdp ping citrix rdpnative portforward]
| |
| # set heading [Definiert einen Header zB "Welcome to mydomain.ch"]
| |
| # set page-layout double-column
| |
| # set allow-user-bookmark [enable | disable]
| |
| # set mac-addr-check [enable | disable]
| |
| # set auto-prompt-mobile-user-download [enable | disable]
| |
| # set limit-user-logins [enable | disable]
| |
| # set host-check none
| |
| # set virtual-desktop [enable | disable]
| |
| # set os-check [enable | disable]
| |
| # set cache-cleaner [enable | disable]
| |
| # config widget
| |
| # edit 1
| |
| # set name "Session Information"
| |
| # set type info
| |
| # set column one
| |
| # set collapse disable
| |
| # next
| |
| # edit 3
| |
| # set name "Bookmarks"
| |
| # set type bookmark
| |
| # set column one
| |
| # set collapse disable
| |
| # set allow-apps web ftp smb telnet ssh vnc rdp ping citrix rdpnative portforward
| |
| # next
| |
| # edit 4
| |
| # set name "Connection Tool"
| |
| # set type tool
| |
| # set column two
| |
| # set collapse disable
| |
| # set allow-apps [Definiert die erlaubten Services im "connection tool" wie zB web ftp smb telnet ssh vnc rdp ping citrix rdpnative portforward]
| |
| # next
| |
| # edit 5
| |
| # set name "Login History"
| |
| # set type history
| |
| # set column one
| |
| # set collapse disable
| |
| # set display-limit 5
| |
| # next
| |
| # end
| |
| # end
| |
|
| |
| Nun diese Möglichkeit der Definition der Service die zur Verfügung stehen sollen im "connection tool" existiert unter FortiOS 5.2 nicht mehr. Dabei stellt sich die Frage wie denn dies zu Konfigurieren ist? Die Lösung ist denkbar einfach dh. die Konfiguration der Services für das "connection tool" wird innerhalb des Firewall Policy Rule durchgeführt für die entsprechende SSL-VPN Portal Mode Firewall Policy Rule. Dies bedeutet: Für den Service innerhalb der Firewall Policy Rule für SSL-VPN Portal Mode wird der entsprechende Service definiert wie zB FTP, RDP, SMP usw. Eine Definition über "config vpn ssl web portal" steht unter FortiOS 5.2 nicht mehr zur Verfügung.
| |
|
| |
| === Wie kann ich ein Timeout für SSL-VPN Verbindungen konfigurieren? ===
| |
|
| |
| Es kann anhand nachfolgenden Kommandos ein Timeout für SSL-VPN Verbindungen resp. User konfiguriert werden. Dies bedeutet: Wenn ein User länger verbunden ist sprich "idle" als dieses Timeout wird er durch das System automatisch (forced) ausgeloggt. Um die Konfiguration durchzuführen führe folgendes unter der CLI durch:
| |
|
| |
| # config vpn ssl settings
| |
| # set auth-timeout [Sekunden zB 18000]
| |
| # end
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Mögliche Werte für das Timeout sind "0" bis "259 200" Sekunden (3 Tage). Wenn das Timeout auf "0" gesetzt wird
| |
| so wird das Timeout komplett deaktiviert!
| |
|
| |
| Diese Konfiguration sollte nicht verwechselt werden mit dem "idle-timeout". Dies bedeutet das "idle-timeout" stellt den Wert dar für das Timeout wenn der Client das Portal nicht benutzt und somit in das "idle-timeout" läuft. Um dieses "idle-timeout" unter der CLI zu setzen benütze folgendes Kommando:
| |
|
| |
| # config vpn ssl settings
| |
| # set idle-timeout [Sekunden zB 300]
| |
| # end
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Mögliche Werte für das Timeout sind "0" bis "259 200" Sekunden (3 Tage). Wenn das Timeout auf "0" gesetzt wird
| |
| so wird das Timeout komplett deaktiviert! Es ist empfehlenswert das "idle-timeout" möglichst tief zu halten. Per Standard
| |
| ist dieses auf 300 Sekunden (5 Minuten) gesetzt!
| |
|
| |
| === Gibt es für IOS und Android einen SSL VPN Client? ===
| |
|
| |
| Die beiden offiziellen Apps von Fortinet für IPhone und Android unterstützen in der 5.0 Version ausschliesslich das Browsen dh. wenn man verbunden ist mit dem APP kann der aufgebaute VPN Tunnel nur für das Browsen benutzt werden deshalb wird dieser Client auch "SSL proxy VPN connection agent" genannt. Neu unter FortiOS 5.2 unterstützt - im Gegensatz zu IOS - Android ebenfalls eine IPSec Verbindung (siehe 5.2 User Guide). Will man eine klassische IPSec Verbindung anhand eines IOS Gerätes durchführen so ist das mit dem Cisco Client (Unity Client) möglich sowie mit der eingebauten VPN Funktion eines IPhones. Nachfolgende Links geben Auskunft wie so eine Verbindung zu konfigurieren ist:
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Für die Konfiguration eines IOS Devices anhand des "build-in" Cisco Client's siehe nachfolgenden Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Gibt_es_eine_M.C3.B6glichkeit_mit_einem_IPhone.2FIPad_.C3.BCber_IPSec_eine_Verbindung_aufzubauen_zu_einer_Fortigate.3F]]
| |
|
| |
| <big>'''Für Android:'''</big>
| |
| https://play.google.com/store/apps/details?id=com.fortinet.forticlient
| |
| http://www.fortinet.com/resource_center/product_downloads.html
| |
|
| |
| '''FortiOS 5.0'''
| |
| [[Datei:FortiClient-v5.0.1-Android-Release-Notes.pdf]]
| |
| [[Datei:FortiClient-v5.0.2-Android-Release-Notes.pdf]]
| |
| [[Datei:FortiClient-v5.0.3-Android-Release-Notes.pdf]]
| |
|
| |
| [[Datei:forticlient-android-user-guide.pdf]]
| |
| [[Datei:connecting-an-Android-to-a-FortiGate-with-SSL-VPN.pdf]]
| |
|
| |
| '''FortiOS 5.2'''
| |
| [[Datei:FortiClient-v5.2.0-Android-Release-Notes.pdf]]
| |
| [[Datei:FortiClient-v5.2.1-Android-Release-Notes.pdf]]
| |
| [[Datei:FortiClient-v5.2.2-Android-Release-Notes.pdf]]
| |
| [[Datei:FortiClient-v5.2.3-Android-Release-Notes.pdf]]
| |
| [[Datei:FortiClient-v5.2.6-Android-Release-Notes.pdf]]
| |
|
| |
| [[Datei:FortiClient-vpn-v5.2.2-Android-Release-Notes.pdf]]
| |
| [[Datei:FortiClient-vpn-v5.2.1-Android-Release-Notes.pdf]]
| |
| [[Datei:FortiClient-vpn-v5.2.3-Android-Release-Notes.pdf]]
| |
| [[Datei:FortiClient-vpn-v5.2.6-Android-Release-Notes.pdf]]
| |
|
| |
| [[Datei:forticlient-android-user-guide-52.pdf]]
| |
| [[Datei:forticlient-android-user-guide-524.pdf]]
| |
| [[Datei:forticlient-android-user-guide-526.pdf]]
| |
|
| |
| <big>'''Für IOS:'''</big>
| |
| http://itunes.apple.com/us/app/fortimobile-ssl-vpn/id345361028?mt=8
| |
| http://www.fortinet.com/resource_center/product_downloads.html
| |
|
| |
| '''FortiOS 5.0'''
| |
| [[Datei:FortiClient-v5.0-Patch-Release-1-iOS-Release-Notes.pdf]]
| |
| [[Datei:FortiClient-v5.0-Patch-Release-2-iOS-Release-Notes.pdf]]
| |
| [[Datei:FortiClient-v5.0-Patch-Release-3-iOS-Release-Notes.pdf]]
| |
|
| |
| [[Datei:forticlient-v5-ios-quickstart.pdf]]
| |
|
| |
| '''FortiOS 5.2'''
| |
| [[Datei:forticlient-v5.2.0-ios-release-notes.pdf]]
| |
|
| |
| [[Datei:forticlient-ios-user-guide-52.pdf]]
| |
|
| |
| === Wie kann ich auf einer FortiGate das SSL-VPN Package unter FortiGuard "up-to-date" bringen? ===
| |
|
| |
| Auf einer FortiGate unter nachfolgender Position wird ein SSL-VPN Package zur Verfügung gestellt. Dieses Package kann manuell auf den neusten Stand gebracht werden:
| |
|
| |
| System -> Settings -> FortiGuard -> Package Information SSL-VPN
| |
|
| |
| Wenn man dieses Package "up-to-date" bringen möchte kann man von der Support Site von Fortinet das entsprechende Package runterladen:
| |
|
| |
| https://support.fortinet.com/Download/FirmwareImages.aspx
| |
|
| |
| Im entsprechenden Verzeichnis dh. zB "/FortiGate/v5.00/5.2/5.2.4/VPN/SSLVPNTools/" kann das entsprechende Package runtergeladen werden sowie über die vorhergehende Position raufgeladen werden. Dabei ist zu beachten, das nur entweder ein 32bit oder ein 64bit Package raufgeladen werden kann. Das Packgage das raufgeladen wird, wird in das folgende Verzeichnis kopiert:
| |
|
| |
| # fnsysctl ls -l /var/log/package_cache/
| |
| -rw-r--r-- 1 0 0 Mon Jun 1 14:46:12 2015 1125 sslvpn_version.h
| |
| -rw-r--r-- 1 0 0 Mon Jun 1 14:46:11 2015 2906511 sslvpnclient.tar.gz
| |
|
| |
| Das Package das Standard existiert ist ein 64bit Package. Das File "sslvpn_version.h" kann mit folgenden Befehl eingesehen werden:
| |
|
| |
| # fnsysctl more /var/log/package_cache/sslvpn_version.h
| |
|
| |
| Wenn zB das Package "sslvpnclient64pkg_4.4.2317.tar.gz" raufgeladen wird so sieht man nach einer Kontrolle nicht den Namen dieses Package sondern wiederum:
| |
|
| |
| # fnsysctl ls -l /var/log/package_cache/
| |
| -rw-r--r-- 1 0 0 Thu Aug 13 15:49:12 2015 1125 sslvpn_version.h
| |
| -rw-r--r-- 1 0 0 Thu Aug 13 15:49:11 2015 2981238 sslvpnclient.tar.gz
| |
|
| |
| Wenn das File "sslvpn_version.h" mit dem nachfolgenden Befehl kontrolliert wird, gibt dieses die neue Version aus:
| |
|
| |
| # fnsysctl more /var/log/package_cache/sslvpn_version.h
| |
|
| |
| --------------- output sslvpn_version.h ---------------
| |
|
| |
| // version.h
| |
| //
| |
| // This file should be generated or updated by the build script
| |
| //
| |
| // All the project resource files should include this file rather than
| |
| // hardcode the version number
| |
| //
| |
| #define SSLVPN_MAJOR_RELEASE_NUM 4
| |
| #define SSLVPN_MINOR_RELEASE_NUM 0
| |
| #define SSLVPN_BUILD_NUM 2317
| |
| //
| |
| #define SSLVPN_MAJOR_RELEASE "4"
| |
| #define SSLVPN_MINOR_RELEASE "0"
| |
| #define SSLVPN_BUILD "2317"
| |
| //
| |
| #define SSLVPN_COMPANY_NAME_ID "Fortinet"
| |
| #define SSLVPN_COMPANY_NAME "Fortinet Inc."
| |
| #define SSLVPN_LEGAL_COPYRIGHT "2004 - 2014 Fortinet Inc. All rights reserved."
| |
| #define SSLVPN_LEGAL_COPYRIGHT_VALUE 2004 - 2014 Fortinet Inc. All rights reserved.
| |
| //
| |
| #define SSLVPN_VERSION_2PARTS SSLVPN_MAJOR_RELEASE "." SSLVPN_MINOR_RELEASE
| |
| #define SSLVPN_VERSION_3PARTS SSLVPN_MAJOR_RELEASE "." SSLVPN_MINOR_RELEASE "." SSLVPN_BUILD
| |
| #define SSLVPN_VERSION_4PARTS SSLVPN_MAJOR_RELEASE "." SSLVPN_MINOR_RELEASE "." SSLVPN_BUILD ".0"
| |
| //
| |
| #define SSLVPN_VERSION SSLVPN_VERSION_3PARTS
| |
| #define SSLVPN_TXT_VERSION SSLVPN_MAJOR_RELEASE"."\
| |
| SSLVPN_MINOR_RELEASE"."\
| |
| SSLVPN_BUILD
| |
|
| |
| --------------- output sslvpn_version.h ---------------
| |
|
| |
| Wenn ein Cluster betrieben wird und das entsprechende File über den Master raufgeladen wird so wird diese nicht automatisch zum Slave transferiert dh. es muss manuell auf dem Slave ebenfalls eingespielt werden.
| |
|
| |
| === Wie installiere ich für FortiClient für iOS (Apple) ein Zertifikat auf den entsprechenden Device? ===
| |
|
| |
| Das nachfolgenden Dokument gibt Auskunft wie ein Zertifikat zu erstellen ist auf einer FortiGate und dieses auf einem iOS (Apple) Device installiert wird:
| |
|
| |
| [[Datei:provision-certificates-to-ios-devices-technical-note.pdf]]
| |
|
| |
| Desweiteren stehen und den Dokumentationen weitere Dokumente zur Verfügung:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wo_findet_ich_die_Dokumente_wie_Datasheets.2C_Quick_Start_Guide.2C_User_Guide_etc._.3F]]
| |
|
| |
| === Kann ich den SSL Traffic betreffend encryption/decryption optimieren und beschleunigen? ===
| |
|
| |
| Dies ist unter Umständen möglich (Ab FortiOS 5.0.3)! Eine FortiGate führt per Standard die Encryption/Decryption (Entschlüsselung/Verschlüsselung) andhand der CP7 oder CP8 FortiASIC Prozessoren durch. Wenn die FortiGate einer hohen Belastung ausgesetzt ist dh. durch eine hohe Anzahl von SSL Traffic und die eingesetzte FortiGate über mehr als 4 CPU's verfügt, kann die SSL Encryption/Decryption Optimiert werden. Dies geschieht indem der FortiGate mitgeteilt wird "WIE" der SSL Traffic zum CPU gesendet werden soll sprich wieviele "worker" bereitgestellt werden. Bei "worker" handelt es sich effektiv um Prozessoren. Um festzustellen über wieviele CPU's die eingesetzte FortiGate verfügt benütze folgende Befehl:
| |
|
| |
| # get hardware cpu
| |
|
| |
| Wenn die FortiGate über mehr als 4 CPU's verfügt können die entsprechenden "worker" (CPU) die für die SSL Verarbeitung benützt werden sollen konfiguriert werden:
| |
|
| |
| # config system global
| |
| # set optimize-ssl [enable oder disable]
| |
| # set ssl-worker-count [Anzahl der "worker" (CPU)]
| |
| # end
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Wenn die Anzahl der "worker" (CPU) erhöht wird sollte das System zu Beginn übewacht
| |
| werden um festzustellen ob die Anzahl der "worker" andere Funktionen auf dem System
| |
| nicht beeinträchtigen!
| |
|
| |
| === Wie kann ich den SSL Traffic betreffend Security zB TLS 1.0, SSLv2 konfigurieren und absichern? ===
| |
|
| |
| Wenn man mit einem SSL-VPN Portal resp. Tunnel Mode arbeitet sind die folgenden Einstellungen relevant um den SSL-VPN Traffic auf bestimmte Versionen von TLS und/oder SSL zu beeinflussen:
| |
|
| |
| sslv2 : disable
| |
| sslv3 : enable
| |
| tlsv1-0 : enable
| |
| tlsv1-1 : enable
| |
| tlsv1-2 : enable
| |
| algorithm : default
| |
|
| |
| Diese Einstellungen stellen den Standard dar. Wenn man eine Uebersicht erlangen möchte was dies genau bedeutet und welche "cipher" aktiv sind durch "algorithm" kann dies anhand eines Scripts überprüft werden. Erstelle auf einem Linux ein File "cipherscan" und fülle es mit dem Inhalt der Datei "Cipherscan.txt" ab:
| |
|
| |
| # mkdir /opt/scripts
| |
| # vi /opt/scripts/cipherscan
| |
| # chown root:root /opt/scripts/cipherscan
| |
| # chmod 700 /opt/scripts/cipherscan
| |
|
| |
| [[Datei:Cipherscan.txt]]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Weitere Scripte auf für Windows und Anweisung siehe Link https://github.com/jvehent/cipherscan. Eine
| |
| andere Möglichkeit einen Scan durchzuführen ist folgender Link zu benutzen:
| |
|
| |
| https://www.ssllabs.com/ssltest/
| |
|
| |
| Nun führe den Scan aus und berücksichtige das die IP sowie der Port der benutzt wird im Kommando Analog für das SSL-VPN Portal Zugriff benutzt wird sowie im Allgemeinen der Zugriff vom Linux Server erlaubt wird:
| |
|
| |
| # /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,1024bits None
| |
| 5 DHE-RSA-AES256-SHA256 TLSv1.2 DH,1024bits None
| |
| 6 DHE-RSA-AES256-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2 DH,1024bits None
| |
| 7 DHE-RSA-CAMELLIA256-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2 DH,1024bits 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,1024bits None
| |
| 16 DHE-RSA-AES128-SHA256 TLSv1.2 DH,1024bits None
| |
| 17 DHE-RSA-AES128-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2 DH,1024bits None
| |
| 18 DHE-RSA-CAMELLIA128-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2 DH,1024bits 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,1024bits 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,1024bits None
| |
| 30 DES-CBC3-SHA SSLv3,TLSv1,TLSv1.1,TLSv1.2 None None
| |
|
| |
| Certificate: UNTRUSTED, 1024 bit, sha1WithRSAEncryption signature
| |
| TLS ticket lifetime hint: 300
| |
| OCSP stapling: not supported
| |
| Cipher ordering: server
| |
|
| |
| Bei diesem "output" sieht man schön welche "cipher" erlaubt werden wie zB "RC4" das als unsicher gilt. Ebenso sieht man welche TLS und/oder SSL Versionen aktiviert und somit benutzt werden können. Die nachfolgenden Befehle deaktivieren verschiedene TLS und/oder SSL Versionen. Dabei ist jedoch zu berücksichtigen das die Kompatibilität sinkt dh. ältere Browser etc. können danach nicht mehr zugreifen weil diese zB TLSv1.2 "noch nicht" unterstützen. Deshalb ist zu bedenken wie weit man dies einschränken möchte. Die verschiedenen zur Verfügung stehenden "cipher" werden über die Option "algorithm" gesteuert dh. über "default, high und low". Um möglichst eine "high" Encryption Algorithmus zu erlauben sowie nur TLSv1.2 kann folgendes ausgeführt werden:
| |
|
| |
| # config vpn ssl settings
| |
| # set tlsv1-0 disable
| |
| # set tlsv1-1 disable
| |
| # set sslv3 disable
| |
| # set algorithm high
| |
| # end
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Diese Einstellungen sind nur zu benutzen in einem kontrollierten Umfeld dh. wie schon erwähnt sinkt die Kompatibilität
| |
| betreffend Zugriff dh. ältere Browser oder Browser die KEINE TLSv1.2 unterstützen sowie die nachfolgenden "cipher"
| |
| können keine Verbindung mehr aufbauen!
| |
|
| |
| Nach der Konfiguration der Optionen kann wiederum ein Test ausgeführt werden der zeigen soll was noch zur Verfügung steht:
| |
|
| |
| # /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,1024bits None
| |
| 5 DHE-RSA-AES256-SHA256 TLSv1.2 DH,1024bits None
| |
| 6 DHE-RSA-AES256-SHA TLSv1.2 DH,1024bits None
| |
| 7 DHE-RSA-CAMELLIA256-SHA TLSv1.2 DH,1024bits 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,1024bits None
| |
| 16 DHE-RSA-AES128-SHA256 TLSv1.2 DH,1024bits None
| |
| 17 DHE-RSA-AES128-SHA TLSv1.2 DH,1024bits None
| |
| 18 DHE-RSA-CAMELLIA128-SHA TLSv1.2 DH,1024bits 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,1024bits None
| |
| 25 DES-CBC3-SHA TLSv1.2 None None
| |
|
| |
| Certificate: UNTRUSTED, 1024 bit, sha1WithRSAEncryption signature
| |
| TLS ticket lifetime hint: 300
| |
| OCSP stapling: not supported
| |
| Cipher ordering: server
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Wie man sieht arbeitet "Diffie Hellmann" dh. DH mit 1024bit. Möchte man mit einer höheren Bit Anzahl arbeiten steht folgendes
| |
| Kommando zur Verfügung:
| |
|
| |
| # config firewall ssl settings
| |
| # set ssl-dh-bits [1024 | 1536 | 2048 | 768]
| |
| # end
| |
|
| |
| Wenn man den VDOM Mode aktiviert hat steht dieser Parameter unter "config global" zur Verfügung!
| |
|
| |
| Wie man sieht wird die Konfiguration "quotiert" dh. es steht nur noch TLSv1.2 zur Verfügung und die unsicheren "cipher" stehen nicht mehr zur Verfügung. 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
| |
| ---
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> 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 [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)". Wie gesagt "Security" technisch gesehen ist die Konfiguration korrekt jedoch die Kompatibilität leidet.
| |
|
| |
| === Welche IP wird benutzt für das SSL-VPN Portal und kann ich diese manipulieren? ===
| |
|
| |
| Grundsätzlich hört ein SSL-VPN Portal auf "alle" IP's die auf dem Interface konfiguriert sind (FortiOS 5.0). Bedeutet: hätte man ein externes Interface mit einer "public IP" in einem Range zB 193.193.135.66/29 hört das SSL-VPN Portal auf die IP "193.193.135.66/29". Möchte man nun zB die IP "193.193.135.67/29" benutzen konfiguriert man diese IP als "Secondary IP" zusätzlich zur IP "193.193.135.66/29". Wenn die IP "193.193.135.66/29" jedoch nicht für den Zugang für das SSL-VPN Portal benutzt werden soll kann dies über eine manuelle "Local-In Policy" verhindert werden da diese vor der regulären Policy abgearbeitet wird. Das Gleiche gilt für alle anderen Interfaces dh. das SSL-VPN Portal ist unter FortiOS 5.0 per Standard auf allen Interface's erreichbar. Soll dies verhindert werden, kann dies über eine manuelle "Local-In Policy" verhindert/konfiguriert werden. Nähere Informationen zu der Erstellung einer "Local-In Policy" siehe nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Was_sind_.22Local_In_Policy.27s.22_und_wie_kann_ich_diese_manipulieren.3F]]
| |
|
| |
| Wenn für den "interne" Request eine andere IP benutzt werden soll so kann dies mit einer entsprechenden NAT Rule/Implementierung gewährleistet werden. Nähere Informationen betreffend NAT Rule/Implementierung siehe Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_wird_ein_Source.2FDestination_NAT_auf_einer_Fortigate_implementiert.3F]]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Unter der global SSL-VPN Konfiguration stehen desweiteren folgende Optionen zur Verfügung:
| |
|
| |
| # config vpn ssl settings
| |
| # set route-source-interface [enable | disable]
| |
| # set source-interface [enable | disable]
| |
| # end
| |
|
| |
| Wenn VDom's aktiviert wurden und eine zusätzlcihe VDom zur "root" VDom über einen "inter-vdom" Link verbunden ist so komuniziert der über's SSL-VPN Portal eingeloggt User über das Interface des "inter-vdom" Link's auf der "root" VDom Seite:
| |
| ______________________ _______________________
| |
| 193.193.135.66/29| | Interface-root-vdom interface-vdom1-vdom | |
| |
| ----- WAN 1 -----| Fortigate vdom-root |------------------------- inter-vdom-link -------------------------| Fortigate vdom-vdom1 |
| |
| |______________________| |_______________________|
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Die Erklärung dazu ist das das "Interface-root-vdom" Interface als WAN Interface gilt für die
| |
| VDom "vdom1"!
| |
|
| |
| === Kann ich für SSL-VPN ein "Custome Language File" erstellen/konfigurieren? ===
| |
|
| |
| Auf einer FortiGate ist das Web Mgmt. Gui und andere Gui's auf Englisch. Unter der folgende Position können andere Sprachen gewählt werden:
| |
|
| |
| System > Admin > Settings > View Settings > Language > [English | French | Spanish | Portuguese | Japanese | Tradional Chinese | Simplified Chinese | Korean]
| |
|
| |
| Andere Sprachen wie Deutsch stehen nicht zur Verfügung. Ab FortiOS 5.2 ist es jedoch möglich für folgende Funktion ein eigenes "Sprachefile" anzulegen (Custome Language File):
| |
|
| |
| • SSL VPN Portal
| |
| • SSL VPN Personal Bookmarks
| |
| • Guest Management Admin Accounts (Guest Access Provisioning)
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Weitere Informationen betreffend "Guest Access Provisioning" siehe nachfolgender Artikel:
| |
|
| |
| [[FortiAP:FAQ#Wie_implementiere_ich_ein_.22Wireless_Guest_Access_Provisioning.22.3F]]
| |
| [[FortiAP:FAQ#Wie_implementiere_ich_ein_.22Wireless_Guest_Access_Provisioning.22_.28Guest_Management.29_ein_.22Custome_Language_File.22.3F]]
| |
|
| |
| Wenn für das SSL-VPN Portal sowie User Settings ein eigenes "Sprachfile" erstellt werden soll muss folgendermassen vorgegangen werden:
| |
|
| |
| # config system global
| |
| # set gui-custom-language enable
| |
| # end
| |
|
| |
| Durch die Aktivierung von "gui-custom-language" wird ein zusätzlicher Menüpunkt auf dem Web. Mgmt. Interface auf der Fortiate
| |
| aktiviert:
| |
|
| |
| System > Config > Advanced > Language
| |
|
| |
| [[Datei:Fortinet-1285.jpg]]
| |
|
| |
| Unter der Position "Download Sample Language Template" kann eine Vorlage runtergeladen werden, die herangezogen werden kann um
| |
| das "Sprachfile" zu erstellen. Nachfolgend ein Beispiel dieses "Sample Language Template":
| |
|
| |
| [[Datei:sample-language-template.txt]]
| |
|
| |
| Nachdem das "Sprachfile" modifiziert wurde kann es unter folgender Position wieder raufgeladen werden:
| |
|
| |
| System > Config > Advanced > Language > Create New
| |
|
| |
| [[Datei:Fortinet-1286.jpg]]
| |
|
| |
| Danach kann das entsprechende File raufgeladen werden:
| |
|
| |
| [[Datei:Fortinet-1287.jpg]]
| |
|
| |
| Damit das entsprechende File benutzt wird in der Funktion muss dies unter Kommandozeil und/oder über Web Mgmt. Interface
| |
| konfiguriert werden:
| |
|
| |
| VPN > SSL > Portals > [Wähle das entsprechende Portal] > Page Layout > [Wähle das entsprechende "Sprachfile"]
| |
|
| |
| [[Datei:Fortinet-1288.jpg]]
| |
|
| |
| # config vpn ssl web portal
| |
| # edit [Wähle das entsprechende Portal]
| |
| # set web-mode enable
| |
| # set custom-lang [Wähle das entsprechende "Sprachfile"]
| |
| # end
| |
| # end
| |
|
| |
| Um das "Sprachfile" betreffend "SSL VPN Personal Bookmarks" basierend zu konfigurieren muss folgendes durchgeführt werden:
| |
|
| |
| # config vpn ssl web user-bookmark
| |
| # edit [Wähle einen entsprechenden Namen]
| |
| # set custom-lang [Wähle das entsprechende "Sprachfile"]
| |
| # end
| |
| # end
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Die Funktion "SSL VPN Personal Bookmarks" ist eine Zusatzfunktion und wird per Standard nicht über das
| |
| Web Mgmt. Interface angezeigt dh. dieses Feature kann über folgende Position aktiviert werden:
| |
|
| |
| System > Config > Feature > Show More > SSL-VPN Personal Bookmark Management
| |
|
| |
| === Wie kann ich für die SSL-VPN Funktion eine Statistik betreffend Memory, Verbindungen, Max User anzeigen lassen? ===
| |
|
| |
| Eine SSL-VPN Statistik kann über Kommandozeile und über folgenden Befehl 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 im Conserve Mode. Oft ist der "busy" Status zurückzuführen auf zuwenig Memory, dass für den Deamon zur Verfügung steht. 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 sich im Conserve Mode befindet sollte untersucht werden, da dies geschieht/ausgeführt wird um nicht die ganze FortiGate zu beeinträchtigen. Somit ist der Conserve Mode des SSL-VPN Deamons nicht gleich Conserve Mode der FortiGate!
| |
|
| |
| === Wie kann ich den SSL-VPN Deamon bei Problemen neu starten? ===
| |
|
| |
| Eine Variante den SSL-VPN Deamon bei und/oder nach Problemen neu zu starten, ist durch die PID (Process ID) und anhand des "kill" Befehls den Deamon zu zwingen einen Neustart auszuführen. Damit dies durchgeführt werden kann, muss zuerst die PID (Prozess ID) eruiert werden. Dies kann durch folgenden Befehl durchgeführt werden:
| |
|
| |
| # diagnose sys top 5 20
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Weitere Informationen dazu siehe nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_kann_ich_rausfinden_was_ein_High_CPU_verursacht_und_was_kann_ich_dagegen_tun.3F]]
| |
|
| |
| Eine andere Variante die Prozess ID (PID) zu eruieren ist über den folgenden Befehl:
| |
|
| |
| # fnsysctl ls -l /var/run/
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> In diesem Verzeichnis befinden sich sämtliche Deamon Prozesse. Für SSL-VPN ist der folgende zuständig:
| |
|
| |
| sslvpnd.pid
| |
|
| |
| Um nun die PID des Files zu eruieren benütze folgenden Befehl:
| |
|
| |
| # fnsysctl more /var/run/sslvpnd.pid
| |
| 75
| |
|
| |
| Wenn die Prozess ID (PID) eruiert wurde kann der Deamon mit folgenden Befehl neu gestartet werden:
| |
|
| |
| # diagnose sys kill [Kill Level/Sequenz 1 - 32 wobei 11 den Prozess stopp und neu startet] [PID des Prozesses zB. "75"]
| |
|
| |
| === Wie kann ich für ein SSL-VPN (Web Mode/Tunnel Mode) ein Registry Check konfigurieren (Host Check)? ===
| |
|
| |
| Mit einem SSL-VPN Portal/Tunnel Mode ist es möglich einen sogenannten "Registry Check" (Host Check) auszuführen dh. wenn der User zB den Browser öffnet und auf das Web Portal (Web Mode) über FQDN und/oder IP zugreift sowie einloggt, wird im Hintergrund ein sogenannter "Host Check" ausgeführt. Soll ein Login in das SSL-VPN Web Portal nur dann ermöglicht werden, wenn ein bestimmter "Registry Eintrag" existiert, kann dies über die Funktion "Registry Check" durchgeführt/konfiguriert werden. Das Gleiche gilt für den SSL-VPN Tunnel Mode was wiederum bedeutet: Versucht sich ein User über SSL-VPN Tunnel Mode einzloggen, wird das Einloggen nur dann erlaubt wenn ein bestimmter "Registry Eintrag" existiert. Dies erlaubt zu unterscheiden, ob ein Zugriff über einen bestimmten Device erlaubt ist wie zB der Zugriff über einen Device im "Internet Café" soll verhindert werden und der Zugriff über einen "Geschäfts Laptop" soll erlaubt werden. Damit dieser "Registry Check" im SSL-VPN Web/Tunnel Mode durchgeführt werden kann, muss der SSL-VPN Client auf dem Device von dem auf den SSL-VPN Web/Tunnel Mode zugegriffen werden soll installiert werden dh. als:
| |
|
| |
| - FortiClient SSL-VPN
| |
| - SSL-VPN Client ActiveX
| |
| - SSL-VPN Client Java Mode
| |
|
| |
| Da der FortiClient/SSL-VPN Client im SSL-VPN Web/Tunnel Mode "immer" als Administrator installiert werden muss, sind die Voraussetzungen gegeben um den entsprechenden "Host Check" auszuführen (Zugriff auf Registry). Um die Konfiguration durchzuführen für den "Web/Tunnel" Mode muss folgendes konfiguriert werden:
| |
|
| |
| '''Definition des entsprechenden Registry Checks'''
| |
|
| |
| # config vpn ssl web host-check-software
| |
| # edit [Name für den Registry 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
| |
|
| |
| '''Angabe des entsprechenden Web Portal sowie Aktivierung des Registry Checks'''
| |
|
| |
| # config vpn ssl web portal
| |
| # edit [Name des entsprechenden Web/Tunnel Mode]
| |
| # set host-check custom
| |
| # set host-check-policy [Name des Registry Check vergeben für "host-check-software"]
| |
| # next
| |
| # end
| |
|
| |
| Wenn ein Client versucht eine Authentifizierung für den entsprechenden Mode SSL-VPN Web/Tunnel Mode auszuführen wird wenn der "Registry Eintrag" nicht existiert folgendes angzeigt:
| |
|
| |
| '''SSL-VPN Tunnel Mode'''
| |
|
| |
| [[Datei:Fortinet-1371.jpg]]
| |
|
| |
| '''SSL-VPN Web Mode'''
| |
|
| |
| [[Datei:Fortinet-1372.jpg]]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Wird im Web Mode kein entsprechender SSL-VPN Client vorinstalliert so erscheint im Browser folgende Nachricht
| |
| um auf diesen Umstand hinzuweisen:
| |
|
| |
| 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 für ein SSL-VPN (Web Mode/Tunnel Mode) ein "Windows OS Check" konfigurieren (OS Check)? ===
| |
|
| |
| Für ein SSL-VPN Web Mode/Tunnel Mode ist es möglich betreffend Windows Version einen sogenannten "OS Check" durchzuführen. Dies bedeutet: Greift der User mit einem Client zu, wird im Hintergrund überprüft ob der User ein bestimmtens OS installiert hat und über einen bestimmten Patch Level verfügt. Beim Patch Level wird angegeben über welchen Patch Level er im "minimum" verfügt. Ist der "OS Check" nicht erfolgreich wird der Zugriff resp. Login nicht erlaubt. Damit dieser "OS Check" im SSL-VPN Web/Tunnel Mode durchgeführt werden kann, muss der SSL-VPN Client auf dem Device von dem auf den SSL-VPN Web/Tunnel Mode zugegriffen werden soll installiert werden dh. als:
| |
|
| |
| - FortiClient SSL-VPN
| |
| - SSL-VPN Client ActiveX
| |
| - SSL-VPN Client Java Mode
| |
|
| |
| Ein "Windows OS Check" wird folgendermassen konfiguriert:
| |
|
| |
| # 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
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Wird die "action" auf "allow" gesetzt muss kein entsprechender Patch Level definiert werden da nur kontrolliert wird
| |
| ob der Client über das definierte "OS" verfügt. Möchte man ein Patch Level überprüfen muss die Option "check-up-to-date"
| |
| gesetzt werden! Wird "check-up-to-date" gesetzt wird mit dem entsprechenden "latest-patch-level" so 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 variert 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
| |
|
| |
| Grundsätzlich ist zu bedenken, dass die Informationen die im Hintergrund durch die FortiGate benutzt werden um das OS zu überprüfen statisch sind dh. wenn Microsoft einen Patch lanciert der diese Ueberprüfung des OS beeinflusst kann es zu Problemen kommen dh. FortiGate muss dann die neuen Informationen wieder in die Ueberprüfung einfliessen lassen. Aus diesem Grund sollte auch die Definition des Patch Levels nicht zu eng gesetzt werden und der OS Check für eine grössere Sicherheit event. mit dem "Host Check" kombiniert werden. Dazu siehe nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_kann_ich_f.C3.BCr_ein_SSL-VPN_.28Web_Mode.2FTunnel_Mode.29_ein_Registry_Check_konfigurieren_.28Host_Check.29.3F]]
| |
|
| |
| === Wie starte/stoppe ich den FortiSSLVPNclient auf auf einer Workstation auf der Kommandozeile? ===
| |
|
| |
| Wenn ein "FortiSSLVPNclient" auf einer Workstation installiert wird (nicht FortiClient Endpoint Security) kann dieser per Kommandozeile manipuliert werden. Dies bedeutet: Soll dieser zB per Kommandozeile anhand eines Scripts gestartet oder gestoppt werden kann folgender Befehl benutzt werden (Dos Box):
| |
|
| |
| > FortiSSLVPNclient.exe [connect | disconnect]
| |
|
| |
| Es stehen ebenfalls für diese "FortiSSLVPNclient.exe" zusätzliche Optionen zur Verfügung:
| |
|
| |
| [[Datei:Fortinet-1596.jpg]]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Wurde der FortiClient Endpoint Security 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]]
| |
|
| |
| === Welche Firewall Policy Rule muss konfiguriert werden wenn über ein VPN SSL (Web Mode) die Destinationen einer IPSec Verbindung erreicht werden will? ===
| |
|
| |
| Ausgehend davon, dass wir ein SSL-VPN konfiguriert haben im "Web Mode" dh. nicht über ssl.root und anhand des FortiClients und über dieses SSL-VPN im Web Mode eine Destination über IPSec erreichen möchten muss bei der Firewall Policy Implementation folgendes implementiert/konfiguriert werden:
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Betreffend Konfiguration eines SSL-VPN im Web Mode siehe nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_konfiguriere_ich_unter_FortiOS_5.0_ein_SSL-VPN_Portal.2FTunnel_auf_einer_Fortigate.3F]]
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_konfiguriere_ich_unter_FortiOS_5.2_ein_SSL-VPN_Portal.2FTunnel_auf_einer_Fortigate.3F]]
| |
|
| |
| Das nachfolgende Beispiel basiert auf FortiOS 5.0.x dh. unter diesem Release wird ein SSL-VPN im "Web Mode" über eine
| |
| sogenannte "Identity Based Policy" erstellt. Unter FortiOS 5.2.x gibt es diese Art dh. "Identity Based Policy nicht"
| |
| mehr. Somit muss eine normale Rule implementiert werden die anhand der SSL-VPN Gruppe für die Authentifizierung den
| |
| Traffic erlaubt. Unter FortiOS 5.2.x stehen betreffend "Web Mode" unter CLI zusätzliche Kommandos zur Verfügung anhand
| |
| dieser die Source IP des "Web Mode" beeinflusst werden kann!
| |
|
| |
| '''Ordentliche Firewall Policy Rule für den VPN-SSL Zugang (Web Mode)'''
| |
| # config firewall policy
| |
| # edit [Integer zB "1"]
| |
| # set srcintf [Interface des ISP zB "wan1"]
| |
| # set dstintf [Interface der Destination die über SSL-VPN erreichbar sein sollen zB "internal"]
| |
| # set srcaddr [Source Public IP Adressen IPv4 oder "all"]
| |
| # set dstaddr [Destination IP Adress Objekt für internal zB "net-lan-192.168.1.0-24"]
| |
| # set action ssl-vpn
| |
| # set comments [Kommentar zB "Allow Incoming SSL VPN Portal"]
| |
| # set identity-based enable
| |
| # config identity-based-policy
| |
| # edit 1
| |
| # set schedule "always"
| |
| # set logtraffic all
| |
| # set utm-status enable
| |
| # set groups [Name User Gruppe für SSL-VPN]
| |
| # set service [Definition der Service zB "ALL"]
| |
| # set sslvpn-portal [Name des SSL-VPN Portals]
| |
| # next
| |
| # end
| |
| # next
| |
|
| |
| '''Zusätzliche Firewall Policy Rule für den VPN-SSL Zugang zum IPSec (Web Mode)'''
| |
| Im nachfolgenden Beispiel gehen wir davon aus, dass auf der FortiGate auf dem das SSL-VPN (Web Mode) konfiguriert
| |
| wurde ein Site2Site VPN exisitiert (Interface Based) mit dem Namen "ipsec-vpn1". Das Destination Netzwerk im IPSec
| |
| das erreicht werden soll ist der IP Rang 10.10.10.0/24. Ebenso wurde für das SSL-VPN ein "IP Pool" Objekt definiert
| |
| mit dem IP Range 192.168.5.0/24.
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Grundvoraussetzung damit die Destination des IPSec erreicht werden kann ist ein routing Eintrag der den IP Range
| |
| 10.10.10.0/24 auf das IPSec Interface "ipsec-vpn1" sendet. Ebenfalls muss die Source IP des "IP Pool" Bereichs von der
| |
| Remote Destination zurück geroutet werden damit das Packet von der Remote Seite wieder den Ausgangspunkt erreicht! Dies
| |
| bedeutet die Remote Seite muss den IP Range für IP Pool 192.168.5.0/24 zurück Routen.
| |
|
| |
| # config firewall policy
| |
| # edit [Integer zB "2"]
| |
| # set srcintf [Interface der Source zB "wan1"]
| |
| # set dstintf [Interface des IPSec Phase1 zB "ipsec-vpn1"]
| |
| # set srcaddr [Source Public IPv4 Adresse Objekt oder "all"]
| |
| # set dstaddr [Destination IP Adress Objekt für ipsec-vpn1 zB "net-lan-10.10.10.0-24"]
| |
| # set action ssl-vpn
| |
| # set comments [Kommentar zB "Allow Outgoing IPSec Reqeust for SSL-VPN Portal"]
| |
| # set identity-based enable
| |
| # config identity-based-policy
| |
| # edit 1
| |
| # set schedule "always"
| |
| # set logtraffic all
| |
| # set utm-status enable
| |
| # set groups [Name User Gruppe für SSL-VPN]
| |
| # set service [Definition der Service zB "ALL"]
| |
| # set sslvpn-portal [Name des SSL-VPN Portals]
| |
| # next
| |
| # end
| |
| # next
| |
|
| |
| # config firewall policy
| |
| # edit [Integer zB "3"]
| |
| # set srcintf [Interface der Source IPSec Phase1 zB "ipsec-vpn1"]
| |
| # set dstintf [Interface der Destination zB "wan1"]
| |
| # set srcaddr [Source IP Adress Objekt für ipsec-vpn1 zB "net-lan-10.10.10.0-24"]
| |
| # set dstaddr [Destination IP Adress Objekt für IP Pool zB "net-ip-pool-192.168.5.0-24"]
| |
| # set action "accept"
| |
| # set comments [Kommentar zB "Allow Incoming IPSec Reqeust for SSL-VPN Portal"]
| |
| # end
| |
|
| |
| == Certificate ==
| |
|
| |
| === Was für ein Standard Zertifikat (Default CA) ist auf einer FortiGate installiert? ===
| |
|
| |
| In der Vergangenheit war auf jedem FortiGate Device das gleiche Standard Zertifikat (Default CA) installiert (FortiOS 5.0.x). Weitere Informationen dazu siehe nachfolgenden Link:
| |
|
| |
| https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-4948
| |
|
| |
| Ab FortiOS 5.2 wird dieses Standard Zertifikat "für den Device" initialisiert (Device Spezifisch) sobald dieses durch eine Funktion benötigt wird wie zB "Deep Inspection, Zugriff über https auf Web Mgmt Interface". Für einige Funktionen wie zB High Availibility (HA) und Load Balancing wird nachwievor das Standard Zertifikat herangezogen für die Konfiguration. Dies kann jedoch per Konfiguration auf das "für den Device" initialisierte Zertifikat geändert werden.
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Bei einem Upgrade auf FortiOS 5.2 werden die vorhandenen Standard Zertifikat und dessen Konfiguration nicht verändert!
| |
|
| |
| Wenn die Initialisierung eines Zertifikates "für den Device" manuell ausgeführt werden soll so kann folgendes durchgeführt werden:
| |
|
| |
| '''Das folgende Kommando generiert den "Public Key" basierend auf der CA (Certificate Authority):'''
| |
|
| |
| # execute vpn certificate local generate default-ssl-ca
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Weitere Informationen zu diesem Befehl siehe auch folgender Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_kann_ich_auf_einer_FortiGate_ein_Certificate_.22Regenerieren.22_um_ein_.22Device_Spezifisches.22_Certificate_zu_erhalten.3F]]
| |
|
| |
| '''Das folgende Kommando generiert den "Private Key" (Auch Server Key) basierend auf der CA (Certificate Authority):'''
| |
|
| |
| # execute vpn certificate local generate default-ssl-serv-key
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Wenn ein Zertifikat von einer FortiGate zu einer anderen FortiGate exportiert/importiert werden soll siehe nachfolgender
| |
| Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_kann_ich_ein_.22Local_Certificate.22_von_einer_FortiGate_exportieren_und_in_eine_andere_FortiGate_importieren.3F]]
| |
|
| |
| Im Hintergrund wird anhand der Befehle folgendes ausgeführt:
| |
|
| |
| <big>'''Public Key'''</big>
| |
|
| |
| # execute vpn certificate local generate default-ssl-ca
| |
|
| |
| --------------- diagnose debug cli -1 ---------------
| |
|
| |
| # config vpn certificate local
| |
| # edit "Fortinet_CA_SSLProxy"
| |
| # set password ENC 3XUrWIPNc/BA42RxIdqcY9GWrZUcHds2An+wxlrPVBof7yVMJkd5iVzRTRXbsdG8j/b2CZ/xVKV6Tc6t5Qxi3CjlSYotGk58lCcZ1BVAwnxFhu5G5bEBBuKPkWT1BmhmbNJX5m0qF6CAFDARCojarpeLaFyE7p7oZ6+6khGfD6rQKVLQo0MBzJIZoNkOuY4cuDC07w==
| |
| # unset private-key
| |
| # set private-key "-----BEGIN ENCRYPTED PRIVATE KEY-----
| |
| MIIFDjBABgkqhkiG9w0BBQ0wMzAbBgkqhkiG9w0BBQwwDgQIE10eK8o+FwoCAggA
| |
| MBQGCCqGSIb3DQMHBAijxt3zyI/ycASCBMgaGu4CjJxFC2creE81Y4qcycEixRfb
| |
| MgvvPAk84mhJjAaV3OJNWZO8TPf+wA2Y7CZOlUS/oiXLFa385ij6xqAvyJlTG8Zu
| |
| pGbo3Gxw79i/VthViMmxiuuh3RYmxFFHRzgDeKDySnm5+o/kMwhr6pdvQhLyOkPW
| |
| IY6CIglgiYOUE9DkmT/PLQEAE7NTobT/N6indklWjnPcWf60UeXG5/eel1+kBdmA
| |
| JPdY6R164Ih4TW5x5rCWlZY+xKH4VQk0uQJtjjeUt55Boo/x3lVPyx46Yhi/QWfk
| |
| z5Zo2Gt7lGQUH6g5onhW6cTHmOqvSRpbEw+2oN03DakXOPRXQMd/iC7FbxBsBzqr
| |
| X8W/PzISKX4GeBdAYkAdEMqFvezd+WG7jGSas5ckCSbiOIm3fx2PGso0SUPHyvnS
| |
| 6eeyfbv281/UBID5XYQ2vvbQ9JDEA7i0yR2Lk8GORjjbiZJdExQrnNyzc1dAESJj
| |
| W9r5g55BFLuz1VuCZQo7rcqkb/0QLtkj3eYYl5biS1GdDjIt0wT9lKFiCQnSbu4i
| |
| JqT8bMFMj69aUG4AJOCHmC+gfALT6FDoExW9sI/R42s3WZhVb53kAB8ClUb1IwWh
| |
| xwA+UnnsrzvMXRl6uO30SKYnTNz6hG6KNgi/In2P7CjD/QZtIROJkpdk62dTqqDn
| |
| qHMs8v/LszGnfOQsOs8X5YL4e/0VMx/xFr4r8itGlD7V/Oqv3G3afaQQj0CIUS13
| |
| DQcCe+R0Op3PunVDy1EP+xzh4L0LUWT9cnQT5W/wUSUduMcAeXTGSMwvkU0Yj+n7
| |
| ETUh1+GhMmMjYcOSZcawQyG2dXtRhzl5683jrJUbCTgK8ECWktK2YK1HYVZ3xtyv
| |
| THon+8GS6Ks8Gl/WI9cMTSHY9Rtv1C8Mu/yXOG+dGA42hWE18fHmoz3JPl9ltpHy
| |
| JHrCbUD4IgLSOgVdfhBm6pAVM+nZhrWSiplq7hEk+iTAZhVA1TPGeOtyfSOrBShV
| |
| WUn68Rb92C81WT5a8PMMqoWRny8OFq15MaEIQyyAwQYTyurJu8exuxHMF0t3XM4T
| |
| hLnqSJERjyjux+TyCzdTPNTRNsBMkbQwz6u0T3gAiAYEjaYaEWcXE7Vr+pqefU7j
| |
| cJQHBMUxQBKpq6ErQmpKH6ONQFhdPRfqaAXpCM57GA796FaElGyi+GeQuzTTasVf
| |
| wCpODSVKmsSJ9Opbvy1qTkGTc7q2epPPdWGW7/HHGpfH83Wx8qLnompZ+LbL0x6l
| |
| FgnRiNY0l3nvMXobgQfXT11Qg+Z4ZN84VQDmlQNb/wabqFqKoHsqzJ4n63IUMMqI
| |
| 4TVZZ7v6i9xZt7N09E+1gex/+qXn+2c2+A4BXMbt2RgXB3qWQFg4SGqltQxd1g+8
| |
| fXMUZdEYCsFGC4EtocScgN4fAKVs9Q8atpEXCHIRu8GEJxpuN9Bv795y/yZkTIbK
| |
| uE3XD2XjYsmgI1DffnVbEi6CZDJY6ljdx7vIR1pmC19xE646aEGeSpt+P5i2us1f
| |
| V4nkNxz6MoGk/MfA9iGOK0KOpzMgGWpn5bgGzgEFD9o7knfbRuJsFHizmx3jc76R
| |
| dfTzOw83sIL5nUEf85FxNiaHyp+cOH3rdGgq9OZ8cxFYfp4ffBdjjOGYnALHhjhy
| |
| -----END ENCRYPTED PRIVATE KEY-----"
| |
| # unset certificate
| |
| # set certificate "-----BEGIN CERTIFICATE-----
| |
| MIID2jCCAsKgAwIBAgIEAdKqcjANBgkqhkiG9w0BAQUFADCBpTELMAkGA1UEBhMC
| |
| VVMxEzARBgNVBAgMCkNhbGlmb3JuaWExEjAQBgNVBAcMCVN1bm55dmFsZTERMA8G
| |
| A1UECgwIRm9ydGluZXQxHjAcBgNVBAsMFUNlcnRpZmljYXRlIEF1dGhvcml0eTEV
| |
| MBMGA1UEAwwMRm9ydGlHYXRlIENBMSMwIQYJKoZIhvcNAQkBFhRzdXBwb3J0QGZv
| |
| cnRpbmV0LmNvbTAeFw0xNDA4MTExNTA0MzJaFw0yNDA4MTExNTA0MzJaMIGlMQsw
| |
| CQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5pYTESMBAGA1UEBwwJU3Vubnl2
| |
| YWxlMREwDwYDVQQKDAhGb3J0aW5ldDEeMBwGA1UECwwVQ2VydGlmaWNhdGUgQXV0
| |
| aG9yaXR5MRUwEwYDVQQDDAxGb3J0aUdhdGUgQ0ExIzAhBgkqhkiG9w0BCQEWFHN1
| |
| cHBvcnRAZm9ydGluZXQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
| |
| AQEAnPRyKu6hfz40NJF7FfZB+E/KCylUgqkqc5V4qyHQahq/Deyai/dvctF748NV
| |
| +7ojuu2t33PoYokyz9L5C/FaBCTnQzYbJNCdgNZFUkzvafTcn8yk9KQYoptB1Lrl
| |
| cix7NLf5xBztlvPhfwT8WCOXZKKhQ0wRC8iUrjkjBWMvMdxZio/2mcPGw2w8/r1q
| |
| Dm6zLVUbr3DQSadmBFXtgFyZ7hZrA2SClRDr/uNg58c5Lds+p8rIA/2icpOGPlEt
| |
| rAjAuXnkk1vHGNaZLN15XGCLnPDjHs6MQ1KRRn24NG/HS8boG4hsAQCO1zteG6kM
| |
| ZwXxZYhbsE//MLJHVgrGxkkMiwIDAQABoxAwDjAMBgNVHRMEBTADAQH/MA0GCSqG
| |
| SIb3DQEBBQUAA4IBAQBcubmobonUjYBWUuKA8zNRH58JwOlYiEfm5b981OvfwiNY
| |
| Vgu48ikq1hp+lzoETfE239ZDnWw4tClLrlnlVPuEQ7JTNl/TvvT6KjoyLCXDADRz
| |
| 51tJLHbLglXmNHE3BlPfMJV41Xg0lpeU3sXkhbGTsnFPBSmeEfFNwA4ylBQEVlT+
| |
| BYEAK76vEd4seEs1+bkMCorZTWipMEb1i2uz9Jh/k1MN4KcfRwqOlfXP8PNXjcsS
| |
| oKhXYJ0/FVXjX19xQKdzHyE9C6qAnyYuJiGgOR51FgRcYVjhaluYqZbfSqv4vW+N
| |
| +6ZmD74gUohcntwE8tLpZpt7YrCLuzwz
| |
| -----END CERTIFICATE-----"
| |
| # unset ike-localid-type
| |
| # end
| |
|
| |
| --------------- diagnose debug cli -1 ---------------
| |
|
| |
| <big>'''Private Key (Server Key)'''</big>
| |
|
| |
| --------------- diagnose debug cli -1 ---------------
| |
|
| |
| # execute vpn certificate local generate default-ssl-serv-key
| |
|
| |
| # config vpn certificate local
| |
| # edit "Fortinet_SSLProxy"
| |
| # set password ENC PtvSApK8tvLRVCM3VshEE/b9RZNswrjVxKtor0QfbMvAI74mGp5c1ib37WV6y4K0Y1r/tpOIQydoGAxruMpzYri5oQASMJf2kewHw5z5uEXcP1G3nywC1uL58Hf0iVJsZMzz8GMhtYiw5GsRYlsFB45g0KfgVBw5r/ktsCRTiOL0MgDhTz5ZgOLx0Ai6ttNRCLc8Mw==
| |
| # unset private-key
| |
| # set private-key "-----BEGIN ENCRYPTED PRIVATE KEY-----
| |
| MIIFDjBABgkqhkiG9w0BBQ0wMzAbBgkqhkiG9w0BBQwwDgQIB0WErcyXLGICAggA
| |
| MBQGCCqGSIb3DQMHBAjU9T3m5lo+YgSCBMhcwlABHfktvX5EZoknsLnwnYGBD0NL
| |
| vDvgYgcc5Yo9jPGjVWR8YgRcfqXE7BBJ/zWtQvWOsMBsvWbmDgNInQzIxBZ/W9R7
| |
| 3wl+pEt/PFgXbiLwToFfH2WqD7IiYokn+zwR77cWOpyIsUP338fzPgFhhtDD1ub4
| |
| 67MAeRPeviuKynEsOLSP/jL+L1D4ktmssBV1CWrNxGmRIwby4ng4FpsOE8TbOjf6
| |
| m+CMnQvEgiDo9t+eDZV0pohJovN2G8QszM9Yd79ZA5SE9GlgVBblpxrEX3nbWYeP
| |
| FLmI5ipUdtLz2/npspfLLu8N8d2pJEbadnh5RhF3e5GdMoIkJR+LyvJDDnHyLPWR
| |
| 50dBgYLU3/G5/tzy/2zFdUjFQ0c2quYgytoo7x2LYKDaDmpniio0YGQChQ95xWwb
| |
| ivof3YY/cEfyp12Yywv6marvRTEjLctiFggoX6YxDkCu429bL5OssU8WBp046vgR
| |
| tehG9fgvFn3xqh/qNUo1PJ4fgGhCz+vssIvzuAX2qQBpq5/yULhoHeS8Vj8nJFm/
| |
| tY0+VEBFMIHg/+wxzxEXniPIk5rnlA5muqnx0EQoY8gGUtez5BRW9ZVhtel+cQRN
| |
| iyJWcbzWjn1If1npyJnYSaW5JpVvZmpYFbSY7puOfYPcGMksFJzA2v5VaYJBE243
| |
| tE4im9KXtVHgml0zKc37Rq7hV2c6xq0GzriADnsPxbggTvdm4eqtau31ELvmbpiy
| |
| T/GRCK8S48RlmTNXN42NIzXlezmFs7+i9OX92HsvI4VFhVU1a84b5vYDnvXjEa8d
| |
| AII4FBHa9ASTr3iDZaF78g7X2Pa4q9Bq/9EC6RcTgK0dbGa7tj8dCbS7Jkwmf/Ns
| |
| acwWIQ9yWahPwCzDes+CAmRpqoNUZI6DXpWU9SqkqSSBp0sYIa9oCZjO5yDtLnku
| |
| mEkdI6T/OFdk7n89vmyDfVXFBVqgrSxhy4ngvueLaPeNDiIaMNz+EieSoQDDrcTD
| |
| rc3RpeQAT76YMlJKCTaisqCc2KdejwUthw7XoOJeQKddveVs4raf23v0qH/vcc61
| |
| 66PoBgeaJyg7dla+mQN+6Yhq8/yBpBdz3Vb+Q3it63HLzkzWK861vK+kyEU+tGED
| |
| g6v3FXDZtpWvSOynxgyEssCdyKHYE9g8f37BXDoiXnfLi/Qv//1DsVRCEuoj0Ck8
| |
| 7noCN1UUmM+PmXIjuu85dHOU8wjA7VNa96KsbZWuC9XvXrrGSYDXyWpyosJh9/ha
| |
| iML+P9Yc8zkZW7dQ/Hi9CgwkqHtDEetv1WwhnIzeHenJwVJ0yW61LKHdMMNouEk4
| |
| 5g+QjqeLV0NULpHVsM5ia88aGNlv/3XRDrJiialLcI9EwhKCkc0LF2P+mBpFRZpn
| |
| C6zfGD/Ak15TH3tptXgxu5loc3uXX5ZV7pzoiOgrKpz0k2XWFXPY4YSK3Awy9DCl
| |
| LUOPzU/Q9iwpp9MIKdjMpsoGcX4PiCVnQbHfpuQaeMC2xiGZLO6MW0gXFXb6FpZR
| |
| 8F68bCkaoWWq5RNLSyIhvyStsuLeyNmLjGAyENO+Tm4URVv6oio375ddDbh2nSYj
| |
| DMt71GMH5OPbRPgumOfR0rlWu+hfFskR2CHXUDcWs6Iz9uptxFY1MVmS9z2Ea4xo
| |
| -----END ENCRYPTED PRIVATE KEY-----"
| |
| # unset certificate
| |
| # set certificate "-----BEGIN CERTIFICATE-----
| |
| MIIDxzCCAq+gAwIBAgIEazUooTANBgkqhkiG9w0BAQUFADCBnTELMAkGA1UEBhMC
| |
| VVMxEzARBgNVBAgMCkNhbGlmb3JuaWExEjAQBgNVBAcMCVN1bm55dmFsZTERMA8G
| |
| A1UECgwIRm9ydGluZXQxEjAQBgNVBAsMCUZvcnRpR2F0ZTEZMBcGA1UEAwwQRm9y
| |
| dGlHYXRlIFNlcnZlcjEjMCEGCSqGSIb3DQEJARYUc3VwcG9ydEBmb3J0aW5ldC5j
| |
| b20wHhcNMTQwODExMTUwNzIwWhcNMjQwODExMTUwNzIwWjCBnTELMAkGA1UEBhMC
| |
| VVMxEzARBgNVBAgMCkNhbGlmb3JuaWExEjAQBgNVBAcMCVN1bm55dmFsZTERMA8G
| |
| A1UECgwIRm9ydGluZXQxEjAQBgNVBAsMCUZvcnRpR2F0ZTEZMBcGA1UEAwwQRm9y
| |
| dGlHYXRlIFNlcnZlcjEjMCEGCSqGSIb3DQEJARYUc3VwcG9ydEBmb3J0aW5ldC5j
| |
| b20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDvrifnOIq20gB89y+y
| |
| ZIA3xzHsdx4x3UsElXBgBpI3cDoVfYJ997WIr0+MLvik7XGHyQAwu92dH+l3U2Mj
| |
| CK7dqkeAIspBx5btS+WTyafWqjF9uKLy3Dp9ukp1opWJ7uBx9jmY/uArPcFL9jAl
| |
| HlbR5CepqGGxhp70cEmvrsDT/XYVjX+jvqDMUt8O7aqWmuXrraP41LI3xP2FXADG
| |
| ZvqrszxgU2IVkA38pyj/tokccmBBVn6omPprqAUdlbS89WHBpaeH1ouH6qsW9PSe
| |
| +ojYKCDDFUE/qnebvT0feeWaMrFDaTNHp2ckTXbhQb8al7uuQ4Yl1OmXRS/ONp4d
| |
| idz7AgMBAAGjDTALMAkGA1UdEwQCMAAwDQYJKoZIhvcNAQEFBQADggEBACaPr9uc
| |
| 71GNMcV7CkbGqVnT/edZJ1zyYqW/0cUFO++yNUU8IkwUfCw9+VShHSj1qkJbDrHl
| |
| wxfVpKXg80FFka0mZRGKAspMGvRwluuJWXI2OAuGLzgg8r6LhElvaRr/EYm8QhAI
| |
| CJm8GVisdqr9W4yBEHr7MxgacLWSdVmCsWjXjMGzMWcl1Q0tvGaiJ4mlZQtyKEOr
| |
| yYOe1T0O58tYANwPDN+ojrhR1R8WKuBdul7cnh2ZKHHFnTOGBCpY92ZMNZXHCTFP
| |
| QapfB8TxrVTCewUiKyY4RK79mFAiysEZ9mnP4X5POSejpQS/Ro3oOKKWq+X6njqH
| |
| IrqxQzTo=
| |
| -----END CERTIFICATE-----"
| |
| # unset ike-localid-type
| |
| # end
| |
|
| |
| --------------- diagnose debug cli -1 ---------------
| |
|
| |
| === Wie kann ich auf einer FortiGate ein Certificate "Regenerieren" um ein "Device Spezifisches" Certificate zu erhalten? ===
| |
|
| |
| Wie im nachfolgenden Artikel erklärt wird auf allen FortiGate betrieben mit FortiOS 5.0.x das gleiche Zertifikat benutzt (Per Standard):
| |
|
| |
| https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-4948
| |
|
| |
| Mit FortiOS 5.2.x wurde dies geändert dh. unter FortiOS 5.2.x wird eine "Device Spezifisches Zertifikat" benutzt und wird dann initialisiert sobald eine spezifische Zertifikats Abhängige Funktion benutzt wird (zB https Zugriff auf das Web Mgmt. Interface):
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Was_f.C3.BCr_ein_Standard_Zertifikat_.28Default_CA.29_ist_auf_einer_FortiGate_installiert.3F]]
| |
|
| |
| Aus diesen Gründen -um ein Maschinenspezifisches Zertifikat zu erzwingen/generieren- wurde unter FortiOS 5.2.x ein neues Kommando zur Verfügung gestellt um dies "nach einem Upgrade" auszuführen. Das folgende Kommando sollte ausgeführt werden um anhand des Standard Zertifikats ein Maschinenspezfisches Zertifikat zu erhalten:
| |
|
| |
| # execute vpn certificate local generate default-ssl-ca
| |
|
| |
| Nach dem ausführen des Befehls wird das "default-ssl-ca" Re-generiert dh. dies kann über folgende Befehl kontrolliert werden:
| |
|
| |
| # config vpn certificate local
| |
| # edit Fortinet_CA_SSLProxy
| |
| # get
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Achte beim Output auf das Datum sprich "Valid from" sowie auf den "Fingerprint" sowie "Serial Num" denn es handelt sich
| |
| nun um ein "Device Spezifisches" Zertifikat!
| |
|
| |
| === Wie kann ich ein Zertifikat umkonvertieren damit ich dieses in die Fortigate importieren kann? ===
| |
|
| |
| Ueber folgende Seite lässt sich ein Zertifikat umkonvertieren damit es nachträglich mit dem richtigen Format in die Fortigate importiert werden kann:
| |
|
| |
| http://www.msxfaq.de/signcrypt/openssl.htm
| |
|
| |
| === Was ist zu beachten bei einem Import eines Zertifikates auf einer Fortigate? ===
| |
|
| |
| Zertifikate werden von CA's ausgestellt (Certifcation Authority). Normalerweise werden diese Certificate als PKCS#12 Format ausgeliefert. Das Certifcate das man vom Certifcation Authority erhält beinhaltet den:
| |
|
| |
| public key (Oeffentliches Zertifikat)
| |
| private key (Privates Zertifikat)
| |
|
| |
| Nachfolgend einige Certificate Formate:
| |
|
| |
| [[Datei:Fortinet-46.jpg]]
| |
|
| |
| Je nach Gebrauch müssen diese Certificates umkonvertiert werden um einen erfolgreichen Import zu ermöglichen. Folgender Artikel gibt Auskunft wie so eine Umkonvertierung zu bewerkstelligen ist:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_kann_ich_ein_Zertifikat_umkonvertieren_damit_ich_dieses_in_die_Fortigate_importieren_kann.3F]]
| |
|
| |
| Um nun ein Certificate in eine Fortigate zu importieren führe folgendes durch:
| |
|
| |
| Muss ein Certificate Request durchgeführt werden kann dies direkt auf die Fortigate durchgeführt werden:
| |
|
| |
| System > Certificates > Local Certificates > Generate
| |
|
| |
| Dieses Certificate-Output wird dann benutzt um dieses auf einem CA (Certificate Authority) signieren zu
| |
| lassen (gegenzeichnen). Sobald das Certificate signiert ist kann dieses wiederum über folgende Position
| |
| importiert werden:
| |
|
| |
| System > Certificates > Local Certificates > Import
| |
|
| |
| Wurde der Certificate-Request '''nicht''' auf der Fortigate erstellt (zB bei Wildcard Certificat *.mydomain.ch)
| |
| kann dieses nicht auf der Fortigate importiert werden. Solch ein Import kann nur folgendermassen bewerkstelligt
| |
| werden:
| |
|
| |
| --> PKCS#12 File/Cert
| |
| --> getrenntes .crt und .key File/Cert
| |
|
| |
| Es ist bei solchen Imports auf Fortigate empfehlenswert die Variante der getrennten .crt und .key File/Cert zu
| |
| wählen. Danach können beide Files dh. .crt und .key über folgende Position importiert werden:
| |
|
| |
| System > Certificates > Local Certificates > Import
| |
|
| |
| Sobald der Import durchgeführt wurde muss deklariert werden für '''WAS''' dieses Certificate verwendet werden
| |
| soll. Dies wird über eine Drop-Down-Liste gewählt zB:
| |
|
| |
| IPSec
| |
| SSL VPN
| |
| etc.
| |
|
| |
| Eine Einstellung (v3.0/4.0) muss über Kommandozeile angegeben werden:
| |
|
| |
| # config system global
| |
| # set admin-server-cert [cert-name]
| |
| # end
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span>
| |
| Ist das Zertifikat nicht direkt von der CA, sondern von einem Intermediate Device/CA (Device
| |
| das ein signiertes Certifcate besitzt von der CA) erstellt worden, wird dieses als '''NICHT'''
| |
| trusted angeschaut. Eine Variante solch ein Intermediate Certificate dennoch als Trusted zu
| |
| verifizieren wäre:
| |
|
| |
| Import des Intermediate Zertifikat auf der Fortigate als „CA Certificate“
| |
|
| |
| Das Intermediate Certificate kann direkt von der CA herunter geladen werden oder es ist im .crt File
| |
| des eigenen Certificate enthalten. Die .crt-Datei kann einfach mit dem Wordpad geöffnet und der
| |
| entsprechende Abschnitt in ein eigenes .crt File gespeichert werden:
| |
|
| |
| '''Beispiel''':
| |
|
| |
| --------------- certificate example ---------------
| |
|
| |
| Bag Attributes
| |
| localKeyID: …
| |
| friendlyName: ALSO Schweiz AG
| |
| subject=/C=CH/O=ALSO Schweiz AG/CN=*.also.com/emailAddress=info@also.com
| |
| issuer=/C=CH/O=SwissSign AG/CN=SwissSign Server Gold CA 2008 - G2
| |
| -----BEGIN CERTIFICATE-----
| |
| MII…
| |
| …
| |
| …xmQ=
| |
| -----END CERTIFICATE-----
| |
|
| |
|
| |
| Bag Attributes
| |
| localKeyID: …
| |
| subject=/C=CH/O=SwissSign AG/CN=SwissSign Server Gold CA 2008 - G2
| |
| issuer=/C=CH/O=SwissSign AG/CN=SwissSign Gold CA - G2
| |
| '''-----BEGIN CERTIFICATE-----'''
| |
| '''MII…'''
| |
| '''…'''
| |
| '''…0qo='''
| |
| '''-----END CERTIFICATE-----'''
| |
| Bag Attributes
| |
| localKeyID: …
| |
| subject=/C=CH/O=SwissSign AG/CN=SwissSign Gold CA - G2
| |
| issuer=/C=CH/O=SwissSign AG/CN=SwissSign Gold CA - G2
| |
| -----BEGIN CERTIFICATE-----
| |
| MII…
| |
| …
| |
| …ZfJ
| |
| -----END CERTIFICATE-----
| |
|
| |
| --------------- certificate example ---------------
| |
|
| |
| In diesem .crt File ist ein Zertifikat für CN=*.also.com zu sehen (erster Abschnitt). Dieses ist
| |
| signiert worden vom Intermediate Certificate '''CN=SwissSign Server Gold CA 2008 - G2'''. Der
| |
| dazugehörige (im Beispiel Fett markiert) Abschnitt muss für unserem Fall in ein .crt File gespeichert
| |
| werden, welches dann als '''CA-Certificate''' in der Fortigate importiert werden kann. Im letzten
| |
| Abschnitt in diesem Beispiel ist das CA Certificate '''CN=SwissSign Server Gold CA 2008 - G2'''
| |
| aufgeführt. Ist das Certificate aufgeführt als "Vertrauenswürdiges Certificate" so muss es nicht
| |
| hinterlegt resp. importiert werden. Ist dies nicht der Fall muss in die CA auf der Fortigate
| |
| importiert werden.
| |
|
| |
| '''ACHTUNG HINWEIS FUER FORTIMAIL'''
| |
| Ist das Certificate signiert/gezeichnet worden von einem '''Intermediate Zertifikat''' muss folgendes berücksichtigt werden:
| |
|
| |
| Das Intermediate Zertifikat darf '''NICHT''' als '''CA Certificate''' eingelesen werden sofern das
| |
| .crt File '''NICHT NUR''' das public Certificate selbst sondern die '''GESAMTE''' Certificate Informationen
| |
| enthält (wie obiges Certifcate Beispiel). Ist dies der Fall gibt Fortimail die gesamten Informationen weiter!
| |
|
| |
| === Wie kann ich ein "Local Certificate" von einer FortiGate exportieren und in eine andere FortiGate importieren? ===
| |
|
| |
| Wenn zB ein Hardware Upgrade betreffend einer FortiGate durchgeführt (zB FG-60D auf FG-100D) wird kann durch Manipulation des Backup Files ein Restore auf der neuen FortiGate durchgeführt werden. Durch den Restore anhand des Backup Files wird das "Local Certificate" ebenfalls Wiederhergestellt. Ist jedoch so ein Restore auf der neuen FortiGate nicht möglich muss das "Local Certificate" zuerst auf der alten FortiGate exportiert werden sowie auf der neun importiert. Nachfolgend die Schritt die dazu nötig sind:
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Die nachfolgenden Schritte beschreiben den Export des "Private Key". zu diesem Zweck gehen wir von
| |
| folgenden Beispiel aus:
| |
|
| |
| -----BEGIN RSA PRIVATE KEY-----
| |
| Proc-Type: 4,ENCRYPTED
| |
| DEK-Info: DES-EDE3-CBC,21F46CF768868B66
| |
|
| |
| Zw+r9xa1L6r79qbsLnpk7o8Dj99fsdfsdfdYRFvPUhzC0ORelfcPzwrvDoyRQJKJ
| |
| QSfAIQ5lwaWsJoWw9e8O1nl8asdwesu4ui0u4LA2l7G6iJPyGy+QMZ2srA32p4iv
| |
|
| |
| [trunkated]
| |
|
| |
| bsLnpk7o8Dj99fjsJywFdYRFvPUhzC0ORelfcPzwrvDoyRQJKJfsf9sfsdfsfsfs
| |
| QSfAIQ5lwaWsJoWw9e8O1nl8o+EpYDu4ui0u4LA2l7G6iJPyGy+QMZ2srA32p4iv
| |
| -----END RSA PRIVATE KEY-----
| |
|
| |
| '''Alte FortiGate'''
| |
|
| |
| 1. Führe ein Login durch über Serial Console, Telnet oder SSH.
| |
| 2. Gebe folgenden Befehl ein:
| |
|
| |
| # config vpn certificate local
| |
| # show full
| |
|
| |
| Durch diesen Befehl werden all Zertifikate aufgelistet. Der "Private Key" wird in der Auflistung folgendermassen
| |
| aufgeführt:
| |
|
| |
| set private-key "-----BEGIN RSA PRIVATE KEY-----
| |
| Proc-Type: 4,ENCRYPTED
| |
| DEK-Info: DES-EDE3-CBC,21F46CF768868B66
| |
|
| |
| Zw+r9xa1L6r79qbsLnpk7o8Dj99fsdfsdfdYRFvPUhzC0ORelfcPzwrvDoyRQJKJ
| |
| QSfAIQ5lwaWsJoWw9e8O1nl8asdwesu4ui0u4LA2l7G6iJPyGy+QMZ2srA32p4iv
| |
|
| |
| [trunkated]
| |
|
| |
| bsLnpk7o8Dj99fjsJywFdYRFvPUhzC0ORelfcPzwrvDoyRQJKJfsf9sfsdfsfsfs
| |
| QSfAIQ5lwaWsJoWw9e8O1nl8o+EpYDu4ui0u4LA2l7G6iJPyGy+QMZ2srA32p4iv
| |
| -----END RSA PRIVATE KEY-----"
| |
|
| |
| Um den "Private Key" zu sichern muss folgendes in ein Text File (*.txt) gesichert werden (Achte darauf das die Zeichen "
| |
| nicht enthalten sind):
| |
|
| |
| -----BEGIN RSA PRIVATE KEY-----
| |
| Proc-Type: 4,ENCRYPTED
| |
| DEK-Info: DES-EDE3-CBC,21F46CF768868B66
| |
|
| |
| Zw+r9xa1L6r79qbsLnpk7o8Dj99fsdfsdfdYRFvPUhzC0ORelfcPzwrvDoyRQJKJ
| |
| QSfAIQ5lwaWsJoWw9e8O1nl8asdwesu4ui0u4LA2l7G6iJPyGy+QMZ2srA32p4iv
| |
|
| |
| [trunkated]
| |
|
| |
| bsLnpk7o8Dj99fjsJywFdYRFvPUhzC0ORelfcPzwrvDoyRQJKJfsf9sfsdfsfsfs
| |
| QSfAIQ5lwaWsJoWw9e8O1nl8o+EpYDu4ui0u4LA2l7G6iJPyGy+QMZ2srA32p4iv
| |
| -----END RSA PRIVATE KEY-----
| |
|
| |
| 3. Nun muss für "dieses" Zertifikat ein Passwort gesetzt werden. Dies wird folgendermassen durchgeführt:
| |
|
| |
| # config vpn certificate local
| |
| # get
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Durch "get" werden alle Einträge aufgelistet. Verifizieren den entsprechenden Eintrag und editiere
| |
| den entsprechenden Eintrag der unser Zertifikat darstellt:
| |
|
| |
| # edit [Name des entsprechenden Zertifikates]
| |
| # set password [Gebe ein entsprechenes Passwort an]
| |
| # end
| |
|
| |
| 4. Gehe nun auf das Web Mgmt. Interface und führe folgendes durch:
| |
|
| |
| System > Certificates > Local Certificates
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Wird im Web Mgmt. Interfaces die Menüposition "Certificates" nicht angezeigt muss diese unter folgender
| |
| Position aktiviert werden:
| |
|
| |
| System > Config > Features > Show More > Certificates
| |
|
| |
| Danach sollte ein Logout sowie ein erneutes Login durchgeführt werden!
| |
|
| |
| Markiere nun den Eintrag des entsprechenden Zertifikates und wähle "Download". Nun kann das Zertifikat als "*.cer"
| |
| runtergeladen werden.
| |
|
| |
| '''Neue FortiGate'''
| |
|
| |
| 1. Ueber das Web Mgmt. Interface auf den neuen FortiGate führe folgendes durch:
| |
|
| |
| System > Certificates > Local Certificates
| |
|
| |
| Wähle im Menü die Position "Import" und danach:
| |
|
| |
| Type Certificate
| |
| Certificate file [Gebe das *.cer File an]
| |
| Key File [Gebe das *.txt File an]
| |
| Password [Gebe das entsprechende Passwort an das gesetzt wurde]
| |
|
| |
| Nach dem Import kontrolliere ob das entsprechende Zertifikat unter der folgenden Position erscheint:
| |
|
| |
| System > Certificates > Local Certificates
| |
|
| |
| === Wir erstelle ich auf einer Fortigate einen Certificate Request und zeichne diesen im Microsoft root CA? ===
| |
|
| |
| Wenn man eine Certificate, dass auf einer Fortigate erstellt wurde (Certificate Request) innerhalb eines Microsoft root CA (Certificate Authority) zeichnen möchte um diesen nachträglich auf der Fortigate zu importieren gehe folgendermassen vor:
| |
|
| |
| '''ACHTUNG''' Fortiate unterstützt folgende zwei Formate: "DER" und "Base-64"
| |
|
| |
| --> Um den Certificate Requests zu erstellen der nachträglich im "Microsoft Root CA" gegengezeichnet werden kann wähle:
| |
|
| |
| '''System > Certificate > Local Certificate > Generate'''
| |
|
| |
| Geben nun folgende Angaben an:
| |
|
| |
| Certificate Name: [Name des Certificates]
| |
| ID Type: [Host IP / Domain Name (FQDN) / Email Adresse]
| |
|
| |
| Organization Unit: [zB ALSO Schweiz AG]
| |
| Organization : [zB Informatik]
| |
| Locality (City): [zB Emmen]
| |
| State/Province: [zB Luzern]
| |
| Country/Region: [zB Schweiz]
| |
| e-mail: [zB info@also.com]
| |
|
| |
| Key Type RSA
| |
| Key Size 2048 Bit
| |
|
| |
| Enrollment Method File Based
| |
|
| |
| Wenn man nun den "OK" Button anklickt wird im Hintergrund der "Requet" erstellt. Sieht man sich die Liste unter folgender Position an so erkennt man das dieser Request auf "Pending" steht. Dies bedeutet, dass dieser Request noch nicht gegengezeichnet ist:
| |
|
| |
| '''System > Certificate > Local Certificate'''
| |
|
| |
| Nun markiert man diese Zeile und geht oben auf die "Download" Position um den Request runterzuladen. Dabei ist wichtig den Download so runterzuladen damit er in einem File gespeichert wird (.csr). Dieses File -wenn man es sich ansieht (zB Wordpad)- sieht folgendermassen aus (es darf nicht gespeichert werden im Wordpad sonst kann das File unbrauchbar werden):
| |
|
| |
| [[Datei:Fortinet-219.jpg]]
| |
|
| |
| Danach geht man auf die "Microsoft Certificat Authority" Konsole und führt folgendes aus:
| |
|
| |
| [[Datei:Fortinet-220.jpg]]
| |
|
| |
| [[Datei:Fortinet-221.jpg]]
| |
|
| |
| [[Datei:Fortinet-222.jpg]]
| |
|
| |
| [[Datei:Fortinet-223.jpg]]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Dieses File das hier gespeichert wird MUSS auf der Fortigate unter den "Local Certificates" importiert werden,
| |
| denn dieses Certificate stellt unser gezeichnetes Certificate dar!
| |
|
| |
| Zurück auf der Fortigate führen wir den Import Vorgang durch:
| |
|
| |
| [[Datei:Fortinet-224.jpg]]
| |
|
| |
| [[Datei:Fortinet-225.jpg]]
| |
|
| |
| Nun das Problem das noch besteht ist das der Fortigate Device momemtan kein Root Certificat hat vom "Microsoft root CA". Dieses muss zuerst aus dem "Certicate Authority" exportiert werden um nachträglich wiederum auf der Fortigate importiert werden. Führe folgendes durch:
| |
|
| |
| [[Datei:Fortinet-226.jpg]]
| |
|
| |
| [[Datei:Fortinet-227.jpg]]
| |
|
| |
| [[Datei:Fortinet-228.jpg]]
| |
|
| |
| [[Datei:Fortinet-229.jpg]]
| |
|
| |
| Erstelle nun eine Verbindung zur Fortigate und importiere das soeben exportierte Certificate:
| |
|
| |
| [[Datei:Fortinet-230.jpg]]
| |
|
| |
| Dieses "Microsoft root CA" muss nun nur noch in den Broswer auf jedem Client/Workstation importiert werden dh. als "Vertrausenwürdiges Stammzertifikat". Das Certificate ist nun importiert und steht vers. Funktionen zur Verfügung dh. zB kann eine Fortigate Anmeldung des Admin Users (über einen Brosser) über ein Certificate durchgeführt werden. Dafür muss folgender Befehl über CLI abgesetzt werden:
| |
|
| |
| # config system global
| |
| # set admin-server-cert "Admin_Users"
| |
| # end
| |
|
| |
| Wenn dies durchgeführt wird muss bei der ersten Verbindung (Browser) das Certifcate (public key) importiert werden dh. in den Container "vertrauenswürdige Stammzertifikate".
| |
|
| |
| === Wie installiere ich für FortiClient für iOS (Apple) ein Zertifikat auf den entsprechenden Device? ===
| |
|
| |
| Weitere Informationen siehe Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_installiere_ich_f.C3.BCr_FortiClient_f.C3.BCr_iOS_.28Apple.29_ein_Zertifikat_auf_den_entsprechenden_Device.3F]]
| |
|
| |
| === Was ist im Allgemeinen der Unterschied zwischen "SSL Certificate Inspection" und "Full SSL Inspection"? ===
| |
|
| |
| Dieser Artikel beschreibt im Allgemeinen den technischen Unterschied zwischen "SSL Certificate Inspection" und "Full SSL Inspection". Dies bedeutet: der Artikel beschreibt nicht im technischen Sinne speziell die Funktion des WebFilters (URL Scan Only" sondern beschreibt im Allgemeinen die Funktion die für alle UTM/Security Profiles zu tragen kommen! Als Hintergrund Information folgendes: Transport Layer Security (TLS) und dessen Vorgänger sowie Secure Sockets Layer (SSL) sind kryptographische Protokolle, um eine sichere Komunikation im Internet zu gewährleisten. Diese kryptographische Protokolle benützen x.509 Zertifikate damit eine asymmetrische Kryptographie für die Authentifizierung ermöglicht wird. Dies bedeutet: Durch diese Authentifizierung wird die Gegenpartei durch einen symmetrischen Schlüssel Authentifiziert resp. erkannt. Dieser symmetrische Schlüssel wird dann verwendet, um Daten zwischen den Parteien zu verschlüsseln. Damit X.509 Zertifikaten angewendet werden können, sind Zertifizierungsstellen und eine öffentliche Schlüssel-Infrastruktur notwendig, um eine Ueberprüfung zwischen den Zertifikaten durchzuführen. Da ein Protokoll entweder mit oder ohne TLS (oder SSL) betrieben werden kann, ist es erforderlich, dass der Client dem Server dies übermittelt resp. eine TLS Verbindung initiert. Eine Möglichkeit des Client dies dem Server mitzuteilen ist ein spezifischer Port zu benützen (zB 443 https). Eine andere Möglichkeit wäre, wenn der Client dem Server dies übermittelt zB auf TLS zu wechseln. Dabei werden Protokoll spezifische Mechanismen benutzt wie zB für TLS den STARTTLS Befehl(SMTP). Durch diesen STARTTLS Befehl übermittelt im SMTP Protokoll der Client dem Server die Absicht auf TLS zu wechseln, um die Komunikation verschlüsselt (TLS) durchzuführen. Sobald dies geschieht, wird durch eine Stateful Verbindung im Zusammenhang mit eine Handshake Verfahren (siehe Punkt 6) und durch vereinbarte Parameter eine verschlüsselte Verbindung zwischen Server und Client etabliert.
| |
|
| |
| 1. Der Client sendet dem Server seine SSL-Versionsnummer, Cipher Einstellungen, Session-spezifische Daten und andere Informationen,
| |
| die der Server benötigt um mit dem Client eine verschlüsselte Verbindung (SSL) zu etablieren.
| |
|
| |
| 2. Der Server sendet dem Client ebenfalls seine SSL-Versionsnummer, Cipher Einstellungen, Session-spezifische Daten und andere Informationen,
| |
| die der Server benötigt um mit dem Client eine verschlüsselte Verbindung (SSL) zu etablieren. Der Server sendet ebenfalls sein eigenes
| |
| Zertifikat zum Client. Werden durch den Client Server-Resourcen angefragt, die eine Authentifizierung des Client Voraussetzen, fordert
| |
| der Server ebenfalls für die Authentifizierung das Zertifikat des CLient an.
| |
|
| |
| 3. Der Client verwendet die Informationen die vom Server gesendet wurden, um die Server-Authentifizierung durchzuführen zB im Fall eines
| |
| Web-Browsers wird eine Verbindung zu einem Web-Server etabliert. Der Browser prüft, ob der Name des empfangene Zertifikat gleich dem
| |
| Namen des Servers ist (Fully Qulified Domain Name), der Aussteller des Zerfikates eine annerkannte Zertifizierungsstelle ist (Trusted CA;
| |
| Certificate Authority), das Zerfikat noch gültig ist resp. nicht abgelaufen ist (Datum) und ob es nicht Wiederrufen (revoked) wurde
| |
| (siehe Punkt 7). Wenn der Server durch diese Informationen nicht Authentifiziert werden kann, wird der Benutzer von dem Problem gewarnt
| |
| und darüber informiert, dass eine verschlüsselte und authentifizierte Verbindung nicht hergestellt werden kann (Browser Meldung). Wenn
| |
| der Server erfolgreich authentifiziert wird, geht der Client zum nächsten Schritt.
| |
|
| |
| 4. Mit allen bisher im Handshake erzeugten Daten zwischen Client und Server -abhängig von den Cipher Einstellungen-, sendet der Client
| |
| seinen erstellten "pre-master key" für die verschlüsselte Verbindung dem Server, der verschlüsselt wurde anhand des "public key" des
| |
| Servers (Zertifikat des Servers).
| |
|
| |
| 5. Wenn der Server zum Client eine Authentifizierung Anfrage sendet (Optional im Handshake), signiert der Client Daten die Einzigartig sind
| |
| innerhalb des Handshake's und beiden bekannt sind dh. Client und Server. In so einem Fall sendet der Client zum Server beides dh. das
| |
| einzigartige signierte Datenpacket und sein eigenes Zertifikat sowie den erstellten und verschlüsselten "pre-master key".
| |
|
| |
| 6. Wenn der Server eine Client-Authentifizierung angefordert hat, versucht der Server den Client anhand der übermittelten Daten zu Authentifizieren.
| |
| Wenn der Client nicht Authentifiziert werden kann, endet die Sitzung. Wenn der Client erfolgreich authentifiziert wird, verwendet der Server
| |
| seinen "private key" um den "pre-master" key des Client zu entschlüsseln und führt einige Schritte durch um den "master key" zu generieren.
| |
| Diese Schritte führt der Client ebenfalls durch und benützt dabei den "pre-master" key.
| |
|
| |
| 7. Beide dh. der Client und der Master benützen den "master key" um den "session key" zu erstellen/generieren. Dieser "session key" ist ein
| |
| "symmetrischer key" der benutzt wird um die Informationen in der SSL Session zu ver-/entschlüsseln sowie die Integrität zu überprüfen.
| |
|
| |
| 8. Der Client sendet eine Nachricht zum Server, dass dessen Informationen für zukünftige Uebermittlungen anhand des "session key" verschlüsselt
| |
| werden. Danach sendet der Client eine getrennte verschlüsselte Meldung, dass der Handshake abgeschlossen ist.
| |
|
| |
| 9. Der Server sendet ebenfalls eine Nachricht an den Client, dass zukünftige Information Uebermittlungen anhand des "session key" verschlüsselt
| |
| werden. Danach sendet der Server ebenfalls einen getrennte verschlüsselte Meldung, dass der Handshake abgeschlossen ist.
| |
|
| |
| 10. Der SSL Handshake ist nun abgeschlossen und die Session beginnt. Der Client/Server benützen nun beide den "session key" um die Daten bei der
| |
| Uebertragen zu ent-/verschlüsseln sowie die Datenintegrität zu überprüfen.
| |
|
| |
| '''SSL Certificate Inspection:'''
| |
| Wenn nun eine "SSL Certificat Inspection" auf einer FortiGate benützt wird so wird der SSL Handshake nicht beeinflusst jedoch liest die
| |
| FortiGate das SNI Feld des Zertifikates aus. Das SNI Feld ist ist eine TLS Erweiterung und beinhaltet die komplette URL die aufgerufen
| |
| wird. Dies wird von den meisten modernen Browsern unterstützt sofern TLS benutzt wird. Wenn jedoch dies durch den Browser nicht unterstützt
| |
| wird liest die FortiGate den "CN" (Common Name) des Zertifikates mit. Der "CN" Teil beinhaltet im normal Fall einen Teil der URL dh. zB
| |
| den FQDN (Fully Qualified Domain Name). Dieser "CN" wird herangenommen um das WebFiltering durchzuführen resp. die Kategorisierung. Dies
| |
| bedeutet: Durch eine "SSL Certificate Inspection" wird nur das SNI Feld ausgelsen oder der "CN" und die FortiGate ist nicht fähig in den
| |
| TLS/SSL Inhalt reinzuschauen und somit Daten und dessen Inhalt zu verifizieren/auszulesen (Keine Full SSL Inspection).
| |
|
| |
| '''Full SSL Inspection:'''
| |
| Wenn dies Art der Inspection verwendet wird, übernimmt die FortiGate den Part des Servers (Man of the middle) resp. simuliert den Server
| |
| selber. Den Client Part übernimmt ebenfalls die FortiGate selber nicht der Client resp. Workstation. In dieser Konstellation ist klar das
| |
| der SSL/TLS Handshake unterbrochen wird und die FortiGate ist erforderlich um ein Zertifikat zur Verfügung zu stellen, dass durch den Client
| |
| resp. durch die URL angefordert wird. Da die FortiGate zwischen den effektiven Client Server steht (man of the middle), muss der FortiGate
| |
| Device dieses Zertifikat zur Verfügung stellen, um einen korrekten Handshake durchzuführen. Dieses Zertifikat wird durch die FortiGate selber
| |
| signiert. Da die FortiGate kein anerkannte Zertifizierungsstellen erkennen kann (Trusted Certificate Authority), um dieses zu signieren, wird
| |
| eine Warnmeldung an den Client ausgegeben die besagt, dass der Unterzeichner des Zertifikates keiner anerkannten Zertifizierungs Stelle
| |
| entspricht. Bei Verwendung dieser Inspection fließt der Traffic von dem Server zur FortiGate verschlüsselt und von der FortiGate an den Client
| |
| ebenfalls verschlüsselt. Der einzige Teil in der Traffic unverschlüsselt ist, wäre auf der FortiGate selber. Dadurch wird es der FortiGate
| |
| ermöglicht in die Daten (Inspection) reinzuschauen und UTM/Security Profiles im Full SSL Inspection Mode (nicht nur WebFilter wie SSL
| |
| Certificate Inspection) anzuwenden wie Antivirus, WebFilter etc. Um dies zu ermöglichen muss das "SSL_Proxy_Inspection Zertifikat" auf der
| |
| Workstation/Client importiert werden als "Vertrauenswürdige Stammzertifikate" (Trusted Authority). Nur so kann verhindert werden, dass keine
| |
| entsprechende Zertifikatsmeldung auf der Workstation/Client erscheint sowie das Zertifikat als "Vertrauenswürdiges Stammzertifikat" erkannt
| |
| wird und somit keine Warnmeldung erscheint.
| |
|
| |
| '''Fazit'''
| |
| Möchte man "alle" UTM/Security Profiles im Full SSL Inspection benutzen, muss ein entsprechendes Zertifikat auf dem Client als
| |
| "Vertrauenswürdiges Stammzertifikat" importiert werden. Dabei ist zu berücksichtigen, dass einige Browser nicht auf das auf dem
| |
| Betriebssystem zur Verfügung stehenden Repositories der "Vertrauenswürdigen Stammzertifikate" zurück greiffen sondern Ihre eigenen
| |
| Repositories benutzen.
| |
|
| |
| Wenn man "nur" WebFiltering im SSL benutzen möchte kann eine SSL Certificat Inspection durchgeführt werden was "kein" Zertifikat
| |
| auf der Workstation/Client benötigt. Alle anderen UTM/Security Profiles haben im SSL Certificat Inspection keine Auswirkungen resp.
| |
| können nicht genutzt werden da eine Full Inspection Möglichkeit fehlt.
| |
|
| |
| Nachfolgenden Links geben weitere Informationen betreffend diesem Thema im Zusammenhamg mit Zerfifikaten sowie Inspectio Mode und URL Scan Only (Certicate Inspection):
| |
|
| |
| [[Allgemein:Zertifikate-SymmetrischeAsymmetrische]]
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_funktioniert_der_HTTPS_scan_innerhalb_des_WebFilter_wenn_.22Deep_Inspection.22_nicht_aktiviert_ist_.28Scan_Encrypted_Connections_.2F_HTTPS_URL_Scan_Only.29.3F]]
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_wird_das_.22Scan_Encrypted_Connections_.2F_HTTPS_URL_Scan_Only.22_ohne_.22Deep_Inspection.22_konfiguriert.3F]]
| |
| [[FortiGate-5.0-5.2:FAQ#Wann_muss_ich_die_UTM_SSL_Proxy.2FProtocol_Options_in_der_Firewall_Rule_aktivierten_und_definieren.3F]]
| |
|
| |
| === Gibt es eine Möglichkeit "Root CA" Zertifikate manuell aus dem Internet runterzuladen und auf eine FortiGate zu importieren? ===
| |
|
| |
| Basierend auf FortiOS 5.0 sowie 5.2 kontrolliert eine FortiGate betreffend Zertifikate ausschliesslich den CN (Common Name) sowie das Datum eines Zertifikates. Die effektive Kontrolle der Zertifikate selber anhand der "Root CA" sowie wie diese zB im Internet Explorer anhand des Containers "Stammzertifikate" durchgeführt wird ist nicht möglich da eine FortiGate über keine Liste der "Root CA" verfügt. Da würde es "theoretischerweise" naheliegen diese Liste der "Root CA's" selber zu importieren. Dies ist "theoretischerweise" auch möglich ist jedoch ein manueller Vorgang und im effektiven Sinne nicht praktikable da diese Liste immer "up-to-date" gehalten werden müsste. Ebenso müsste die Liste für andere "CA's" ebenso unterhalten werden dh. bei zB Unternehmen die Ihre eigene "CA" propagieren. Aus diesem Grund ist die das importieren der "Root CA" auf einer FortiGate ein theoretischer Lösungsansatz jedoch aus unserer Sicht nicht praktikable da aus administrativer Sicht zu intensiv. Der nachfolgende Artikel beschreibt und zeigt wie die Liste der "Root CA" manuell aus dem Internet (Mozilla CA Tree) heruntergelade werden kann sowie diese in auf eine FortiGate importiert werden kann:
| |
|
| |
| [[Allgemein:Zertifikate-SymmetrischeAsymmetrische#Gibt_es_eine_M.C3.B6glichkeit_.22Root_CA.22_Zertifikate_manuell_aus_dem_Internet_runterzuladen.3F]]
| |
|
| |
| == User / Gruppen ==
| |
|
| |
| === Was ist die maximal Länger eines Passwortes für eine User Authentication? ===
| |
|
| |
| Unter FortiOS 5.0 war die maximal Länge eines Passwortes für eine User Authentication in den verschiedenen Funktionen unterschiedlich. Ab FortiOS 5.2 wurde dies vereinheitlich dh. Jede Authentifizierung im Zusammenhang mit einem User ist die maximale Länge des Passwortes:
| |
|
| |
| 128 Zeichen
| |
|
| |
| Die Authentifizierung im Zusammenhang mit einem User ist so zu verstehen, dass zB für eine User Authentifizierung über LDAP ebenfalls unter FortiOS 5.2 die max. Länge von 128 Zeichen gilt!
| |
|
| |
| === Wie kann ich für die Authentication ein "debug" ausführen um ein Troubleshooting durchzuführen? ===
| |
|
| |
| Wenn für diverse Funktionen auf einer FortiGate eine Authentifizierung konfiguriert wird und nachträglich bei Problemen ein "debug" ausgeführt werden soll, kann dies über den "FortiGate None-Blocking Auth Deamnon" durchgeführt werden. Diese wird folgendermassen ausgeführt:
| |
|
| |
| '''Setze den Debug Filter zurück:'''
| |
|
| |
| # diagnose debug reset
| |
|
| |
| '''Setze einen neuen Debug Filter:'''
| |
|
| |
| # diagnose debug application fnbamd -1
| |
|
| |
| '''Aktiviere den Debug Modus mit dem gesetzen Debug Filter:'''
| |
|
| |
| # diagnose debug enable
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Wenn der Deamon "fnbamd" neu gestartet werden soll führe folgendes aus:
| |
|
| |
| # diagnose test application fnbamd 99
| |
|
| |
| Der "diagnose debug" Befehl ist "persistent" dh. auch wenn ausgeloggt wird läuft dieser im Hintergrund weiter und belastet -je nach Debugging- den Device im hohen Masse. Aus diesem Grund ist es wichtig den Debug wiederum zu "disablen" dh. führe folgendes aus:
| |
|
| |
| '''Deaktiviere den Debug Modus:'''
| |
|
| |
| # diagnose debug disable
| |
|
| |
| '''Setze den Debug Filter zurück:'''
| |
|
| |
| # diagnose debug reset
| |
|
| |
| '''Kontrolliere den Debug Filter ob dieser zurückgesetzt wurde:'''
| |
|
| |
| # diagnose debug info
| |
|
| |
| === Wie kann ich das das Passwort des User "admin" (Administrator) ändern? ===
| |
|
| |
| Das "admin" Passwort kann innerhalb des "Dashboards" unter folgenden Position geändert:
| |
|
| |
| [[Datei:Fortinet-16.jpg]]
| |
|
| |
| Das Passwort kann auch über die "Administratoren" Position geändert werden:
| |
|
| |
| [[Datei:Fortinet-17.jpg]]
| |
|
| |
| Möchte man das Passwort des User's admin über Kommandozeile ändern muss folgendes durchgeführt werden:
| |
|
| |
| # config system admin
| |
| # edit admin
| |
| # set password [Setze ein neues Passwort]
| |
| # next
| |
|
| |
| === Wie aktiviere ich für den User "admin" den Management Zugriff und was muss ich dabei berücksichtigen? ===
| |
|
| |
| Der User "admin" der per Standard existiert ist eine Administrator der über ein Profile "super_admin" (Volle Rechte) verfügt. Dieser User "admin" kann grundsätzlich auch gelöscht werden und mit einem neuen Administrator ersetzt werden basierend auf dem Profile "super_admin". Dies wird jedoch nicht empfohlen. Die Profile für die Administratoren können anhand neu angelegter Profile unter folgender Position erstellt werden:
| |
|
| |
| System > Admin > Admin Profile > Create New
| |
|
| |
| In einem Profile können vers. Funktionen im "Read Only, Read-Write sowie auf None" gesetzt werden und somit eingeschränkt werden. Weitere Einschränkungen in den einzelnen Funktionen die zur Verfügung stehen sind nicht möglich und stehen auch nicht auf Kommandozeile zur Verfügung. Wenn dies gewünscht wird muss ein FortiManager eingesetzt werden denn dieser ist Mandantenfähig. Ein zusätzlicher Administrator kann unter folgender Position erstellt werden und bei der Erstellung kann das entsprechende Profile dem Administrator hinzugefügt werden:
| |
|
| |
| System > Admin > Administrators
| |
|
| |
| Um den Zugriff für die Administratoren auf die FortiGate sei es per HTTPS, PING, HTTP, SSH zu gewährleisten muss auf einem entsprechenden Interface der nötige Service aktiviert werden. Dazu wähle folgendes:
| |
|
| |
| System > Network > Interfaces > [Wähle das entsprechende Interface zB "internal"] > Administrative Access > [Aktiviere den entsprechenden Service]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Dabei ist folgendes zu berücksichtigen: Im Hintergrund wird eine entsprechende "Local-In" Policy implementiert (Automatisch) die den Zugriff für
| |
| den entsprechenden Service "aus dem Segment" erlaubt. Dies bedeutet: Würde man HTTP auf dem Interface "internal" aktiviert würde folgende Rule
| |
| Automatisch im Hintergrund implementiert werden:
| |
|
| |
| Source [IP Range/Segment Interface oder "Trusted Host 1-3 ACL Administrator"]
| |
| Destination [IP des Interface]
| |
| Service [HTTP]
| |
| User [Administrator mit entsprechenden Rechte]
| |
| Action [Allow]
| |
|
| |
| Diese Policy kann eingsehen werden unter folgenden Punkt:
| |
|
| |
| Policy / Policy Objects > Policy > Local In > Administrative Access
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Leider ist diese "Local In" Policy nicht sehr Transparent dh. es wird unter "Administrative Access" nicht detailliert angezeigt WAS
| |
| Implementiert wurde. Dies bedeutet die "Trusted Host 1-3" für Administratoren werden nicht abgebildet!
| |
|
| |
| Wenn ein Administrator zB User "admin" mit "Trusted Host 1-3" versehen wird werden die aktivierten Services ebenfalls auf diese "Trusted Host 1-3" beschränkt. Dies bedeutet würde man auf Interface "wan1" HTTPS und PING aktivieren und den User "admin" beschränken auf eine bestimmte Public IP würde ein Login auf HTTPS sowie ein PING nur noch von dieser Source möglich sein. "Trusted Host 1-3" werden innerhalb eines Administrators und folgender Position definiert:
| |
|
| |
| System > Admin > Administrators > [Wähle den entsprechenden Administrator] > [Aktiviere "Restrict this Administrator Login from Trusted Hosts Only"] > [Definiere "Trusted Host" IP Range]
| |
|
| |
| Wenn die Konfiguration auf Kommandozeile durchgeführt werden möchte ist folgendes durchzuführen:
| |
|
| |
| '''Aktivieren eines Service auf einem Interface'''
| |
| # config system interface
| |
| # edit [Name des Interfaces]
| |
| # set allowaccess [http | https | ping | ssh | telnet]
| |
| # end
| |
|
| |
| '''Hinzufügen von "Trusted Host" für einen Administrator'''
| |
| # config system admin
| |
| # edit [Name des Administrators zB "admin"]
| |
| # set trusthost1 [IPV4 Adresse mit Subnet Mask zB "192.168.1.0 255.255.255.0"]
| |
| # set trusthost2 [IPV4 Adresse mit Subnet Mask zB "192.168.1.0 255.255.255.0"]
| |
| # set trusthost3 [IPV4 Adresse mit Subnet Mask zB "192.168.1.0 255.255.255.0"]
| |
| # set trusthost4 [IPV4 Adresse mit Subnet Mask zB "192.168.1.0 255.255.255.0"]
| |
| # set trusthost5 [IPV4 Adresse mit Subnet Mask zB "192.168.1.0 255.255.255.0"]
| |
| # set trusthost6 [IPV4 Adresse mit Subnet Mask zB "192.168.1.0 255.255.255.0"]
| |
| # set trusthost7 [IPV4 Adresse mit Subnet Mask zB "192.168.1.0 255.255.255.0"]
| |
| # set trusthost8 [IPV4 Adresse mit Subnet Mask zB "192.168.1.0 255.255.255.0"]
| |
| # set trusthost9 [IPV4 Adresse mit Subnet Mask zB "192.168.1.0 255.255.255.0"]
| |
| # set trusthost10 [IPV4 Adresse mit Subnet Mask zB "192.168.1.0 255.255.255.0"]
| |
| # end
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> IM Web Mgmt. Interface sind die "trusthost" Einträge limitiert für FortiOS 5.0.x dh. auf 3. Ab FortiOS 5.2.x max 10 Einträge
| |
| zur Verfügung. Auf Kommandozeile stehen für FortiOS 5.0.x sowie 5.2.x max. 10 Einträge zur Verfügung.
| |
|
| |
| === Wenn das Passwort des User's "admin" (Administrator) nicht mehr bekannt ist wo kann ich dieses zurücksetzen/neu setzen? ===
| |
|
| |
| Als Grundvorraussetzung muss die '''Serien Nummer''' der Fortigate bekannt sein, denn diese wird benötigt um sich als User '''maintainer''' einzuloggen. Zugleich ist dieser Vorgang nur anhand einer Seriellen Verbindung möglich:
| |
|
| |
| -> Erstelle eine Serielle Console.
| |
|
| |
| 8 bits
| |
| no parity
| |
| 1 stop bit
| |
| 9600 baud (the FortiGate-300 uses 115,000 baud)
| |
| Flow Control = None
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Weitere Informationen betreffend RS-232 Console findet man im folgenden Artikel:
| |
|
| |
| FortiGate-5.0-5.2:FAQ#Was_f.C3.BCr_ein_Kabel_ben.C3.B6tige_ich_f.C3.BCr_den_Consolen_Anschluss_.28Seriell_RS232.29_einer_Fortinet.3F
| |
|
| |
| -> Schalte den Device aus und ein oder starte diesen neu.
| |
| -> Sobald der Login erscheint gebe ein:
| |
|
| |
| User = maintainer
| |
| Password = bcpbFGT[Serien Nummer ohne Produktbezeichnung "FGT" dh. zB 60C4613015338]
| |
| Welcome!
| |
|
| |
| # config system admin
| |
| # edit admin
| |
| # set password [Neues Passwort]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Dieser Vorgang im Ganzen dh. das Einloggen anhand des Users "maintainer" steht nach dem ersten
| |
| erscheinen des regulären "login's" 2 Minuten zur Verfügung (auf einigen Devices nur 14 Sekunden) dh.
| |
| wird innerhalb dieser 2 Minuten der User "maintainer" nicht benutzt für das Einloggen so deaktiviert
| |
| sich dieser Funktion dh. muss diese wiederum genutzt werden so muss erneut ein Neustart ausgeführt
| |
| werden! Dieser Vorgang dh. das Zurücksetzen des Superadmin Passwort ist für alle Geräte von Fortinet
| |
| durchzuführen. Für das Passwort des Users "maintainer gilt:
| |
|
| |
| bcpb[Fortinet Produkt Bezeichnung zB FortiGate "FGT" oder FortiWifi "FWF"][Serien Nummer ohne Produktbezeichnung]
| |
|
| |
| Möchten man die "Funktion" des "maintainer" deaktivieren dh. keine Möglichkeit geben diesen zu benutzen so kann
| |
| dies folgendermassen durchgeführt werden:
| |
|
| |
| # config system global
| |
| # set admin-maintainer disable
| |
| # end
| |
|
| |
| Anstelle des "maintainer" -der nur benutzt werden kann über die lokale Consolen- kann auch der Consolen Port komplett
| |
| deaktiviert werden. Nähere Informationen siehe Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_setze_ich_eine_Fortigate_auf_.22Factory_Defaults.22.3F]]
| |
|
| |
| Fortinet hat im Juli 2013 ein Dokument unter "SysAdmin's Notebook" released das diesen Vorgang ebenfalls beschreibt/zeigt:
| |
|
| |
| [[Datei:Resetting_a_lost_admin_password.pdf]] (Resetting a lost admin password)
| |
|
| |
| === Kann ich das Timeout für ein Login komplett ausschalten? ===
| |
|
| |
| Per Standard für eine FortiGate ein "Login Recording" durch dh. sobald ein Login durcheführt wird setzt ein Counter ein und zeichnet diesen Login auf. Sobald betreffend diesem Login ein "Timeout" erreicht wird so wird ein "Logout" durchgeführt. Unter FortiOS 5.0 ist das standard Verhalten einer FortiGate und kann -ausser ein Timeout zu setzen- nicht manipuliert werden. Unter FortiOS 5.2 kann das "Login Recording" komplett deaktiviert werden mit folgender globalen Option:
| |
|
| |
| # config system global
| |
| # set login-timestamp disable
| |
| # end
| |
|
| |
| Um unter FortiOS 5.0 die verschiedenen "Timeout's" zu setzen siehe nachfolgende Links:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_kann_ich_f.C3.BCr_die_User_und_Gruppen_das_Authentication_Timeoute_setzen.3F]]
| |
| [[FortiGate-5.0-5.2:FAQ#Welches_Timeout_gilt_f.C3.BCr_den_User_.22admin.22_.28Administrator.29_und_wo_manipuliere_ich_Dieses.3F]]
| |
|
| |
| === Gibt es eine Möglichkeit nicht erfolgreiche Admin Login's aufzulisten? ===
| |
|
| |
| Login's des Admin's werden im Hintergrund aufgezeichnet/geloggt. Ueber Gui sieht man diese Login's der Admins sei es erfolgreich oder nicht über die "Alert Message Console" dh.:
| |
|
| |
| System > Dashboard > Status > Alert Message Console
| |
|
| |
| Neu ab FortiOS 5.2.1 steht ebenfalls in der CLI folgendes Kommando zur Verfügung das "nicht erfolgreiche" Login's der Admin's auflistet:
| |
|
| |
| # diagnose debug admin error-log
| |
| The recent admin user failed login details:
| |
| error code : -102
| |
| method : ssh
| |
| login name : admin
| |
| cmdb name : admin
| |
| login vdom : root
| |
| current vdom : root
| |
| override vdom : null
| |
| login profile : super_admin
| |
| override profile: null
| |
| login time : 2014-09-22 10:43:19
| |
|
| |
| === Welches Timeout gilt für den User "admin" (Administrator) und wo manipuliere ich Dieses? ===
| |
|
| |
| Für den Administrator gilt 5 Minuten als Timeout. Dieses wird über folgenden Menüpunkt manipuliert:
| |
|
| |
| [[Datei:Fortinet-24.jpg]]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Ueber die Kommandozeile wird die Konfiguration folgendermassen durchgeführt:
| |
|
| |
| # config system global
| |
| # set admintimeout [Timeout Minutes]
| |
| # end
| |
|
| |
| Wenn das Timeout für den Administrator betreffend SSH angepasst werden soll siehe folgender Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_setze_ich_f.C3.BCr_den_User_.22admin.22_.28Administrator.29_das_Timeout_f.C3.BCr_SSH.3F]]
| |
|
| |
| Das Timeout kann unter FortiOS 5.2 auch komplett ausgeschaltet werden. Dazu siehe nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Kann_ich_das_Timeout_f.C3.BCr_ein_Login_komplett_ausschalten.3F]]
| |
|
| |
| === Wie konfiguriere ich für den User "admin" (Administrator) eine Public Key Authentication? ===
| |
|
| |
| Logge dich als User "root" auf dem System ein auf dem der Zugriff auf die FortiGate erfolgen soll. In unserem Beispiel wäre dies ein CentOS basierendes System. Nach dem Einloggen wechsle in das Root Verzeichnis des User's "root". In unserem Beispiel wäre dies "/root":
| |
|
| |
| # cd /root
| |
| # pwd
| |
| /root
| |
|
| |
| Die "Public Key Authentication" Informationen werden im User "root" Verzeichnis im Verzeichnis "/root/.ssh" abgelegt. Erstelle dieses Verzeichnis und vergebe die entsprechenden Rechte:
| |
|
| |
| # mkdir /root/.ssh
| |
| # chmod 700 /root/.ssh
| |
| # chown root:root /root/.ssh
| |
|
| |
| Als nächsten Schritt erstellen wir für die Public Key Authentication eine "privat" sowie einen "public" Key. Diese sind voneinander abhängig dh. der "public" Key basiert auf dem "privat" Key:
| |
|
| |
| # which ssh-keygen
| |
| /usr/bin/ssh-keygen
| |
|
| |
| # ssh-keygen -t rsa -f /root/.ssh/id_rsa
| |
| Generating public/private rsa key pair.
| |
| Enter passphrase (empty for no passphrase):
| |
| Enter same passphrase again:
| |
| Your identification has been saved in /root/.ssh/id_rsa.
| |
| Your public key has been saved in /root/.ssh/id_rsa.pub.
| |
| The key fingerprint is:
| |
| 2b:cf:8d:7f:51:cb:5b:d4:77:13:d4:79:93:ab:da:63 root@mydomain.local.intra
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Gebe keine "passphrase" ein sondern einfach "Enter"!
| |
|
| |
| Nach der erfolgreichen Generierung haben wir folgende Keys:
| |
|
| |
| # ls -la /root/.ssh/*
| |
| -rw------- 1 root root 1675 Dec 9 13:07 /root/.ssh/id_rsa
| |
| -rw-r--r-- 1 root root 408 Dec 9 13:07 /root/.ssh/id_rsa.pub
| |
|
| |
| Das File "id_rsa" stellt den "privat" Key dar und MUSS umbedingt geschützt werden dh. vergebeentsprechende Rechte:
| |
|
| |
| # chmod 600 /root/.ssh/id_rsa
| |
|
| |
| Der Public Key muss nun auf der FortiGate konfiguriert werden. Dies wird folgendermassen durchgeführt:
| |
|
| |
| # more /root/.ssh/id_rsa.pub
| |
| ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAsum+V+qTCDNAfjGCtgn/X771NZHveHJgHAfoi6JXjVpZ7Ojd7wQ/30jM7Ma8kwecbAdGV/MStq/lX2Z09qZ/Wkq3V0k+XctrNBOc5fR26vsMwZk5GeJuYLmhXD+agTNNDf1VfRhOKj7UcLoV45kKYBZwzkOFt1E0dODFcdOY+12LwVgAHGd5cPSR3tRXY07HEEnlob0fOSb6XuKZmpgBWhEfNbGBH2gI+bEJC9E9ZoqWYGF3Vi5RgvoeW8l9zSYwtj+zwG9VG0MN9SKJR6gAhqpSvSLsZEUkbNJ9zHocxMsIw4qZ+ATU9+QYhECJTfZmWWCuC1amyV+e1KljpiH9aQ== root@mydomain.local.intra
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> der "ssh-rsa" Key ist "eine" Zeile dh. achte darauf wenn die Information für "key-value"
| |
| im nächste Schritt auf der FortiGate konfiguriert wird!
| |
|
| |
| Auf der FortiGate führe folgendes aus:
| |
|
| |
| # config system admin
| |
| # edit admin
| |
| # set ssh-public-key1 "[key-type] [key-value]"
| |
| # end
| |
|
| |
| Für unseres Beispiel würde das folgendes bedeuten:
| |
|
| |
| # config system admin
| |
| # edit admin
| |
| # set ssh-public-key1 "ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAsum+V+qTCDNAfjGCtgn/X771NZHveHJgHAfoi6JXjVpZ7Ojd7wQ/30jM7Ma8kwecbAdGV/MStq/lX2Z09qZ/Wkq3V0k+XctrNBOc5fR26vsMwZk5GeJuYLmhXD+agTNNDf1VfRhOKj7UcLoV45kKYBZwzkOFt1E0dODFcdOY+12LwVgAHGd5cPSR3tRXY07HEEnlob0fOSb6XuKZmpgBWhEfNbGBH2gI+bEJC9E9ZoqWYGF3Vi5RgvoeW8l9zSYwtj+zwG9VG0MN9SKJR6gAhqpSvSLsZEUkbNJ9zHocxMsIw4qZ+ATU9+QYhECJTfZmWWCuC1amyV+e1KljpiH9aQ== root@mydomain.local.intra"
| |
| # end
| |
|
| |
| Nun ist alles bereit dh. vom Linux System aus kann nun ein Test durchgeführt werden:
| |
|
| |
| # ssh admin@mydomain.local.intra
| |
| The authenticity of host 'mydomian.local.intra (mydomain.local.intra)' can't be established.
| |
| RSA key fingerprint is 71:cb:81:d8:2d:e0:09:82:0a:c1:e9:28:10:05:ad:35.
| |
| Are you sure you want to continue connecting (yes/no)? yes
| |
| Warning: Permanently added 'mydomain.local.intra' (RSA) to the list of known hosts.
| |
| #
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Die Frage nach dem spezifischen Host der unsere FortiGate erscheint
| |
| nur einmal zu Beginn der ersten Verbindung! Bei der zweiten Verbindung
| |
| erscheint diese Frage nicht mehr. Der Host auf dem zugegriffen wird dh.
| |
| unsere FortiGate wird mit dessen Hostnamen und/oder IP im folgenden File
| |
| abgelegt:
| |
|
| |
| # cat /root/.ssh/known_hosts
| |
| mydomain.local.intra ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQDrSes+GhiRczY3D/X+AzEHp8X+esH017S4VeqFs4yaGh8rbyUb/iGIoeixqJkB3B1YxLlQ7jc5kgHXspoDl5XN2uoUjd65mBpXZ61/cezNZR+YFmCKCsozHsNjO+LZsvfgXmW03tdX6lL53MzGZdYrW7AOzI2SOJXE7kDANMh5xQ==
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Wechselt der Name resp. die IP des Hosts muss der entsprechende Eintrag im
| |
| File "known_hosts" gelöscht werden ansonsten wird der Zugriff verweigert!
| |
|
| |
| Zusätzlich zum SSH Zugriff kann SCP für den Admin auf der FortiGate aktiviert werden. Dazu siehe folgender Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_kann_ich_f.C3.BCr_den_User_.22admin.22_.28Administrator.29_zus.C3.A4tzlich_zum_SSH_SCP_aktivieren.3F]]
| |
|
| |
| Um den Zugang zu tesen benutze vom Linux System aus folgendes Kommando:
| |
|
| |
| # scp admin@mydomain.local.intra:sys_config /root/
| |
| sys_config 100% 104KB 20.7KB/s 00:05
| |
| # ls -la /root/sys_config
| |
| -rw------- 1 root root 106032 Dec 9 13:31 sys_config
| |
|
| |
| Dieser Vorgang kann nun benutzt werden um auf dem Linux ein autom. Backup der FortiGate zu erstellen! Dies kann zB anhand eines "crontab" Eintrages konfiguriert werden:
| |
|
| |
| # crontab -e
| |
|
| |
| -------------- crontab --------------
| |
|
| |
| 30 3 * * 0 scp admin@mydomain.local.intra:sys_config /root/$(date +%Y%m%d)-sys_config
| |
|
| |
| -------------- crontab --------------
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Der Cron Eintrag hat folgende Bedeutung und Aufbau:
| |
|
| |
| * * * * * [Path to script or command]
| |
|
| |
| * Minuten (0-59)
| |
| * Stunden (0-23)
| |
| * TagDesMonats (1-31)
| |
| * Monat des Jahres (1-12)
| |
| * TagDerWoche (0-6 with 0=Sunday)
| |
|
| |
| === Wie kann ich für den User "admin" (Administrator) zusätzlich zum SSH SCP aktivieren? ===
| |
|
| |
| Die Funktion SSH wird über folgende Positon aktiviert:
| |
|
| |
| System > Network > Interfaces > [Wähle das entsprechende Interface] > Administrative Access > [Aktiviere SSH]
| |
|
| |
| Diese Konfiguration umfasst auschliesslich SSH (per Standard auf Port 22) und nicht SCP. Möchte man SCP für den Administrator zusätzlich zu SSH freischalten führe auf der Kommandozeile folgendes durch:
| |
|
| |
| # config system global
| |
| # set admin-scp enable
| |
| # end
| |
|
| |
| === Wie setze ich für den User "admin" (Administrator) das Timeout für SSH? ===
| |
|
| |
| Per Standard gilt für den Administrator bezüglich SSH Timeout 2 Minuten (120 seconds). Um dieses Timeout anzupassen benutze folgenden Befehl auf der Console:
| |
|
| |
| # config system global
| |
| # set admin-ssh-grace-time [Angaben der Sekunden von 0 - 3600]
| |
| # end
| |
|
| |
| === Wie kann ich für eine User "admin" (Administrator) für HTTPS eine bestimmte TLS Version zB 1.0 deaktivieren? ===
| |
|
| |
| Ab FortiOS 5.2.2 gibt es unter den "config system global" eine Konfigurationsmöglichkeit um die benutzten TLS Versionen für den Web Mgmt. Zugriff über "https" zu definieren. Folgender Befehl steht zur Verfügung (Pers Standard ist TLS 1.1 sowie 1.2 aktiviert):
| |
|
| |
| # config system global
| |
| # set admin-https-ssl-versions [sslv3 | tlsv1-0 | tlsv1-1 | tlsv1-2]
| |
| # end
| |
|
| |
| Die aktiven Version dh. TLS Versionen können einfach überprüft werden sowie die benutzen "DH" Parameter. Dafür kann ein kleines Script installiert werden das über einen Linux Server ausgeführt werden kann. Kopiere den Inhalt des Files "Cipherscan.txt" in ein File auf dem Linux Server dh. zB:
| |
|
| |
| # mkdir /opt/scripts
| |
| # vi /opt/scripts/cipherscan
| |
| # chown root:root /opt/scripts/cipherscan
| |
| # chmod 700 /opt/scripts/cipherscan
| |
|
| |
| [[Datei:Cipherscan.txt]]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Weitere Scripte auf für Windows und Anweisung siehe Link https://github.com/jvehent/cipherscan. Eine
| |
| andere Möglichkeit einen Scan durchzuführen ist folgender Link zu benutzen:
| |
|
| |
| https://www.ssllabs.com/ssltest/
| |
|
| |
| Danach kann auf dem Linux ein Scan durchgeführt werden auf den Mgmt. Port der FortiGate sprich zB auf das LAN Interface. Der Port auf dem LAN Interface resp. HTTPS muss aktiviert sein. Wenn der Mgmt. Port nicht über Standard HTTPS 443 konfiguriert wurde muss der Port dem Script durch folgendes Kommando mitgegeben werden:
| |
|
| |
| # /opt/scripts/cipherscan 198.18.0.1:8443
| |
| custom openssl not executable, falling back to system one from /bin/openssl
| |
| .................................
| |
| Target: 198.18.0.1:8443
| |
|
| |
| 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 TLSv1.1,TLSv1.2 ECDH,prime256v1,256bits prime256v1
| |
| 4 DHE-RSA-AES256-GCM-SHA384 TLSv1.2 DH,1024bits None
| |
| 5 DHE-RSA-AES256-SHA256 TLSv1.2 DH,1024bits None
| |
| 6 DHE-RSA-AES256-SHA TLSv1.1,TLSv1.2 DH,1024bits None
| |
| 7 DHE-RSA-CAMELLIA256-SHA TLSv1.1,TLSv1.2 DH,1024bits None
| |
| 8 AES256-GCM-SHA384 TLSv1.2 None None
| |
| 9 AES256-SHA256 TLSv1.2 None None
| |
| 10 AES256-SHA TLSv1.1,TLSv1.2 None None
| |
| 11 CAMELLIA256-SHA 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 TLSv1.1,TLSv1.2 ECDH,prime256v1,256bits prime256v1
| |
| 15 DHE-RSA-AES128-GCM-SHA256 TLSv1.2 DH,1024bits None
| |
| 16 DHE-RSA-AES128-SHA256 TLSv1.2 DH,1024bits None
| |
| 17 DHE-RSA-AES128-SHA TLSv1.1,TLSv1.2 DH,1024bits None
| |
| 18 ECDHE-RSA-DES-CBC3-SHA TLSv1.1,TLSv1.2 ECDH,prime256v1,256bits prime256v1
| |
| 19 DHE-RSA-SEED-SHA TLSv1.1,TLSv1.2 DH,1024bits None
| |
| 20 DHE-RSA-CAMELLIA128-SHA TLSv1.1,TLSv1.2 DH,1024bits None
| |
| 21 EDH-RSA-DES-CBC3-SHA TLSv1.1,TLSv1.2 DH,1024bits None
| |
| 22 AES128-GCM-SHA256 TLSv1.2 None None
| |
| 23 AES128-SHA256 TLSv1.2 None None
| |
| 24 AES128-SHA TLSv1.1,TLSv1.2 None None
| |
| 25 SEED-SHA TLSv1.1,TLSv1.2 None None
| |
| 26 CAMELLIA128-SHA TLSv1.1,TLSv1.2 None None
| |
| 27 DES-CBC3-SHA TLSv1.1,TLSv1.2 None None
| |
| 28 ECDHE-RSA-RC4-SHA TLSv1.1,TLSv1.2 ECDH,prime256v1,256bits prime256v1
| |
| 29 RC4-SHA TLSv1.1,TLSv1.2 None None
| |
| 30 RC4-MD5 TLSv1.1,TLSv1.2 None None
| |
| 31 EDH-RSA-DES-CBC-SHA TLSv1.1,TLSv1.2 DH,1024bits None
| |
| 32 DES-CBC-SHA TLSv1.1,TLSv1.2 None None
| |
|
| |
| Certificate: UNTRUSTED, 1024 bit, sha1WithRSAEncryption signature
| |
| TLS ticket lifetime hint: 300
| |
| OCSP stapling: not supported
| |
| Cipher ordering: client
| |
|
| |
| Wie man vom "output" sieht sind die Version TLSv1.1 sowie 1.2 aktiv. Um nun die Version 1.1 zu deaktivieren führe folgendes aus:
| |
|
| |
| # config system global
| |
| # set admin-https-ssl-versions tlsv1-2
| |
| # end
| |
|
| |
| Nun kann abermals ein Scan ausgeführt werden:
| |
|
| |
| # /opt/scripts/cipherscan 198.18.0.1:8443
| |
| custom openssl not executable, falling back to system one from /bin/openssl
| |
| .................................
| |
| Target: 198.18.0.1:8443
| |
|
| |
| 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 TLSv1.2 ECDH,prime256v1,256bits prime256v1
| |
| 4 DHE-RSA-AES256-GCM-SHA384 TLSv1.2 DH,1024bits None
| |
| 5 DHE-RSA-AES256-SHA256 TLSv1.2 DH,1024bits None
| |
| 6 DHE-RSA-AES256-SHA TLSv1.2 DH,1024bits None
| |
| 7 DHE-RSA-CAMELLIA256-SHA TLSv1.2 DH,1024bits 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,prime256v1,256bits prime256v1
| |
| 13 ECDHE-RSA-AES128-SHA256 TLSv1.2 ECDH,prime256v1,256bits prime256v1
| |
| 14 ECDHE-RSA-AES128-SHA TLSv1.2 ECDH,prime256v1,256bits prime256v1
| |
| 15 DHE-RSA-AES128-GCM-SHA256 TLSv1.2 DH,1024bits None
| |
| 16 DHE-RSA-AES128-SHA256 TLSv1.2 DH,1024bits None
| |
| 17 DHE-RSA-AES128-SHA TLSv1.2 DH,1024bits None
| |
| 18 ECDHE-RSA-DES-CBC3-SHA TLSv1.2 ECDH,prime256v1,256bits prime256v1
| |
| 19 DHE-RSA-SEED-SHA TLSv1.2 DH,1024bits None
| |
| 20 DHE-RSA-CAMELLIA128-SHA TLSv1.2 DH,1024bits None
| |
| 21 EDH-RSA-DES-CBC3-SHA TLSv1.2 DH,1024bits None
| |
| 22 AES128-GCM-SHA256 TLSv1.2 None None
| |
| 23 AES128-SHA256 TLSv1.2 None None
| |
| 24 AES128-SHA TLSv1.2 None None
| |
| 25 SEED-SHA TLSv1.2 None None
| |
| 26 CAMELLIA128-SHA TLSv1.2 None None
| |
| 27 DES-CBC3-SHA TLSv1.2 None None
| |
| 28 ECDHE-RSA-RC4-SHA TLSv1.2 ECDH,prime256v1,256bits prime256v1
| |
| 29 RC4-SHA TLSv1.2 None None
| |
| 30 RC4-MD5 TLSv1.2 None None
| |
| 31 EDH-RSA-DES-CBC-SHA TLSv1.2 DH,1024bits None
| |
| 32 DES-CBC-SHA TLSv1.2 None None
| |
|
| |
| Certificate: UNTRUSTED, 1024 bit, sha1WithRSAEncryption signature
| |
| TLS ticket lifetime hint: 300
| |
| OCSP stapling: not supported
| |
| Cipher ordering: client
| |
|
| |
| Wie man sieht ist "nur" noch die Version TLSv1.2 aktiv. Was in diesem "output" ebenfalls ersichtlich ist sind die "ciphers" die eigentlich nicht benutzt werden sollen. Wenn man auf einem Linux Server das Package "openssl" vorhanden ist (which openssl) kann anhand des Client Teil von OpenSSL ein Test ausgeführt werden um festzustellen ob eine entsprechende "cipher" akzeptiert würde. Im nachfolgenden Beispiel wird getestet ob die "cipher" DES möglich ist:
| |
|
| |
| # openssl s_client -connect 198.18.0.1:8443 -cipher "DES"
| |
| CONNECTED(00000003)
| |
| depth=1 C = US, ST = California, L = Sunnyvale, O = Fortinet, OU = Certificate Authority, CN = support, emailAddress = support@fortinet.com
| |
| verify error:num=19:self signed certificate in certificate chain
| |
| verify return:0
| |
| ---
| |
| Certificate chain
| |
| 0 s:/C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=FortiGate/CN=FG300C3913601712/emailAddress=support@fortinet.com
| |
| i:/C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Certificate Authority/CN=support/emailAddress=support@fortinet.com
| |
| 1 s:/C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Certificate Authority/CN=support/emailAddress=support@fortinet.com
| |
| i:/C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Certificate Authority/CN=support/emailAddress=support@fortinet.com
| |
| ---
| |
| Server certificate
| |
| -----BEGIN CERTIFICATE-----
| |
| MIIDRTCCAi2gAwIBAgIDC9W6MA0GCSqGSIb3DQEBBQUAMIGgMQswCQYDVQQGEwJV
| |
| UzETMBEGA1UECBMKQ2FsaWZvcm5pYTESMBAGA1UEBxMJU3Vubnl2YWxlMREwDwYD
| |
| VQQKEwhGb3J0aW5ldDEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MRAw
| |
| DgYDVQQDEwdzdXBwb3J0MSMwIQYJKoZIhvcNAQkBFhRzdXBwb3J0QGZvcnRpbmV0
| |
| LmNvbTAeFw0xMzAzMDUwMjAyMzFaFw0zODAxMTkwMzE0MDdaMIGdMQswCQYDVQQG
| |
| EwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTESMBAGA1UEBxMJU3Vubnl2YWxlMREw
| |
| DwYDVQQKEwhGb3J0aW5ldDESMBAGA1UECxMJRm9ydGlHYXRlMRkwFwYDVQQDExBG
| |
| RzMwMEMzOTEzNjAxNzEyMSMwIQYJKoZIhvcNAQkBFhRzdXBwb3J0QGZvcnRpbmV0
| |
| LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAvbxgu84VKi3SL78ZpAdB
| |
| 5yaqOQfNf44KFwxFAqk94D8vjcNi0i0igSVdNZD80hRJUqbkVprgAaOPG4BvnadN
| |
| 2LIB0S1ajvjJfOctdfstpiVYRU2W3i5sjqkoRLyn1Vy0olZ3MVQMZUP0saPqQPnF
| |
| vrBSwDJ/CJ31mMMyyIP+JncCAwEAAaMNMAswCQYDVR0TBAIwADANBgkqhkiG9w0B
| |
| AQUFAAOCAQEANb9WMN1Tedd+qvQuYvtjCJm5XEgWuQNG3LfSsHFU7ZB2Sjybj39/
| |
| cfzHZuFdUtib6QPO1AuOvWyXZwIK8bcx6eFxoq7Ox6rTJVgJkw9XxoUbC2s2Du/o
| |
| CtfPNc5cJJ/Xjlmufr3mNUT+26kG1RG1E8+QViTsRzwT/L9+SIX4KDvqUaZI+gqj
| |
| 6VSgVD2EkUK2OtHS1CvtFsCbVpwBTmcKErjPcnUl1RyvWoBtMLDbHOc09r/joJoS
| |
| ruKoDlXKinkPMDeuazIR3JFYj40V3+OXXlSoc1H1DuXKKyZsZXFp9gKfoQXAllkO
| |
| qlBsAiyXAsieWQsQoiAyyAyNpp8zGgIKxA==
| |
| -----END CERTIFICATE-----
| |
| subject=/C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=FortiGate/CN=FG300C3913601712/emailAddress=support@fortinet.com
| |
| issuer=/C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Certificate Authority/CN=support/emailAddress=support@fortinet.com
| |
| ---
| |
| No client certificate CA names sent
| |
| Server Temp Key: DH, 1024 bits
| |
| ---
| |
| SSL handshake has read 2394 bytes and written 271 bytes
| |
| ---
| |
| New, TLSv1/SSLv3, Cipher is EDH-RSA-DES-CBC-SHA
| |
| Server public key is 1024 bit
| |
| Secure Renegotiation IS supported
| |
| Compression: NONE
| |
| Expansion: NONE
| |
| SSL-Session:
| |
| Protocol : TLSv1.2
| |
| Cipher : EDH-RSA-DES-CBC-SHA
| |
| Session-ID: F4B05A8E17FE406186242860D92EC90B9FF09EE731FE2C9DC3CE3B0EB57D50DC
| |
| Session-ID-ctx:
| |
| Master-Key: 36EDD661CE7E6688395FF8FF1F76349A1E7054F62EE4D55590A24BB1C15B6FDF9EC3B3B92A7ECF3731424F4F5D9C3626
| |
| Key-Arg : None
| |
| Krb5 Principal: None
| |
| PSK identity: None
| |
| PSK identity hint: None
| |
| Start Time: 1435042817
| |
| Timeout : 300 (sec)
| |
| Verify return code: 19 (self signed certificate in certificate chain)
| |
| ---
| |
|
| |
| Dieser "output" bestätigt die Verbindung kommt zu stande und dies ist im "generellen" schlecht dh. Grundsätzlich sollten folgende "cipher" deaktiviert werden:
| |
|
| |
| aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK, aECDH, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CDC3-SHA, KRB5-DE5, CBC3-SHA
| |
|
| |
| Die FortiGate bietet die Möglichkeit diese mit folgenden Befehl zu deaktiveren:
| |
|
| |
| # config system global
| |
| # set strong-crypto enable
| |
| # end
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Das aktivieren von "strong-crypto" beeinflusst den Mgmt. Access für HTTPS/SSH!
| |
|
| |
| Nun führen wir wiederum einen Test durch:
| |
|
| |
| # /opt/scripts/cipherscan 198.18.0.1:8443
| |
| custom openssl not executable, falling back to system one from /bin/openssl
| |
| ................
| |
| Target: 198.18.0.1:8443
| |
|
| |
| 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 TLSv1.2 ECDH,prime256v1,256bits prime256v1
| |
| 4 DHE-RSA-AES256-SHA256 TLSv1.2 DH,1024bits None
| |
| 5 DHE-RSA-AES256-SHA TLSv1.2 DH,1024bits None
| |
| 6 AES256-SHA256 TLSv1.2 None None
| |
| 7 AES256-SHA TLSv1.2 None None
| |
| 8 ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 ECDH,prime256v1,256bits prime256v1
| |
| 9 ECDHE-RSA-AES128-SHA256 TLSv1.2 ECDH,prime256v1,256bits prime256v1
| |
| 10 ECDHE-RSA-AES128-SHA TLSv1.2 ECDH,prime256v1,256bits prime256v1
| |
| 11 DHE-RSA-AES128-GCM-SHA256 TLSv1.2 DH,1024bits None
| |
| 12 DHE-RSA-AES128-SHA256 TLSv1.2 DH,1024bits None
| |
| 13 DHE-RSA-AES128-SHA TLSv1.2 DH,1024bits None
| |
| 14 AES128-SHA256 TLSv1.2 None None
| |
| 15 AES128-SHA TLSv1.2 None None
| |
|
| |
| Certificate: UNTRUSTED, 1024 bit, sha1WithRSAEncryption signature
| |
| TLS ticket lifetime hint: 300
| |
| OCSP stapling: not supported
| |
| Cipher ordering: client
| |
|
| |
| Nun sieht das Ganze korrekt aus dh. nur die gewünschten "cipher" sind aktiv und dies kann wiederum getestet werden zB anhand "DES":
| |
|
| |
| # openssl s_client -connect 198.18.0.1:8443 -cipher "DES"
| |
| CONNECTED(00000003)
| |
| 140357317728160: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
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Eine andere Variante dh. zB 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 [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 kommt die Verbindung nicht zustande dh. dies indiziert die Position "hadshare failure" sowie "New, (NONE), Cipher is (NONE)"! Wenn Wert gelegt wird auf Sicherheit sollte auf jeder FortiGate folgende Einstellungen durchgeführt werden:
| |
|
| |
| # config system global
| |
| # set strong-crypto enable
| |
| # set admin-https-ssl-versions tlsv1-2
| |
| # end
| |
|
| |
| Beachte jedoch durch die höhere Security leidet die Kompatibilität dh. ältere Browser sind nicht mehr fähig zu verbinden da diese "noch" die "alten" Versionen resp. tlsv1-0/1 usw. unterstützen.
| |
|
| |
| === Wie kann ich ein "Passwort Lockout" des User's "admin" (Administrator) konfigurieren/verändern? ===
| |
|
| |
| Wenn ein Administrator sich 3 X falsch anmeldet wird ein "Lockout" ausgeführt dh. für eine bestimmte Zeit kann der Administrator sich nicht mehr anmelden. Die Anzahl der Versuche sowie die Zeitspanne kann angepasst werden dh. führe folgendes auf der Console aus:
| |
|
| |
| # config system global
| |
| # set admin-lockout-threshold [Anzahl Möglichkeiten; Standard Wert ist 3]
| |
| # set admin-lockout-duration [Zeitspanne in Sekunden; Stanard Wert ist 60]
| |
| # end
| |
|
| |
| === Wie kann ich einen "read-only" Administrator konfigurieren/erstellen? ===
| |
|
| |
| Unter folgender Positionen kann für eine "Administrator" ein eigenes "Profil" erstellt werden zB "read-only" und dieses nachträglich einem "read-only" Administrator als Profil zugewiesen werden:
| |
|
| |
| [[Datei:Fortinet-18.jpg]]
| |
|
| |
| [[Datei:Fortinet-19.jpg]]
| |
|
| |
| [[Datei:Fortinet-20.jpg]]
| |
|
| |
| [[Datei:Fortinet-21.jpg]]
| |
|
| |
| [[Datei:Fortinet-22.jpg]]
| |
|
| |
| === Wie aktiviere ich für einen lokalen User Two-Faktor Authentication anhand ODA? ===
| |
|
| |
| Wenn man einen User lokal erfasst geschieht dies normalerweise anhand eines Usernamens und Passwortes. Möchte man nun -um die Sicherheit zu erhöhen- diesen User mit einem ODA (On Demand Authentication) versehen zB SMS Token kann dies auf Kommandozeile konfiguriert werden. Ausgangslage zu diesem Beispiel ist, dass ein Lokaler User mit Username und Passwort unter der folgenden Position erfasst wird:
| |
|
| |
| User & Device > User Definition > Create New
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Ab FortiOS 5.0.3 steht nach "Create New" ein Setup Wizard zur Verfügung. Wähle in diesem "Local User"
| |
| und vergebe einen Usernamen und Passwort. Definiere für SMS eine Mobiel Nummer sowie den SMS Server
| |
| jedoch aktiviere Two-Factor Authentication nicht! Dies geschieht über Kommandozeile!
| |
|
| |
| Um nun dem lokalen User zusätzlich zum Usernamen und Passwort beim Login ein SMS Token zu senden (ODA) führe für den entsprechenden User den wir erfasst haben folgende Konfiguration aus:
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Wenn ein SMS Server erfasst werden soll dh. "Custom" und nicht "FortiGuard" erfasse/konfiguriere diesen. Wie
| |
| das geschieht siehe folgender Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_konfiguriere_ich_meinen_eigenen_SMS_Provider.2FServer.3F]]
| |
|
| |
| # config user local
| |
| # edit [Wähle den entsprechenden User]
| |
| # set two-factor [Wähle disable | fortitoken | email | sms]
| |
| # set sms-server [Wähle fortiguard | custom]
| |
| # set sms-custom-server [Wähle den entsprechenden "Custom" SMS Server sofern vorhanden]
| |
| # set authtimeout [Setze das Timeout der Authentifizierung dh. "0 - 1440" wobei 0 = Global Konfiguration gilt]
| |
| # set auth-concurrent-override [Sind mehrfache Login's erlaubt "enable | disable]
| |
| # end
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Wenn für "authtimeout" 0 gewählt wird gilt die "Globale Konfiguration" diese wird folgendermassen
| |
| definiert:
| |
|
| |
| # config system global
| |
| # set two-factor-sms-expiry [Setze 30 bis 300 Sekunden; Standard ist 60 Sekunden gesetzt]
| |
| # two-factor-email-expiry [Setze 30 bis 300 Sekunden; Standard ist 60 Sekunden gesetzt]
| |
| # end
| |
|
| |
| Der User kann nun zB für das SSL-VPN Portal konfiguriert werden. Wenn sich der User einloggt gibt er normal Usernamen und Passwort ein. Im Hintergrund werden die Informationen übermittelt und wenn der User auf SMS Two Factor Authentication gesetzt ist, wird ein SMS ausgelöst sofern Usernamen und Passwort korrekt verifiziert wurden. Dem User wird auf eine neue Seite weitergeleitet auf der er den ODA Token (On Demand Authentication) -der im über SMS zugesendet wird- eingegeben kann (Token Code:)!
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Die Seite des SMS Token Code Eingabe kann über die "Replacement Message Groups" modifiziert und angepasst
| |
| werden!
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Was_sind_.22Replacement_Message_Groups.22_und_wie_verwende_ich_diese.3F]]
| |
|
| |
| Grundsätzlich kann die Funktion für jede Authentifizierung im Zusammenhang mit FortiGate benutzt werden inder ein User lokal definiert wird. Remote Authenentifizierungen innerhalb von Gruppen wie zB LDAP und/oder Radius können nicht zusätzlich mit einer Two Factor Authentification ausgestattet werden dazu benötigt man den FortiAuthenticator.
| |
|
| |
| === Wie kann ich für die User und Gruppen das Authentication Timeoute setzen? ===
| |
|
| |
| Ein "Authentication Timeout" kann auf Globaler Ebene gesetzt werden dh. für ALLE User oder auf gruppen Ebene für eine bestimmte Gruppe:
| |
|
| |
| '''Global für ALLE User (exkl. "admin"):'''
| |
| # config user setting
| |
| # set auth-timeout [Anzahl Minuten; per Standard 5; Maximum 1440 minutes (24 Stunden)]
| |
| # set auth-timeout-type [idle-timeout | hard-timeout | newsession]
| |
| # end
| |
|
| |
| '''Auf Gruppen Ebene:'''
| |
| # config user group
| |
| # edit [Name der Gruppe]
| |
| # set authtimeout [Anzahl Minuten; per Standard 0)
| |
| # end
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Falls ein User Mitglied von mehreren User Gruppen ist, bei welchen jeweils ein gruppenspezifisches
| |
| authtimeout konfiguriert wurde, gilt für den Benutzer das global definierte authtimeout (Default 5 Min.).
| |
| Ab FortiOS 5.2 kann das "Login" Timeout komplett in den globalen Optionen deaktiviert werden. Dazu siehe
| |
| nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Kann_ich_das_Timeout_f.C3.BCr_ein_Login_komplett_ausschalten.3F]]
| |
|
| |
| Desweiteren ist zu berücksichtigen, dass es für bestimte Funktionen wie den Admin, Console etc. spezifische Timeouts gibt die man explizit setzen kann:
| |
|
| |
| # config system global
| |
| # set admintimout [Globales "admin" Timeout; Möglicher Wert 480 Minuten (8 Stunden); Standard 5 Minuten]
| |
| # set admin-console-timeout [Ueberschreibt "admintimeout" für Console; Standard 0 = Kein Timeout resp. "admintimeout gilt]
| |
| # set admin-ssh-grace-time [Timout für SSH zwischen Verbindung und Authentication; Möglicher Wert 10 - 3600 Sekunden; Standard 120 Sekunden]
| |
|
| |
| # set remoteauthtimout 5
| |
| # end
| |
|
| |
| === Wie kann ich für jeden User (inkl. "admin") und/oder User in Gruppen ein "multiple login" verhindern? ===
| |
|
| |
| Per Standard erlaubt eine FortiGate "multiple" Login's der User, Gruppen sowie für den "admin" User von der gleichen sowie unterschiedlichen IP's/Subnet. Um dies zu verhindern kann für den "admin" folgende Option deaktiviert werden:
| |
|
| |
| # config system global
| |
| # set admin-concurrent [enable | disable]
| |
| # end
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Wenn diese Option deaktiviert wird dh. nur noch ein Login möglich ist sollte die Option des "admin" Timeouts
| |
| berücksichtigt werden dh. wird die Option "admin-concurrent" deaktiviert und die Verbindung zur FortiGate wird
| |
| unvorhergesehen unterbrochen kann in einigen Situationen nicht mehr eingeloggt werden solange das Timeout des
| |
| "admin" noch besteht! Weitere Informationen betreffend des "admin" Timout siehe folgender Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_kann_ich_f.C3.BCr_die_User_und_Gruppen_das_Authentication_Timeoute_setzen.3F]]
| |
|
| |
| Wenn ein "multiple login" für User/Gruppen verhindert werden soll so stehen folgende Optionen zur Verfügung:
| |
|
| |
| '''Global für ALLE User/Gruppen:'''
| |
| # config system global
| |
| # set policy-auth-concurrent [Multiple Logins Definition; Standard 0 = No Limit]
| |
| # end
| |
|
| |
| Sofern in „group“ und/oder „local“ override „enable“ gesetzt ist wird die Global Option überschrieben und gilt nicht mehr!
| |
|
| |
| '''Auf Gruppen Ebene (Ueberschreibt Globale Konfig):'''
| |
| # config user group
| |
| # edit [Name der Gruppe]
| |
| # set auth-concurrent-override [enable | disable]
| |
| # set auth-concurrent-value [Wenn "auth-concurrent-override" auf enable Definiton der Login's zB "1"]
| |
| # end
| |
|
| |
| '''Auf User Ebene (Ueberschreibt Globale Konfig):'''
| |
| # config user local
| |
| # edit [Name des User's]
| |
| # set auth-concurrent-override [enable | disable]
| |
| # set auth-concurrent-value [Wenn "auth-concurrent-override" auf enable Definiton der Login's zB "1"]
| |
| # end
| |
|
| |
| Auch bei den User/Gruppen ist das Timout zu berücksichtigen. Dazu siehe nachfolgenden Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_kann_ich_f.C3.BCr_die_User_und_Gruppen_das_Authentication_Timeoute_setzen.3F]]
| |
| [[FortiGate-5.0-5.2:FAQ#Was_kann_ich_betreffend_.22User_Authentication.22_auf_globaler_User_Ebene_sowie_Grupen_Ebene_konfigurieren.3F]]
| |
|
| |
| === Was kann ich betreffend "User Authentication" auf globaler User Ebene sowie Grupen Ebene konfigurieren? ===
| |
|
| |
| Betreffend Authentifizierung auf User Ebene sowie Gruppen Ebene sind verschiedenen Konfigurationen möglich. Eine davon wäre die Konfiguration des "Timeouts". Details siehe nachfolgenden Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_kann_ich_f.C3.BCr_die_User_und_Gruppen_das_Authentication_Timeoute_setzen.3F]]
| |
|
| |
| Zusätzlich zum "Timeout" kann folgendes gesetzt werden:
| |
|
| |
| '''Global für ALLE User:'''
| |
| # config user setting
| |
| # set auth-blackout-time [Setze die "blackout-time"; 0 - 3600 Sekunden möglich; Standard 0]
| |
| # set auth-http-basic [enable | disable]
| |
| # set auth-invalid-max [Anzahl möglicher Authentifizierung bevor User geblockt wird; Standard 5]
| |
| # set auth-lockout-duration [Lockout Zeit in Sekunden; Standard 0]
| |
| # set auth-lockout-threshold [Lockout Threshold; Danach wird "lockout-duration" ausgeführt; Standard 3]
| |
| # set auth-multi-group [enable | disable]
| |
| # set auth-secure-http [enable | disable]
| |
| # set auth-type [ftp | http | https | telnet]
| |
| # set auth-timeout [Anzahl Minuten; per Standard 5; Maximum 1440 minutes (24 Stunden)]
| |
| # set auth-timeout-type [idle-timeout | hard-timeout | newsession]
| |
| # config auth-ports
| |
| # end
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Diese Konfiguration unter "config user setting" sind Global. In den Gruppen der User können diese Optionen mit Ausnahme des "Timeout's"
| |
| nicht differenziert gesetzt werden da diese Optionen nur unter "config user setting" vorhanden sind. Auch in den local User setting dh.
| |
| "config user local" kann mit Ausnhame des Timeouts diese Konfiguration anhand dieser Optionen nicht local für den User gesetzt werden
| |
| da diese Optionen nur unter "config user setting" dh. Global zur Verfügung stehen. Zu den oben angegeben Optionen folgende Erläuterungen:
| |
|
| |
| auth-blackout-time Bei der Blackout Time handelt es sich um folgendes: Wenn eine Authentifizierung innerhalb von einer Minute 5 Mal
| |
| falsch durchgeführt wird so wir die Source IP des Authentifizierenden für die Blackout Time gesperrt!
| |
|
| |
| auth-http-basic Wenn aktiviert wird so wird anstelle der Login Seite des Fortinet OS das reguläre Pop-Up Fenster des Browsers
| |
| angzeigt um die Authentifizierung durchzuführen.
| |
|
| |
| auth-multi-group (Standard aktiviert) steuern ob ein User -sei es local oder ActiveDirectory in mehrer Gruppen vorkommt. Ist dies
| |
| nicht der Fall dh. jeder User nur in einer Gruppe kann diese Funktion deaktiviert werden. Die Funktione
| |
|
| |
| auth-secure-http Wird diese Option aktiviert so wird ein Redirect ausgeführt auf den sicheren Port HTTPS (per Standard deaktiviert)
| |
|
| |
| auth-type Wenn der User eine Authentifizierung durchführen soll betreffend einer Firewall Policy können hier die verschiedene
| |
| Protokolle die für diese Authentifizierung benutzt werden sollen aktiviert/deaktiviert werden. Per Standard sind alle
| |
| Protokolle aktiviert/definiert.
| |
|
| |
| config auth-ports Werden keine Standard Ports benutzt für "ftp | http | https | telnet" können diese "nicht" Standard Ports hier definiert
| |
| werden.
| |
|
| |
| == Redirection ==
| |
|
| |
| === In einer Redirection zB für eine Authentifizierung wird auf der Fortigate die IP anstelle des FQDN benutzt? ===
| |
|
| |
| Wenn zB in einer "Identiy Based Policy" zB für HTTPS Zugriff (User muss sich Authentifizieren um HTTPS aufzurufen) benutzt wird so wird sobald der User eine HTTPS Seite aufruft ein Redirect auf die Authentifizierungs Seite (ebenfalls ein HTTPS Port; Standard 1003) der Fortigate ausgelöst. Die Weiterleitung auf diese Authentifizierungs Seite geschieht IP basierend dh. im Link der Authentifizierungs Seite erscheint die interne IP der Fortigate. Wird mit Zertifikaten gearbeitet löst dies jedoch wieder eine Zertifikats Hinweis/Fehlermeldung aus da das Zertifikat Namens Basierend ist und nicht IP basierend. Die Lösung wäre den Redirect Namens basierend auszulösen und nicht IP basierend.
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Der Lösungsansatz den Redirect Namens basierend auszulösen und nicht IP basierend ist auch dann in Anwendung zu
| |
| bringen wenn der User hinter einem NAT Device (zB Router) sitzt!
| |
|
| |
| Für das bessere Verständnis nachfolgend ein kurzes Schema wie so ein Redirect ausgelöst wird (per Standard):
| |
|
| |
| | USER | ----> network -----> | FortiGate | -- HTTPS Site/Resources
| |
|
| |
| 1 --------> User "matched" eine Firewall Rule/Policy für HTTPS in der "Identiy Based Policy" aktiviert ist
| |
| 2 <------- Ein Redirect auf einen HTTPS Port (Standard 1003) und auf eine IP Adresse der Fortigate wird ausgelöst
| |
| 3 --------> User führt Authentifizierung aus
| |
| 4 --------> User Authentifiziert sich erfolgreich und wird zur gewünschten HTTPS Seite weitergeleitet
| |
|
| |
| Nachfolgend wird über die Console aufgezeigt wie die Konfiguration durchzuführen ist damit ein FQDN (Fully Qualified Domain Name) benutzt wird anstelle der IP:
| |
|
| |
| '''ACHTUNG''' Der benutzte FQDN muss sauber "intern" aufgelöst werden können. Wird ein externes Zertifikat benutzt das extern mit einer
| |
| Public IP auflöst muss anhand eines Split DNS Servers die nötigen Konfiguration durchgeführt werden damit "intern" der
| |
| FQDN mit einer "internen" IP aufgelöst wird. Ist intern kein Splitt DNS Server vorhanden kann die Fortigate herangezogen
| |
| werden um dies zu erreichen!
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Kann_ich_auf_der_Fortigate_einen_Splitt_DNS_Server_einrichten.3F]]
| |
|
| |
| # config firewall policy
| |
| # edit [Gebe die entsprechende Policy ID an inder die "Identiy Based Policy" für HTTPS Zugriff aktiviert wurde]
| |
| # set auth-redirect-addr "[Gebe hier den Fully Qualified Domain Name an]"
| |
| # next
| |
| # end
| |
|
| |
| Wenn es nötig wird eine spezielle IP Adresse zu definieren (zB NAT Device) dann kann auch eine IP definiert werden:
| |
|
| |
| # config firewall policy
| |
| # edit <my_policy_ID>
| |
| # set auth-redirect-addr "[Definiere hier die spezielle IP Adresse zB NAT IP Adresse]"
| |
| # next
| |
| # end
| |
|
| |
| Wenn man den Standard Port 1003 verändern möchte dh. auf einen anderen Port dann benütze folgendes:
| |
|
| |
| # config system global
| |
| # set auth-https-port [Setze hier den gewünschten HTTPS Port]
| |
| # end
| |
|
| |
| Möchte man HTTP für die Authentifizierung ebenfalls aktivieren (Per Standard deaktiviert) führe folgendes aus:
| |
|
| |
| # config user setting
| |
| # set auth-secure-http enable
| |
| # end
| |
|
| |
| == Authentication ==
| |
|
| |
| === Wie kann ich eine Two-Factor Authentication zB ODA implementieren? ===
| |
|
| |
| ODA steht für "On Demand Authentication" was wiederum zu vestehen ist ist als "Auf Abruf". Diese Authentifizierungs Methode ist die Gleiche wie eine Token Authentifizierung jedoch wird bei ODA diese durch den User selber ausgelöst (On Demand). Für weitere Informationen siehe folgender Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_aktiviere_ich_f.C3.BCr_einen_lokalen_User_Two-Faktor_Authentication_anhand_ODA.3F]]
| |
|
| |
| === Wie kann ich Authentifizierte User auf der FortiGate Auflisten/Monitoren? ===
| |
|
| |
| Wenn auf einer FortiGate eine Authentifizierung zB anhand Radius, LDAP, Lokal durchgeführt wird, können die authentifizierten User über GUI anhand des Monitors aufgelistet werden. Die entsprechende Position findet man unter:
| |
|
| |
| User & Device > Monitor > Firewall
| |
|
| |
| Diese authentifizierten User können ebenfalls über CLI aufgelistet werden. Dazu steht für das Filtering ebenfalls ein entsprechende Funktion zur Verfügung:
| |
|
| |
| # diagnose firewall auth filter
| |
| Current filters used to list authenticated policies:
| |
| Policy ID: any
| |
| User: any
| |
| Group: any
| |
| Source(IPv4): any
| |
| Source(IPv6): any
| |
| Method: any
| |
|
| |
| Um einen Filter zu setzen benutze die entsprechend zur Verfügung stehenden Filter:
| |
|
| |
| # diagnose firewall auth filter ?
| |
| clear Clear all filters.
| |
| source IPv4 source address.
| |
| source6 IPv6 source address.
| |
| policy Policy ID.
| |
| user User name.
| |
| group Group name.
| |
| method method
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Um zB eine "source" zu setzen benütze:
| |
|
| |
| # diagnose firewall auth filter source 192.168.1.1
| |
|
| |
| Danach kann der Filter abermalls kontrolliert werden:
| |
|
| |
| # diagnose firewall auth filter
| |
| Current filters used to list authenticated policies:
| |
| Policy ID: any
| |
| User: any
| |
| Group: any
| |
| Source(IPv4): 192.168.1.1
| |
| Source(IPv6): any
| |
| Method: any
| |
|
| |
| Nun können die "authentifizierten" User anhand dieses gesetzten Filter aufgelistet werden:
| |
|
| |
| # diagnose firewall auth list
| |
|
| |
| Um den Filter zurück zu setzen benütze:
| |
|
| |
| # diagnose firewall auth filter clear
| |
|
| |
| Wenn es bei den aufgelisteteten User zu Problemen kommt betreffend Authentifizierung kann ebenfalls die betreffende Session des Users aufgelistet werden. Dazu siehe nachfolgenden Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Welche_Informationen_werden_f.C3.BCr_eine_einzelne_Session_in_der_.22session.22_Liste_aufgef.C3.BChrt_und_was_bedeuten_diese.3F]]
| |
|
| |
| == Radius ==
| |
|
| |
| === Wie kann ich einen Radius Server Anbindung Troubleshooten? ===
| |
|
| |
| Nun ein Radius Server wird auf der FortiGate über die folgenden Position konfiguriert resp. hinzugefügt:
| |
|
| |
| User & Device > Authentication > RADIUS Servers
| |
|
| |
| Dabei werden Angaben wie der Name (FQDN) sowie die IP des Radius Server angegeben. Die Konfiguration des Radius Server geschieht auf der FortiGate anhand eines "Preshared Key" (Server Secret). Ebenso wird die FortiGate auf dem Radius Server als sogenannten "Radius Client" erfasst und zwar mit demselben "Preshared Key". Anhand dieser Einträge sowie des "Preshared Key" wird der Traffic über TCP 1812 (New Radius) sowie -sofern benutzt- für das Accounting TCP 1813 verschlüsselt und Authorisiert. Die Etablierung der Authentifizierung kann über die FortiGate - sofern diese als Radius Client auf dem Radius Server erfasst wurde - anhand des "Test" Button durchgeführt werden. Um die Komunikation zwischen dem Radius Client und Server zu überprüfen stehen folgende Diagnose Kommandos zur Verfügung:
| |
|
| |
| '''Teste einene entsprechenden User mit dessen Passwort:'''
| |
|
| |
| # diagnose test authserver radius [Server Name] [Schema] [Gebe einen entsprechenden User an] [Gebe das Passwort an des gewählten Users]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Als "Schema" kann folgendes definiert werden:
| |
|
| |
| chap, pap, mschap, mschap2
| |
|
| |
| '''Kontrolliere den Traffic über den entsprechenden Port:'''
| |
|
| |
| # diagnose sniffer packet [Name des Interfaces zB "internal"] 'port 1812' 3
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Weiter Informationen betreffend "Sniffer" Kommando siehe nachfolgenden ARtikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_benutze_ich_das_Sniffer_Kommando_.22diagnose_sniffer_packet.22.3F]]
| |
|
| |
| Muss der Radius Port von New Radius 1812 auf Old Radius 1645 gewechselt werden führe folgendes auf der Kommandozeile durch:
| |
|
| |
| # config system global
| |
| # get | grep radius-port
| |
| radius-port :1812
| |
|
| |
| # set radius-port 1645
| |
| # get | grep radius-port
| |
| radius-port :1645
| |
|
| |
| # end
| |
|
| |
| Desweiteren ist es möglich die Kommunikation zwschen der FortiGate sowie dem Radius Server einzusehen anhand folgenden Debug Mode:
| |
|
| |
| '''Setze den Debug Filter zurück:'''
| |
|
| |
| # diagnose debug reset
| |
|
| |
| '''Setze einen neuen Debug Filter:'''
| |
|
| |
| # diagnose debug application authd –1
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Beim "authd" handelt es sich um den Deamon für sämtliche lokalen, remote sowie FSSO Authentifizierungen!
| |
|
| |
| '''Aktiviere den Debug Modus mit dem gesetzen Debug Filter:'''
| |
|
| |
| # diagnose debug enable
| |
|
| |
| '''Deaktiviere die Debug Funktion'''
| |
|
| |
| # diagnose debug disable
| |
|
| |
| '''Setze den Debug Filter zurück'''
| |
|
| |
| # diagnose debug reset
| |
|
| |
| Desweiteren steht für ein Debug betreffend Radius "fnbamd" zur Verfügung:
| |
|
| |
| '''Setze den Debug Filter zurück:'''
| |
|
| |
| # diagnose debug reset
| |
|
| |
| '''Setze einen neuen Debug Filter:'''
| |
|
| |
| # diagnose debug application fnbamd –1
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Beim "fnbadm" handelt es sich um den "Fortigate non-blocking auth deamon"!
| |
|
| |
| '''Aktiviere den Debug Modus mit dem gesetzen Debug Filter:'''
| |
|
| |
| # diagnose debug enable
| |
|
| |
| '''Deaktiviere die Debug Funktion'''
| |
|
| |
| # diagnose debug disable
| |
|
| |
| '''Setze den Debug Filter zurück'''
| |
|
| |
| # diagnose debug reset
| |
|
| |
| === Kann ich für eine FortiGate über Radius mit LDAP Anbidung ein Single-Sign-On konfigurieren (RSSO)? ===
| |
|
| |
| Ja dies ist möglich und wird im nachfolgenden Dokument von Fortinet anhand des FortiAuthenticator's Schritt für Schritt beschrieben:
| |
|
| |
| [[Datei:FortiGate-Solutions-RSSO-RADIUS-Single-Sign-On.pdf]]
| |
| [[Datei:Fortios-rsso-with-win-server-2012-and-nps.pdf]]
| |
|
| |
| == Active Directory (LDAP) ==
| |
|
| |
| === Wie binde ich ein Active Directory (LDAP) für eine Authentifizierung ein? ===
| |
|
| |
| Nun um ein ActiveDirectory für verschiedenen Authentifizierungen einzubinden gehe folgendermassen vor:
| |
|
| |
| User & Device > Authentication > LDAP Server > Create New
| |
|
| |
| [[Datei:Fortinet-719.jpg]]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Für "Regular" (empfohlen) muss ein Active Directory User erstellt werden mit einem entsprechenden Passwort.
| |
| Es wird empfohlen diesen User als Read/Only Administrator zu erfassen und diesem Rechte über das ganzen Tree resp.
| |
| Active Directory zu vergeben. Natürlich ist es möglich eine regulären User zu erfassen (nicht Administrator)
| |
| und diesem die entsprechenden Rechte im Active Directory zu vergeben! Sobald der entsprechende User mit dessen
| |
| Passwort unter "Regular" konfiguriert wurde kann anhand des Button "Test" die Konfiguration getestet werden. Dieser
| |
| Test beinhaltet nur den Access dh. es zeigt nicht ob durch das Active Directy ein "browsing" durchgeführt werden
| |
| kann. Möchte man dies Testen so benutze das gezeigte "icon" denn damit lässt sich das Active Directory effektiv
| |
| öffnen:
| |
|
| |
| [[Datei:Fortinet-837.jpg]]
| |
|
| |
| Wenn die Verbindung zum Active Directory verschlüsselt durchgeführt werden soll (Port 689) so muss ein entsprechendes
| |
| Certificat definiert werden denn diese Verbindung basiert auf einer SSL Verbindung! Es stehen LDAPS sowie STARTTLS zur
| |
| Verfügung.
| |
|
| |
| Sobald die Active Directory (LDAP) Konfiguration erfolgreich durchgeführt wurde kann nun eine Gruppe erstellt werden um dort das Active Directory einzubinden:
| |
|
| |
| User & Device > User > User Group
| |
|
| |
| [[Datei:Fortinet-720.jpg]]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Nun im unteren Bereich anhand des "Add" Button kann der entsprechende Active Directory (LDAP) Server hinzugefügt werden.
| |
| Die Position "Any" bedeutet, dass ein entsprechender User (Active Directory Username) über das "ganze" Active Directory
| |
| mit dessem Tree durchsucht wird. Wir der entsprechende User gefunden wird die Authentifizierung durchgführt. Die Position
| |
| "Specify" gibt die Möglichkeit eine Gruppe zu definieren. Anhand dieser Definition wird wiederum der Tree des Active
| |
| Directory durchsucht um festzustellen ob der User der eine Authentifizierung durchführt Mitglied ist dieser Gruppe. Ist
| |
| dies der Fall wird eine Authentifizierung durchgeführt. Der Gruppen Name der unter "Specify" angegeben wird muss "unique"
| |
| sein dh. wenn mehrer Gruppen mit dem gleichen Name im Tree des Active Directory existieren gilt "Top Down first Match wins".
| |
| Wenn mehrere Gruppen definiert werden soll so kann anhand des "Add" Button eine weitere Zeile mit einer weiteren Gruppen
| |
| Definition hinzugefügt werden. Um eine LDAP Anbidung zu troubleshooten siehe nachfolgenden Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_kann_ich_eine_.22Active_Directory.22_.28LDAP.29_Anbindung_debuggen.3F]]
| |
|
| |
| Die Generellen Vorbereitungen für eine Active Directory Authentifizierung sind abgeschlossen nun kann diese Konfiguration für verschiedenen weitere Konfigurationen benutzt werden wie:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Kann_ich_f.C3.BCr_einen_Webfilter_betreffend_.22Local_Category.22_eine_Authentifizierung_.28authenticate.29_.C3.BCber_Active_Directory_.28LDAP.29_konfigurieren.3F]]
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_konfiguriere_ich_unter_FortiOS_5.0_ein_SSL-VPN_Portal.2FTunnel_auf_einer_Fortigate.3F]]
| |
|
| |
| Nachfolgend einige wichtige Informationen betreffend einer Anbindung eines Active Directory's dh. welche Ueberlegungen durchgeführt werden sollten sowie welche Möglichkeiten zur Verfügung stehen:
| |
|
| |
| Bestimmung und Identifizierung folgender LDAP Komponenten:
| |
|
| |
| • User
| |
| • User group
| |
| • container (Shared folder)
| |
| • Organization unit (ou)
| |
|
| |
| Die Komponenten besitzen folgende Active Directory Struktur:
| |
|
| |
| • '''root''' wird definiert als '''dc'''
| |
| • '''organizational unit''' wird definiert als '''ou'''
| |
| • '''container''' oder '''user/group''' wird definiert als '''cn'''
| |
|
| |
| Daraus resultiert der '''dn''' dh. im Klartext werden die Struktur vom User zu root aufgelistet. Um den '''dn''' zu ermitteln gehen wir von folgenden Beispiel aus:
| |
|
| |
| [[Datei:Fortinet-205.jpg]]
| |
|
| |
| Somit ergiebt sich folgendes:
| |
|
| |
| • ou=Testou2
| |
| • ou=Testou1
| |
| • ou=Vancouver
| |
| • dc=get
| |
| • dc=local
| |
|
| |
| • cn=Users
| |
| • dc=get
| |
| • dc=local
| |
|
| |
| '''SIMPLE BINDING WITHOUT GROUP SEARCH'''
| |
|
| |
| Nachfolgends Beispiel zeigt eine Anbindung ohne '''"group search"''' Funktion (simple binding). Dies wird benutzt, wenn
| |
| die User die Authentifiziert werden müssenk, direkt in '''containers''' oder '''organizational units''' befinden dh. in
| |
| unserem Beispiel sind die User "Testou1" und "Testou2" in der '''organizational unit''' "Vancouver". Somit ergiebt sich
| |
| folgendes:
| |
|
| |
| Vancouver --> get --> local
| |
|
| |
| '''oder'''
| |
|
| |
| • ou=Vancouver
| |
| • dc=get
| |
| • dc=local
| |
|
| |
| Um dies zu konfiguriere gebe auf der Console folgendes ein:
| |
|
| |
| # config user ldap
| |
| # edit ldaptest
| |
| # set server [Active Directory Server IP]
| |
| # set cnid cn
| |
| # set dn ou=Vancouver,dc=get,dc=local
| |
| # next
| |
| # end
| |
|
| |
| '''ACHTUNG''' Nur User die '''direkt''' in der '''organizational unit''' "Vancouver" drin sind werden authentifiziert.
| |
| User die nicht in dieser organizational unit oder unter "childs" (ous) von der organizational unit
| |
| "Vancouver" drin sind werden nicht authentifiziert. Ebenfalls User die in Gruppen drin sind, die
| |
| unter der organizational unit "Vangouver" drin sind, werden nicht authentifiziert.
| |
|
| |
| '''REGULAR BINDING WITHOUT GROUP SEARCH'''
| |
|
| |
| Nachfolgends Beispiel zeigt ebenfalls eine Anbindung ohne '''"group search"''' Funktion (regular binding) jedoch
| |
| befinden sich die User in verschiedenen '''containers''' und/oder '''organizational units'''! Für diese Art der
| |
| Konfiguration wird ein '''username''' und '''password''' benötigt um die Anbidung an das Active Directory durchzuführen.
| |
| Für diesen Zweck sollte auf dem Active Directory ein spezieller User erstellt werden der über die nötigen Rechte verfügt
| |
| in die vers. '''containers''' oder '''organizational units' reinzuschauen (Read Only Administrator). In unserem Beispiel
| |
| wären dies der User "user1ou1" in der orgainizational unit "ou1":
| |
|
| |
| # config user ldap
| |
| # edit testldap
| |
| # set server [Active Directory Server IP]
| |
| # set cnid cn
| |
| # set dn dc=get,dc=local
| |
| # set type regular
| |
| # set username cn=user1ou1,ou=ou1,dc=get,dc=local
| |
| # set password [Passwort des Users user1ou1]
| |
| # next
| |
| # end
| |
|
| |
| '''ACHTUNG''' In diesem Beispiel spielt es keine Rolle "wo" sich die User befinden dh. in welchen "containers"
| |
| und/oder "organizational units".
| |
|
| |
| '''SIMPLE BINDING WITH GROUP SEARCH'''
| |
|
| |
| Nachfolgends Beispiel zeigt eine Anbindung mit '''"group search"''' Funktion (simple binding). Dies wird benutzt, wenn
| |
| die User die Authentifiziert werden müssenk zu einer bestimmten Gruppe gehören und ALLE User dieser Gruppe liegen im
| |
| gleichen '''containers''' oder '''organizational units'''! Es ergiebt sich folgendes wenn eine Gruppe "Test Users"
| |
| existiert im container "Builtin" sowie alle Mitglieder der Gruppe "Test Users" in dem container "Users" befinden:
| |
| folgendes:
| |
|
| |
| Builtin > Test Users --> get --> local
| |
|
| |
| '''oder'''
| |
|
| |
| • cn=Test Users
| |
| • cn=Builtin
| |
| • dc=get
| |
| • dc=local
| |
|
| |
| Um dies zu konfigurieren gebe folgendes über die Console ein:
| |
|
| |
| # config user ldap
| |
| # edit ldaptest
| |
| # set server [Active Directory Server IP]
| |
| # set cnid cn
| |
| # set dn cn=Users,dc=get,dc=local
| |
| # set group cn="Test Users",cn=Builtin,dc=get,dc=local
| |
| # next
| |
| # end
| |
|
| |
| '''ACHTUNG''' Wenn in den Namen Leerschläge vorkommen dh. wie in unserem Beispiel "Test Users" so muss bei
| |
| der Konfiguration der Name mit Hochkommas angegeben werden!
| |
|
| |
| '''REGULAR BINDING WITH GROUP SEARCH'''
| |
|
| |
| Nachfolgends Beispiel zeigt ebenfalls eine Anbindung mit '''"group search"''' Funktion (regular binding) jedoch
| |
| befinden sich die User in Gruppen und diesen Gruppen in verschiedenen '''containers''' und/oder '''orgainizational
| |
| units'''. Ebenfalls können dies Mitglieder dieser Gruppe in "child" oder "parent" container existieren! Für diesen
| |
| Zweck sollte auf dem Active Directory ein spezieller User erstellt werden der über die nötigen Rechte verfügt in
| |
| die vers. '''containers''' oder '''organizational units' reinzuschauen (Read Only Administrator). In unserem Beispiel
| |
| wären dies der User "user1ou1" in der orgainizational unit "ou1":
| |
|
| |
| Builtin > Test Users --> get --> local
| |
|
| |
| '''oder'''
| |
|
| |
| • cn=Test Users
| |
| • cn=Builtin
| |
| • dc=get
| |
| • dc=local
| |
|
| |
| Um dies zu konfigurieren gebe folgendes über die Console ein:
| |
|
| |
| # config user ldap
| |
| # edit ldaptest
| |
| # set server 10.151.0.35
| |
| # set cnid cn
| |
| # set dn "dc=get,dc=local"
| |
| # set type regular
| |
| # set username cn=user1ou1,ou=ou1,dc=get,dc=local
| |
| # set password [Passwort des Users user1ou1]
| |
| # set group cn="Test Users",cn=Builtin,dc=get,dc=local
| |
| # next
| |
| # end
| |
|
| |
| Um eine Verbindung betreffend "Active Direktory" zu debuggen benütze folgendes:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_kann_ich_eine_.22Active_Directory.22_.28LDAP.29_Anbindung_debuggen.3F]]
| |
|
| |
| === Wie finde ich für eine Active Directory Anbindung (Regular) den entsprechenden User DN resp. Bind DN heraus? ===
| |
|
| |
| Wenn ein Active Directory Anbindung auf einer FortiGate konfiguriert wird so kann das über das Web Mgmt. Interface durchgeführ werden unter folgender Position:
| |
|
| |
| User & Device > Authentication > LDAP Server
| |
|
| |
| Um einen Active Directory Anbindung für die meist gebräuchliche Art dh. "Regular Bind" zu konfiguriren sind 3 Grundsätzliche Informationen unerlässlich:
| |
|
| |
| Administrator Username und dessen Passwort
| |
| User DN (Regular Bind, Bind Type User DN mit Passwort)
| |
| Bind DN (Distiguished Name)
| |
|
| |
| Für den Administrator empfehlen wir - unter normalen Umständen - einen Administrator auf dem Active Directory zu erstellen mit "vollen" Rechten jedoch "read-only". Dieser Administrator wird benutzt um die Verbindung in das Active Directory zu ermöglichen. Um den entsprechenden "User DN" herauszufinden kann "auf" dem Active Directory Server in einer DOS Box folgendes eingegeben werden:
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Die Dos Box dh. "cmd" muss auf dem Active Directory Server als Administrator gestartet werden. Wird dies nicht explizit
| |
| durchgeführt wird "dsquery" nicht gefunden!
| |
|
| |
| > dsquery user -name [Name des Adminstrators]
| |
| cn=Adminstrator,cn=users,dc=also,dc=com
| |
|
| |
| Um den korrekten "Bind DN" herauszufinden kann "auf" dem Active Directory Server in einer DOS Box folgendes eingegeben werden:
| |
|
| |
| > dsquery user -samid Administrator
| |
| cn=Adminstrator,cn=users,dc=also,dc=com
| |
|
| |
| Somit kann für die Konfiguration folgendes benutzt werden:
| |
|
| |
| Name [Name des Active Directory Servers; empfohlen FQDN]
| |
| Server IP/Name [IPv4 Adresse des Active Directory Servers]
| |
| Server Port 389
| |
| Common Name Identifier ["cn" für vollständiger Name | "sAMAccountName" für Login Name]
| |
| Distiguished Name [dc=also,dc=com]
| |
| Bind Type Regular
| |
| User DN [1:1 Output von "dsquery user -samid Administrator" dh. cn=Adminstrator,cn=users,dc=also,dc=com]
| |
| Password [Entsprechendes Passwort des Administrator Username]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Wird für "Common Name Identifier" die Konfiguration "cn" benutzt muess die User mit dessen vollständigen Namen einloggen
| |
| im Gegensatz zu "sAMAccountName" der den Login Name der User akzeptiert!
| |
|
| |
| === Wie kann ich für eine Active Directory (LDAP) Anbindung ein Passwort Expyring Renewal Nachricht konfigurieren? ===
| |
|
| |
| Wenn zB ein SSL-VPN betreffend Authentifizierung über ein Active Directory konfiguriert wird ist zu berücksichtigen, dass wenn ein "Passwort Renewal" konfiguriert wurde im Active Directory, dies ebenfalls für die Active Directory Anbindung auf der FortiGate zu konfigurieren ist. Dies bedeutet führe folgendes durch in der CLI um die "Expyring" Warnung sowie das "Renewal" zu aktivieren:
| |
|
| |
| # config user ldap
| |
| # edit [LDAP Server Name]
| |
| # set password-expiry-warning [enable oder disable]
| |
| # set password-renewal [enable oder disable]
| |
| # end
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Wird diese Konfigurtion durchgeführt muss berücksichtigt werden, dass die LDAP Anbindung auf der
| |
| FortiGate anhand eines Administrators durchgeführt wird der "Read/Write" Rechte besitzt, denn wenn
| |
| die Funktion "password-renewal" aktiviert ist so muss ein Schreibprozess durch die LDAP Anbindung
| |
| auf der FortiGate in das ActiveDirecory erfolgen! Ohne Read/Write Rechte des Administrators -der
| |
| die Anbindung zum ActiveDirectory ermöglicht- kann dieser Schreibprozess nicht erfolgen. Im Grundsatz
| |
| wird dies nicht empfohlen!
| |
|
| |
| === Kann ich einen WiFi Client/Workstation über einen Active Directory LDAP Server unter Benutzung von WPA/WPA2 Authentifizieren? ===
| |
|
| |
| Ein direkte Anbindung eines "LDAP" Servers im Zusammenhang mit einer "WPA/WPA2 LDAP Authentifizierung" wird für WiFi Clients/Workstations unterstützt. Jedoch nicht jeder "LDAP" Server. Dies bedeutet: der benutzte "LDAP" Server muss erlauben, dass das Passwort des "WiFi Clients/Workstation" über "clear-text" gesendet wird resp. der benutzte "LDAP" Server muss "clear-text" Passwörter akzeptieren. Ein "Windows Active Directory" unterstützt diese Art dh. "clear-text" Uebermittlung nicht mehr (seit Windows 2000). Aus diesem Grund müssen "WiFi Clients/Workstations" für "WPA/WPA2 LDAP Authentifizierung" über einen '''OpenLDAP''' eingebunden werden da nur ein "OpenLDAP" ein "clear-text" Uebermittlung des Passwortes akzeptiert. Der Grund für diesen Umstand ist, das "WPA" und "WPA2" Sicherheits Protokolle verschiedene "Hash Schemas" verwenden die nicht "Windows Active Directory" Kompatibel sind. Das ist der Grund wieso eigentlich für "WPA/WPA2" LDAP die Anbindungen über "OpenLDAP" Server geschehen muss/sollte.
| |
|
| |
| http://kb.fortinet.com/kb/microsites/search.do?cmd=displayKC&docType=kc&externalId=FD33251&sliceId=1&docTypeID=DT_KCARTICLE_1_1&dialogID=33038401&stateId=0
| |
|
| |
| Um das Problem zu umgehen - wenn "OpenLDAP" nicht in Frage kommt - ist die Authentifizierung über Radius durchzuführen in dem das "Windows Active Directory" Angebunden/Konfiguriert wurde. Dies bedeutet: Die "WiFi Clients/Workstation" senden für "WPA/WPA2 LDAP Authentifizierung" deren Passwörter über "clear-text" zum Radius Server. Dieser erstellt die nötigen "Hash Schemas" die durch "Windows Active Directories" verstanden werden und sendet die Authentifizierungs Informationen zum angebundenen/konfigurierten "Windows Active Directory". Somit kann die Authentifizierung für "WPA/WPA2 LDAP Authentifizierung" über ein "Windows Active Directory" durchgeführt werden. Als Radius Server kann ein "FortiAuthenticator" eingesetzt werden oder auch anderen Radius Server die eine "Windows Active Directory" Anbinung ermöglichen.
| |
|
| |
| === Wie kann ich die "Password Renewal" Funktion für ein "Active Directory" (LDAP) Anbindung aktivieren? ===
| |
|
| |
| Wenn ein "Active Directory" (LDAP) Anbindung konfiguriert wird zB. im Zusammenhang mit FortiClient IPSec Verbindung oder SSL-VPN stellt sich die Frage - wenn auf einem Active Directory die "Password Renewal" Funktion aktiviert ist - wie die User das Passwort wechseln können für das "Active Directory" wenn diese nicht Vorort sind? Diese Situation ist dann zu berücksichtigen, wenn User nicht sehr oft Vorort sind im internen LAN und somit angewiesen sind das Passwort zB über FortiClient IPSec oder SSL-VPN zu wechseln. Für diese Konfiguration gelten zwingend folgende Voraussetzungen:
| |
|
| |
| Die Implementation für die "Password Renewal" Funktion ist zwingend beschränkt für "Microsoft Active Directory". Andere
| |
| LADP Anbindungen wie zB OpenLDAP, Oracle usw. werden nicht unterstützt. Die Funktion des "Password Renewal" muss in der
| |
| entsprechenden "Active Directory" Konfiguration auf der FortiGate mit folgenden Kommandos aktiviert werden:
| |
|
| |
| # config user ldap
| |
| # edit [Name des entsprechenden Active Directory resp. "Microsoft Active Directory"]
| |
| # set password-expiry-warning [disable | enable]
| |
| # set password-renewal [disable | enable]
| |
| # end
| |
|
| |
| Desweiteren ist zwingend, dass die entsprechende Konfiguration auf der FortiGate für das "Active Directory" resp. für den
| |
| "Microsoft Active Directory" Server mit verschlüsselten Port durchgeführt werden muss dh. der Port muss von 389 auf 689
| |
| gesetzt werden sprich LDAPS. Die "Password Renewal" Funktion wird nicht über "clear-text" Port unterstützt dh. 389. Für
| |
| die Konfiguration für LDAPS ist folgendes zu definieren ausgehend davon das ein bestehende Konfiguration besteht:
| |
|
| |
| # config user ldap
| |
| # edit [Name des entsprechenden Active Directory resp. "Microsoft Active Directory"]
| |
| # set secure ldaps
| |
| # set ca-cert [Name des entsprechenden Zertifikats des "Microsoft Active Directory" Server]
| |
| # end
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Das benutzte Zertifikat des "Microsoft Active Directory" Servers muss auf der FortiGate entsprechend Importiert werden!
| |
|
| |
| Wenn diese zwei Voraussetzungen gegeben sind kann die "Password Renewal" Funktion im Zusammenhang mit FortiGate Funktionen benutzt werden.
| |
|
| |
| === Eine "Active Directory" Replizierung funktioniert nicht über ein VPN Tunnel (netbios forward)? ===
| |
|
| |
| Wenn zwei FortiGate's verbunden werden über einen VPN Tunnel und über diesen eine "Active Directory" Replizierung durchgeführt wird so wird dieser Traffic geblockt. Der Grund dafür ist das der "netbios" Traffic "forward" nicht über ein Interface per Standard erlaubt ist. Um diesen Traffic dennoch zu erlauben muss auf dem entsprechenden Interface "netbios" erlaubt werden:
| |
|
| |
| # config system interface
| |
| # edit [Name des Interface]
| |
| # set netbios-forwarding enable
| |
| # end
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Diese Konfiguration ist durchzuführen für eine NAT Firewall. Wird eine Transparent
| |
| Firewall benutzt resp. muss "netbios forward" über eine Transparent Firewall konfiguriert
| |
| werden muss folgendes Kommando abgesetzt werden:
| |
|
| |
| # config system interface
| |
| # edit [Name des Interface]
| |
| # set l2forward enable
| |
| # end
| |
|
| |
| === Wie kann ich eine "Active Directory" (LDAP) Anbindung debuggen? ===
| |
|
| |
| Um eine "LDAP" Anbindung zu testen kann ein entsprechender User mit dessen Passwort der im ActiveDirectory existiert herangezogen werden um einen entsprechenden Test auf der FortiGate durchzuführen:
| |
|
| |
| # diagnose test authsever ldap [Server Name] [Gebe einen entsprechenden User an] [Gebe das Passwort an des gewählten Users]
| |
|
| |
| Desweiteren kann über "diagnose debug" Befehl folgendes ausgeführt werden:
| |
|
| |
| '''Setze den Debug Filter zurück:'''
| |
|
| |
| # diagnose debug reset
| |
|
| |
| '''Setze einen neuen Debug Filter:'''
| |
|
| |
| # diagnose debug application fnbamd –1
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Beim "fnbadm" handelt es sich um den "Fortigate non-blocking auth deamon"!
| |
|
| |
| '''Aktiviere den Debug Modus mit dem gesetzen Debug Filter:'''
| |
|
| |
| # diagnose debug enable
| |
|
| |
| '''Deaktiviere die Debug Funktion'''
| |
|
| |
| # diagnose debug disable
| |
|
| |
| '''Setze den Debug Filter zurück'''
| |
|
| |
| # diagnose debug reset
| |
|
| |
| Desweiteren steht für ein Debug "authd" zur Verfügung für alle lokalen, remote sowie FSSO Authentifizierungen:
| |
|
| |
| '''Setze den Debug Filter zurück:'''
| |
|
| |
| # diagnose debug reset
| |
|
| |
| '''Setze einen neuen Debug Filter:'''
| |
|
| |
| # diagnose debug application authd –1
| |
|
| |
| '''Aktiviere den Debug Modus mit dem gesetzen Debug Filter:'''
| |
|
| |
| # diagnose debug enable
| |
|
| |
| '''Deaktiviere die Debug Funktion'''
| |
|
| |
| # diagnose debug disable
| |
|
| |
| '''Setze den Debug Filter zurück'''
| |
|
| |
| # diagnose debug reset
| |
|
| |
| Eine weitere Möglichkeit LDAP Authentifizierungs Probleme zu verifizieren ist über das Sniffer Kommando eine entsprechende "error" Nachricht zu erhalten zB "user not found". Weitere Informationen dazu siehe nachfolgenden Artikel:
| |
|
| |
| [[FortiGate:Diagnose-Sniffer-Guide#Sniffe_Packet_f.C3.BCr_LDAP_Port_389_um_entsprechende_.22error.22_Nachrichten_zu_erhalten.3F]]
| |
|
| |
| === Wie kann ich eine "Active Directory" (LDAP) Anbindung testen? ===
| |
|
| |
| Um eine Anbindung zu einem Active Directory auf "User" Basis zu testen kann folgender "diagnose test" Befehl ausgeführt werden:
| |
|
| |
| # diagnose test authserver ldap [Name Windows LDAP Server] [Username] [Passwort]
| |
| authenticate '[Username]' against 'WindowsLDAP' succeeded!
| |
|
| |
| == FSSO (Fortinet Single-Sign-On) ==
| |
|
| |
| === Wie ist FSSO zu verstehen? ===
| |
|
| |
| FSSO steht für "Fortinet Single-Sign-On" und steht im Zusammenhang mit "Directory Services". Es werden Windows Active Directory unterstützt sowie Novell eDirecotry. FSSO wird ebenfalls durch FSAE (Fortinet Server Authentication Extension) benutzt oder früher war FSSO auch bekannt als "Fortinet Server".
| |
|
| |
| === Was kann mit FSSO durchgeführt/angezeigt werden? ===
| |
|
| |
| FSSO kann folgende Information verarbeiten:
| |
|
| |
| > Zeigt Login Events an
| |
| > Zeigt Workstation Name, Domain und User an
| |
| > Löst den Workstation Name zur korrespondierenden IP Adresse auf
| |
| > Löst Gruppen auf zu dessen User Mitglieder sind
| |
| > Sendet Login Informationen zum Fortigate Device
| |
| > Erstellt Log Einträge auf dem Fortigate Device
| |
|
| |
| Grundsätzlich gilt: Die FSSO Funktion überwacht welche User über Active Directory oder eDirecorry eingeloggt sind und leitet diese Information dem Fortigate Device weiter! Ist der User Mitglied einer Gruppe die in einer Policy definiert wurde, erhält der User Zugriff auf die Netzwerk Resource!
| |
|
| |
| === Es gibt zwei Arten wie FSSO arbeitet; welche sind das? ===
| |
|
| |
| FSSO kann in zwei vers. Arten ausgeführt werden:
| |
|
| |
| Domain Controller Agent mode
| |
| Polling mode
| |
|
| |
| === Wie funktioniert der "Controller Agent mode"? ===
| |
|
| |
| Für den "Controller Agent mode" muss auf '''jedem''' Domain Controller der '''Domain Controller Agent''' installiert werden. Zusätzlich auf einem Windows Server der Wahl muss der '''Collector Agent''' installiert werden. Dieser "Collector Agent" erhält die Login Informationen übe den "Domain Controller Agent" und leitet diese dem Fortigate Device weiter. Basierend auf der '''Gruppen''' Zugehörigkeit des Users und die definierte Policy (Gruppe wird definiert in der Policy) erhält der User Zugriff auf die definierte Resource in der Policy.
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> In dieser Konstellation gilt als Nachteil, dass auf '''jedem''' Domain Controller ein Agent
| |
| (Software) zu installieren ist. In grossen Umgebungen kann dies einigen Aufwand bringen.
| |
| Für die korrekte Uebermittlung der Informationen zum Collector Agent muss zwischen dem
| |
| Domain Controller und Collector Agent eine garantierte Bandbreite von 64 kb zur Verfügung
| |
| stehen.
| |
|
| |
| === Wie funktioniert der "Polling mode"? ===
| |
|
| |
| Für den "Polling mode" muss auf dem Domain Controller '''kein''' "Domain Controller Agent" installiert werden. Es reicht den '''Collector Agent''' auf einem Server der Wahl zu installieren. Der "Collector Agent" weist den Domain Controller in kurzen (wenige Sekunden) Abständen an (polling) die Login Informationen der User zu übermitteln um diese sogleich dem Fortigate Device weiterzuleiten. Basierend auf der '''Gruppen''' Zugehörigkeit des Users und die definierte Policy (Gruppe wird definiert in der Policy) erhält der User Zugriff auf die definierte Resource in der Policy.
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Wenn der "Domain Controller" ausgelastet ist, kann es vorkommen das Login Informationen nicht
| |
| durch den "Collector Agent" verifiziert werden. Dies gilt als Nachteil wobei in grossen
| |
| Environemnts mit vielen Domain Controllern der Vorteil übewiegt nicht auf jedem Domain
| |
| Controller eine Software zu installieren da die Installation eines Collector Agents ausreicht!
| |
|
| |
| === Ueber welchen Port kommuniziert FSSO (Collector Agent) und der Fortigate Device? ===
| |
|
| |
| FSSO (Collectory Agent) benutzt den Port '''8256''' für die Uebermittlung der Informationen zum Fortigate Device!
| |
|
| |
| === Kann NTLM im Zusammenhang mit FSSO benutzt werden? ===
| |
|
| |
| Ja dies ist möglich. In so einer Konstellation initiert der Fortigate Device eine NTLM Komunikation (negotiation) mit dem Client Browser (Internet Explorer only; FireFox benötigt ein NTLM Plug-In). Der Fortigate Device übermittelt die NTML Package zum "Fortigate Collector" und dieser überprüft die Informationen über den "Domain Controller". Basierend auf der '''Gruppen''' Zugehörigkeit des Users und die definierte Policy (Gruppe wird definiert in der Policy) erhält der User Zugriff auf die definierte Resource in der Policy. Auf der entsprechenden Rule muss für die Identity Based Policy folgende Optionen gesetzt werden:
| |
|
| |
| # config firewall policy
| |
| # edit [Gebe den Integer an der entsprechenden Policy]
| |
| # set srcintf [Gebe das Source Interface an]
| |
| # set dstintf [Gebe das Destination Interface an]
| |
| # set srcaddr [Definiere die Source Adresse/n an]
| |
| # set dstaddr [Definiere die Destination Adresse/n an]
| |
| # set action accept
| |
| # set service "webproxy"
| |
| # set identity-based [enable]
| |
| # set ip-based [enable]
| |
| # set active-auth-method [ntlm]
| |
| # set sso-auth-method [fsso]
| |
| # edit [Gebe den Integer an einer neuen Identity Based Policy zB "1"]
| |
| # set schedule "always"
| |
| # set utm-status [enable]
| |
| # set groups [Definiere eine Active Directory Gruppe]
| |
| # set webfilter-profile [Definiere einen entsprechenden WebFilter]
| |
| # set profile-protocol-options [Definiere ein entsprechendes Profil]
| |
| # next
| |
| # end
| |
|
| |
| === Wie kontrolliere ich ob der FSSO "Collector Agent" und die Fortigate zusammen kommunzieren? ===
| |
|
| |
| '''Setze den Debug Filter zurück:'''
| |
|
| |
| # diagnose debug reset
| |
|
| |
| '''Setze einen neuen Debug Filter:'''
| |
|
| |
| # diagnose debug application auth 8256
| |
|
| |
| '''Aktiviere den Debug Modus mit dem gesetzen Debug Filter:'''
| |
|
| |
| # diagnose debug enable
| |
|
| |
| Nach Gebrauch deaktivieren wieder den debug Modus!
| |
|
| |
| '''Deaktiviere den Debug Modus:'''
| |
|
| |
| # diagnose debug disable
| |
|
| |
| '''Setze den Debug Filter zurück:'''
| |
|
| |
| # diagnose debug reset
| |
|
| |
| '''Kontrolliere den Debug Filter ob dieser zurückgesetzt wurde:'''
| |
|
| |
| # diagnose debug info
| |
|
| |
| === Wie kann ich kontrolliere welche User moment eingeloggt sind über FSSO? ===
| |
|
| |
| '''Setze den Debug Filter zurück:'''
| |
|
| |
| # diagnose debug reset
| |
|
| |
| '''Setze einen neuen Debug Filter:'''
| |
|
| |
| # diagnose debug authd fsso list
| |
|
| |
| '''Aktiviere den Debug Modus mit dem gesetzen Debug Filter:'''
| |
|
| |
| # diagnose debug enable
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Zusätzlich zu der Angaben "auth fsso list" kann "firewall auth list" benützt werden um die
| |
| Authentifizierung an der Firewall anzuzeigen!
| |
|
| |
| Desweiteren steht anstelle von "list" noch folgende Parameter zur Verfügung:
| |
|
| |
| clear logon (Löscht alle Login Informationen)
| |
| list (Listes alle momentan Login auf)
| |
| refresh-groups (Erneure das Group Mapping)
| |
| refresh-logons (Re-Synchronisiere die Login Database)
| |
| server status (Zeige FSSO Server Verbindungen)
| |
| summary (Summary der momentanen Login's)
| |
|
| |
| Um den Debug auszuschalten führe folgendes aus:
| |
|
| |
| '''Deaktiviere den Debug Modus:'''
| |
|
| |
| # diagnose debug disable
| |
|
| |
| '''Setze den Debug Filter zurück:'''
| |
|
| |
| # diagnose debug reset
| |
|
| |
| '''Kontrolliere den Debug Filter ob dieser zurückgesetzt wurde:'''
| |
|
| |
| # diagnose debug info
| |
|
| |
| == HA (High Availibility) ==
| |
|
| |
| === Gibt es für Cluster (Hardware und/oder Virtuell) Spezielle Konditionen bei Fortinet? ===
| |
|
| |
| Nun Fortinet bietet seinen Resellern Spezielle Konditionen auf Hardware (keine speziellen Konditionen auf Virtuell Appliance sprich VMware) für einen Cluster! Dabei gelten folgenden Vorrausetzungen:
| |
|
| |
| *************************************************************************************************************************************
| |
| * <span style="color:#ba0c2f">'''NOTE'''</span> Diese Informationen sind ab 1. April 2015 "nicht mehr gültig" dh. bei spezielleren Projekten grösser 15'000 CHF hat man die *
| |
| * Möglichkeit Anfragen über einen SPR (Special Price Request) bei Fortinet zu platzieren. Diese Aenderungen gelten für die *
| |
| * Schweiz und Oesterreich dh. in allen anderen Ländern ist diese Aenderung dh. dass Fortinet keine Cluster Konditionen mehr *
| |
| * bietet seit mehr als 2 Jahren aktiv. *
| |
| *************************************************************************************************************************************
| |
|
| |
| -> Nur auf Hardware 100D oder grösser
| |
| -> Hardware muss identisch sein dh. zB 2 X 100D
| |
| -> FortiCare (min. 8 X 5) und FortiGuard (Bundle) muss bezogen werden für jeden Node (ab 1000C "Next Generation Firewall" FortiGuard Update Service möglich)
| |
| -> Minimum Laufzeit für FortiCare (min. 8 X 5) und FortiGuard für jeden Node mind. 2 Jahre
| |
| -> Darauffolgende Jahre FortiCare (min. 8 X 5) und FortiGuard keine speziellen Konditionen für 1 Jahr Renewal
| |
| -> Darauffolgende Jahre FortiCare (min. 8 X 5) und FortiGuard spezielle Konditionen für 2 Jahr Renewal oder mehr
| |
|
| |
| Folgende Konditionen gelten für Hardware und/oder Services:
| |
|
| |
| -> Hardware = 1ter Node 100% (Regulärer Partnerpreis)
| |
| 2ter node 50% auf Regulärer Partnerpreis
| |
|
| |
| '''Bedeutet'''
| |
| Listenpreis minus Partner Status Discount zB Bronze 25% = Regulärer Partnerpreis
| |
| Regulärer Partnerpreis minus Cluster Discount 50% = Cluster Konditionen Hardware
| |
|
| |
| -> Service (FortiCare / FortiGuard (Bundle) ) = 1ter Node 100% (Regulärer Partnerpreis)
| |
| 2ter node 30% auf Regulärer Partnerpreis
| |
|
| |
| '''Bedeutet'''
| |
| Listenpreis minus Partner Status Discount zB Bronze 12.5% = Regulärer Partnerpreis
| |
| Regulärer Partnerpreis minus Cluster Discount 30% = Cluster Konditionen Service
| |
|
| |
| Folgende Dokumente geben detailliert Auskunft über das oben beschriebene:
| |
|
| |
| [[Datei:FORTINET_ALPS_High_Availability_Policy.pdf]]
| |
| [[Datei:Fortinet_HApolicy_Discount-Matrix-Reseller.pdf]]
| |
|
| |
| === Kann ich mit unterschiedlichen FortiGate Hardware einen Cluster bauen? ===
| |
|
| |
| Nun grundsätzlich Nein dh. das FGCP (FortiGate Cluster Protokoll) basiert auf der Hardware dh. mit unterschiedlicher FortiGate Hardware zB FG-60C mit FG-60D kann KEIN Cluster gebaut werden. Auch innerhalb der gleichen Devices gibt es vers. Revisionen sowie Hardware Generationen. Weitere Informationen betreffend Hardware Revisions/Generationen siehe nachfolgenden Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_verifiziere_ich_die_Hardware_Revision_eines_FortiGate_Devices.3F]]
| |
|
| |
| Diese Ueberprüfung der gleichen Hardware Revisions/Generationen kann mit folgenden Befehl deaktiviert werden:
| |
|
| |
| # execute ha ignore-hardware-revision status
| |
| The ignore mode is disabled
| |
|
| |
| Im normal Fall wird Hardware für einen Cluster als Cluster Hardware bezogen dh. um in den Genuss der Cluster Konditionen zu kommen. Weitere Informationen siehe folgender Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Gibt_es_f.C3.BCr_Cluster_.28Hardware_und.2Foder_Virtuell.29_Spezielle_Konditionen_bei_Fortinet.3F]]
| |
|
| |
| Dies bedeutet wird ein Hardware Device als Standalone bezogen, und erst später daraus ein Cluster gebaut, kommt man nicht in den Genuss der Cluster Konditionen. Ebenfalls kann diese Situation einige Probleme verursachen dh. wenn es sich beim zusätzlichen Node um eine andere Hardware Revision/Generation handelt, muss nachfolgender Befehl auf der Kommandozeile abgesetzt werden um die unterschiedlichen Revisionen/Generation innerhalb des FGCP zu ignorieren:
| |
|
| |
| # execute ha ignore-hardware-revision enable
| |
|
| |
| # execute ha ignore-hardware-revision status
| |
| The ignore mode is enabled
| |
|
| |
| Desweiteren darf sich die Hardware von beiden Nodes nicht unterscheiden dh. beiden müssen über die gleiche Anzahl/Art Interface verfügen. Ebenfalls müssen beiden Nodes über eine Disk in der gleichen Grösse verfügen. Ist dies zB nicht der Fall können die Disk zB unformatiert bleiben, sprich dadurch sind diese nicht mehr in Gebrauch und werden ignoriert.
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Es ist zu empfehlen gleiche Hardware in einem Cluster jedoch mit unterschiedlichen Revisions etc. zu verhindern,
| |
| denn dies kann zu Problemen führen im Betrieb des Clusters. Wichtig ist auch, dass bei einem allfälligen RMA
| |
| Austausch klar für den Device der auszutauschen ist, den Hinweis zu liefern, dass dieser in einem Cluster benützt
| |
| wird (Serien Nummer). Somit ist gewährleistet, dass Fortinet als Austausch eine kompatiblen Device liefert. Ist/Wäre
| |
| dieser Device für einen Austausch nicht mehr lieferbar sendet Fortinet zwei Devices mit gleicher Revisions.
| |
|
| |
| === Ist es möglich ein FortiGate Cluster zu konfigurieren wenn DHCP/PPPoE auf den Interfaces benutzt wird (HA)? ===
| |
|
| |
| Bis anhin war dies nicht möglich unter FortiOS 5.0. Dies bedeutet, war ein Interface -ob in Gebrauch oder nicht- als DHCP und/oder PPPoE definiert stand der Befehl "config system ha" nicht zur Verfügung. Neu ist unter FortiOS 5.2 ist dies möglich dh. für Active-Passive Cluster. Weitere Informationen wie ein Active-Passive Cluster konfiguriert wird siehe nachfolgenden Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_setze_ich_f.C3.BCr_Fortigate_einen_Cluster_auf_.28HA.29.3F]]
| |
|
| |
| === Wie setze ich für Fortigate einen Cluster auf (HA)? ===
| |
|
| |
| Wenn man einen Cluster (HA) für zwei Fortigate aufsetzen möchte dann ist folgendes dabei zu beachten:
| |
|
| |
| -> Gleiche Hardware Konfiguration (Kein Support für unterschiedliche Modelle in einem Cluster)
| |
| -> Gleiche Konfiguration/Grösse für die Harddisk
| |
| -> Gleiche Zusatz Karten sofern vorhanden (AMC / FMC)
| |
| -> Gleicher mode Interface/Switch/Hub (Sofern Switch Interfaces vorhanden sind)
| |
| -> Gleiche Softswitch Konfiguration
| |
| -> Kein Interface im PPPoE oder DHCP Mode (HA Mode ist Deaktiviert resp. "config system ha" steht nicht zur Verfügung FortiOS 5.0)
| |
| -> Gleiche Firmware auf beiden Devices
| |
| -> Gleicher Operation Mode (Transparent oder NAT)
| |
| -> Gleicher VDOM mode (aktiviert oder deaktiviert)
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Betreffend vers. FortiGate Modelle/Revisions in einem Cluster siehe nachfolgender
| |
| Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Kann_ich_mit_unterschiedlichen_FortiGate_Hardware_einen_Cluster_bauen.3F]]
| |
|
| |
| Unter FortiOS 5.2 ist es möglich im Gegensatz zu FortiOS 5.0 einen Active-Passive Cluster
| |
| zu konfigurieren obwohl DHCP und/oder PPPoE benutzt wird!
| |
|
| |
| In unserem Beispiel gehen wir von folgender Konstellation aus:
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Beide Fortigate's befinden sich in Factory Default Status dh. das Internal Interface ist mit der
| |
| IP 192.168.1.99/24 versehen!
| |
| __________
| |
| | |
| |
| | INTERNET |
| |
| |__________|
| |
| |
| |
| _______|______
| |
| ________________| |________________
| |
| | | Red Switch | |
| |
| | WAN1 |______________| | WAN1
| |
| _____|_____ _____|_____
| |
| | | | |
| |
| | |<---- DMZ Interface Heartbeat------>| |
| |
| | | | |
| |
| | FORTI | | FORTI |
| |
| | | | |
| |
| | |<---- WAN2 Interface Heartbeat----->| |
| |
| |___________| |___________|
| |
| | ______________ |
| |
| | INTERANL | | | INTERNAL
| |
| |________________| Green Switch |_______________|
| |
| |______________|
| |
| |
| |
| _____|____
| |
| | |
| |
| | LAN |
| |
| |__________|
| |
|
| |
| Wenn diese Vorraussetzungen gegeben sind gehe folgendermassen vor:
| |
|
| |
| Starte den "Master" und logge dich ein auf dem Web Mgmt. Interface und setze den Hostname für den Master:
| |
|
| |
| System > Dashboard > Status > System Information > Host Name
| |
|
| |
| Nun gehe zur folgenden Position um den HA Modus zu aktivieren:
| |
|
| |
| System > Config > HA
| |
|
| |
| Mode Active-Passive
| |
| Device Priority 128
| |
| Group Name FGT-HA
| |
| Password ********
| |
| Enable Session Pick-up [aktiviert]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Wenn "Enable Session Pick-up" nicht aktiviert wird so werden die aktiven Sessions des Master's nicht
| |
| dem Slave Device mitgeteilt dh. bei einem "Failover" vom Master zum Slave kommt es zum Unterbruch da
| |
| der Slave nicht weiss welche Sessions er übernehmen muss. Die zuständigen Interfaces für diese Session
| |
| Uebermittlung sind die "Heartbeat" Interfaces. Ein "Heartbeat" Interface sollte exklusiv benutzt werden
| |
| dh. NUR für die Uebermittlung der Sessions (100 Mbit). Der Wert der Priority dieses Interfaces sollte
| |
| höher liegen als des zweiten Interfaces (zB 100). Es ist zu empfehlen ein zweites "Heartbeat" Interface
| |
| zu definieren. Dieses muss nicht exkl. für "Heartbeat" resp. zur Session Uebermittlung benutzt werden.
| |
| Wenn zB das "wan2" genutzt wird kann diess auf Priority "50" gesetzt werden. Da das "Heartbeat" das
| |
| exkl. zur Session Uebermittlung auf "100" steht wird nur dieses genutzt und über "wan2" da nur auf
| |
| "50" gesetzt keine Sessions Uebermittelt (Kein Traffic). Dieses "wan2" wird nur dann genutzt wenn das
| |
| exkl. "Heartbeat" das auf "100" steht ausfällt. Für das "Heartbeat" Interface muss nicht zwingen eine
| |
| IP Konfig durchgeführt werden:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Welche_IP_Adressen_werden_in_einer_HA_Konfiguration_f.C3.BCr_ein_Heartbeat_Interface_vergeben.3F]]
| |
|
| |
| Wenn als zweites Interface für den "Heartbeat" ein reguläres Interface benutzt wird zB "Internal" sollte
| |
| berücksichtigt werden, dass die Session Uebermittlung in "clear-text" erfolgt dh. Potentiell können die
| |
| Sessions/Traffic mitgehört werden. Dies sollte man verhindern indem man den "Heartbeat" Traffiv verschlüsselt:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Kann_ich_f.C3.BCr_den_Heartbeat_eine_Verschl.C3.BCsselung_und.2Foder_eine_Authentifizierung_aktivieren.3F]]
| |
|
| |
| Desweiteren hat Fortinet betreffend "Heartbeat" ein Dokument released das aufzeigt wie dieses Konfiguriert wird.
| |
| In diesem Dokument wird gezeigt was bei einem "Heartbeat" zu berücksichtigen ist:
| |
|
| |
| [[Datei:FGSP_Configuration_Guide.pdf]] (FortiGate Session Life Support Protocol)
| |
|
| |
| dmz Heartbeat Interface Enable (Priority 100)
| |
| wan2 Heartbeat Interface Enable (Priority 50)
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Später muss der Slave ebenfalls im gleichen Sinne konfiguriert werden. Möchte man das der Master immer als Master
| |
| aggiert (nach Failover wird der effektive Master Device wieder Master was normalerweise nicht geschieht da beide
| |
| Device über die gleiche Priority verfügen) kann die Priority gegenüber dem Slave höher angesetzt werden! Dies gilt jedoch
| |
| nur insofern, dass die Priority überschrieben wird von der Anzahl Monitored Inferfaces sowie dem "age" (uptime des Device).
| |
| Nachfolgende Abbildung gibt Auskunft nach welchen Kritieren/Funktionen ein Primary zum Primary wird:
| |
|
| |
| [[Datei:Fortinet-336.jpg]]
| |
|
| |
| Das Kommando das eingegeben werden muss auf dem Device um die Device Priority über die Console anzupassen wäre:
| |
|
| |
| # config system ha
| |
| # set priority [Priority]
| |
| # end
| |
|
| |
| '''PLEASE NOTE''' Um zu gewährleisten, dass der Device mit der höheren Priority zum Primary wird kann die Option "override"
| |
| benutzt werden. Diese Option ist per Standard "disabled" sofern es sich nicht um einen virtuellen Cluster
| |
| handelt denn in so einem Fall ist "override" per Standard "enabled". Die Option "override" löst eine häufigere
| |
| "negotiation" aus für die Cluster Devices. Die Option "override" überschreibt wenn diese auf "enabled" steht
| |
| die Funktion "age". Dies bedeutet wiederum das "priority" an erster Stelle steht "vor" der Funktion "age".
| |
| Somit wird "age" nicht deaktiviert sondern "priority" greift zuerst "vor" der Funktion "age". Haben beide
| |
| Devices die gleiche Priority und "override" steht auf "enabled" so greift das System zurück auf die Funktion
| |
| "age". Im Grundsatz wird empfohlen die Option "override" auf "disabled" zu belassen. Wenn diese dennoch auf
| |
| "enabled" gesetzt wird muss folgendes berücksichtigt werden um einen Konfigurations Verlust zu verhindern:
| |
|
| |
| - Devices in einem Cluster müssen beide einwandfrei Mitglieder des Clusters sein (get system ha status)
| |
| - Device Priority auf dem Primary Device MUSS höher sein als auf dem Slave Device
| |
| - Bei Austausch von Devices ist Vorsicht geboten um einen Konfigurationsverlust zu verhindern da der "master"
| |
| mit "override" aktiviert den "slave" überschreibt!
| |
|
| |
| Um "override" zu benutzen muss auf dem PRIMARY folgender Befehl abgesetzt werden:
| |
|
| |
| # config system ha
| |
| # set override enable
| |
| # end
| |
|
| |
| Wenn nun die Konfiguration mit Device Priority sowie mit der Funktion "override" belassen wird reagiert der Cluster nicht auf
| |
| Ausfälle von Interfaces sondern nur auf den Ausfall eines Devices im Cluster. Um einen Interface Verlust abzudecken muss das
| |
| betreffenden Interface für das Monitoring konfiguriert werden. Weitere Informationen siehe Artikel:
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Das Montitoring der Interface darf erst dann aktiviert werden wenn der Cluster vollumfänglich aktiv ist und alle Interfaces
| |
| sauber angeschlossen und überprüft worden sind!
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_soll_die_Funktion_des_.22Port_Monitoring.22_der_Interface_in_einem_HA_Cluster_benutzt_werden.3F]]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Es ist zu empfehlen 2 oder mehrere Interfaces als Heartbeat zu definieren. Wenn nur ein Hearbeat konfiguriert ist
| |
| und dieser unterbrochen wird, (Cluster sehen sich nicht mehr) aggiert jeder Device als Standalone (split-brain configuration)
| |
| und es kommt es zum Netzwerkunterbruch! Aus diesem Grund sollten mind. 2 Interfaces als Hearbeat konfiguriert werden. Wenn
| |
| mehr als 1 "Hartbeat" (exklusiv oder geshared) benutzt wird und über die gleiche Priorität verfügen, wird der Hartbeat Traffic
| |
| über das Interface gesendet, dass über den kleineren "has map order value" verfügt. Wenn die Priorität unterschiedlich gesetzt
| |
| ist wird der "Hartbeat" Traffic über das Interface gesendet mit der höheren Priorität und das Interface mit der "kleineren" wird
| |
| als "fallback" benutzt!
| |
|
| |
| Bestätige die Konfiguration und es geschieht folgendes:
| |
|
| |
| Temporaer kann die Verbindung zur Fortigate verloren gehen da die Fortigate bei der Bestätigung die MAC Adresse der Interfaces
| |
| entfernt und eine virtuelle MAC Adresse für den Cluster erstellt. Möchte man den Unterbruchen so klein wie möglich halten die
| |
| ARP Table auf der Workstation über die man auf die Fortigae zugreift gelöscht werden (zB für Windows):
| |
|
| |
| arp -d *
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Weitere Befehle siehe im DOS Prompt "arp /?"!
| |
|
| |
| Nun muss der "Master" runtergefahren werden! Bevor dies geschieht, erstellen wir vom "Master" ein Backup:
| |
|
| |
| System > Dashbaoard > System Information > Backup
| |
|
| |
| Nun fahre nachdem erstellen des "Backup's" den Master über die CLI runter (ausschalten):
| |
|
| |
| # execute shutdown
| |
|
| |
| Starte den Slave (nicht am Netz)! Konfiguriere den Slave exact im gleichen Sinne wie der Master dh. Hardware-Technisch, Firmware
| |
| (nicht vergessen event. die Harddisk zu formatieren "execute formatlogdiks"). Oeffne das Backup File des Masters und ändere den
| |
| Hostname (Position):
| |
|
| |
| # config system global
| |
| # set hostname [Gewünschter Hostname]
| |
|
| |
| Nachdem der Slave Hardware-Technisch sowie Firmware-Technisch exakt genau gleich aufgesetzt ist wie der Master, erstelle
| |
| auf die Slave Maschine eine Verbindung auf das Web Mgmt. Führe nun anhand des modifizierten Backup Files des Masters ein
| |
| "Restore" durch unter:
| |
|
| |
| System > Dashbaoard > System Information > Backup
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Bei FortiOS 5 benötigt das File keine Modifikationen wenn es auf einem anderen/neuen Device wiederum als Restore
| |
| eingespielt wird. Bei FortiOS 4 benötigt man Modifikationen des Files ansonsten kann das File nicht auf einem anderen
| |
| Device eingespielt werden. Folgender Artikel gibt Auskunft was bei FortiOS 4 durchzuführen ist:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Was_ist_bei_einem_Restore_zu_ber.C3.BCcksichtigen.3F]]
| |
|
| |
| Nachdem Neustart des Devices greife erneut auf das Web Mgmt. zu. Es gilt nun die IP resp. die Zugangsinformationen gemäss
| |
| Restore resp. Backup File des Masters. Auf dem Web Mgmt. ändere die Priorität des Slave (Tiefere Priorität) dh. unter:
| |
|
| |
| System > Config > HA > [Rechts auf Edit]
| |
|
| |
| Nach dieser Konfiguration fahre ebenfalls den Slave runter und schalte diesen aus (über CLI oder Web Mgmt):
| |
|
| |
| # exec shutdown
| |
|
| |
| Nun verkable die beiden Devices gemäss Abbildung die zu Beginn dieses Artikel aufgezeigt wird. Bei den Heartbeat's können ebenfalls
| |
| Crossover Kabel zum Zuge kommen oder "transparente" VLAN's! Sobald die Devices korrekt verkabelt wurden starten zuerst den:
| |
|
| |
| Master
| |
|
| |
| Sobald der Master "up" ist kontrolliere diesen über das WebMgmt. Danach starte den "Slave" Der Cluster Aufbau findet beim Start der
| |
| Devices statt und benötigt keine weitere Konfiguration. Wenn man auf der Console des "Slave's" das Ganze mitverfolgt fällt einem auf,
| |
| dass nachdem Start folgende Meldungen auf der Console erscheinen:
| |
|
| |
| [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)
| |
|
| |
| Dieser Zustand dh. "not in sync" bleibt solange bis der "erste" Sync durchgeführt wurded (ca. 2 - 3 Minuten). Danach erscheint eine Bestätigung
| |
| des erfolgreichen "Sync":
| |
|
| |
| slave succeeded to sync external files with master
| |
|
| |
| Sobald der Cluster aktiv ist kann dieser wie eine Single Unit konfiguriert werden. Die einzelnen Device des Clusters können nicht mehr
| |
| angesprochen werden sofern nicht je Device ein "Dediziertes Management Interface mit IP's" benutzt wird. Sobald der Cluster Aktiv ist wird
| |
| diser nur noch mit den Cluster MAC Adressen und dazugehöriger IP angesprochen. Es wird für die einzelnen Nodes kein IP Adresse mehr benötigt.
| |
|
| |
| Als nächstes kann/können die benötigten Interfaces mit deren IP Adressen konfiguriert werden. Um auf die Fortigate zu verbinden öffnet einen
| |
| Broswer und verbinde dich auf die Virtuelle Cluster Adresse und logge dich ein:
| |
|
| |
| https://192.168.1.99
| |
|
| |
| Wenn es Probleme gibt betreffend Verbindung so konfiguriee den Client mit einer IP aus dem gleichen Subnet dh. zB 192.168.1.1/24. Konfiguriere
| |
| nun den Cluser betreffend IP Adressen, DNS Server, Routing etc. wie gewohnt.
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Nun kann nach Abschluss der Konfiguration und der korrekten Verkabelung das Monitoring der Interfaces eingeschaltet werden:
| |
|
| |
| System > Config > HA
| |
|
| |
| Weitere Informationen zu diesem Thema findet man im Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_soll_die_Funktion_des_.22Port_Monitoring.22_der_Interface_in_einem_HA_Cluster_benutzt_werden.3F]]
| |
|
| |
| '''ACHTUNG''' Sobald die Grundkonfiguration durchgeführt wurde betreffend IP Adressen, DNS sowie Routing teste den Cluster in seinen Funktionen
| |
| dh. führe einen kontrollierten Failover durch sowie unkontrollierte Failovers (ausstecken eines Ethernet Kabels). Achte darauf ob
| |
| und welcher Device NACH dem Failover wiederum Master wird! Nach einem Failover wird durch Fortigate kein Failover auf den Ausgangs
| |
| Device durchgeführt sofern die Priorität dieses Devices nicht höher liegt als die des Failover Devices (Master/Slave)!
| |
|
| |
| === Wie führe ich auf einem Cluster ein Firmware Update durch? ===
| |
|
| |
| Das manuelle Einspielen auf einem FortiGate Cluster einer neuen Firmware ist grundsätzlich der gleiche Vorgang wie auf einem Standalone Device. Das Besondere auf einem Cluster ist zu wissen WAS im Hintergrund geschieht damit im Fall der Fälle eingegriffen werden kann. Der nachfolgende Artikel erklärt wie so ein Firmware Update auf einem Cluster vor sich geht:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_f.C3.BChre_ich_auf_einem_Cluster_ein_Firmware_Update_durch.3F]]
| |
|
| |
| === Kommando über CLI "set mode" für "config system ha" steht nicht mehr zur Verfügung? ===
| |
|
| |
| Wenn man eine Fortigate in den HA/Cluster Mode setzen möchte so muss der "mode" für den Cluster gesetzt werden. Hat man zB eine Fortigate im "factory default" Status kann das Kommando "set mode" resp. "set mode ?" nicht abgesetzt werden. Der Grund dafür ist, dass die Fortigate im "factory default" status Interface's auf PPPoE oder DHCP gesetzt hat (FortiOS 5.0). Ist dies der Fall kann kein HA/Cluster konfiguriert werden da die Fortigate für PPPoE und DHCP kein HA/Cluster unterstützt. Setze alle Interfaces auf "static" und nachträglich steht das Kommando in der CLI "set mode" resp. "set mode ?" wieder zur Verfügung (Neustart wird nicht benötigt):
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Ab FortiOS 5.2 ist es möglich einen Cluster HA zu konfigurieren auch wenn auf einem Interface PPPoE und/oder DHCP
| |
| konfiguriert wird. Weitere Informationen siehe nachfolgenden Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Ist_es_m.C3.B6glich_ein_FortiGate_Cluster_zu_konfigurieren_wenn_DHCP.2FPPPoE_auf_den_Interfaces_benutzt_wird_.28HA.29.3F]]
| |
|
| |
| # config system ha
| |
| # set mode ?
| |
| The system may run in HA a-a or HA a-p mode only when all interfaces are not using PPPoE/DHCP as an addressing mode
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Bei älteren Release's von FortiOS 5.0 steht das Kommando "set mode" nicht zur Verfügung solange
| |
| Interfaces existieren die "nicht" auf Static gesetzt sind:
| |
|
| |
| # config system ha
| |
| # mode | grep mode
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Um festzustellen "ob" solche Interfaces existieren kann folgender Befehl abgesetzt werden:
| |
|
| |
| # show system interface | grep -f mode
| |
|
| |
| Durch die Angabe "grep -f" wird der Context der Konfig "mode" angezeigt für "system interface"!
| |
| Kontrolliere ob solche Interface's existieren resp. auf DHCP und/oder PPPoE gesetzt sind. Sofern
| |
| dies der Fall ist wechsle diese betroffenen interfaces auf "set mode static":
| |
|
| |
| # config system interface
| |
| # edit [Port Name zB wan1]
| |
| # set mode static
| |
| # end
| |
|
| |
| Jetzt sollte der "set mode" wieder erscheinen resp. kann gesetzt werden:
| |
|
| |
| # config system ha
| |
| # get | grep mode
| |
| mode : standalone
| |
|
| |
| # config system ha
| |
| # set mode ?
| |
|
| |
| # config system ha
| |
| # set mode a-p
| |
|
| |
| === Welche Sessions werden im Fall eines Failovers in einem HA Cluster übernommen? ===
| |
|
| |
| Grundsätzlich werden in einem Cluster die Sessions des Masters (Session Table) über den/die Heartbeat Interface's Synchronisiert. Somit weiss der Slave (Standby in einem Active-Passive Konfiguration) welche Sessions übernommen werden müssen im Fall eines "Failovers". Dies gilt jedoch nicht für folgende Sessions oder Funktionen:
| |
|
| |
| - UTM Features (Speziell Antivirus und IPS)
| |
| - Zertifikat Basierende Funktionen
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Eine Aussnahme stellt die 100D dar die über eine spezielle Funktion verfügt.
| |
| Diese Funktion "frup-settings" kann über CLI aktiviert werden! Diese Funktion setzt
| |
| jedoch vorraus, dass das zB ein "wan1" Interface übers Kreuz mit zwei Routern
| |
| verbunden ist. "frups" benützt virtuelle MAC Adressen sowie virtuelle IP's.
| |
| Desweiteren ist zu beachten das die Funktion "frup" unter FortiOS 5.4 nicht
| |
| mehr unterstützt wird!
| |
|
| |
| [[Datei:Fortinet-753.jpg]]
| |
|
| |
| Fortinet hat zusätzlich unter "Supplementary Recipes" ein Dokument bereitgestellt, dass zeigt wie eine FRUP Konfiguration gemäss vorhergehenden Abbildung durchgeführt wird. Das Dokument findet man im nachfolgenden Artikel im Abschnitt "Cookbook Supplementary Recipes FortiOS 5.0":
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wo_findet_ich_die_Dokumente_wie_Datasheets.2C_Quick_Start_Guide.2C_User_Guide_etc._.3F]]
| |
|
| |
| === Kann ich die Differenz für das Cluster "age" anpassen oder verändern? ===
| |
|
| |
| Die Funktion "age" basiert auf der "Uptime eines Devices" im Cluster dh. für die Kriterien die herangezogen werden ob ein Master/Primary zum Master/Primary wird ist die Funktion "age" an zweiter Stelle nach der Anzahl überwachter Interfaces (Interface Monitoring):
| |
|
| |
| [[Datei:Fortinet-336.jpg]]
| |
|
| |
| Wenn man nun die Differenz die herangezogen wird für das "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]
| |
| # end
| |
|
| |
| Um die Differenz eines Devices anzuzeigen benütze folgenden Befehl:
| |
|
| |
| # diagnose sys ha dump 1
| |
| HA information.
| |
| vcluster id=1, nventry=2, state=work,
| |
| digest=fe.21.14.b3.e1.8d...
| |
| ventry idx=0,id=1,FG50012205400050,prio=128,0,claimed=0,
| |
| override=0,flag=1,time=0,mon=0.
| |
| mondev=port5,50
| |
| ventry idx=1,id=1,FG50012204400045,prio=128,0,claimed=0,
| |
| override=0,flag=0,time=194,mon=0.
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Das Kommando "diagnose sys ha dump" existiert ab FortiOS 5.0.5 nicht mehr und wurde mit
| |
| folgenden Kommandos ersetzt:
| |
|
| |
| # diagnose sys ha dump-by [all-xdb | all-vcluster| rcache | all-group | memory | debug-zone | vdom | kernel | device | stat| sesync]
| |
|
| |
| Zusätzlich stehen noch folgende Kommandos zur Verfügung:
| |
|
| |
| # diagnose sys ha sesync-stats
| |
| # diagnose sys ha extfile-sig
| |
|
| |
| 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 Device. Die Zeile "mondev" gibt an welche Interface überwacht werden. Auf dem Device auf dem der Administrator momentan eingeloggt ist zeigt betreffend "time" immer "0". Der untergordnete Device zeigt die Differenz zum Primary dh. in unserem Beispiele "194" (194 geteil durch 10 = 19.4 Sekunden). Wenn nun "age" als Standard auf "300" Sekunden steht hat dies KEINEN Einfluss als Kriterium ob der Device zum Primary wird oder nicht, denn solange die Differenz der Devices diese "300" Sekunden nicht übersteigt hat "age" keinen Einfluss.
| |
|
| |
| Wenn nun aus vers. Gründen die "age" zurückgestellt werden soll (wenn zB der Primary über die Priorität gesteuert werden soll) auf ALLEN Devices, kann folgender Befehl ausgeführt werden:
| |
|
| |
| # diagnose sys ha reset-uptime
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Dieses Kommando sollte mit bedacht angewendet werden denn die "age" Zeit wird intern zurückgestellt.
| |
| Dies bedeutet kontrolliert man nachträglich mit dem Kommando "diagnose sys ha dump 1" die "age" oder
| |
| über das Dashboard die Uptime sowie in der Cluster Member List wir die Zeit die der Device up-and-runnig
| |
| ist wie gewohnt angezeigt. Dies bedeutet dieser Befehl setzt nicht die "Uptime" Global zurück sondern
| |
| nur für die Funktion "age" im Clustering!
| |
|
| |
| === Wie soll die Funktion des "Port Monitoring" der Interface in einem HA Cluster benutzt werden? ===
| |
|
| |
| Für die einzelnen Interfaces in einem HA Cluster kann das "Monitoring der Interface" eingeschaltet werden. Es ist folgendes zu berücksichtigen:
| |
|
| |
| • Bevor ein Monitoring konfiguriert/verändert werden soll muss der Cluster up and running sein
| |
| • Alle Interfaces müssen zum Cluster korrekt verbunden sein sowie keien RX/TX, Duplex Mismatch etc. verursachen
| |
|
| |
| Um ein "Interface Monitoring" zu aktivieren auf einem spezifischen Interface resp. Port benütze folgenden Befehl:
| |
|
| |
| # config system ha
| |
| # set monitor [Spezifizieren den zu überwachenden Port zB port1]
| |
| # end
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Wird in einem Cluster "kein" Interface/Port für das Monitoring konfiguriert handelt es
| |
| sich bei solch einem Cluster um einen reinen "Device Failover only". Dies bedeutet "nur"
| |
| der Ausfall eines Devices erzwingt einen Failover! Somit wird "nur" die Hardware eines
| |
| Devices in einem Cluster überwacht jedoch nicth die einzelnen Interface's.
| |
|
| |
|
| |
| Desweiteren kann zusätzlich zum "Port Monitoring" auch die Verbindung selber übwacht werden. Nähere Informationen dazu siehe folgender Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_kann_ich_auf_einer_FortiGate_im_Cluster_Mode_zus.C3.A4tzlich_zum_.22Port_Monitoring.22_ein_.22Destination_Monitoring.22_.28DGD.29_konfigurieren.3F]]
| |
|
| |
| === Kann ich für den Heartbeat eine Verschlüsselung und/oder eine Authentifizierung aktivieren? ===
| |
|
| |
| Grundsätzlich sollte "ein" dediziertes/seperates Interface benutzt werden für den "Heartbeat" resp. für die Synchronisation der "Session Table". Wenn ein zusätzliches "Heartbeat" zB über das WAN Interface benutzt wird -als Fallback- so ist es ratsam dieses zu Verschlüsseln und zu Authentifizieren. Wenn dies nicht geschieht ist es event. möglich, dass der Traffic über ein Sniffing mitgehört werden kann um zB falsche Cluster Status Informationen zu senden oder die Session Table abzuhören. Per Standard ist die Verschlüsselung sowie die Authentifizierung deaktiviert. Wenn diese aktiviert werden möchte führe folgendes aus:
| |
|
| |
| # config system ha
| |
| # set authentication enable
| |
| # set encryption enable
| |
| # end
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Wenn die Verschlüsselung sowie die Authentifizierung aktiviert werden so sinkt die Performance auf den
| |
| Devices denn diese wird benötigt um die Packet zu Verschlüsseln etc. sowie zu Authentifizieren! Der Impact ist
| |
| zwar nicht enorm dennoch muss dieser mitberücksichtigt werden! Für die Verschlüsselung/Authentifizierung wird in
| |
| einem Fortinet Cluster Verbund folgendes benutzt:
| |
|
| |
| AES-128 für die Verschlüsselung
| |
| SHA1 für die Authentifizierung
| |
|
| |
| === Welche IP Adressen werden in einer HA Konfiguration für ein Heartbeat Interface vergeben? ===
| |
|
| |
| Das FGCP (FortiGate Cluster Protokoll) vergibt "link-local IP4 Adressen" (RFC 3927) im Range 169.254.0.x für HA "Heartbeat Interfaces" sowie für "inter-VDOM Link". Wenn ein Cluster initial gestartet wird so wird dem Primary "Heartbeat Interface" die Adresse 169.254.0.1 zugewiesen und für den Slave eine IP aus folgendem Range 169.254.0.2 - 63. Für "inter-VDOM Link's" wird der Range 169.254.0.65 und höher benutzt. Um die vergebene IP Adresse für das Heartbeat in einem HA Cluster zu eruieren gebe folgendes Kommando über die Console ein:
| |
|
| |
| # get system ha status
| |
| Model: 300
| |
| Mode: a-p
| |
| Group: 0
| |
| Debug: 0
| |
| ses_pickup: enable, ses_pickup_delay=disable
| |
| Master:128 alsochlu-sg0e1 FG300C3913601712 1
| |
| Slave : 96 alsochlu-sg0e2 FG300C3913602452 0
| |
| number of vcluster: 1
| |
| vcluster 1: work 169.254.0.2
| |
| Master:0 FG300C3913601712
| |
| Slave :1 FG300C3913602452
| |
|
| |
| === Die Auslastung auf einem Heartbeat Interface ist zu hoch und es kommt zu einem unkontrollierten Fail-Over? ===
| |
|
| |
| Wenn in einem HA Cluster die Auslastung steigt -zB durch hohes Verkehrsaufkommen- wird der CPU stark beansprucht. In so einem Fall kann es vorkommen das die Heartbeat Packete -durch den Primary- nicht zur richtigen Zeit über das Heartbeat Interface -zum Slave- gesendet werden da der CPU anderweitig beschäftigt ist. In so einem Fall kann es zu einem unkontrollierten Fail-Over kommen da der Slave vom Primary keine oder verspätete und somit abgelaufene Packete bekommt und den Primary Part übernimmt. So eine Situation kann ebenfalls eintreffen wenn eine "syn flood attacke" gefahren wird der den Device komplett auslastet und somit wiederum die nötigen Heartbeat Packet nicht oder verspätet zum Slave gesendet werden. Wenn der Grund eines unkontrollierten Fail-Over die Auslastung regulärem Traffic ist so können die Intervall und/oder die Threshold der Packet angepasst werden um einen unkontrollierten Fail-Over zu verhindern. Dazu können über die Console folgende Kommandos abgesetzt 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
| |
|
| |
| '''hb-interval'''
| |
| Der Heartbeat Interval gibt an "wielange" benötigt wird um die Heartbeat Packete 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, dass wenn der Slave
| |
| 6 Packete nicht bekommt davon ausgeht das der Primary nicht mehr korrekt funktioniert und zum
| |
| Primary wird. Das Gleiche gilt für den Primary selbst dh. wenn er vom Slave die 6 Packet nicht
| |
| bestätigt bekommt geht der Primary davon aus das der Slave nicht mehr ordnungsgemäss funktioniert.
| |
| Im Generellen gilt: je kleiner der Threshold desto schneller wird ein Fail-Over durchgeführt.
| |
|
| |
| '''helo-holddown'''
| |
| Der hello State hold-down ist die Dauer in Sekunden die der Cluster wartet bis dieser vom
| |
| "hello-state" zum "work-state" wechselt. Nach einem Fail-Over oder beim starten des Clusters
| |
| arbeitet der Cluster im "hello-state" dh. Heartbeat Packete werden im Cluster zu den Devices
| |
| im Cluster gesendet damit jeder Device im Cluster sich austauschen kann. Sobald alle Devices
| |
| im Cluster Verbund erreicht wurden geht der Status auf "work-state". Sehen sich die Devices
| |
| im Cluster aus irgendwelchen Gründen nicht kann dies zu Unterbrüchen führen da der Cluster
| |
| nicht vollständig ist. Ein Grund, dass sich die Devices nicht finden ist zB ein unterschiedlicher
| |
| Standort mit weiten Strecken zwischen den Standorten dh. durch den Delay in der Komunikation
| |
| kann der Status nicht von "hello-state" in den "work-state" gehen. In so einem Fall kann die
| |
| Zeit die benötigt wird damit die Devices 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 Möglichkeit wäre bei einem hohen Aufkommen von "Sessions" über das "Heartbeat" Interface zusätzliche Ports zu definieren um das "Heartbeat" Interface zu entlasten. Bei dieser Möglichkeit werden nicht zusätzliche "Heartbeat" 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 abgewickelt und die zusätzlich definierten Ports übernehmen die arbeit des "Heartbeat" Interface's in dessen Namen. Dies bedeutet ebenfalls, dass die definierten Ports die Synchronisation übernehmen. Was wiederum bedeutet, dass über das "Hearbeat" Interface solange die defnierten Ports erreichbar sind keine Uebermittlung mehr stattfindet. Sind diese definierten Ports nicht mehr erreichbar (available) übernimmt wiederum das "Heartbeat" Interface die Arbeit der Uebermittlung der "Session Table". 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 port10 port12
| |
| # end
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Diese Konfiguration 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.
| |
|
| |
| === Wie setzt sich die virtuelle MAC Adresse in einem HA Cluster zusammen und wie ändere ich diese? ===
| |
|
| |
| Die virtuelle MAC Adresse in einem HA Cluster setzt 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 VDom nicht aktiviert sind setzt der HA Cluster 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 Formle 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 (Beispiel: base1 wird zuerst gelistet und danach port1).
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Nur die <idx> Position für die virtuelle MAC Adresse variert für jedes Interface. Die Position <vcluster_integer>
| |
| variert nur dann wenn VDom verwendet werden.
| |
|
| |
| Nachfolgend einige Beispiele für virtuelle MAC Adressen und deren Umrechnung:
| |
|
| |
| '''Group ID 0 (Default) und VDom's sind 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 und VDom's sind 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
| |
|
| |
| Um eine virtuelle MAC Adresse zu setzen führe folgendes auf der Console aus:
| |
|
| |
| # config system interface
| |
| # edit port1
| |
| # set macaddr [MAC Adresse]
| |
| # end
| |
| # end
| |
|
| |
| Bevor man einen Cluster baut ist die MAC Adresse = Hardware Adresse:
| |
|
| |
| # get hardware nic internal
| |
|
| |
| MAC: 02:09:0f:78:18:c9
| |
| Permanent_HWaddr: 02:09:0f:78:18:c9
| |
|
| |
| Man sieht das die MAC Adresse = der Hardware Adresse ist. Konfiguriert man einen Cluster und setzt wiederum den Befehl ab zeigt sich folgendes Bild:
| |
|
| |
| # get hardware nic internal
| |
|
| |
| MAC: 00:09:0f:09:00:02
| |
| Permanent_HWaddr: 02:09:0f:78:18:c9
| |
|
| |
| Man sieht nach der HA Cluster Konfiguration sind die MAC Adresse und die Physische MAC Adresse unterschiedlich. Möchte man also die virtuelle MAC Adresse auf allen Interfaces wechseln um zB einen MAC Adressen Konflikt zu umgehen muss "nur" die Group ID geändert werden:
| |
|
| |
| # config system ha
| |
| # set group-id <id_integer>
| |
| # end
| |
|
| |
| === Kann ich anhand eines Befehls den HA Sync Prozess einsehen? ===
| |
|
| |
| Folgender Befehl gibt die Möglichkeit den HA Sync Prozess einzusehen:
| |
|
| |
| # diagnose debug application hasync -1
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Ab FortiOS 5.2.1 kann der "hasync" Debug über Schalter "switch on/of" beeinflusst werden. Dies bedeutet:
| |
| über folgenden Befehl können vorgängig die benötigten Schalter aktiviert oder deaktiviert werden. Dies
| |
| kommt einer Filterfunktion für "diagnose debug application hasync" gleich. Es stehen folgende Schalter
| |
| zur Verfügung:
| |
|
| |
| # diagnose test application hasync [1-19,50-53]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Die Schalter "[1-19,50-53]" 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.
| |
|
| |
| === Was ist zu beachten wenn ich die Priorität eines Cluster Nodes anpasse/verändere? ===
| |
|
| |
| Die Konfiguration der Priorität eines Devices in einem Cluster wird nicht innerhalb des Clusters synchronisiert da die Priorität auf den Device gebunden ist. Somit wenn die Priorität angepasst wird in einem Cluster muss dies auf dem jeweiligen Device durchgeführt werden:
| |
|
| |
| # config system ha
| |
| # set priority [Nummerische Zahl]
| |
| # end
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> um in einem Cluster auf einen Node zu verbinden siehe folgender Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_Manage_ich_einen_Cluster_resp._wie_erlange_ich_Zugriff_auf_einen.2Fden_.22nicht.22_aktiven_Node.3F]]
| |
|
| |
| === Wie Manage ich einen Cluster resp. wie erlange ich Zugriff auf einen/den "nicht" aktiven Node? ===
| |
|
| |
| Wenn man einen Cluster aufsetzt und nicht ein entsprechendes Interface unter der nachfolgenden Position konfiguriert, kann auf die einzelnen Nodes im Cluster nicht mehr zugegriffen werden:
| |
|
| |
| System > Config > HA > [Setze den Mode auf "Active-Passive" oder "Active-Active] > Reserve Management Port for Cluster Member
| |
|
| |
| Diese Position bewirkt, dass das definierte Interface komplett aus dem Cluster Verbund genommen wird und unabhängig als reguläres Interfaces agiert. Bedeutet diese Interfaces können je Node mit einer normalen IP versehen werden. Somit kann anhand dieser Interface auf die Nodes im Cluster zugegriffen werden sowie die einzelnen Nodes zB über SNMP überwacht werden!
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Beachte dabei, dass immer auf den richtigen Node zugegriffen wird, wenn eine Konfiguration durchgeführt werden muss!
| |
| Denn der "nicht" aktive Node wird vom "aktiven" Node alle 15 Minuten überschrieben. Dies bedeutet würde man eine
| |
| Konfiguration "irrtümlicherweise" auf dem "Slave" durchführen und dies nicht bemerken, wird diese Konfiguration
| |
| durch den Master wiederum überschrieben da die Konfiguration nicht auf dem Master stattgefunden hat!
| |
|
| |
| Diese Konfiguration eines seperaten definierten Interfaces pro Node in einem Cluster um die Nodes zu überwachen, managene sowie für das Troubleshooting ist "absolut" zu empfehlen. Ist dies aus irgendwelchen Gründen nicht möglich kann der Zugriff auf den "nicht aktive" Node nur über die Kommandozeile des Master erfolgen. Bedeutet dies wird folgendermassen ausgeführt:
| |
|
| |
| Erstelle eine Verbindung auf die Kommandozeile (CLI) des Masters. Verifiziere
| |
| die "Device ID" des nicht aktiven Nodes im Clusterverbund:
| |
|
| |
| # 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:
| |
|
| |
| # execute ha manage 0
| |
|
| |
| Nun wird in der Kommandozeile (CLI) der Prompt des nicht aktiven Nodes angezeigt!
| |
|
| |
| === Wie kann ich überprüfen ob ein Cluster "In-Synch" ist? ===
| |
|
| |
| Folgender Befehl zeigt ob ein Cluster "In-Synch" ist dh. ist dies der Fall muss auf beiden Nodes die gleiche Checksum erscheinen:
| |
|
| |
| # diagnose sys ha showcsum
| |
|
| |
| Weitere Befehle um den Status eines Clusters abzufragen siehe Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_kann_ich_den_Status_eines_HA_Cluster_abfragen.3F_2]]
| |
|
| |
| === Heartbeat "Ethertype Packete" werden durch den Switch verworfen wieso und was ist zu tun? ===
| |
|
| |
| Normale IP Packete sind 802.3 Packete die über ein "Ethernet" Feld verfügen mit der Wert:
| |
|
| |
| 0x0800
| |
|
| |
| Andere Werte werden innerhalb des "Ethernet" Feldes als Level 2 Frames verstanden anstelle von IP Packeten. HA Heartbeat Packete von '''NAT/Route Mode''' (ha-eth-type) Cluster benutzen den "Ethernet" Type "0x8890". Diese Packete werden spezielle dazu benutzt die Mitglieder des Clusters und/oder anderen Cluster im Netz zu finden. HA Heartbeat Packet im '''Transparent Mode''' (hc-eth-type) benutzen den "Ethernet" Type "0x8891". HA '''Telnet Sessions''' (l2ep-eth-type) zwischen Cluster Devices over HA Heartbeat Links benützen den "Ethernet" Type "0x8893". Somit muss der Switch der für das Heartbeat benutzt wird diese "Ethernet" Types erlauben. Ist dies nicht der Fall da der Switch diese "Ethernet" Types bereits für interne Funktionen benützt muss der "Ethernet" Type modifiziert werden. Dies kann über 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
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Bei Cisco N5K/Nexus Switches wird der "Ethernet" Type 0x8890 für interne Funktionen benützt. Wenn
| |
| dieser Switch solche "Ethernet" Type Packet erhält verwirft er diese (CRC errors) und dies verhindet
| |
| die einwandfreie Komunikation zwischen den Nodes innerhalb eines Cluster. Lösung wäre der "Ethernet"
| |
| Type auf einem freien Wert zu definieren zB "0x888".
| |
|
| |
| === Wie kann ich für einen HA Cluster den Gruppen Namen auf Kommandozeile konfigurieren? ===
| |
|
| |
| Der Gruppen Name in einem Cluster ist dazu da um die dazugehörigkeit der Nodes in einem Cluster zu konfigurieren. Dazu gehören ebenfalls das Cluster Passwort sowie die Group ID. Andere Cluster im Netz dürfen nicht den gleichen Gruppen Namen benützen sondern müssen sich für eine eindeutige Identifikation unterscheiden. Um den Gruppen Namen in einem Cluster über CLI zu definieren führe folgendes aus:
| |
|
| |
| # config system ha
| |
| # set group-name [Gruppen Namen]
| |
| # end
| |
|
| |
| === Wie kann ich für einen HA Cluster den Gruppen ID auf Kommandozeile konfigurieren? ===
| |
|
| |
| Die Group ID ist wie der Gruppen Namen und das Passwort dazu da einen Cluster Verbund zu identifizieren dh. andere Cluster im Netz dürfen nicht die gleiche Group ID, Passwort sowie Gruppen Namen benützen. Um die Group ID für einen Cluster über CLI zu konfigurieren benütze:
| |
|
| |
| # config system ha
| |
| # set group-id [Group ID 0 - 255]
| |
| # end
| |
|
| |
| === Wie kann ich für einen HA Cluster das Passwort der Gruppe auf Kommandozeile konfigurieren? ===
| |
|
| |
| In einer Cluser Konfiguration wird zur einen Seite ein Gruppen Namen gesetzt und zum anderen ein Passwort. Dieses Passwort sowie der Gruppen Name muss für alle Node's im Cluster gesetzt werden dh. andere Cluster im gleichen Netz dürfen weder den gleichen Gruppen Namen noch über das gleiche Passwort verfügen. Um das Passwort zu setzen über CLI benutze folgendes Kommando:
| |
|
| |
| # config system ha
| |
| # set password [Passwort max. Länge 19]
| |
| # end
| |
|
| |
| === Wie kann ich über Kommandozeile den Status eines HA Cluster abfragen? ===
| |
|
| |
| Folgender Befehl gibt eine kurze Auskunft über den Status eines HA Clusters:
| |
|
| |
| # get system ha status
| |
| Model: 620
| |
| Mode: a-a
| |
| Group: 0
| |
| Debug: 0
| |
| ses_pickup: disable
| |
| Master:128 620_ha_2 FG600B3908600825 0
| |
| Slave :128 620_ha_1 FG600B3908600705 1
| |
| number of vcluster: 1
| |
| vcluster 1: work 169.254.0.1
| |
| Master:0 FG600B3908600825
| |
| Slave :1 FG600B3908600705
| |
|
| |
| 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: bc 3b 17 fe 44 b2 2d c7 1e d1 59 44 8b cd 64 a9
| |
| root: b9 c0 bf 46 f3 00 e6 fe d5 ed 2a 6c 79 38 01 c7
| |
| VDOM-1: a8 0b bf 2e cb d8 5d 26 43 a9 00 b9 e3 3b 9a a1
| |
| VDOM-2: 9b d1 63 60 79 9d 1c a3 7c 1e eb 7a c5 50 77 bc
| |
| VDOM-3: 43 da 8b 01 1f a3 7d 24 e1 0b 49 29 3a b1 90 29
| |
| all: 16 a0 79 8b 64 39 c0 37 40 ed c6 ee 77 62 16 7e
| |
|
| |
| checksum
| |
| global: bc 3b 17 fe 44 b2 2d c7 1e d1 59 44 8b cd 64 a9
| |
| root: b9 c0 bf 46 f3 00 e6 fe d5 ed 2a 6c 79 38 01 c7
| |
| VDOM-1: a8 0b bf 2e cb d8 5d 26 43 a9 00 b9 e3 3b 9a a1
| |
| VDOM-2: 9b d1 63 60 79 9d 1c a3 7c 1e eb 7a c5 50 77 bc
| |
| VDOM-3: 43 da 8b 01 1f a3 7d 24 e1 0b 49 29 3a b1 90 29
| |
| all: 16 a0 79 8b 64 39 c0 37 40 ed c6 ee 77 62 16 7e
| |
|
| |
| Betreffend Konfiguration etc. gibt es noch folgende Befehle die angewendet werden können um den Status inkl. Konfiguration eines HA abzufragen:
| |
|
| |
| # show full-configuration system ha
| |
| config system ha
| |
| set group-id 0
| |
| set group-name "FGT-HA"
| |
| set mode a-p
| |
| set password ENC
| |
| set hbdev "port5" 20 "port6" 10
| |
| set route-ttl 10
| |
| set route-wait 0
| |
| set route-hold 10
| |
| set sync-config enable
| |
| set encryption disable
| |
| set authentication disable
| |
| set hb-interval 2
| |
| set hb-lost-threshold 6
| |
| set helo-holddown 20
| |
| set arps 5
| |
| set arps-interval 8
| |
| set session-pickup enable
| |
| set link-failed-signal disable
| |
| set uninterruptable-upgrade enable
| |
| set vcluster2 disable
| |
| set override enable
| |
| set priority 254
| |
| set monitor "port4" "port5" "port6"
| |
| unset pingserver-monitor-interface
| |
| set pingserver-failover-threshold 0
| |
| set pingserver-flip-timeout 60
| |
| end
| |
|
| |
| # diagnose sys ha status
| |
| HA information
| |
| Statistics
| |
| traffic.local = s:2096712 p:2541238162 b:1972123729708
| |
| traffic.total = s:9497465 p:2541238496 b:1972123977459
| |
| activity.fdb = c:0 q:0
| |
|
| |
| Model=311, Mode=2 Group=0 Debug=0
| |
| nvcluster=1, ses_pickup=1
| |
| HA group member information: is_manage_master=1.
| |
| FG311B1111111111, 0. Master:254 myfirewall1
| |
| FG311B1111111112, 1. Slave:128 myfirewall2
| |
|
| |
| vcluster 1, state=work, master_ip=10.0.0.1, master_id=0:
| |
| FG311B1111111111, 0. Master:254 myfirewall1(prio=0, rev=0)
| |
| FG311B1111111112, 1. Slave:128 myfirewall2(prio=1, rev=1)
| |
|
| |
| === Wie kann ich einen FortiGate HA Cluster eine "Manuelle Synchronisation" ausführen/kontrollieren? ===
| |
|
| |
| Wenn ein FortiGate HA Cluster überprüft werden soll so wird/kann folgendes Kommando auf jedem "Node" des Cluster dazu abgesetzt werden um zu überprüfen ob der HA Cluster in "Synchronisation" ist (in-sync):
| |
|
| |
| master # diagnose sys ha cluster-csum
| |
|
| |
| --------------- node-1 ---------------
| |
| is_manage_master()=0, is_root_master()=0
| |
| debugzone
| |
| global: 89 f2 f0 0b e8 eb 0d ee f8 55 8b 47 27 7a 27 1e
| |
| root: cf 85 55 fe a7 e5 7c 6f a6 88 e5 a9 ea 26 e6 92
| |
| all: f4 62 b2 ce 81 9a c9 04 8f 67 07 ec a7 44 60 1f
| |
|
| |
| checksum
| |
| global: 89 f2 f0 0b e8 eb 0d ee f8 55 8b 47 27 7a 27 1e
| |
| root: cf 85 55 fe a7 e5 7c 6f a6 88 e5 a9 ea 26 e6 92
| |
| all: f4 62 b2 ce 81 9a c9 04 8f 67 07 ec a7 44 60 1f
| |
| --------------- node-1 ---------------
| |
|
| |
| slave # diagnose sys ha cluster-csum
| |
|
| |
| --------------- node-2 ---------------
| |
| is_manage_master()=1, is_root_master()=1
| |
| debugzone
| |
| global: 89 f2 f0 0b e8 eb 0d ee f8 55 8b 47 27 7a 27 1e
| |
| root: cf 85 55 fe a7 e5 7c 6f a6 88 e5 a9 ea 26 e6 92
| |
| all: f4 62 b2 ce 81 9a c9 04 8f 67 07 ec a7 44 60 1f
| |
|
| |
| checksum
| |
| global: 89 f2 f0 0b e8 eb 0d ee f8 55 8b 47 27 7a 27 1e
| |
| root: cf 85 55 fe a7 e5 7c 6f a6 88 e5 a9 ea 26 e6 92
| |
| all: f4 62 b2 ce 81 9a c9 04 8f 67 07 ec a7 44 60 1f
| |
| --------------- node-2 ---------------
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Soll das Kommando auf einer FortiGate benutzt werden die mehrer VDOM's konfiguriert hat muss folgendes
| |
| Kommando abgesetzt werden:
| |
|
| |
| # diagnose system ha showcsum <level> <vdom>
| |
|
| |
| Die möglichen "level" sind "01-04"! Dies ergiebt wiederum als Beispiel folgendes Kommando:
| |
|
| |
| # diagnose system ha showcsum 01 root
| |
|
| |
| 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
| |
|
| |
|
| |
| Wurde die "Synchronisation" ausgeführt kann abermalls mit "diagnose sys ha cluster-csum" die "checksum" überprüft werden. Ist die "checksum" unterschiedlich muss eventuel ein Objekt neu "Kalkuliert" werden denn jede Position dieser "checksum" stellen Objekte der FortiGate Konfiguration dar. Um eine "Re-Kalkulierung" durchzuführen führe folgendes auf jedem Node aus:
| |
|
| |
| master # diagnose sys ha csum-recalculate
| |
| slave # diagnose sys ha csum-recalculate
| |
|
| |
| Danach kann wiederum eine "Manuelle Synchronisation" anhand "execute ha synchronize start" ausgeführt werden sowie muss wiederum auf jedem Node die "checksum" überprüft werden dh. anhand des Befehls "diagnose sys ha cluster-csum". Ist die "checksum" danach unterschiedlich kann eruiert werden "Welches Objekt" diesen Unterschied hervorruft. 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:
| |
|
| |
| master # diagnose sys ha showcsum 2
| |
| accprofile.prof_admin: e6c12eee11f0793a0da0fcb864f0a522
| |
| accprofile.webfilter-admin: f6f2be9a42fe61f0326ee56d6c3a8c06
| |
| vap.fortinet4guest: selected-usergroups.gr-wifi-captive-local.intra: 237da722b1ac1bd9d7a5ab6c83ead6ea
| |
| 0edcb17a269eafa5890d746dba1c1380
| |
| vap.fortinet4intern: ba17ba924e2cbd36f75e313b938cfcb2
| |
| interface.dmz: b7c816698773650a428ed780eaf43663
| |
| interface.fortinet4guest: f2c026f8dd449374d4216afa7b10d068
| |
| interface.fortinet4intern: 96fd253d8d6e8e92b071f32567e23a47
| |
| interface.internal1: 302ebffe4602fafdfbb7d6cafd44ca52
| |
| interface.internal2: 54dcf24a0990698798297df3ac868ab6
| |
| interface.internal3: 225e1a910c0745ff7113d411a92d4edb
| |
| interface.internal4: 0d52b772ff93a73420aa22d975ee7cac
| |
| interface.internal5: 7f9e66a49f626a251a904c5d3c13fde7
| |
| interface.internal6: 9c420bdb806c33f558abcb6c2428e829
| |
| interface.internal7: 9e62abe84d68395870d6f8c5c32e671d
| |
| interface.ipsec-cisco: e768abdb46431c65a8fd6b25efb8e4c5
| |
| interface.ipsec-fc: ac4f31e8ee548b1e45542eaca899b9e2
| |
| interface.ipsec-ios: 607a0d3651451d1be408e0b1794a413a
| |
| interface.modem: 42199dc9dfc27125d4498c0a74d85fd5
| |
| interface.ssl.root: 3741086cbe973343bd0f624f23ee81d5
| |
| interface.wan1: c7af1e6fbb378fd788a4ee1eabf29965
| |
| interface.wan2: b1c8e61b1719b68539e09048a2d861cf
| |
| admin.FMG-Admin-local: vdom.root: e88d11390bb3c55f75284028ee0c7bd7
| |
| e078130dceee55940c5d43a469a3b69a
| |
| admin.WebFilter-Admin-local: vdom.root: 5584a69e82404d24f11e2fcdd5db8baa
| |
| ea050dfa9a23ccb7c1b84e6eb8259296
| |
| admin.WiFi-Admin-local: vdom.root: 5c6cf9d1d0c112254716d3352e8f485d
| |
| guest-usergroups.gr-wifi-captive-local.intra: 0bbd732c8a5225e7ad902539c99dc223
| |
| efd19ec8e4c24d0502b7c242ad132212
| |
| admin.admin: vdom.root: 1658041e980edb6ebf6336b748f5a4f6
| |
| dashboard-tabs.1: f3ef99ffd22012e54e2f98b4d78e3a32
| |
| dashboard-tabs.2: 49d7b151b650aa80725b3806d5cd48e0
| |
| dashboard-tabs.3: fca4025c88b2ed28864ac361ec82e612
| |
| dashboard-tabs.4: 96ab9f8d5da1f045f7f30ee600be509d
| |
| dashboard.1: 96ab9f8d5da1f045f7f30ee600be509d
| |
| dashboard.2: 96ab9f8d5da1f045f7f30ee600be509d
| |
| dashboard.3: 96ab9f8d5da1f045f7f30ee600be509d
| |
| dashboard.4: 96ab9f8d5da1f045f7f30ee600be509d
| |
| dashboard.5: 96ab9f8d5da1f045f7f30ee600be509d
| |
| dashboard.6: 96ab9f8d5da1f045f7f30ee600be509d
| |
| dashboard.21: 96ab9f8d5da1f045f7f30ee600be509d
| |
| dashboard.31: 96ab9f8d5da1f045f7f30ee600be509d
| |
| dashboard.41: 96ab9f8d5da1f045f7f30ee600be509d
| |
| cab9fdba23cedba3807d953f03e7f999
| |
| storage.FLASH1: 2b5863acb8708ae8bc6b7db8f7a42664
| |
| ddns.1: monitor-interface.wan1: bea6622a30a0d0c3a763b2654681694b
| |
| bea6622a30a0d0c3a763b2654681694b
| |
| replacemsg-image.logo_fguard_wf: a0b1569aca4c011c24ac7f71b0f64d05
| |
| replacemsg-image.logo_fnet: fc9bc11e0b91daacfcef45bbfea09039
| |
| replacemsg-image.logo_fw_auth: 0eb3bf0f8fc1a2861d9159ff76048ac7
| |
| replacemsg-image.logo_v2_fguard_wf: 8081ff5484a4ab6a52e6c19a43db3c0c
| |
| replacemsg-image.logo_v2_fnet: abaaae5c8cf8fd067715a6c717a6e1da
| |
| mail.email-block: 215f70c3662a8ff70c4054eef899716e
| |
| mail.email-dlp-ban: 1d28183b29e358018793b08bd25124c4
| |
| mail.email-dlp-subject: 2f66423880dd8358dd1ba9f80e69ceeb
| |
| mail.email-filesize: 95827a836428dc88ef6d5123ab725ba4
| |
| mail.partial: 106ca8627465ff1bbc6c0275634e4073
| |
| mail.smtp-block: 35d514772329e1b496d5f75f475d175a
| |
| mail.smtp-filesize: e7141c57579943dc527fdee44e808832
| |
| http.bannedword: aad5d9f4173a50c5c6feb89d486c57c3
| |
| http.http-archive-block: c60cb7b8d02e5376092f0f1406dae69c
| |
| http.http-block: 4839486226787ef5a68062ca615bf61f
| |
| http.http-client-archive-block: cee9ba86151c7f3ec0d4c943557aaf20
| |
| http.http-client-bannedword: 1abbc597e3ae31bceea29b989ded8491
| |
| http.http-client-block: cf32f82860f35d3f597826b154cf0fea
| |
| http.http-client-filesize: dba9dd30d113825d36f9007e2fa18631
| |
| http.http-contenttypeblock: 25b90bd05db96f11454c114bc39fb52b
| |
| http.http-dlp-ban: 07ef324d3aa1f37a45cfc00c4ac9c22b
| |
| http.http-filesize: 03c1ed216b09eeb5a8a1d879ce6f3528
| |
| http.http-post-block: ca741d301ae8268e6a0bb6952c1e6738
| |
| http.https-invalid-cert-block: d009b717b9f83bda22ab9ca248d5321a
| |
| http.infcache-block: d5afec4d6d02c3da29f33017fd6d9316
| |
| http.switching-protocols-block: f1f10383086f133f3a34f72c880dc225
| |
| http.url-block: ce3082f810da35079e1fdb77db909179
| |
| http.urlfilter-err: 121b0079e8177d83fc565d85e232d214
| |
| webproxy.auth-authorization-fail: 1e27f0aa24b4da6ae054372ec1e0e4c1
| |
| webproxy.auth-challenge: 08d7c0209e3262f55112eaed8682b012
| |
| webproxy.auth-login-fail: 57e88aecf0f70424efecfa55b4c657d6
| |
| webproxy.deny: eaf4a33e901aa6a8f50c2e8f89409207
| |
| webproxy.http-err: cb31aa748ea3ee6d8434d64f76e1118f
| |
| webproxy.user-limit: 735ab20d5751b212788bbcf9a293a62e
| |
| ftp.ftp-dl-archive-block: f6563b7432483299884cd9b847d74802
| |
| ftp.ftp-dl-blocked: e47ed3508020c70d0edfe91fa8ae4cc5
| |
| ftp.ftp-dl-dlp-ban: 835f625ed95a4841e38feb5cfd5f492c
| |
| ftp.ftp-dl-filesize: ce6e771adb6df55f1fd110d185523167
| |
| ftp.ftp-explicit-banner: fc0f30c41c1d5595e8858ede9f0930c2
| |
| nntp.nntp-dl-blocked: bd5aff6faa2ca4263377a2063d5a6190
| |
| nntp.nntp-dl-filesize: 00a9b573695e0fb3b399de40e3759a12
| |
| nntp.nntp-dlp-ban: cdf8928fb4266d3fbacdd13ad614522f
| |
| nntp.nntp-dlp-subject: 2939108716199734af3795cd735c78dd
| |
| fortiguard-wf.ftgd-block: 69436e64aaaaa73402e3f6fe2c1c5491
| |
| fortiguard-wf.ftgd-ovrd: f410194115b47fac24e8f5ec4cff5a48
| |
| fortiguard-wf.ftgd-quota: 33353214bc24c18710ead5334e82b941
| |
| fortiguard-wf.ftgd-warning: 07b28e0ffb1ba243c54e30ed9a050f0f
| |
| fortiguard-wf.http-err: 2ac16407ecfc615bdc297400204ebf9c
| |
| spam.ipblocklist: e9a0a3bb116c02269b59ccecff467d77
| |
| spam.reversedns: b52e9929a298ef41b4e7460b30ad32c4
| |
| spam.smtp-spam-ase: cd190fa14463135f6d1cec545c718896
| |
| spam.smtp-spam-bannedword: 37eac5ec0099f90b44bac6eb97559327
| |
| spam.smtp-spam-dnsbl: 092cfc6f3933b87db727513a0b5cb9cc
| |
| spam.smtp-spam-emailblack: 08272682bf0e3b33657099e9f2bd477b
| |
| spam.smtp-spam-feip: 75bce07b7e201beb788732f8d2b86e0e
| |
| spam.smtp-spam-helo: e0cbe3142ec6b06469af0af8f94ecdbb
| |
| spam.smtp-spam-mimeheader: 0f875724f74904ccef95e08e2643a739
| |
| spam.submit: cde7381d8842f56de56d97cc98fbc886
| |
| im.im-dlp: 1993cf162e3d48565ab40cb6f31aacb5
| |
| im.im-dlp-ban: 790bf4ff27936e1f3a2b24f42989b96f
| |
| im.im-file-xfer-block: 75270b801ee0f557be5aa478da96926d
| |
| im.im-file-xfer-infected: d6d0a299f34e6ee92a812d5226687b97
| |
| im.im-file-xfer-name: ce291ae8efcb5cc321d3e5eaa4e10f74
| |
| im.im-file-xfer-size: cc555d2eab349eb2817df1ab094086a9
| |
| im.im-long-chat-block: 78c3d8995a4c9c2d86c85d68ac7f24f3
| |
| im.im-photo-share-block: a773777ecbb63c7e9f33c948ac04ac7c
| |
| im.im-video-chat-block: 461f2b67932c4518cc41ac668f49d271
| |
| im.im-voice-chat-block: d59e6c20aeb88a796fffbfeabdcc895c
| |
| alertmail.alertmail-block: b2f4e0425097ef0857cf4acce641e4de
| |
| alertmail.alertmail-crit-event: 206c14630f7101127d5f7987aef10095
| |
| alertmail.alertmail-disk-full: 7d77b6b59bd54fe12235c4b6460039bb
| |
| alertmail.alertmail-nids-event: ec40fe2bdecda9105e0ce4497d58e6bb
| |
| alertmail.alertmail-virus: 17a10ca304354cd77591e6119ba9d689
| |
| admin.post_admin-disclaimer-text: 5b9fa46ff007122aa6eeb5d33780f9fa
| |
| admin.pre_admin-disclaimer-text: 588b1a8c4f2996cfa1b01ac4fd7b059c
| |
| auth.auth-cert-passwd-page: 3ab646d6485ed6423592f5df8d55e82b
| |
| auth.auth-challenge-page: d5bc10632bd2e9cf53f9408792ce7df8
| |
| auth.auth-disclaimer-page-1: daca77388620229a9024c854b698275b
| |
| auth.auth-disclaimer-page-2: 3ab48006284d6cfdec39cbeef07cf1f5
| |
| auth.auth-disclaimer-page-3: 2e857f6c46674079bb92dd8c48520a8e
| |
| auth.auth-email-failed-page: f056f7c0d08fb0f574d6b87fd2e7b097
| |
| auth.auth-email-harvesting-page: f23be16befe3f27f86bf15b164b1f9c5
| |
| auth.auth-email-token-page: 70f1aaba159818bc0db3cb1c8a745eba
| |
| auth.auth-fortitoken-page: c473d24ec3f412b5588ad02785bbfaad
| |
| auth.auth-guest-email-page: f871f75eed48f9b603c21344441d33a9
| |
| auth.auth-guest-print-page: a3a6584ea87dd959fd9de6e0b9648910
| |
| auth.auth-keepalive-page: 49f82155fd508f8bf682a8fdee3bc0e3
| |
| auth.auth-login-failed-page: c4dfdf2bb4d6005dc0394cb85ba7f0e9
| |
| auth.auth-login-page: 6ca9a45313cd0cd04fbb3a388421387f
| |
| auth.auth-next-fortitoken-page: cd5293d456d287fa31500fd7e51f87fa
| |
| auth.auth-password-page: ba9b34aa8483f63af8be1500a55d3f62
| |
| auth.auth-portal-page: ce1c67dee85591385f76397aa974cb63
| |
| auth.auth-reject-page: d1cef4e64560147613e42f6da551c8fe
| |
| auth.auth-sms-token-page: 73d79a5c745fb5707a0a1ca366706152
| |
| auth.auth-success-msg: 46625386e08fe57aff7e2ea89abdc346
| |
| auth.auth-token-login-failed-page: 9f051e20eca9f037e6cf2e0bf6c04a4e
| |
| auth.auth-token-login-page: 5f8d80a39b38dd93245b83bc1d9c120e
| |
| captive-portal-dflt.cpa-disclaimer-page-1: 24b79b5f924ce0ec4a1608f933dc6230
| |
| captive-portal-dflt.cpa-disclaimer-page-2: 047d091290f33bee8581ca7e20c96b10
| |
| captive-portal-dflt.cpa-disclaimer-page-3: de7f93e046e199f6cf24fab5bd1f773e
| |
| captive-portal-dflt.cpa-login-failed-page: 0d83b8a677a520dd898727615ed1fa7f
| |
| captive-portal-dflt.cpa-login-page: 529bf84ce4e1f75b66470167b3042ba3
| |
| captive-portal-dflt.cpa-reject-page: 9a60315063471c82f220af25302620b5
| |
| sslvpn.sslvpn-limit: 41d883501e833dfe2a23d3d9dae13a7b
| |
| sslvpn.sslvpn-login: 5bd84c065547ce06936c56d64572d94a
| |
| ec.endpt-download-portal: dd2ff1e3bb81964b630ad1fc95261dcb
| |
| ec.endpt-download-portal-aos: ce6fab68eb943137fb09b9164f892cf8
| |
| ec.endpt-download-portal-ios: c5ba6f053fca28d69b1309af11f5424f
| |
| ec.endpt-download-portal-mac: 7aa645f2de82b85d2463a0bcdfebb107
| |
| ec.endpt-download-portal-other: 0d6695569919be015f26aa4ac017f280
| |
| device-detection-portal.device-detection-failure: 33956ec31fb6cd51a6989b8a9d3569e5
| |
| nac-quar.nac-quar-dlp: 029293d9f9abbe3057a7f5b4cd382552
| |
| nac-quar.nac-quar-dos: 95ae75398b57991dc2cd63aaae5b9ffb
| |
| nac-quar.nac-quar-ips: 3ec4f59ba62e2a369400c8cd46649777
| |
| nac-quar.nac-quar-virus: 7d87c03bd6b7a7f2fe88c8c687f09d77
| |
| traffic-quota.per-ip-shaper-block: eabc45be536adb930bc78e5bf069effc
| |
| utm.dlp-html: 87ef0cbcb3cbcab70a51d6aff3baef7a
| |
| utm.dlp-text: 76a3e1acb1a0af911b9375e866bf62bc
| |
| utm.virus-html: 804de49134b9de8dc1bd51fd40615d5f
| |
| utm.virus-text: 01e280340d7dc5a4e8330a0681ec0b2c
| |
| device-category.all: db290eda5dc00d7757946b786a847ef2
| |
| device-category.android-phone: 774be2d630cdbd86d85d652da35acaec
| |
| device-category.android-tablet: f5fe456bb6b8feb29f0c2bac04719542
| |
| device-category.blackberry-phone: bd98886e9ef03cee1eb5a842b5b16462
| |
| device-category.blackberry-playbook: c36afa9e5e3f362b844da0e9299452ff
| |
| device-category.collected-emails: 04797efde106db7aa8c8d1ffe2d73af9
| |
| device-category.fortinet-device: 1c5d31d6defc163997885b2d46506aa4
| |
| device-category.gaming-console: 1bf36a48b915fa2a0b0fc31a3ca0f665
| |
| device-category.ip-phone: e803d00fea368ff7b0c67b38cdde1f68
| |
| device-category.ipad: 8ab3079cec093a6898121492d41d6705
| |
| device-category.iphone: d35841f5c22f46a74935c1be079879bb
| |
| device-category.linux-pc: f66e74ef0d2490fdf0943d492f0a40dc
| |
| device-category.mac: 6ddb5d6141e7b6643b366f577ea8b0cf
| |
| device-category.media-streaming: 143b727dc8f623dcd69f4300a0cce39a
| |
| device-category.other-network-device: c3276590b5c3e82208f7535caa15bbc7
| |
| device-category.router-nat-device: f81423a950779f73e262d69e5d5d8ec9
| |
| device-category.windows-pc: 3f3d3087919f1d1438cec42e0205ae40
| |
| device-category.windows-phone: 9f4de14f15d1751ddf4f63d53109fe8e
| |
| device-category.windows-tablet: 3b3f8459c77854dd83e2001be0f1356f
| |
| service.ftp: 7eae36f56100443fea72c5ab76be7ef8
| |
| service.ftps: d15f1668020cfcb980f95c16ac2af03c
| |
| service.http: c0f9eec57d6906eb2a21782b736b9843
| |
| service.https: d1de9fab1fb277e8b7a46aafab710961
| |
| service.im: ed850151a7c86ace0b2d5bec2213616a
| |
| service.imap: 7588123dbc53ddfbd60cd6cbc00b1190
| |
| service.imaps: a132952e51bf10b4db59e8ef833cdcc2
| |
| service.nntp: 6ce18bff5025d7d8c15d028cb1a1c3d6
| |
| service.pop3: b2d30fb99a90653c147c68a0377ec88c
| |
| service.pop3s: b5cf20208ac994c4da113cf347c5fa4a
| |
| service.smtp: 4e03925a250839d71a1e8152e8e5a564
| |
| service.smtps: 9b31e571ccbe3daf27090f0d73fce7b8
| |
| storage.FLASH1: 9b31e571ccbe3daf27090f0d73fce7b8
| |
| session-helper-1: dfedb7f1b41f4a293552710f56622ca8
| |
| session-helper-2: bc635b8b106c498155455ad5ff9729b2
| |
| session-helper-3: cbc209e98b2ce0b0d3fd64762148182a
| |
| session-helper-4: db24d580f9422d39bb5ff28e01f690c7
| |
| session-helper-5: 552826ed4886dd25fcd808d835cd0177
| |
| session-helper-6: c947bacff9c3c986d060c9430b267dfb
| |
| session-helper-7: a0f263e4b36cae603df8fa59a46163e7
| |
| session-helper-8: c1ca8b0c5d0099ac3d805fb06378041b
| |
| session-helper-9: 9fba0cb41a2716e859698324560c6930
| |
| session-helper-10: ccceeb64feec514e9939ea0a10f83041
| |
| session-helper-11: 5fda52bbdf945cfe3a1d0519fbdbf49e
| |
| session-helper-12: 4fef3e9ae29223fbda89bedd107949a6
| |
| session-helper-13: 672c0353e341a982ce022b2bbd2c8cdc
| |
| session-helper-14: 26eb138059e2cf0cabf61b1b2b646b38
| |
| session-helper-15: c2fea018351bea2856ad042b92a5320a
| |
| session-helper-16: 41b2418b1c48ec90c75b8f296d1d52e8
| |
| session-helper-17: 7f4ee1a14d0dc5269c5bdfa154be7f06
| |
| session-helper-18: 89165aebbcbd8f531c8c15126b14fdf6
| |
| session-helper-19: 24ec476747dd6dea3d522836559ed393
| |
| interface.dmz: 293547b7c09961fcea1a00d502b5b005
| |
| interface.fortinet4guest: ba51b5c8b5944a675df22987ae0c0953
| |
| interface.fortinet4intern: a2ead6e9d77aed2c26f746a71e07cc30
| |
| interface.internal1: 1ac06432534ae099140b40375ec5253d
| |
| ntpserver.1: 8ec37555eba565a1166fc2a8c4365282
| |
| ntpserver.2: 917e47ca71df43e638d3484363442631
| |
|
| |
| Führe nun auf dem "slave" ebenfalls diesen Kommando aus und vergleiche jede Position resp. Objekt denn alle müssen "in-sync" sein:
| |
|
| |
| slave # diagnose sys ha showcsum 2
| |
|
| |
| Wenn eine entsprechendes Objekt nicht "in-sync" ist kann dieses anhand folgendes Befehls näher angeschaut werden:
| |
|
| |
| # diagnose system ha showcsum <path.object>
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Dies bedeutet zB als Beispiel folgendes:
| |
|
| |
| # diagnose sys ha showcsum system.admin
| |
|
| |
| Wir für ein Objekt ein Unterschied festgestellt muss dieser Unterschied anhand des Objektes auf der FortiGate Konfiguration eruiert werden. Zur Problemlösung macht es event. Sinn -sofern möglich- das entsprechende Objet zu löschen und neu zu erstellen (master/slave). Danach eine "Re-Kalkulierung" auszuführen sowie die "checksum" Kontrolle.
| |
|
| |
| === Kann ich für einen Cluster eine VDOM erstellen die ausschliesslich für das Management benutzt wird? ===
| |
|
| |
| Auf der einen Seite gibt es in einem Cluster die Möglichkeit ein spezifisches Interface auf jedem Node zu konfigurieren (HA Reserved Management Interface) die für das Management der einzelnen Nodes zuständig sind. Diese Art der Konfiguration ermöglicht es die einzelnen Nodes zu überwachen (SNMP) und diese über das spezifische Interface zu Managen/Troubleshooten. Der Nachteil in dieser Konfiguration liegt im Logging Bereich dh. bei der Log Uebertragung auf einen Remote Log Server wie zB "Syslog". Nichts desto trotz ist dies die meist gewählte Implementierung und sollte auch unter normalen Umständen gewählt werden. Dazu wählt man in der HA Konfiguration ein dezidiertes Interface:
| |
|
| |
| System > Config > HA > Reserve Management Port for Cluster Member
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Beachte dabei das dieses Interface vom "Clustering" ausgenomme ist dh. durch das Konfigurieren
| |
| einer IP für jeden Node auf dem spezifischen Interface das als "Reserve Management Port for
| |
| Cluster Member" konfiguriert wurde kann über diese IP jeder Node einzeln angegangen werden.
| |
| Dies ermöglichkt auch -über dieses Interace- jeden Node einzeln über SNMP zu überwachen.
| |
|
| |
| Wie oben beschrieben unter normalen Umständen sollte diese Art der Implementation eines Management Interface's konfiguriert werden. Möchte man jedoch mit einer "seperaten" VDOM dh. Mgmt. VDOM arbeiten und die Möglichkeit haben über diese VDOM den Cluster zu managen sowie Log's einzel für jeden Node zB zu einem Syslog zu senden kann eine "Management VDOM" implementiert werden. Dabei ist zu beachten, dass diese Management VDOM "nicht" im Clustering enthalten ist dh. diese wird nicht "synchronized" und ist komplett unabhängig vom Cluster. Alle Interfaces/Ports die innerhalb einer solchen "Management VDOM" zur Verfügung stehen können genutzt werden um den Cluster zu Administrieren. Dabei spielt es keine Rolle ob man die Interfaces/IP's benutzt des Slaves und/oder des Masterw da die "Management VDOM" nicht Bestandteil des "Clustering" ist. Aus diesem Grund werden ebenfalls die Logs unabhängig für jeden Node einzel mit dessen IP resp. die für die Management VDOM benutzt werden zB einem "Syslog" übermittelt. Gleichzeitig kann wie bei der "HA Reserved Management Interface" jeder einzelne Node des Clusters über diese IP's/Interfaces zB über SNMP überwacht werden. Um eine solche Konfiguration durchzuführen bedarf es FortiOS 5.0. Folgendes muss durchgeführt werden über die Console auf dem Cluster:
| |
|
| |
| __________
| |
| | |
| |
| | INTERNET |
| |
| |__________|
| |
| |
| |
| _______|______
| |
| ________________| |________________
| |
| | | Red Switch | |
| |
| | WAN1 |______________| | WAN1
| |
| _____|_____ _____|_____
| |
| | | | |
| |
| | |<---- PORT1 Interface Heartbeat---->| |
| |
| | | | |
| |
| | FORTI | | FORTI |
| |
| |____ | | ____|
| |
| | | | | | |
| |
| MGMT VDOM |____|______| |______|____| MGMT VDOM
| |
| | | ______________ | |
| |
| MGMT1 | | INTERANL | | INTERNAL | | MGMT1
| |
| | |________________| Green Switch |_______________| |
| |
| | |______________| |
| |
| | | |
| |
| | _____|____ |
| |
| | | | |
| |
| | | LAN | |
| |
| | |__________| |
| |
| | |
| |
| _|_____________ _____________|_
| |
| | | | |
| |
| | Mgmt. Switch | | Mgmt. Switch |
| |
| |_______________| |_______________|
| |
| | |
| |
| | |
| |
| | |
| |
| | Mgmt. Network | Mgmt. Network
| |
| | |
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Dieses Beispiel geht davon aus das beide Devices "nicht" produktiv sind und nicht im
| |
| Netzwerk verbunden sind. Die Devices dh. der Master und der Slave werden Standalone
| |
| Konfiguriert und erst zu einem späteren Zeitpunkt über das Heartbeat Interface
| |
| verbunden! Dabei gelten die gleichen Vorraussetzungen für den Bau eines Cluster wie
| |
| im folgenden Artikel beschrieben:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_setze_ich_f.C3.BCr_Fortigate_einen_Cluster_auf_.28HA.29.3F]]
| |
|
| |
| '''Master'''
| |
|
| |
| # config system global
| |
| # set vdom-admin enable
| |
| # end
| |
|
| |
| # config vdom
| |
| # edit [Erstelle eine neue VDOM zB mit dem Namen "MGMT"]
| |
| # end
| |
|
| |
| # config global
| |
| # config system global
| |
| # set management-vdom [Name der neu erstellten VDOM zB "MGMT"]
| |
| # end
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Wenn das Kommando "management-vdom" benutzt wird kann die "root"
| |
| VDOM nicht angegeben werden in der Konfiguration!
| |
|
| |
| # config system ha
| |
| # set mode [Setze den Mode Active/Passive dh. "a-p"]
| |
| # set hbdev [Setze die Ports für den Heartbeat (Sync) sowie Priorität zB "port1 50"]
| |
| # set standalone-mgmt-vdom enable
| |
| # set priority [Setze einen Integer für Prority zB "200"]
| |
| # set group-name [Gruppen Namen zB "FG-HA-SG0E0]
| |
| # set group-id [Group ID zB "10"]
| |
| # set password [Passwort max. Länge 19]
| |
| # set override enable
| |
| # end
| |
| # end
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Die Option "override enable" wird benutzt damit der Master bei einem Failover
| |
| nachträglich wiederum Master wird! Weitere Informationen zu dieser Option siehe
| |
| nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_setze_ich_f.C3.BCr_Fortigate_einen_Cluster_auf_.28HA.29.3F]]
| |
|
| |
| # config vdom
| |
| # edit [Gebe den Namen der erstellten Mgmt. VDOM an zB "MGMT"]
| |
| # config system interface
| |
| # edit [Wähle das Interface für die Mgmt. VDOM zB "mgmt1"]
| |
| # set vdom [Füge das Interface der Mgmt. VDOM hinzu "MGMT"]
| |
| # set ip [Vergebe die IPv4 Adresse mit deren Subnet zB "192.168.1.99/24]
| |
| # end
| |
|
| |
| # config router static
| |
| # edit 1
| |
| # set device [Wähle das Interface für den Routing Eintrag zB "mgmt1"]
| |
| # set gateway [Konfiguriere den Gateway als IPv4 Adresse zB "192.168.1.1"]
| |
| # next
| |
| # end
| |
|
| |
| '''SLAVE'''
| |
|
| |
| # config system ha
| |
| # set mode [Setze den Mode Active/Passive dh. "a-p"]
| |
| # set set hbdev [Setze die Ports für den Heartbeat (Sync) sowie Priorität zB "port1 50"]
| |
| # set standalone-mgmt-vdom enable
| |
| # set priority [Setze einen Integer für Prority zB "100"]
| |
| # set group-name [Gruppen Namen zB "FG-HA-SG0E0]
| |
| # set group-id [Group ID zB "10"]
| |
| # set password [Passwort max. Länge 19]
| |
| # end
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Beim "hbdev", "mode", "group-name", "group-id" sowie "password" müssen die gleichen Werte wie
| |
| beim "Master" Device gesetzt werden!
| |
|
| |
| Nun führe einen "shutdown" durch für den Slave dh.:
| |
|
| |
| # execute shutdown
| |
|
| |
| Verbinde nun den Master mit dem Slave Device über das konfigurierte "Heartbeat" (hbdev) Interface.
| |
| Danach starte den "Slave" Device erneut und kontrolliere über die Console auf dem Slave das folgende
| |
| Meldung erscheint:
| |
|
| |
| 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)
| |
| slave succeeded to sync external files with master
| |
| slave succeeded to sync external files with master
| |
|
| |
| Sobald der Slave Device in "sync" ist mit dem Master kann nun auf dem Slave Device das Interface für
| |
| die Management VDOM -wie schon auf dem Master geschehen- durchgeführt werden:
| |
|
| |
| # config vdom
| |
| # edit [Gebe den Namen der erstellten Mgmt. VDOM an zB "MGMT"]
| |
| # config system interface
| |
| # edit [Wähle das Interface für die Mgmt. VDOM zB "mgmt1"]
| |
| # set vdom [Füge das Interface der Mgmt. VDOM hinzu "MGMT"]
| |
| # set ip [Vergebe die IPv4 Adresse mit deren Subnet zB "192.168.1.100/24]
| |
| # end
| |
|
| |
| # config router static
| |
| # edit 1
| |
| # set device [Wähle das Interface für den Routing Eintrag zB "mgmt1"]
| |
| # set gateway [Konfiguriere den Gateway als IPv4 Adresse zB "192.168.1.1"]
| |
| # next
| |
| # end
| |
|
| |
| Nun kann zB ein "Syslog" Server konfiguriert werden:
| |
|
| |
| # config log syslogd setting
| |
| # set status enable
| |
| # set server "192.168.1.103"
| |
| # end
| |
|
| |
| Wenn man sich nun die Logs anschaut - die auf dem Syslog Server übermittelt werden - sieht man das diese "pro" Node mit unterschiedlichen IP's übermittelt werden da diese über jeden Node einzeln über die Management VDOM gesendet werden:
| |
|
| |
| Feb 17 16:06:44 192.168.1.99 date=2014-02-16 time=23:09:10 devname=FG3K9B3E13700260 devid=FG3K9B3E13700260 logid=0001000014 type=traffic subtype=local level=notice vd=MGMT srcip=
| |
| 192.168.1.103 srcport=137 srcintf="mgmt1" dstip=192.168.1.255 dstport=137 dstintf="MGMT" sessionid=865 status=deny policyid=0 dstcountry="Reserved" srccountry="Reserved" trandisp=noop
| |
| service=137/udp proto=17 app=137/udp duration=0 sentbyte=0 rcvdbyte=0
| |
|
| |
| Feb 17 16:06:44 192.168.1.100 date=2014-02-16 time=23:09:10 devname=FG3K9B3E10700346 devid=FG3K9B3E10700346 logid=0001000014 type=traffic subtype=local level=notice vd=MGMT srcip=
| |
| 192.168.1.103 srcport=137 srcintf="mgmt1" dstip=192.168.1.255 dstport=137 dstintf="MGMT" sessionid=704 status=deny policyid=0 dstcountry="Reserved" srccountry="Reserved" trandisp=noop
| |
| service=137/udp proto=17 app=137/udp duration=0 sentbyte=0 rcvdbyte=0
| |
|
| |
| Weitere Informationen betreffend Einrichtung eines Syslog Servers siehe Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_kann_ich_auf_einer_Fortigate_die_Logs_zus.C3.A4tzlich_einem_Syslog_Server_senden.3F]]
| |
|
| |
| === Wie kann ich auf einer FortiGate im Cluster Mode zusätzlich zum "Port Monitoring" ein "Destination Monitoring" (DGD) konfigurieren? ===
| |
|
| |
| In einem FortiGate Cluster wird "Port Monitoring" aktiviert um den Status (Link) der Interfaces zu übewachen. Wird dieser Link beeinträchtigt wird ein Failover ausgeführt. In einigen Konstellation kann es Wichtig sein nicht nur den Port resp. das Interface zu übewachen sondern die Verbindung selber. Dies kann zusätzlich zum FortiGate HA Cluster konfiguriert werden anhand der Funktion "Dead Gateway Detection" (Link Monitor). Damit dies durchgeführt werden kann muss zuerst die Funktion des "Dead Gateway Detection" im HA konfiguriert werden:
| |
|
| |
| # config system ha
| |
| # set pingserver-monitor-interface [Definition der Interfaces für die Aktivierung der "Dead Gateway Detection" Funktion zB "port1" "port2"]
| |
| # set pingserver-failover-threshold [Gewichtung des Failovers; Möglich 0 - 50, Standard 10]
| |
| # set pingserver-flip-timeout [Flip-Timout in Minuten; Möglich 6 to 2147483647; Standard 6]
| |
| # end
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Die Option "pingserver-failover-threshold" steht im direkten Zusammenhang mit "ha-priority" konfiguriert unter "config
| |
| router gwdetect". Wird der Wert unter "pingserver-failover-threshold" auf 0 gesetzt wird ein Failover durchgeführt sobald
| |
| ein Ping verloren geht. Unter "pingserver-flip-timeout" wird definiert, dass wenn auf allen Cluster Nodes die definierte
| |
| Destination nicht erreichbar ist während des gesetzten Wertes ein Failover verhindert wird.
| |
|
| |
| Nachdem die Funktion im HA durch "pingserver-monitor-interface" aktiviert wurde, kann diese unter "Dead Gateway Detection" (Link Monitor) konfiguriert werden:
| |
|
| |
| # config router gwdetect
| |
| # edit 1
| |
| # set failtime [Anzahl Fehlversuche bevor ein Failover ausgeführt wird; Möglich 1 - 5; Standard 5]
| |
| # set ha-priority [Definiton der Gewichtung; Möglicher Wert 1 - 50; Standard 1]
| |
| # set interface "port1"
| |
| # set server [IPv4 Adresse des Servers resp. Pingserver]
| |
| # next
| |
| # edit 2
| |
| # set failtime [Anzahl Fehlversuche bevor ein Failover ausgeführt wird; Möglich 1 - 5; Standard 5]
| |
| # set ha-priority [Definiton der Gewichtung; Möglicher Wert 1 - 50; Standard 1]
| |
| # set interface "port2"
| |
| # set server [IPv4 Adresse des Servers resp. Pingserver]
| |
| # next
| |
| # end
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Die "ha-priority" kommt eine wichtige Funktion zu dh. der definierte Wert wird bei Verlust des Pings der HA Gewichtung hinzugefügt. Wenn
| |
| unter "config system ha" die Option auf "pingserver-failover-threshol" 10 gesetzt wird und die "ha-priority" auf 5, wird dêr Wert 5 bei
| |
| jedem Ping Verlust addiert dh. gehen 2 Pings verloren (5+5) = 10 = Failover da der Wert für "pingserver-failover-threshold" erreicht ist!
| |
| Die Option "ha-priority" wird nicht synchronisert in einem Cluster.
| |
|
| |
| == Wireless-Controller ==
| |
|
| |
| === Wo finde ich Informationen betreffend FortiGate Wireless Controller und Forti Access Points? ===
| |
|
| |
| Nachfolgender Artikel gibt Auskunft über die verschiedenen Konfigurationen und Betrieb von Forti Access Points im Zusammenhang mit dem FortiGate Wireless Controller:
| |
|
| |
| [[FortiAP:FAQ]]
| |
|
| |
| == Vdom ==
| |
|
| |
| === Was ist eine Vdom und was ist darunter zu verstehen sowie wie aktiviere ich diese? ===
| |
|
| |
| VDom (Virtuell Domain) wurde durch Fortinet 2004 vorgestellt und ist seitdem her ein fester Bestandteil jeder FortiGate Firewall. VDom ist eine Virtualisierung einer Firewall Instanz im Gesamten dh. sämtliche Firewall Komponenten/Konfiguration wird separariert. Eingeloggte Administratoren sehen auf den Ihnen zugeteilter VDom Instanz nur deren Konfiguration. Interkomunikation zwischen VDom Instanzen sind über virtualisierte Interfaces (Inter-VDOM-Link) direkt möglich ohne physikalische zu benutzen. Jede FortiGate hat die Möglichkeit -ohne zusätzliche Lizensierung- 10 VDOM's zu benutzen. Bis zur FortiGate-1000 können diese VDOM's nicht erweitert werden. Für FortiGate 1000 und grösser können die VDOM Instanzen anhand 25er Package erweitert werden! Die VDOM Funktionalist auf einer FortiGate ist per Standard deaktiviert. Um diee Funktion zu aktivieren führe folgendes durch:
| |
|
| |
| # config system global
| |
| # set vdom-admin enable
| |
| # end
| |
| You will be logged out for the operation to take effect
| |
| Do you want to continue (y/n)'''y'''
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Duruch die Aktivierung der VDOM Funktion auf einer FortiGate wird die bestehende Instanz zur "root" VDOM. Diese
| |
| Instanz kann nicht unbenannt werden! Weitere Informationen betreffend Details, Informationen sowie Konfiguration
| |
| siehe nachfolgenden Artikel:
| |
|
| |
| [[Datei:Fortigate-vdoms-50.pdf]]
| |
|
| |
| Desweiteren sollte betreffend CLI im Zusammenhang mit VDOM's folgender Artikel berücksichtigt werden:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Was_muss_in_der_CLI_.28Kommandozeile.29_betreffend_VDom.27s_beachtet_werden.3F]]
| |
|
| |
| === Was ist betreffend VDOM und verschiedenen Administratoren Rechte zu berücksichtigen? ===
| |
|
| |
| Wenn ein FortiGate Device betrieben wird mit veschiedenen VDOM's so können für diese VDOM's verschiedene Administratoren erstellt werden sowie diese den einzelnen VDOM' zugewiesen werden. Diesen Administratoren kann anhand der entsprechenden Mgmt. Profiles Rechte zugewiesen werden. Diese Mgmt. Profiles steuern auf welche Funktionen diese Administratoren Zugriff erlangen (zB Read-Only). Weitere Informationen über diese Mgmt. Profiles siehe auch folgendender Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_kann_ich_einen_.22read-only.22_Administrator_konfigurieren.2Ferstellen.3F]]
| |
|
| |
| Wenn mehrer VDOM's existieren und einzelne Administratoren diesen VDOM's zugewiesen wurden, sollte darauf geachtet werden, dass diese zusätzlichen Adminstratoren im Gegensatz zum Super Administrator nicht über folgende Rechte verfügen:
| |
|
| |
| - Kein Zugriff auf die Kommandozeile (CLI) sei es per SSH, Telnet, Console und CLI Widget
| |
| - Zugriff sollte nur erlaubt werden auf Web Mgmt. Interface ohne CLI Widget
| |
|
| |
| Der Grund liegt im undokumentierten Befehl "fnsysctl". Weitere Informationen über "fnsysctl" siehe nachfolgender Artikel:
| |
|
| |
| [[FortiGate:fnsysctl]]
| |
|
| |
| Anhand dieses Befehls kann "jeder" Administrator über die Kommandozeile (CLI) die Konfiguration jeder einzelnen VDOM sowie Globale Komponenten auslesen. Die "einzige" Möglichkeit dies zu verhindern ist der sogenannte "FIPS-CC Mode" in der eine FortiGate betrieben wird. Dabei handelt es sich um einen Standard resp. FIPS bedeutet "Federal Information Processing Standard". Siehe auch:
| |
|
| |
| http://de.wikipedia.org/wiki/Federal_Information_Processing_Standard
| |
|
| |
| Per Standard ist "FIPS-CC Mode" auf jeder FortiGate "deaktivert" und dies kann anhand folgenden Befehls kontrolliert werden:
| |
|
| |
| # get system status | grep FIPS
| |
| FIPS-CC mode: disable
| |
|
| |
| Wenn dieser Mode aktiviert werden soll kann dies durch folgenden Befehl durchgeführt werden:
| |
|
| |
| # config system fips-cc
| |
| # set status enable
| |
| # end
| |
|
| |
| Es ist jedoch absolut '''Ünabdingbar''' vorhergehend sich '''Ausgiebig''' zu informieren um was es sich beim "FIPS-CC Mode" handelt und welche Einschränkungen/Auswirkungen zu beachten sind. Dazu steht unter folgenden Link ein Dokument zur Verfügung das dies ausführlich beschreibt:
| |
|
| |
| [[Datei:Fips-cc-50.pdf]]
| |
| [[Datei:FIPS-CC-Certification-History.pdf]]
| |
|
| |
| === Was muss in der CLI (Kommandozeile) betreffend VDom's beachtet werden? ===
| |
|
| |
| Sobald auf der Kommandozeile (CLI = Command Line Interface) die VDOM Funktion aktiviert wird erweitert sich die hirarchische Struktur in der CLI um die einzelnen Konfigurationen der Firewall Instanzen abzubilden. Wie die VDOM Funktion aktiviert wird siehe nachfolgenden Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Was_ist_eine_Vdom_und_was_ist_darunter_zu_verstehen_sowie_wie_aktiviere_ich_diese.3F]]
| |
|
| |
| Nach dem die VDOM Funktion aktiviert ist verhätl sich die CLI folgendermassen:
| |
|
| |
| '''Global Editieren'''
| |
| # config global
| |
| # config sytem global
| |
|
| |
| '''VDOM Editieren
| |
| # config vdom
| |
| # edit [Vdom Name]
| |
|
| |
| === Müssen VDom Instanzen lizensiert werden und wie kann man diese Erweitern? ===
| |
|
| |
| Jede Fortigate besitzt per Standard 10 VDom Instanzen (FortiGate bis 1000er Serie untersützten 10 VDom’s und sind nicht erweiterbar). Upgrade auf einer höhere Anzahl VDom's bei grösseren Devices als FortiGate 1000er Serie sind jederzeit möglich (25 Package)! Die Virtualisierte Version der FortiGate unterstützt in der Basis Version (VM-00) KEINE VDom's und kann nicht anhand VDOM Lizenzen mit VDom's versehen werden! Wieviel VDom's welche virtuelle Version der FortiGate unterstützt und ob diese Erweiterbar sind sieht man aus dem folgenden Dokument:
| |
|
| |
| [[Fortinet:ProduktInfo#FortiGate_VM]]
| |
|
| |
| === Wie Registriere/Aktiviere ich eine zusätzliche VDom Lizenz auf einer FortiGate? ===
| |
|
| |
| Nachfolgender Artikel gibt Auskunft welche FortiGate (inkl. Virtualisierung) wieviele VDom's unterstützen:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#M.C3.BCssen_VDom_Instanzen_lizensiert_werden_und_wie_kann_man_diese_Erweitern.3F]]
| |
|
| |
| Wenn eine FortiGate sei es Physisch oder Virtualisiert mit zusätzlichen VDom's erweitert wird, muss folgendermassen vorgegangen werden:
| |
|
| |
| - Die zusätzlichen VDom Lizenzen werden anhand eines Lizenz Zertifikates geliefert!
| |
|
| |
| - Auf diesem Lizenz Zertifikat ist unter "VDOM License Number:" der entsprechende Lizenz Code aufgeführt!
| |
|
| |
| - Logge dich auf https://support.fortinet.com auf den Account ein indem die FortiGate mit dessen Serien Nummer registriert ist!
| |
|
| |
| - Wähle "Manage/View Products" klicke auf die entsprechende Serien Nummer der FortiGate auf der die VDom Lizenzerweiterung durchgeführt werden soll!
| |
|
| |
| - Wähle unter der entsprechenden Serien Nummer der FortiGate "Add VDOM License" und geben den auf dem Zertifikat aufgeführten "VDOM License Number:" ein!
| |
|
| |
| - Führe die Registration durch!
| |
|
| |
| - Nach der Registration wird ein entsprechender VDom Key unter "Add VDOM License" aufgeführt.
| |
|
| |
| - Nun muss der entsprechende "VDom Key" auf der FortiGate unter folgender Position eingespielt werden:
| |
|
| |
| Dashboard > Status > License Information > Virtual Domains
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Wenn ein Cluster Betrieben wird MUSS vorgängig ein Backup durchgeführt werden! Der "VDom Key"
| |
| muss auf beiden Nodes des Clusters eingespielt werden! Das Einspielen der Lizenz führt zu einem
| |
| sofortigen Neustart der Fortigate ohne Warnung!
| |
|
| |
| - Nach dem Neustart kann die max. Anzahl der VDom's unter folgender Position verifiziert werden:
| |
|
| |
| System > Dashboard> License Information > Virtual Domains
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Diese Verifikation sollte auf Master und Slave durchgeführt werden!
| |
|
| |
| === Kann ich die zur Verfügung stehenden Resourcen wie Memory, CPU etc. auf einer FortiGate einer bestimmten VDOM zuweisen? ===
| |
|
| |
| Nein dies ist so nicht möglich dh. eine feste Zuweisung von Resourcen wie zB RAM Bereich und/oder CPU usw. ist nicht möglich. Was konfiguriert werden kann ist die "Limitierung" von Resourcen. Damit wird gewährleistet, dass durch "Eine" VDOM/Instanz nicht alle Resourcen aufgebraucht werden und somit andere VDOM's beeinträchtigt werden. Nachfolgend die Konfigurationspunkte die für die Limitierung konfiguriert werden können (Stand FortiOS 5.0.4 / 5.2):
| |
|
| |
| Folgende Position zeigt die "Globalen Resourcen" die zur Verfügung stehen:
| |
|
| |
| [[Datei:Fortinet-812.jpg]]
| |
|
| |
| Unter folgender Position können die "Globalen Resourcen" für die einzelnen VDOM's limitiert werden:
| |
|
| |
| [[Datei:Fortinet-813.jpg]]
| |
|
| |
| Einige Resourcen sind für die einzelnen VDOM Instanzen über Mgmt. Web Interface ersichtlich. Dies gilt für folgende Resourcen:
| |
|
| |
| • Interface
| |
| • Ref. (Spalte im Web Mgmt. Interface per Standard deaktiviert)
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Ab FortiOS 5.2 sind zusätzlich folgende Resourcen über Web Mgmt. Interface ersichtlich:
| |
|
| |
| • CPU
| |
| • Memory
| |
| • New Sessions per Second (Spalte im Web Mgmt. Interface per Standard deaktiviert)
| |
| • Sessions (Spalte im Web Mgmt. Interface per Standard deaktiviert)
| |
|
| |
| [[Datei:Fortinet-1127.jpg]]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Auf der Kommandozeile steht für FortiOS 5.2 folgendes Kommando zur Verfügung:
| |
|
| |
| # diagnose sys vd stats
| |
| vdom-1 cpu:0% mem:0%
| |
| root cpu:5% mem:14%
| |
|
| |
| === Kann ich die "management-vdom" Funktion die der "root" VDOM zugewiesen ist einer anderen VDOM zuweisen? ===
| |
|
| |
| Der Funktion "management-vdom" kommt einer wichtigen Funktion gleich dh. über diese VDOM resp. deren Interfaces wird sämtlicher "local" Traffic ausgeführt. Dies bedeutet die FortiGate benötigt für Ihre Services wie Antivirus, IPS, Application Control, WebFilter usw. Definition Files, DNS Resolution etc. All dieser "local" Traffic wird über die "management-vdom" abgewickelt resp. deren Interface's. Per Standard ist die VDOM "root" als "management-vdom" definiert. Möchte man das Aendern kann dies über Web Mmt. Interface durchgeführt werden:
| |
|
| |
| [[Datei:Fortinet-1128.jpg]]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Die Auswirkungen, wenn die "managemnt-vdom" von der VDOM "root" auf eine neue VDOM verschoben
| |
| wird, sollten gut überlegt sein sowie deren Auswirkungen. Die Konfiguration kann ebenfalls
| |
| über die Kommandozeile durchgeführt werden:
| |
|
| |
| # config system global
| |
| # set managemtn-vdom [Name der entsprechenden VDOM]
| |
| # end
| |
|
| |
| === Welche Konfiguration/Resourcen werden durch die "Globale Instanz" einer VDom Instanz zur Verfügung gestellt? ===
| |
|
| |
| VDom's sind Firewall Instanzen die komplett separiert sind und zB keine Routing Table, Policy, Object etc. teilen. Nichts desto trotz werden vers. Komponenten von der "Global Instanz" den VDOM Instanzen zur Verfügung gestellt. Dies sind zB Antivirus Definition Files, Firmware etc. Nachfolgend einen Ueberblick "was" von der "Global Instanz" den VDom Instanzen zur Verfügung gestellt wird:
| |
|
| |
| - Hostname
| |
| - DNS Settings
| |
| - System Time (NTP)
| |
| - Firmware Version
| |
| - Log Konfiguration betreffend Log Speicherort
| |
| - Endpoint Scans
| |
| - UTM Datenbanken
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Zertifikate werden in der "Globalen Instanz" vewaltet und sind Global zu betrachten!
| |
|
| |
| Alle diese Funktionen benötigen teilweise Internet Access und werden auf einer FortiGate auch als "local-in/out" Traffic angesehen. Dieser "local-in/out" Traffic wird über das Interface der "management-vom" abgewickelt (Standard VDOM "root"). Die Zuweisung der "management-vdom" kann verändert werden. Dazu siehe nachfolgenden Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Kann_ich_die_.22management-vdom.22_Funktion_die_der_.22root.22_VDOM_zugewiesen_ist_einer_anderen_VDOM_zuweisen.3F]]
| |
|
| |
| === Ist das Routing für eine VDom "Global" oder per "VDom" zu verstehen? ===
| |
|
| |
| Das Routing ist nicht "Global" implementiert sondern per "VDom". Dies bedeutet eine "VDom" ist wie eine seperate in sich geschlossene Routing Instanz und verfügt somit auch ihre eigenen Routing Table. Deshalb muss in jeder "VDom" seperat geroutet werden! Ein Routing Eintrag innerhalb einer VDom wird wie üblich erstellt:
| |
|
| |
| [[Datei:Fortinet-138.jpg]]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Ein entsprechender Routing Eintrag kann ebenfalls über die Kommandozeile durchgeführt werden:
| |
|
| |
| # config vdom
| |
| # edit [Name der entsprechenden VDom]
| |
| # config router static
| |
| # edit [Gebe einen Sequenz an zB "1"]
| |
| # set dst [IPv4 Subnet]
| |
| # set gateway [IPv4 Adresse]
| |
| # end
| |
|
| |
| === Was muss ich berücksichtigen im Zusammenhang mit einer VDom und Layer 2? ===
| |
|
| |
| Eine VDom im Transparent Modus reagiert eigentlich wie eine Bridge dh. die Interface's die für eine Transparent VDom benutzt werden sind nicht konfigurierbar mit einer IP. Die Aussage, dass eine Fortigate im Transparent Modus als "Bridge" agiert ist zwar im Grundsatz richgit dennoch wiederum nicht ganz richtig dh. richtig wäre "wie ein Switch". Der Grund liegt in den UTM Möglichkeiten im Transparent Modus denn diese benötigen einen Layier um eine Proxyfizierung durchzuführen und deshalb die Festellung "wie ein Switch". Auch im Layer 2 sind einige Umstände zu berücksichtigen damit Traffic von Layer 2 korrekt abgearbeitet wird. Fortinet hat in der "Knowledge Base" ein Dokument Released das diesem Umstand Rechnung trägt:
| |
|
| |
| [[Datei:Fortinet+Solutions+for+Transparent+Mode+(Layer-2)-v2.pdf]]
| |
|
| |
| === Können VDom's im HA (High Availability) betrieben werden? ===
| |
|
| |
| VDOM’s sind Vollumfänglich HA-fähig (Cluster). In Active-Passive Mode laufen sämtliche VDOM’s per Standard jeweils auf der aktiven FortiGate. Der andere passive Device wird erst aktiv sobald die aktive FortiGate resp der primäre Device ausfällt. Dies ist das Standard Verhalten im Cluster (Active-Passive Modus). Es kann jedoch aus Resourcen Gründen (zB Performance) auf einer Active-Passive Installation VDom's auf den Passiven Device ausgelagert werden. Wenn dies durchgeführt wird bleibt der Cluster zwar Active-Passive aber die jeweiligen Nodes übernehmen betreffend den VDom's entweder den Activen Part und/oder den Passiven Part.
| |
|
| |
| '''Node Active''' '''Node Passive'''
| |
| Phyiscal-Node1 Physical-Node2
| |
| vdom-1 (Active) vdom-1 (Passive)
| |
| vdom-2 (Passive) vdom-2 (Active)
| |
|
| |
| === Wie kann ich eine neue VDom erzeugen/erstellen ===
| |
|
| |
| Grundvoraussetzung um eine VDom auf einer FortiGate zu erstellen ist das die Funktion aktiviert ist. Nachfolgender Artikel gibt Auskunft wie dies durchgeführt wird:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Was_ist_eine_Vdom_und_was_ist_darunter_zu_verstehen_sowie_wie_aktiviere_ich_diese.3F]]
| |
|
| |
| Wenn die Funktion VDom aktiviert wird so wird automatisch anhand der vorhandene Konfiguation eine VDom mit dem Namen "root" erstellt (kann nicht umbenannt werden)! Möchte man zu dieser VDom eine zusätzliche VDOM erzeugen so kann dies im Mgmt. Web Interface über folgende Position durchgeführt werden:
| |
|
| |
| Global > VDOM > VDOM > Create New
| |
|
| |
| Es muss ein entsprechender Name vergeben werden sowie der "Operation Mode" den die VDOM benutzen soll. Möchte man eine Transparent Vdom erstellen muss eine "Management IP/Netmask" konfiguriert werden. Diese "Management IP/Netmask" stellt ein entsprechendes Interface dar auf der FortiGate auf der die entsprechende IP konfiguriert ist. Da eine Transparent VDom über kein Routing verfügt (Bridge) muss für das "Management IP/Netmask" Interface ein Routing definiert werden. Dieses Routing beschränkt sich einzig und alleine auf diese "Management IP/Netmask" resp. auf das physisch konfigurierte Interface. Weitere Informationen betreffend Konfiguration einer Transparent VDom siehe nachfolgenden Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_konfiguriere.2Ferstelle_ich_eine_VDom_Instanz_im_Transparent_Mode.3F]]
| |
|
| |
| === Wie konfiguriere/erstelle ich eine VDom Instanz im Transparent Mode? ===
| |
|
| |
| Wenn man eine Transparent VDom erstellen möchte kann auch ohne die VDom Funktion zu aktivieren die "root" VDom die als NAT definiert ist als "Transparent Mode" definiert werden. Wenn jedoch zusätzlich zur "root" VDom eine zusätzliche VDom im Transparent Mode erstellt werden soll muss zuerst die VDom Funktion aktiviert werden. Wie dies durchzuführen ist siehe nachfolgenden Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Was_ist_eine_Vdom_und_was_ist_darunter_zu_verstehen_sowie_wie_aktiviere_ich_diese.3F]]
| |
|
| |
| Danach erstelle eine neue VDOM und konfiguriere diese für Transparent Modus:
| |
|
| |
| # config vdom
| |
| # edit [Name der neuen VDom zB "vdom-2"]
| |
| # config system settings
| |
| # set opmode transparent
| |
| # set manageip [IPv4 Adresse des Management Interfaces]
| |
| # end
| |
|
| |
| # config router static
| |
| # edit 1
| |
| # set gateway [IPv4 Adresse des Gateway für "manageip"]
| |
| # end
| |
|
| |
| # end
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Die Option "manageip" definiert die IP eines bestehenden und konfigurierten physischen Interfaces. Dieses
| |
| wird benutzt um die Transparent Firewall zu verwalten da diese ja nicht zugänglich ist da eine Transparent
| |
| Firewall über keine IP verfügt (Bridge). Aus diesem Grund muss für dieses Interface "manageip" eine Route
| |
| gesetzt werden. Diese Route ist beschränkt auf die Konfiguration "manageip" resp. auf das physische Interface.
| |
| Eine VDom im Transparent Modus reagiert eigentlich wie eine Bridge dh. die Interface's die für eine Transparent
| |
| VDom benutzt werden sind nicht konfigurierbar mit einer IP. Die Aussage, dass eine Fortigate im Transparent
| |
| Modus als "Bridge" agiert ist nicht ganz richtig dh. richtig wäre "wie ein Switch". Der Grund liegt in den
| |
| UTM Möglichkeiten im Transparent Modus denn diese benötigen einen Layier um eine Proxyfizierung durchzuführen
| |
| und deshalb die Festellung "wie ein Switch". Im nachfolgenden Dokumentation wird erklärt wie Interface's im
| |
| Zusammenhang mit VDom's zu benützen sind:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wo_findet_ich_die_Dokumente_wie_Datasheets.2C_Quick_Start_Guide.2C_User_Guide_etc._.3F |Hosting More as one FortiOS instance on a single FortiGate using VDOMS an VLANs"]]
| |
|
| |
| Im Zusammenhang mit Layer 2 und VDom's sind einige Umstände zu berücksichtigen dh. Fortinet hat in der "Knowledge
| |
| Base" ein Dokument Released das diesem Umstand Rechnung trägt:
| |
|
| |
| [[Datei:Fortinet+Solutions+for+Transparent+Mode+(Layer-2)-v2.pdf]]
| |
|
| |
| === Was sind inter-VDom-Links (Interfaces) und wie werden diese erstellt? ===
| |
|
| |
| Immer wieder ist von inter-VDom-Links resp Interface die Rede. Inter-VDom-Links sind "Virtuelle Interfaces" (Soft-Link), welche eine NAT/Routing-VDommit einer anderen NAT/Routing-VDomverbinden. Diese Inter-VDom-Links ersetzen "physische Kabel". Inter-VDom-Links sollten -sofern keine Transparent Mode VDom- immer mit einer IP Konfiguration versehen werden obwohl dies nicht ein "muss" ist. Empfohlen wird zwischen Zwei VDom NAT Firewall zB ein "Transfer Segment" zu konfigurieren und die entsprechenden IP Ranges/Subnets darüber zu Routen. Auch können mit inter-VDom-Links "meshed" Netzwerke zwischen verschiedenen VDom’s etabliert werden. Um Ringrouten (Loop) zu vermeiden, wird der TTL eines IP-Packets durch die Inter-VDom-Links auf 6 "hope" beschränkt. Das Packet kann also maximal 6x durch ein Inter-VDom-Link übertragen werden bevor es verworfen wird.
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Unter FortiOS 4 MR3 war es nicht möglich Inter-VDom-Links zu erstellen zwischen zwei VDom's in vers. Modi dh. Transparent
| |
| und/oder NAT. Inter-VDom-Links waren unter FortiOS 4 MR3 nur möglich wenn beide VDom's im gleichen Mode liefen. Die einzige
| |
| Möglichkeit in solche einem Scenario unter FortiOS 4 MR3 war die "physischen Interfaces" mit einem RJ-45 zu verbinden. Unter
| |
| FortiOS 5.0 / 5.2 ist es nun möglich Inter-VDom-Links zu erstellen zwischen VDom's die in unterschiedlichen Modi konfiguriert
| |
| sind. dh. NAT und Transparent Modus.
| |
|
| |
| Ein Inter-Vdom-Link kann nur in der "Globalen" Instanz konfiguriert werden und so einer entsprechenden Instanz zur Verfügung gestellt werden. Ein Inter-VDom-Link wird folgendermassen erstellt:
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Es ist möglich unter bestimmten Vorraussetzungen eine Acceleration für einen Inter-VDom-Link zu konfigurieren.
| |
| Um welche Vorraussetzung es sich handelt siehe nachfolgenden Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Kann_man_f.C3.BCr_einen_Inter-VDom-Link_eine_Interface_Acceleration_konfigurieren.3F]]
| |
|
| |
| System > Network > Interface
| |
|
| |
| [[Datei:Fortinet-135.jpg]]
| |
|
| |
| [[Datei:Fortinet-136.jpg]]
| |
|
| |
| [[Datei:Fortinet-137.jpg]]
| |
|
| |
| In unserem Beispiel wurde die VDom "root" verbunden mit der VDom "root-2" anhand eines Transfernetzes 172.20.0.0/24! Wenn hinter der VDom "root-1" ein weiteres Netzwerk existieren würde müsste dieses auf der VDom "root" geroutet werden dh. auf den VDom Link! Da unsere VDom "root-1" mit einem inter-VDOM-Link versehen ist muss der Default Gateway der VDom "root-1" auf den Inter-VDom-Link von "root" zeigen dh. erstelle einen Routing Eintrag und berücksichtige folgender Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Ist_das_Routing_f.C3.BCr_eine_VDom_.22Global.22_oder_per_.22VDom.22_zu_verstehen.3F]]
| |
|
| |
| [[Datei:Fortinet-138.jpg]]
| |
|
| |
| === Kann man für einen Inter-VDom-Link eine Interface Acceleration konfigurieren? ===
| |
|
| |
| Unter FortiOS 4 M3 war dies nicht möglich. Neu mit FortiOS 5.0 / 5.2 ist dies nun möglich, jedoch nur wenn der Device über "NP4/NP6 Network Processor" verfügt (Kein SoC). Der Unterschied zwischen dem NP4 und/oder NP6 Prozessor liegen daher gehend, dass eine Acceleration für ein Inter-VDom-Link zwischen einer NAT und Transparent VDom nur mit einem NP6 Prozessor möglich ist jedoch nicht für NP4. Wenn ein Inter-VDom-Link mit Acceleration versehen wird (verlinkt) so erscheinen diese Links folgendermassen:
| |
|
| |
| npuX-vlink0
| |
| npuX-vlink1
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> "X" indiziert den Index des NP4/NP6 Prozessors! Ein Beispiel wäre:
| |
|
| |
| npu'''0'''-vlink0, npu'''0'''-vlink1 (Inter-VDOM Link ist verlinkt mit dem "Ersten" ("0") Prozessors des NP4/NP6 Prozessors)
| |
| npu'''1'''-vlink0, npu'''1'''-vlink1 (Inter-VDOM Link ist verlinkt mit dem "Zweiten" ("1") Prozessors des NP4/NP6 Prozessors)
| |
|
| |
| Um Inter-VDom-Link's aufzulisten um festzustellen ob diese Accelerated resp. verlinkt sind zum "NP4/NP6 Prozessor" gebe auf der Kommandozeile folgendes ein:
| |
|
| |
| # get hardware nic | grep npu
| |
|
| |
| Folgendes Kommando auf der CLI zeigt auf welche Ports auf den "NP4/NP6 Prozessor" verlinkt sind:
| |
|
| |
| # diagnose npu [np4 | np6] list
| |
| ID Model Slot Interface
| |
| 0 On-board port1 port2 port3 port4
| |
| port5 port6 npu0-vlink0 npu0-vlink1|
| |
| 1 FMC-C20 FMC3 fmc3/1 fmc3/2 fmc3/3 fmc3/4
| |
| fmc3/5 fmc3/6 fmc3/7 fmc3/8
| |
| fmc3/9 fmc3/10 fmc3/11 fmc3/12
| |
| fmc3/13 fmc3/14 fmc3/15 fmc3/16
| |
| fmc3/17 fmc3/18 fmc3/19 fmc3/20
| |
| npu1-vlink0 npu1-vlink1
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Weitere Informationen siehe Knowledge-Base Artikel:
| |
|
| |
| http://kb.fortinet.com/kb/microsites/search.do?cmd=displayKC&docType=kc&externalId=FD33888&sliceId=1&docTypeID=DT_KCARTICLE_1_1&dialogID=48363952&stateId=0 0 48365253
| |
|
| |
| === In Zusammenhang mit VDom's auf einer FortiGate über welche VDom läuft der Mgmt. Traffic? ===
| |
|
| |
| Wenn ein Fortigate im Zusammenhang mit VDom benutzt wird und mehrer VDom Instanzen vorhanden sind ist zu berücksichtigen, dass der Mgmt. Traffic per Standard über die "root" VDom läuft. Als Mgmt. Traffic wird der "local-in/out" Traffic definiert. Dieser "local-in/out" Traffic wird definiert als zB:
| |
|
| |
| DNS
| |
| NTP
| |
| External Logging
| |
| FortiGuard
| |
| Alert Emails
| |
| SNMP traps
| |
| Quarantine
| |
|
| |
| Wir die "root" VDom als Transparent VDom konfiguriert übernimmt der Mgmt. Traffic das Interface das in der Transparent VDom als "manageip" definiert wird. Weitere Informationen dazu siehe nachfolgenden Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_konfiguriere.2Ferstelle_ich_eine_VDom_Instanz_im_Transparent_Mode.3F]]
| |
|
| |
| Wenn auf einer Fortigate der Mgmt. Traffic "nicht" über die "root" VDom abgewickelt werden möchte kann die Aufgabe einer anderen VDom zugewiesen werden. Weitere Informationen dazu siehe nachfolgenden Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Kann_ich_die_.22management-vdom.22_Funktion_die_der_.22root.22_VDOM_zugewiesen_ist_einer_anderen_VDOM_zuweisen.3F]]
| |
|
| |
| === Kann ein physisches Interface auf einer FortiGate mehreren VDom's zugewiesen werden? ===
| |
|
| |
| Als Grundsatz gilt: Ein physisches Interface kann nur "einer" VDom zugewiesen werden. Wenn ein physisches Interface mehreren VDom's zugewiesen werden soll, muessen auf dem physischen Interface VLAN's konfiguriert werden und diese VLAN's den einzelnen VDom's zugewiesen werden. Nur so kann ein physisches Interface für mehrere VDom's benutzt werden. Nachfolgend ein Beispiel einer Konfiguration:
| |
|
| |
| # config system interface
| |
| # edit [Name des VLAN's]
| |
| new entry added
| |
| # set interface port1
| |
| # set vlanid [VLAN ID]
| |
| # set ip [VLAN IP Adresse sowie Subnet Maske zB 10.100.1.10/24]
| |
| # set vdom [Name der entsprechenden VDOM]
| |
| # end
| |
|
| |
| === Kann ich für eine FortiGate eine VDOM erstellen die ausschliesslich für Management genutzt wird? ===
| |
|
| |
| Um dies zu realisieren stehen vers. Möglichkeiten zu Verfügung. Grunsätzlich geht man jedoch von zwei Möglichkeiten aus dh. wird ein Cluster betrieben kann die HA Funktion "Reserve Management Port for Cluster Member" benützt weden oder anderseits kann in einem Cluster eine VDOM erstellt werden die ausschlisslich für Management Zwecke zur Verfügung steht. Beide Möglichkeiten stehen im Zusammenhang mit dem Clustering. Weitere detaillierte Informationen zu diesen zwei Möglichkeiten siehe nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Kann_ich_f.C3.BCr_einen_Cluster_eine_VDOM_erstellen_die_ausschliesslich_f.C3.BCr_das_Management_benutzt_wird.3F]]
| |
|
| |
| === Ich möchte BGP Traffic über eine Transparent VDOM/Firewall erlauben jedoch wird dieser geblockt? ===
| |
|
| |
| Wenn man eine Transparent Firewall (normalerweise eine VDOM) konfiguriert und auf jeder Seite der Interface's ein Router angeschlossen ist, die miteinander komunizieren und BGP Informationen austauschen (TCP 179), wird dieser Traffic durch die Transparent Firewall -sofern eine entsprechende Firewall Policy Rule existiert- abgearbeiet. Damit der Traffic sauber durchgeht muss folgendes kontrolliert werden:
| |
|
| |
| • Auf der Transparent Firewall muss eine Multicast Policy konfiguriert werden (Per Standard existiert diese dh. "all allow")
| |
|
| |
| • Es muss eine Firewall Policy konfiguriert werden die den BGP Traffic erlaubt zwischen den Interfaces (TCP-179)
| |
|
| |
| • Auf den Interface's muss folgendes konfiguriert werden (sofern mit mehreren Segmenten gearbeitet wird zB VLAN's):
| |
|
| |
| # config system interface
| |
| # edit [Gebe das ensprechende Interface an zB wan1]
| |
| # set l2forward enable
| |
| # set forward-domain 10
| |
| # end
| |
|
| |
| # config system interface
| |
| # edit [Gebe das ensprechende Interface an zB internal1]
| |
| # set l2forward enable
| |
| # set forward-domain 10
| |
| # end
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Durch die Konfiguration der Interface's in der gleichen "forward-domain" werden diese
| |
| direkt verbunden! Dies bedeutet "Layer 2 broadcasts" werden beschränkt auf die gleiche Gruppe.
| |
| Per Standard sind alle Interfaces in der Gruppe "0". Das Kommando "forward-domain" steht nur
| |
| im Transparent Mode zur Verfügung. Wenn VLAN's im Transparent Mode benutzt werden muss/sollte
| |
| jedes VLAN in eine seperate "forward-domain" da ansonsten ARP Packete dupliziert werden da
| |
| für jedes VLAN im Transparent Mode die gleiche MAC Adresse benutzt wird. Somit kann/kommt es
| |
| zu Kollisionnen! Desweiteren sollte die MTU kontrolliert werden dh. wenn die BGP Session kurz
| |
| hochgefahren wird um nachträglich gleich wieder in den "closed" Status zu gehen muss die MTU
| |
| Size auf den Router kontrolliert sowie event. die der Fortinet angepasst werden. Die MTU Size
| |
| auf einer Fortigate anzupassen wird wiefolgt durcheführt:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_passe_ich_auf_einem_Interface_die_MTU_Size_an.3F]]
| |
|
| |
| == Client Reputation/Threat Weight/Device Identification ==
| |
|
| |
| === Wie funktioniert "Client Reputation/Threat Weight" und/oder "Device Identification" sowie auf welchen Geräten steht diese Funktion zur Verfügung? ===
| |
|
| |
| Eine "Client Reputation" (Ab FortiOS 5.0) sowie "Threat Weight" (Ab FortiOS 5.2) bedeutet, dass Clients überprüft werden anhand eines Scores wie deren Reputation (Ruf) aussieht. Dies wird anhand des Logs durchgeführt. Was wiederum bedeutet, dass die Reputation anhand der Logs und deren Events eine Auswertung durchführt um die Reputation jedes einzelnen Clients zu ermitteln. Die Ermittlung der Clients umfasst die folgenden Informationen:
| |
|
| |
| • MAC Adresse
| |
| • IP Adresse
| |
| • Operating System
| |
| • Hostname
| |
| • Username
| |
| • Zeit die vergangen ist seit ein Device das letzte Mal erkannt wurde und über welches Interface diese Erkennung stattgefunden hat.
| |
|
| |
| Diese Client Informationen sind über folgende Position auf einer FortiGate ersichtlich:
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Unter FortiOS 5.2 wurde der Name betreffend "Client Reputation" gewechselt auf
| |
| "Threat Weigt". Ebenfalls wurde die Menüpositon verschoben und ist neu ersichtlich
| |
| unter:
| |
|
| |
| Log & Report > Log Config > Threat Weight
| |
|
| |
| User & Device > Device > Device Definition
| |
|
| |
| Die Auswertung um die Reputation der Clients zu ermitteln umfasst folgende Funktionen:
| |
|
| |
| • Firewall Policy Block
| |
| • Verbindungend Fehlgeschlagen
| |
| • Intrusion Protection
| |
| • Malware Detection
| |
| • Web Aktivitäten
| |
| • Application Protection
| |
| • Geo Lokation
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Um die Reputation der Clients zu ermitteln werden die UTM Funktionen auf der FortiGate benützt! Dies bedeutet folgende UTM
| |
| Funktionen müssen folgendermassen konfiguriert sein:
| |
|
| |
| • UTM Security Profiles > Antivirus
| |
| Konfiguriere für DLP die Funktionen die notwendig sind!
| |
|
| |
| • UTM Security Profiles > Web Filter
| |
| In den WebFilter Profilen müssen die entsprechenden Kategorien die nicht zugelassen sind auf "Block" sein sowie ALLE Kategorien
| |
| die erlaubt sind auf "Monitor". Kombinationen mit "Authenticate" sind natürlich ebenfalls möglich. Da die "Client Reputation"
| |
| über das Log ermittelt wird muss einfach gewährleistet sein, dass die Clients über den WebFilter anhand zB "Monitor" übewacht werden!
| |
|
| |
| • UTM Security Profiles > Application Control > Application Sensor
| |
| Für die Funktion Application Controll gilt dasselbe wie für den WebFilter dh. auch hier analysiert die Client Reputation die
| |
| Logs was wiederum bedeutet, dass ALLE Applicationen entweder auf "Block" oder auf "Monitor" gesetzt werden ob "known" oder
| |
| "unknown". Nur so könnend die Clients überwacht werden (Log) und später durch die "Client Reputation" das Log ausgewertet werden.
| |
|
| |
| • UTM Security Profiles > Intrusion Protection > IPS Sensor
| |
| Im IPS Sensor muss für die "Clients" ein Client Sensor konfiguriert werden dh. ein Sensor der ALLE Signaturen betreffend Client
| |
| "Monitored" und ins Log schreibt. Nur so ist gewährleistet das die "Client Reputation" die nötigen Auswertungen über das IPS Log
| |
| durchführen kann. Wenn Server etc. ebenfalsl in die "Client Reputation" einbezogen werden sollen muss ein entsprechender IPS
| |
| Sensor mit den nötigen Signaturen konfiguriert und über "Monitor" in das Log geschrieben werden.
| |
|
| |
| • UTM Security Profiles > Email Filter
| |
| Konfiguriere Email Filtering die Funktionen die notwendig sind!
| |
|
| |
| • UTM Security Profiles > Data Leak Prevention > Sensor
| |
| Konfiguriere für DLP die Funktionen die notwendig sind!
| |
|
| |
| Die Funktion "Client Reputation" für FortiOS 5.0 sowie "Threat Weight" für FortiOS 5.2 stehen auf folgenden Devices zur Verfügung (Siehe Software Matrix "UTM"):
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Welche_Ger.C3.A4te.2FDevices_werden_vom_neuen_FortiOS_5_unterst.C3.BCtzt_und_welche_neuen_Features_umfasst_FortiOS_5.3F]]
| |
|
| |
| Um die "Client Reputation" zu aktivieren auf einem Device muss innerhalb der "Interface" Konfiguration unter "System > Network > Interface" die Position "Detect and Identify Devices" aktiviert werden. Dies bedeutet das die "Client Reputation/Threat Weight" im direkten Zusammenhang steht mit der Device Identifikation! Die "Client Reputation/Threat Weight" kann unter folgender Position aktiviert sowie konfiguriert werden:
| |
|
| |
| '''FortiOS 5.0'''
| |
| User & Device > Client Reputation > Reputation Definition
| |
|
| |
| '''FortiOS 5.2'''
| |
| Log & Report > Log Config > Threat Weight
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Sobald die "Client Reputation" aktiviert wird erscheint eine Hinweis/Warnmeldung, dass alle Policys und alle Funktionen
| |
| auf Log gesetzt werden. Dieser Umstand gilt für FortiOS 5.0 jedoch nicht für FortiOS 5.2. Da die "Client Reputation/Threat Weight"
| |
| über Log Analyse durchgeführt wird und als Grundlage muss geloggt werden. Dies bedeutet die vers. zB Policys können nicht mehr
| |
| für das Logging deaktiviert werden da die entsprechende Position auf dem WebGui "invers" erscheint da geforced durch die
| |
| (gilt nur für FortiOS 5.0) "Client Reputation". Aus diesem Grund hier nochmals der Hinweis, dass "Client Reputation" sehr
| |
| Performance intensiv ist und nur auf den entsprechenden Devices und auch dort mit Vorsicht zu implementieren ist.
| |
|
| |
| === Was ist der Unterschied zwischen "Client Reputation" und "Threat Weight"? ===
| |
|
| |
| Unter FortiOS 5.0 wurde "Client Reputation" Funktion neu implementiert. Details betreffend "Client Reputation" siehe nachfolgenden Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_funktioniert_.22Client_Reputation.2FThreat_Weight.22_und.2Foder_.22Device_Identification.22_sowie_auf_welchen_Ger.C3.A4ten_steht_diese_Funktion_zur_Verf.C3.BCgung.3F]]
| |
|
| |
| Unter FortiOS 5.2 wurde "Client Reputation" umgetauft auf "Threat Weight" und die Menüposition verschoben:
| |
|
| |
| Log & Report > Log Config > Threat Weight
| |
|
| |
| Der "offensichtliche" Hauptunterschied liegt darin, dass unter FortiOS 5.0 dh. für "Client Reputation" die Log's "geforced" aktiviert werden. Dies bedeutet sobald ich unter FortiOS 5.0 "Client Reputation" benutzen möchte, werden ALLE Logs aktiviert und diese können nicht mehr deaktiviert/manipuliert werden. Unter FortiOS 5.2 wird dies nicht durchgeführt und die Logs bleiben konfigurier/manipulierbar. Nicht nur die Menüposition wurde für FortiOS 5.2 verschoben sondern ebenfalls das Kommando in der CLI:
| |
|
| |
| # config log threat-weight
| |
| # set blocked-connection [low | medium | high | critical | disable]
| |
| # set failed-connection [low | medium | high | critical | disable]
| |
| # set malware-detected [low | medium | high | critical | disable]
| |
| # set max-rep-db-size [Maximum MBytes]
| |
| # set url-block-detected [low | medium | high | critical | disable]
| |
| # set window-size [Maximal Tage des Zeitfenster für die Daten 1 - 30]
| |
| # config application
| |
| # edit [Gebe einen entsprechenden Category ID an; benutze ? für weitere Infos]
| |
| # set category [category_int>
| |
| # set level [low | medium | high | critical | disable]
| |
| # end
| |
| # config geolocation
| |
| # edit [Gebe einen entsprechenden Integer an zB 1]
| |
| # set country [Gebe den entsprechenden Country Code an]
| |
| # set level [low | medium | high | critical | disable]
| |
| # end
| |
| # config ips
| |
| # set info-severity [low | medium | high | critical | disable]
| |
| # set low-severity [low | medium | high | critical | disable]
| |
| # set medium-severity [low | medium | high | critical | disable]
| |
| # set high-severity [low | medium | high | critical | disable]
| |
| # set critical-severity [low | medium | high | critical | disable]
| |
| # end
| |
| # config level
| |
| # set low [1 bis 10]
| |
| # set medium [5 bis 30]
| |
| # set high [10 bis 50]
| |
| # set critical [30 bis 100]
| |
| # end
| |
| # config web
| |
| # edit [Gebe einen entsprechenden Integer an zB 1]
| |
| # set group [Gebe eine Entsprechende Group Category ID an; benutze ? für weitere Infos]
| |
| # set level [disable | low | medium | high | critical]
| |
| # end
| |
| # end
| |
|
| |
| === Wie kann ich über die Device Identification Funktion anhand einer Mac Adresse einen Device blocken (802.11x)? ===
| |
|
| |
| Wenn über die Funktion der "Device Identification" ein spezifischer Device mit einer spezifischen MAC Adresse geblockt werden soll (802.11x) so kann dies folgendermassen konfiguriert werden:
| |
|
| |
| # config user device
| |
| # edit [Name für den entsprechenden Device zB "phone-1"
| |
| # set mac [MAC Adresse des Device den man blocken möchte zB "01:12:13:14:15:16"]
| |
| # next
| |
| # end
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Diese Konfiguration kann ebenfalls über das Web Mgmt. Interface durchgeführt werden und zwar über folgende
| |
| Position:
| |
|
| |
| User & device > Device > Device definition > Create new
| |
|
| |
| Die nachfolgende Konfiguration ist nur über Kommandozeile möglich. Dies bedeutet. Als Erstes muss eine Liste zB. "black-list" erfasst werden und der vorgängig erfasste Device mit dessen MAC Adresse zu dieser "black-list" hinzugefügt werden:
| |
|
| |
| # config user device-access-list
| |
| # edit [Name der Liste zB "black-list "]
| |
| # set default-action [accept | deny; Standard "accept"]
| |
| # config device-list
| |
| # edit [Gebe einen entspechenden Integer an zB "1"]
| |
| # set device [Name des entsprechenden Device das unter "config user device" definiert wurde zB "phone-1"]
| |
| # set action [Gebe die entsprechende Action ein dh. "deny | accept"]
| |
| # next
| |
| # end
| |
| # next
| |
| # end
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Wenn eine "device-access-list" erstellt wird und alle Device erfasst werden die Zugriff erlangen sollen dh. "white-list"
| |
| kann die "default-action" auf "deny" gesetzt werden. Wenn die Position "default-action" auf "deny" steht werden alle nicht
| |
| definierten/bekannten Device's geblockt!
| |
|
| |
| Nun muss die "device-access-list" die erstellt wurde unter dem entsprechenden Device konfiguriert werden:
| |
|
| |
| # config system interface
| |
| # edit [Name des entsprechenden Devices zB "internal"]
| |
| # set device-identification enable
| |
| # set device-access-list [Name der entsprechende "device-access-list" zB "black-list"]
| |
| # next
| |
| # end
| |
|
| |
| Wenn diese Konfiguration im Zusammenhang mit einer Forti Access Point genutzt werden soll gibt nachfolgender Artile Auskunft über diese Konfiguration:
| |
|
| |
| [[FortiAP:FAQ#Wie_und_soll_ich_.C3.BCberhaupt_f.C3.BCr_eine_SSID_einen_Mac_Filter_.28802.11x.29_Konfigurieren_f.C3.BCr_eine_Authentifizierung.3F]]
| |
|
| |
| === Wie kann ich im Log einer FortiGate die MAC Adressen von Device's anzeigen lassen? ===
| |
|
| |
| Wenn im "Forward" Log auf einer FortiGate sowie im "Traffic" Log eines FortiAnalyzer die MAC Adresse der Devices in der Spalte "Source MAC" aufgelistet werden soll so muss auf dem entsprechenden Interface die "Identify and Detect Device" Funktion aktiviert werden. Dazu steht im Mgmt. Interface ein entsprechender Punkt zur Verfügung der aktiviert werden kann. Um die Funktion auf Kommandozeile zu aktivieren führe folgendes aus:
| |
|
| |
| # config system interface
| |
| # edit [Name des entsprechenden Devices zB "internal"]
| |
| # set device-identification enable
| |
| # end
| |
|
| |
| Danach steht die MAC Adresse in der Spalte "Source Mac" Adresse im Log sei es auf der FortiGate und/oder FortiAnalyzer zur Verfügung.
| |
|
| |
| == UTM Proxy Options / Protocol Options ==
| |
|
| |
| === Wie konfiguriere ich die UTM Proxy/Protocol Options manuell über Kommandozeile? ===
| |
|
| |
| Bei kleineren Devices steht die Menüposition für die UTM Proxy/Protocol Options nicht mehr über Gui zur Verfügung. Diese müssen für diese Devices zB 40C über Kommandozeile konfiguriert werden. Dies wird folgendermassen durchgeführt:
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Unter FortiOS 5.2 existiert die Positione "extended-utm-log" nicht mehr!
| |
| Um "streaming" von UTM auszuschliessen existiert unter FortiOS 5.2 folgende
| |
| option die jedoch für FortiOS 5.0 nicht exisitert:
| |
|
| |
| streaming-content-bypass
| |
|
| |
| Wenn "streaming" von UTM ausgeschlossen werden soll muss unter FortiOS 5.0
| |
| explizit eine "Content-Header" Konfiguration durchgeführt werden. Weitere
| |
| Informationen findet man unter folgenden Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_kann_ich_innerhalb_eines_WebFilters_einen_bestimmten_.22MIME.22_Type_.28zB_Audio.29_blockieren_.28Content-Header.29.3F]]
| |
|
| |
| Desweiteren wurde unter FortiOS 5.2 das Protokoll "im" komplett entfernt und
| |
| steht für eine Konfiguration nicht mehr zur Verfügung.
| |
|
| |
| '''FortiOS 5.0'''
| |
| # config firewall profile-protocol-options
| |
| # edit [Wähle das entsprechende Profile]
| |
| # get
| |
| name : default
| |
| comment : all default services
| |
| replacemsg-group :
| |
| oversize-log : disable
| |
| switching-protocols-log : disable
| |
| extended-utm-log : disable
| |
| http:
| |
| ports : 80
| |
| status : enable
| |
| inspect-all : disable
| |
| options : no-content-summary
| |
| comfort-interval : 10
| |
| comfort-amount : 1
| |
| post-lang :
| |
| fortinet-bar : disable
| |
| streaming-content-bypass : enable
| |
| switching-protocols : bypass
| |
| oversize-limit : 10
| |
| retry-count : 0
| |
| ftp:
| |
| ports : 21
| |
| status : enable
| |
| inspect-all : disable
| |
| options : no-content-summary splice
| |
| comfort-interval : 10
| |
| comfort-amount : 1
| |
| oversize-limit : 10
| |
| imap:
| |
| ports : 143
| |
| status : enable
| |
| inspect-all : disable
| |
| options : fragmail no-content-summary
| |
| oversize-limit : 10
| |
| mapi:
| |
| ports : 135
| |
| status : enable
| |
| options : fragmail no-content-summary
| |
| oversize-limit : 10
| |
| pop3:
| |
| ports : 110
| |
| status : enable
| |
| inspect-all : disable
| |
| options : fragmail no-content-summary
| |
| oversize-limit : 10
| |
| smtp:
| |
| ports : 25
| |
| status : enable
| |
| inspect-all : disable
| |
| options : fragmail no-content-summary splice
| |
| oversize-limit : 10
| |
| server-busy : disable
| |
| nntp:
| |
| ports : 119
| |
| status : enable
| |
| inspect-all : disable
| |
| options : no-content-summary splice
| |
| oversize-limit : 10
| |
| im:
| |
| status : enable
| |
| options :
| |
| oversize-limit : 10
| |
| dns:
| |
| ports : 53
| |
| status : enable
| |
| mail-signature:
| |
| status : disable
| |
| signature :
| |
|
| |
| '''FortiOS 5.2'''
| |
| # config firewall profile-protocol-options
| |
| # edit [Wähle das entsprechende Profile]
| |
| # get
| |
| name : default
| |
| comment : all default services
| |
| replacemsg-group :
| |
| oversize-log : disable
| |
| switching-protocols-log: disable
| |
| http:
| |
| ports : 80
| |
| status : enable
| |
| inspect-all : disable
| |
| options : no-content-summary
| |
| comfort-interval : 10
| |
| comfort-amount : 1
| |
| post-lang :
| |
| fortinet-bar : disable
| |
| streaming-content-bypass: enable
| |
| switching-protocols : bypass
| |
| oversize-limit : 10
| |
| uncompressed-oversize-limit: 10
| |
| uncompressed-nest-limit: 12
| |
| scan-bzip2 : disable
| |
| block-page-status-code: 200
| |
| retry-count : 0
| |
| ftp:
| |
| ports : 21
| |
| status : enable
| |
| inspect-all : disable
| |
| options : no-content-summary splice
| |
| comfort-interval : 10
| |
| comfort-amount : 1
| |
| oversize-limit : 10
| |
| uncompressed-oversize-limit: 10
| |
| uncompressed-nest-limit: 12
| |
| scan-bzip2 : disable
| |
| imap:
| |
| ports : 143
| |
| status : enable
| |
| inspect-all : disable
| |
| options : fragmail no-content-summary
| |
| oversize-limit : 10
| |
| uncompressed-oversize-limit: 10
| |
| uncompressed-nest-limit: 12
| |
| scan-bzip2 : disable
| |
| mapi:
| |
| ports : 135
| |
| status : enable
| |
| options : fragmail no-content-summary
| |
| oversize-limit : 10
| |
| uncompressed-oversize-limit: 10
| |
| uncompressed-nest-limit: 12
| |
| scan-bzip2 : enable
| |
| pop3:
| |
| ports : 110
| |
| status : enable
| |
| inspect-all : disable
| |
| options : fragmail no-content-summary
| |
| oversize-limit : 10
| |
| uncompressed-oversize-limit: 10
| |
| uncompressed-nest-limit: 12
| |
| scan-bzip2 : disable
| |
| smtp:
| |
| ports : 25
| |
| status : enable
| |
| inspect-all : disable
| |
| options : fragmail no-content-summary splice
| |
| oversize-limit : 10
| |
| uncompressed-oversize-limit: 10
| |
| uncompressed-nest-limit: 12
| |
| scan-bzip2 : disable
| |
| server-busy : disable
| |
| nntp:
| |
| ports : 119
| |
| status : enable
| |
| inspect-all : disable
| |
| options : no-content-summary splice
| |
| oversize-limit : 10
| |
| uncompressed-oversize-limit: 10
| |
| uncompressed-nest-limit: 12
| |
| scan-bzip2 : disable
| |
| dns:
| |
| ports : 53
| |
| status : enable
| |
| mail-signature:
| |
| status : disable
| |
| signature :
| |
|
| |
| Nun kann das entsprechende UTM Proxy/Protocol Options in die entsprechende Firewall Policy Rule implementiert werden:
| |
|
| |
| # config firewall policy
| |
| # edit [Wähle die entsprechende Policy ID]
| |
| # set utm-status enable
| |
| # set profile-protocol-options [Wähle das entsprechende Proxy/Protocol Option Profil]
| |
| # end
| |
|
| |
| === Wie konfiguriere ich die UTM SSL Proxy/Protocol Options manuell über Kommandozeile? ===
| |
|
| |
| Bei kleineren Devices steht die Menüposition für die UTM Proxy/Protocol Options nicht mehr über Gui zur Verfügung. Diese müssen für diese Devices zB 40C über Kommandozeile konfiguriert werden. Die SSL Proxy/Protocol Options werden benutzt in folgenden Situationen:
| |
|
| |
| • SSL Deep Inspection (Client Zertifikat muss auf dem Client/Workstation installiert werden)
| |
| • URL Scan only (Es wird kein Client Zertifikat auf dem Client/Workstation benötigt jedoch "WebFilter Only")
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Betreffend "URL Scan only" Konfiguration siehe nachfolgende Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_funktioniert_der_HTTPS_scan_innerhalb_des_WebFilter_wenn_.22Deep_Inspection.22_nicht_aktiviert_ist_.28Scan_Encrypted_Connections_.2F_HTTPS_URL_Scan_Only.29.3F]]
| |
| [[FortiGate-5.0-5.2:FAQ#Wann_muss_ich_die_UTM_SSL_Proxy.2FProtocol_Options_in_der_Firewall_Rule_aktivierten_und_definieren.3F]]
| |
|
| |
| Die Konfiguration der SSL Proxy/Protocol Options auf der Kommandozeile erfolgt folgendermassen:
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Unter FortiOS 5.2 wurde die "Deep Inspection Engine" für eine bessere Performance
| |
| modifiziert. Ebenfalls wurde der Name in der Kommandozeile umbenannt und ist neu zu finden
| |
| unter:
| |
|
| |
| # config firewall ssl-ssh-profile
| |
|
| |
| Folgende Option wurde unter FortiOS 5.2 entfernt:
| |
|
| |
| extended-utm-log
| |
|
| |
| Folgende Option ist unter FortiOS 5.2 dazugekommen:
| |
|
| |
| # config ssl-exempt
| |
|
| |
| # config ssl
| |
| # set inspect-all [disable | certification-inspection | deep-inspection]
| |
| # end
| |
|
| |
| # config [https | ftps | impas | pop3s | smtps]
| |
| # set status [disable | certification-inspection | deep-inspection]
| |
| # end
| |
|
| |
| Somit kann durch "certification-inspection" über alles (inspect-all) oder
| |
| in den einzelnen Protokollen (zB https) gesettzt werden!
| |
|
| |
| # config firewall deep-inspection-options
| |
| # edit [Wähle das entsprechende Profile]
| |
| # get
| |
| name : default
| |
| comment : all default services
| |
| ssl:
| |
| inspect-all : disable
| |
| allow-invalid-server-cert: disable
| |
| ssl-ca-list : disable
| |
| https:
| |
| ports : 443
| |
| status : enable
| |
| client-cert-request : bypass
| |
| unsupported-ssl : bypass
| |
| allow-invalid-server-cert: disable
| |
| ssl-ca-list : disable
| |
| ftps:
| |
| ports : 990
| |
| status : enable
| |
| client-cert-request : bypass
| |
| unsupported-ssl : bypass
| |
| allow-invalid-server-cert: disable
| |
| ssl-ca-list : disable
| |
| imaps:
| |
| ports : 993
| |
| status : enable
| |
| client-cert-request : inspect
| |
| unsupported-ssl : bypass
| |
| allow-invalid-server-cert: disable
| |
| ssl-ca-list : disable
| |
| pop3s:
| |
| ports : 995
| |
| status : enable
| |
| client-cert-request : inspect
| |
| unsupported-ssl : bypass
| |
| allow-invalid-server-cert: disable
| |
| ssl-ca-list : disable
| |
| smtps:
| |
| ports : 465
| |
| status : enable
| |
| client-cert-request : inspect
| |
| unsupported-ssl : bypass
| |
| allow-invalid-server-cert: disable
| |
| ssl-ca-list : disable
| |
| caname : Fortinet_CA_SSLProxy
| |
| certname : Fortinet_SSLProxy
| |
| ssl-server:
| |
| extended-utm-log : disable
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Zusätzlich steht in den SSL/SSH Protocol Options wie schon erwähnt "config ssl-exempt" zur Verfügung.
| |
| Dies bedeutet: Soll innerhalb der "Deep Inspection" Konfiguration eine Seite von der "Deep Inspection"
| |
| Funktion ausgenommen werden kann diese Seite unter "config ssl-exempt" konfiguriert werden:
| |
|
| |
| # config firewall ssl-ssh-profile
| |
| # edit [Wähle das entsprechende Profile]
| |
| # config ssl-exempt
| |
| # edit [Wähle einen Integer zB 1]
| |
| # set type [fortiguard-category | address | address6]
| |
| # set fortiguard-category [sofern set type fortiguard-category]
| |
| # set address [sofern set type address]
| |
| # set address6 [sofern set type address6]
| |
| # end
| |
|
| |
| Fortinet hat ein Dokument Released der diese neue Funktion umschreibt und erklärt wieso diese implementiert
| |
| wurde:
| |
|
| |
| [[Datei:Preventing-security-certificate-warnings-52.pdf]]
| |
|
| |
| Nun kann das entsprechende UTM SSL Proxy/Protocol Options in die entsprechende Firewall Policy Rule implementiert werden:
| |
|
| |
| # config firewall policy
| |
| # edit [Wähle die entsprechende Policy ID]
| |
| # set utm-status enable
| |
| # set deep-inspection-options [Wähle das entsprechende SSL Proxy/Protocol Option Profil]
| |
| # end
| |
|
| |
| === Wann muss ich die UTM SSL Proxy/Protocol Options in der Firewall Rule aktivierten und definieren? ===
| |
|
| |
| Wenn ein UTM SSL Proxy/Protocol Option Profile konfiguriert wird so fragt sich wann diese in einer Firewall Rule zusammen mit einem UTM Feature konfiguriert werden muss. Diese Frage ist FortiOS 5.0 resp. 5.2 abhängig da unter FortiOS 5.2 die "Deep Inspection Options" modifiziert wurden. Nachfolgend eine Uebersicht:
| |
|
| |
| '''FortiOS 5.0'''
| |
| Die SSL Proxy/Protocol Options werden dann definiert wenn:
| |
|
| |
| • SSL Deep Inspection (Client Zertifikat muss auf dem Client/Workstation installiert werden)
| |
| • URL Scan only (Es wird kein Client Zertifikat auf dem Client/Workstation benötigt jedoch "WebFilter Only")
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Betreffend "URL Scan only" Konfiguration siehe nachfolgenden Artikle:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_funktioniert_der_HTTPS_scan_innerhalb_des_WebFilter_wenn_.22Deep_Inspection.22_nicht_aktiviert_ist_.28Scan_Encrypted_Connections_.2F_HTTPS_URL_Scan_Only.29.3F]]
| |
|
| |
| '''FortiOS 5.2'''
| |
| Die SSL Proxy/Protocol Options werden "automatisch" definiert wenn:
| |
|
| |
| • Ein Security Profile selektiert wird!
| |
|
| |
| Die SSL Proxy/Protocol Options müssen "manuell" definiert werden wenn:
| |
|
| |
| • "SSL Deep Inspection" benötigt wird
| |
|
| |
| Grundsätzlich unterscheidet sich FortiOS 5.0 und/oder FortiOS 5.2 in den SSL Proxy/Protocol Options folgendermassen:
| |
|
| |
| '''FortiOS 5.0'''
| |
| • SSL Proxy/Protocol Options Profile, All UTM Features (https-url-scan disabled)
| |
| • HTPPS URL Scan Only, WebFilter Only (https-url-scan enabled)
| |
|
| |
| '''FortiOS 5.2'''
| |
| • Certificate Inspection ("certificate-inspection" Option in der CLI), Untersucht nur den SSL Handshake
| |
| • Deep Inspection ("deep-inspection" Option in der CLI), Aktiviert Full Deep Inspection für SSL Traffic
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Diese Konfiguration kann für jedes Protokoll zB https, ftps seperate durchgeführt werden zB:
| |
|
| |
| # config firewall ssl-ssh-profile
| |
| # edit [Gebe einen Namen ein für das Profile]
| |
| # config https
| |
| # set status [disable | certificate-inspection | deep-inspection]
| |
| # end
| |
| # config ftps
| |
| # set status [disable | certificate-inspection | deep-inspection]
| |
| # end
| |
|
| |
| Für FortiOS 5.2 existiert eine "vordefiniertes" Profile mit dem Namen "certificate-inspection".
| |
| Dieses Profile ist basierend auf der Funktion "certificate-inspection" und wird als Default
| |
| Profile benutzt im Hintergrund wenn ein UTM Feature benutzt wird. Dies ist auch der Grund
| |
| wieso ein SSL Proxy/Protocol Option Profile nur dann in einer Firewall Rule zusammen mit einem
| |
| UTM Feature definiert werden muss, wenn "Deep Inspection" benützt wird. Die neue Funktion
| |
| "certificate-inspection" ersetzt die unter FortiOS 5.0 Option "https-url-scan"!
| |
|
| |
| === Wie aktiviere ich für die SSL Proxy Options auf einer FortiGate das Extended-UTM-Log? ===
| |
|
| |
| Für die sogenannten "deep-inspection-options" kann auf einer FortiGate das "Extended-UTM-Log" aktiviert werden. Die Konfiguration wird folgendermassen durchgeführt:
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Unter FortiOS 5.2 gibt es diese Option "extended-utm-log" nicht mehr. Ebenfalls
| |
| wurden die "deep-inspection-options" modifiziert. Weitere Informationen betreffend
| |
| diesen Neuerungen FortiOS 5.2 findet man im nachfolgenden Artikeln:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_aktiviere_ich_auf_einer_FortiGate_das_.22Extended-UTM-Log.22.3F]]
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_konfiguriere_ich_die_UTM_SSL_Proxy.2FProtocol_Options_manuell_.C3.BCber_Kommandozeile.3F]]
| |
|
| |
| # config firewall deep-inspection-options
| |
| # edit [Name des Profile]
| |
| # set extended-utm-log [enable | disable]
| |
| # set ssl-invalid-server-cert-log [enable | disable]
| |
| # set allow-invalid-server-cert [enable | disable]
| |
| # end
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Die Option "allow-invalid-server-cert" steht im Zusammenhang mit "extended-utm-log". Dies bedeutet
| |
| wird "allow-invalid-server-cert" aktiviert muss "extended-utm-log" auf enabled stehen! Dies gilt nur für
| |
| FortiOS 5.0 und nicht für FortiOS 5.2 da diese Option unter FortiOS 5.2 nicht existiert.
| |
|
| |
| === Wird unter FortiOS 5.0/5.2 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! Für SSL Offloading und andere Proxy Features wird jedoch TLS 1.2 nicht unterstützt. Ab FortiOS 5.2.8 wird TLS 1.2 in folgender Funktion unterstützt:
| |
|
| |
| • SSL offload (LoadBalancer VIP)
| |
|
| |
| Ab FortiOS 5.4 wird TLS 1.2 in folgenden Funktionen 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
| |
|
| |
| == DLP ==
| |
|
| |
| === Wie schalte ich für einen DLP Sensor auf einer FortiGate das Extended-UTM-Log ein? ===
| |
|
| |
| Im normal Fall werden "DLP Events" im regulären Log geloggt (Traffic Log). Nun möchte man die Event's seperiert in einem Log loggen, kann dies durch das sogenannte Extended-UTM-Log (Nur für FortiOS 5.0) erreicht werden. Um dieses Extended-UTM-Log zu aktivieren führe folgendes durch:
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Das Kommando "extended-utm-log" steht für FortiOS 5.2 nicht mehr zur Verfügung.
| |
| Weitere Informationen siehe nachfolgenden Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_aktiviere_ich_auf_einer_FortiGate_das_.22Extended-UTM-Log.22.3F]]
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_sieht.2Ff.C3.BChre_ich_eine_vollst.C3.A4ndige_Log_Konfiguration_auf_einer_FortiGate_aus.3F]]
| |
|
| |
| # config dlp sensor
| |
| # edit [Gebe das entsprechende Profile an]
| |
| # set extended-utm-log [enable | disable]
| |
| # set dlp-log [enable | disable]
| |
| # set nac-quar-log [enable | disable]
| |
| # end
| |
|
| |
| Sobald diese "Extended-UTM-Log's" wieder zur Verfügung stehen, kann das "UTM Monitoring" wiederum aktiviert werden. Weitere Informationen siehe nachfolgenden Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_aktiviere_ich_auf_einer_FortiGate_die_.22UTM_Monitor.22_Funktion.3F]]
| |
|
| |
| === Kann die DLP Funktion im Zusammenhang mit verschlüsselten Verbindungen benutzt werden? ===
| |
|
| |
| Ja dies ist möglich, sprich in Verbindung mit der DLP Funktion kann "Deep Inspection" benutzt werden mit folgenden Services:
| |
|
| |
| HTTPS
| |
| FTPS
| |
|
| |
| SMTPS
| |
| POP3S
| |
| IMAPS
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Wenn man einen neuens Filter erstellt in der DLP (Data Leak Prevention) Funktion so kann man
| |
| die entsprechenden Protokolle anwählen jedoch stehen nur die unverschlüsselten Protokolle zur
| |
| Wahl wie zB SMTP. Wenn zB SMTP angewählt ist und es wird "Deep Inspection" im Zusammenhang mit
| |
| DLP benutzt (anhand des SSL Proxy/Protocol Options) so wird automatisch SMTPS benutzt. Das
| |
| Beispiel für SMTP/SMTPS gilt auch für die anderen Protokoll wie oben aufgeführt. Wie/Wann eine
| |
| "Deep Inspection" konfiguriert wird siehe nachfolgenden Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wann_muss_ich_die_UTM_SSL_Proxy.2FProtocol_Options_in_der_Firewall_Rule_aktivierten_und_definieren.3F]]
| |
|
| |
| === Wie kann ich verhindern das eine bestimmte Grösse von Files übermittelt werden? ===
| |
|
| |
| Wenn man verhindern will, dass eine bestimmte Grösse von Files runtergeladen/raufgeladen wird zB will man alles verhindern das grösser ist als 20 MB (20480) so muss diese Konfiguration über einen "DLP Sensor" (Data Leak Prevention) durchgeführt werden. Innerhalb eines existierenden "DLP Sensor" wählt man folgendes:
| |
|
| |
| '''FortiOS 5.0 / 5.2'''
| |
|
| |
| [[Datei:Fortinet-1118.jpg]]
| |
|
| |
| [[Datei:Fortinet-1119.jpg]]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Die Positon "File Size >=" ist zu verstehen als "Grösser und/oder Gleich"!
| |
|
| |
| Gebe im Filter die entsprechenden Protokolle an wie "HTTP-POST" (Upload) und/oder "HTTP-GET" (Download) etc. Wenn die Protokolle im Zusammenhang mit "Deep Inspection" benutzt werden sollten folgende Artikel berücksichtigt werden:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Kann_die_DLP_Funktion_im_Zusammenhang_mit_verschl.C3.BCsselten_Verbindungen_benutzt_werden.3F]]
| |
| [[FortiGate-5.0-5.2:FAQ#Wann_muss_ich_die_UTM_SSL_Proxy.2FProtocol_Options_in_der_Firewall_Rule_aktivierten_und_definieren.3F]]
| |
|
| |
| === Wie erstelle ich ein autom. Fingerprinting und benutze dieses in einem DLP Profile? ===
| |
|
| |
| Ein DLP Fingerprinting wird benutzt um Dokumente durch einen Hash zu schützen. Dies bedeutet: Anhand eines autom. Suchvorganges -und/oder manuellen Uploads- wird einem bestimmten Dokument zB einem Word Dokument ein Hash zugewiesen. Anhand dieses Hash's und des zuständingen DLP Profiles in einer Policy, wird das Dokument wieder erkannt und verhindert, dass dieses übermittelt wird. Um ein Hash automatisch auf einem Fileshare zu erzeugen konfiguriere folgendes:
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Unter FortiOS 5.2 steht das Fingerprinting für Devices 100D und kleiner nur noch den
| |
| Devices 60C/D sowie 90D zur Verfügung. Auskunft darüber gibt die Software Matrix:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Welche_Ger.C3.A4te.2FDevices_werden_vom_neuen_FortiOS_5_unterst.C3.BCtzt_und_welche_neuen_Features_umfasst_FortiOS_5.3F]]
| |
|
| |
| UTM Security Profiles > Data Leak Prevention > Document Fingerprinting
| |
|
| |
| - Danach wähle unter Document Sources > Create New
| |
|
| |
| [[Datei:Fortinet-637.jpg]]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> In diesem Beispiel wird ein Windows Share konfiguriert. In diesem Share soll nach einem Mountpoint
| |
| "export" gesucht werden und darin nach Files "*.txt". Werden diese gefunden sollen diese mit einem
| |
| Sensitive Level "Private" (Hash) versehen werden. Der Scan kann auch per Schedule regelmässig aus-
| |
| geführt werden. Unter Advanced sind einige zusätzliche Einstellungen möglich die je nach Bedarf
| |
| aktiviert oder deaktivert werden können! Unter FortiOS 5.2 gibt es die "seperate" Menüpositon zur
| |
| Konfiguration des Fingerprintings nicht mehr und muss über CLI durchgeführt werden:
| |
|
| |
| # config dlp doc-source
| |
| # set name [Gebe einen entsprechenden Namen ein für die Doc Source]
| |
| # set server-type [samba]
| |
| # set server [IPv4 Adresse des Servers]
| |
| # set period [none | daily | weekly | monthly]
| |
| # set vdom [mgmt | current]
| |
| # set scan-subdirectories [enable | disable]
| |
| # set remove-deleted [enable | disable]
| |
| # set keep-modified [enable | disable]
| |
| # set username [Gebe den entsprechenden Usernamen an]
| |
| # set password [Gebe das entsprechende Passwort an]
| |
| # set file-path [Setze den entsprechenden File Path]
| |
| # set file-pattern [Setze einen entsprechenden File Pattern]
| |
| # set sensitivity [Critical | Private | Warning]
| |
| # end
| |
|
| |
| Damit den Hash zu speichern muss eine Datenbank zur Verfügung gestellt werden
| |
| sowie ein Storage Device:
| |
|
| |
| # config dlp settings
| |
| # set storage-device [Der zur Verfügung stehende Device zB Internal]
| |
| # set size [Grösse in MB der Datenbank; Standard 16]
| |
| # set db-mode [remove-modified-then-oldest | remove-oldest | stop-adding]
| |
| # set cache-mem-percent [Zur Verfügung stehenden Cache von Memory 1-15; Standard 2]
| |
| # set chunk-size [Setze den Chunksize; Standard 2800]
| |
| # end
| |
|
| |
| Nachdem das Fingerprinting durchgeführt wurde kann dieses in einem DLP Profil hinzugefügt werden! Erstelle ein neues DLP Profile und füge den Fingerprint hinzu:
| |
|
| |
| UTM Security Profiles > Data Leak Prevention > Sensor > Create New
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Unter FortiOS 5.2 gibt es die seperate Menüposition "Sensor" nicht mehr sondern
| |
| die Menüposition "Data Leak Prevention" stellt die "Sensor" Position direkt dar!
| |
|
| |
| [[Datei:Fortinet-638.jpg]]
| |
|
| |
| - Vergebe einen Namen für das DLP Profile und wähle danach "Create New":
| |
|
| |
| [[Datei:Fortinet-639.jpg]]
| |
|
| |
| [[Datei:Fortinet-640.jpg]]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Achte auf die verschiedenen Einstellungen dh. wie zB "Action" Block sowie die zu
| |
| ueberwachenden Services (Wähle nur diese die Zweckmässig und Angebracht sind)!
| |
|
| |
| Das DLP Profile ist nun konfiguriert und kann in einer entsprechenden Policy benutzt werden:
| |
|
| |
| Policy > Policy > Create New
| |
|
| |
| [[Datei:Fortinet-641.jpg]]
| |
|
| |
| Wenn nun versucht wird ein dementsprechendes File des Shares in der konfigurierten Policy zu übermitteln, wird dieses je nach konfigurierter "Action" behandelt dh. in unserem Fall "Block". Diese "Action" ist ersichtlich -sofern das Log im DLP Profile akiviert ist- unter:
| |
|
| |
| Log & Report > UTM Security Log > Data Leak Prevention
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Diese Art des DLP ist sehr Performance Intensiv und sollte nur dann genutzt werden wenn der
| |
| Device auch dementsprechende über genügend Performance verfügt! Betreffend Log Konfiguration
| |
| im Zusammenhang mit DLP siehe nachfolgenden Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_schalte_ich_f.C3.BCr_einen_DLP_Sensor_auf_einer_FortiGate_das_Extended-UTM-Log_ein.3F]]
| |
|
| |
| === Wie kann ich verhindern das bestimmte Files wie zB .exe runtergeladen werden? ===
| |
|
| |
| Wenn man verhindern möchte, dass bestimmte Files zB über einen "Explicit Proxy" runtergeladen werden können so muss diese Konfiguration über DLP anhand eines entsprechenden Filters/Profiles durchgeführt werden. Die gleiche Konfiguration kann benutzt werden um das runterladen der bestimmten Files über einen "Transparent Proxy" zu verhindern. Als Erstes muss ein entsprechender "File Filter" erstellt werden:
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Diese Konfiguration ist unter FortiOS 5.2 nicht mehr nötig resp. die Menüposition
| |
| "File Filter" steht nicht mehr zur Verfügung. Die entsprechende Konfiguration unter
| |
| FortiOS 5.2 kann direkt innerhalb des Sensor's/Profile durchgeführt werden! Weitere
| |
| Details entnehme aus dem nachfolgenden Abschnitt für FortiOS 5.2!
| |
|
| |
| '''FortiOS 5.0'''
| |
|
| |
| UTM Profiles > Data Leak Prevention > File Filter
| |
|
| |
| [[Datei:Fortinet-264.jpg]]
| |
|
| |
| [[Datei:Fortinet-265.jpg]]
| |
|
| |
| [[Datei:Fortinet-266.jpg]]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Es kann zwischen "File Name Pattern" und "File Type" gewählt werden! Der Unterschied liegt darin, dass der "File Name Pattern"
| |
| ausschliesslich "Namens" basierend ist dh. es wird im Header des Files nicht nachgeschaut ob es sich wirklich zB um ein .exe
| |
| handelt sondern wie erwähnt nur die angegebene Extension "Namens" basierend angeschaut. Somit wenn ein "File Name Pattern" *.exe
| |
| konfiguriert ist und man würde einem User so ein File auf dem Internet für das Runterladen bereitstellen, müsste man dieses damit es
| |
| runtergeladen werden kann einfach vorgehend umbenennen um das Runterladen zu ermöglichen. Möchte man dies verhindert so muss ein
| |
| "File Type" konfiguriert werden dh. in diesem Filter wird verifiziert -im Application Header des Files- um was es sich hier
| |
| für ein File handelt. Somit bringt das umbenennen des Files vor dem Runterladen nichts, denn auch durch das Umbenennen bleibt
| |
| der "Application Header" des Files bestehen und wird somit auch als bestimmter "File Type" erkannt.
| |
|
| |
| [[Datei:Fortinet-267.jpg]]
| |
|
| |
| [[Datei:Fortinet-268.jpg]]
| |
|
| |
| [[Datei:Fortinet-269.jpg]]
| |
|
| |
| Nun erstellen wir einen DLP Sensor und fügen unser File Pattern Filter diesem DLP Sensor hinzu:
| |
|
| |
| UTM Profiles > Data Leak Prevention > Sensor
| |
|
| |
| [[Datei:Fortinet-270.jpg]]
| |
|
| |
| [[Datei:Fortinet-271.jpg]]
| |
|
| |
| [[Datei:Fortinet-272.jpg]]
| |
|
| |
| [[Datei:Fortinet-273.jpg]]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Unter FortiOS 5.0 wurde die Menüführung verändert dh. wenn man auf "Create New" geht steht einem ein Filter Menü zur Verfügung indem vers.
| |
| Varianten konfiguriert werden können. Ausgehend von dieser hier gezeigten Konfiguration kann der "File Filter" der vorgehend Konfiguriert
| |
| wurde über die Menüpositionen "Files > File Type included in" ausgewählt werden. Welche Protokolle für den Filter kontrolliert werden sollen
| |
| kann über die Position "Examine the following Services" gewählt werden. Unter FortiOS 5.0 wird die Definition der Services zB HTTP über
| |
| folgende Konfiguration gesteuert "UTM Proxy Options"!
| |
|
| |
| [[Datei:Fortinet-274.jpg]]
| |
|
| |
| '''FortiOS 5.2'''
| |
|
| |
| Security Profiles > Data Leak Prevention > Create New
| |
|
| |
| [[Datei:Fortinet-1115.jpg]]
| |
|
| |
| [[Datei:Fortinet-1116.jpg]]
| |
|
| |
| Unter FortiOS 5.2 muss nicht zuerst ein "File Filter" erstellt werden sondern die Konfiguration des "File Types"
| |
| sowie des "File Name Patterns" kann Analog FortiOS 5.0 direkt im Profile eingegeben/konfiguriert werden:
| |
|
| |
| [[Datei:Fortinet-1117.jpg]]
| |
|
| |
| [[Datei:Fortinet-264.jpg]]
| |
|
| |
| Nun muss nur noch den erstellten DLP Sensor zur entsprechenden Policy für den "Explicit Proxy" (Wenn kein "Explicit Proxy" benutzt wird einfach die entsprechende Policy wählen) hinzugefügt werden:
| |
|
| |
| Policy > Policy > Policy
| |
|
| |
| [[Datei:Fortinet-275.jpg]]
| |
|
| |
| === Wie kann ich den Prozess des Fingerprintings neu starten? ===
| |
|
| |
| Folgender Befehl kann benützt werden auf der CLI um DLP "fingerprinting" Deamon neu zu starten:
| |
|
| |
| # diagnose test app dlpfingerprint 99
| |
|
| |
| == IPS (Intrusion Prevention System) ==
| |
|
| |
| === Was ist der Unterschied zwischen "regular" und "extended" IPS Database? ===
| |
|
| |
| Ab FortiOS 5 stehen zwei Datenbanken zur Verfügung dh. eine Reguläre und eine Erweiterte! Die Erweiterte Datenbank steht folgenden Geräten zur Verfügung:
| |
|
| |
| FWF-81CM, 110C und höher
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Ab FortiOS 5 110C oder höher. Der entsprechende Konfigurationspunkt um die "extended" Database
| |
| zu aktivieren befindet sich innerhalb "System > Config > FortiGuard"!
| |
|
| |
| Die erweiterte Datenbank ist folgende Modelle nicht konfigurierbar dh. nur die Reguläre steht zur Verfügung:
| |
|
| |
| 20C bis 60C und alle andere 8x Modelle
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Neu steht die "extended" Database ab FortiOS 5.0.6 für die "D" Desktop Modelle zur Verfügung
| |
| sowie wird für folgende Modelle ab FortiOS 5.2.4 per Standard aktiviert:
| |
|
| |
| 300D/500D/1000D/1200D/1500D/3700D/3700DX/3810D/5001D
| |
|
| |
| Der Unterschied dieser zwei Datenbanken für IPS Signaturen liegt in der Grösse dh. regulär ca. 5700 IPS Signaturen und die erweiterte ca. 7700 IPS Signaturen. Folgendes Kommando kann benutzt werden um die Reguläre oder die Erweiterte Datenbank zu defnieren/aktivieren:
| |
|
| |
| # config ips global
| |
| # set database [extended / regular]
| |
| # end
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Wenn die Database auf "extended" konfiguriert wird sollte event. die Acceleration
| |
| überprüft werden dh. dazu siehe folgender Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Kann_ich_IPS_Funktion_auf_einer_FortiGate_.C3.BCber_Hardware_beschleunigen.3F]]
| |
|
| |
| === Wie kann ich auf einer FortiGate die Packet Statistike für IPS anzeigen/auflisten? ===
| |
|
| |
| Wenn man auf einer FortiGate IPS im Einsatz hat und die Statistik der Packet anzeigen/auflisten möchtek kann nachfolgender Befehl benutzt werden um dies durchzuführen:
| |
|
| |
| # diagnose ips packet status
| |
|
| |
| PACKET STATISTICS:
| |
| total packets 60347021
| |
| tcp packets 48904151
| |
| udp packets 10835395
| |
| icmp packets 607475
| |
| other packets 16256
| |
|
| |
| PACKET ACTION STATISTICS:
| |
| PASS 3351862 0
| |
| DROP 87 0
| |
| RESET 0 0
| |
| RESET_CLIENT 0 0
| |
| RESET_SERVER 0 0
| |
| DROP_SESSION 66 0
| |
| PASS_SESSION 3585 0
| |
| CLEAR_SESSION 0 0
| |
| EXEMPT 0 0
| |
|
| |
| Weitere Optionen resp. Daten für die IPS Engine/Monitor können über folgenden Befehl abgerufen werden:
| |
|
| |
| # diagnose test application ipsmonitor
| |
|
| |
| IPS Engine Test Usage:
| |
|
| |
| 1: Display IPS engine information
| |
| 2: Toggle IPS engine enable/disable status
| |
| 3: Display restart log
| |
| 4: Clear restart log
| |
| 5: Toggle bypass status
| |
| 6: Submit attack characteristics now
| |
| 10: IPS queue length
| |
| 11: Clear IPS queue length
| |
| 12: IPS L7 socket statistics
| |
| 13: IPS session list
| |
| 14: IPS NTurbo statistics
| |
| 15: IPSA statistics
| |
| 16: Display device identification cache
| |
| 17: Clear device identification cache
| |
| 96: Toggle IPS engines watchdog timer
| |
| 97: Start all IPS engines
| |
| 98: Stop all IPS engines
| |
| 99: Restart all IPS engines and monitor
| |
|
| |
| === Wie kann ich auf einer FortiGate den IPS Prozess/Service stoppen, neu starten oder einen "bypass" aktivieren? ===
| |
|
| |
| Der IPS Service resp. die Funktion von IPS ist die Resourcenintensivste Funktion auf einer FortiGate. Speziell dann wenn diese Funktion nicht korrekt eingesetzt resp. konfiguriert wird. Wenn es mit dem IPS Service resp. Funktion zu Problemen kommt sollte der IPS Service/Prozess nicht regulär anhand "diagnose sys kill" neu gestartet werden. Wenn der IPS Prozess/Service eine sehr hohe Auslastung zeigt und vermutet wird das der Prozess/Service zB hängen geblieben ist kann versucht werden kurzfristig den "bypass" zu aktivieren dh. kurzfristig die "IPS inspection" zu deaktivieren. Dies kann ebenfalls benutzt werden, wenn durch die hohe Auslastung durch den IPS Prozess/Service, die verursacht wurde durch eine nicht korrekte IPS Konfiguration, eine weitere Konfiguration zur Fehlerkorrektur nicht möglich ist. Dies kann anhand folgendes Befehls durchgeführt werden:
| |
|
| |
| # diagnose test application ipsmonitor 5
| |
| bypass: enable
| |
|
| |
| Durch diesen Befehl wird die IPS Engine angewiesen keine "IPS inspection" mehr durchzuführen dh. der Prozess/Service der IPS Engine wird dadurch nicht gestoppt sondern die "IPS inspection" deaktiviert. Um den "bypass" zu deaktivieren geben wiederum folgender Befehl ein:
| |
|
| |
| # diagnose test application ipsmonitor 5
| |
| bypass: disable
| |
|
| |
| Wenn dennoch aus irgendwelchen Gründen der IPS Service/Prozess neu gestartet werden soll kann folgender Befehl benutzt werden:
| |
|
| |
| # diagnose test application ipsmonitor 99
| |
| restarting ipsmonitor
| |
|
| |
| Desweiteren steht für diesen Befehl "diagnose test application ipsmonitor" weitere Optionen zur Verfügung:
| |
|
| |
| # diagnose test application ipsmonitor
| |
|
| |
| IPS Engine Test Usage:
| |
|
| |
| 1: Display IPS engine information
| |
| 2: Toggle IPS engine enable/disable status
| |
| 3: Display restart log
| |
| 4: Clear restart log
| |
| 5: Toggle bypass status
| |
| 6: Submit attack characteristics now
| |
| 10: IPS queue length
| |
| 11: Clear IPS queue length
| |
| 12: IPS L7 socket statistics
| |
| 13: IPS session list
| |
| 14: IPS NTurbo statistics
| |
| 15: IPSA statistics
| |
| 16: Display device identification cache
| |
| 17: Clear device identification cache
| |
| 96: Toggle IPS engines watchdog timer
| |
| 97: Start all IPS engines
| |
| 98: Stop all IPS engines
| |
| 99: Restart all IPS engines and monitor
| |
|
| |
| === Wann sollte das "Packet Logging" für IPS eingeschaltet werden? ===
| |
|
| |
| Das "Packet Logging" ist nicht zu verwechseln mit dem "Logging" an und für sich dh. "Packet Logging" ähnelt einem "tcpdump" und hat mit dem "Logging" an und für sich nichts zu tun. Diese Funktion sollte mit bedacht eingesetzt werden sowie dass "Packet Logging" sollte nur zu "Development" Zwecken eingeschaltet werden da es enorm Peformance Intensiv (CPU, RAM) ist. Diesie aus dem "Packet Logging" stammenden Informationen können später im zB "Wireshark" anylysiert werden um selber zB zu bestimmten Zwecke Signaturen zu erstellen! Die Position für das "Packet Logging" findet man in einem "IPS Filter" dh.:
| |
|
| |
| [[Datei:Fortinet-43.jpg]]
| |
|
| |
| === Kann eine Fortigate betreffend IPS als "Sniffer" eingesetzt werden? ===
| |
|
| |
| Ja, dies ist möglich. Dazu benötigt man auf einem Switch einen Monitor/Mirror Port sowie die Fortigate muss auf einem bestimmten Port auf den Sniffer Modus gesetzt werden. Um den Sniffer Port zu konfigurieren/aktivieren muss folgender Befehl auf der CLI ausgeführt werden:
| |
|
| |
| # config system interface
| |
| # edit [Name des Ports zB port3]
| |
| # set ips-sniffer-mode enable
| |
| # end
| |
|
| |
| === Wie sollte auf einer Fortigate ein "IPS Profil" aktiviert werden? ===
| |
|
| |
| Um optimale Performance zu erreichen sollten vers. Profile für IPS (Sensor) erstellt werden dh. schränkt man die Möglichkeiten ein innnerhalb eines IPS Sensors senkt sich die Anzahl der zu überprüfenden Signaturen. Dies bedeutet erstelle Profile für spezielle Zwecke dh. Server und/oder Clients. Nachfolgend ein Beispiel wie so ein Profil erstellt wird:
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Wenn aus irgendwelchen Gründen die IPS zuviel Performance benötigt speziell im RAM Bereich kann folgender Befehl
| |
| dazu benutzt werden um den Speicher für IPS zu begrenzen:
| |
|
| |
| # config ips global
| |
| # set algorithm low
| |
| # end
| |
|
| |
| '''INFO''' Zusätzlich zur benützten IPS Engine kann die Buffer Size durch den Befehl "socket-size" gesetzt werden dh.
| |
| bei den meisten Devices ist die Standard Einstellung die korrekte und die Anzuwendende. Dies bedeutet diese
| |
| Einstellung ist Device Art Abhängig!
| |
|
| |
| Für die IPS Engine sind grundsätzlich folgende Einstellungen möglich:
| |
|
| |
| engine-pick Die IPS Engine selber entscheidet welche Methode die Beste ist.
| |
|
| |
| high Schnellste Methode jedoch benötigt mehr Memory. Sollte nur eingesetzt
| |
| werden für FortiGate's mit mind. 1 GB Memory.
| |
|
| |
| low Langsamere Methode jedoch Memory Resource schonender. Dieser Mode sollte
| |
| auf FortiGates eingesetzt werden die über 512 MB Memory verfügen oder weniger.
| |
|
| |
| super Dieser Mode sollte für FortiGate's gewählt werden die mehr als 4 GB Memory verfügen
| |
|
| |
| [[Datei:Fortinet-44.jpg]]
| |
|
| |
| [[Datei:Fortinet-45.jpg]]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Ab FortiOS 5.0.4 stehet ein zusätzliche Menüpunkt innerhalb der IPS zur Verfügung dh. wenn man "Filter Based"
| |
| aktiviert kann zwischen "Basic" und "Advanced" umgestellt werden. Es ist zu empfehlen wenn IPS benutzt wird
| |
| "Filter Based > Advanced" zu wählen da einem diese Variante mehr Optionen bietet den Sensor für den bestimmten
| |
| Zweck einzuschränken. Zusätzlich können unter den -durch "Advanced"- eingeblendeten Menüpunkte "Appliaction"
| |
| und "Protocol" unter "Show more..." zusätzliche Positione eingeblendet werden. Dies gibt einem die Möglichkeite
| |
| den Sensor so zu optimieren:
| |
|
| |
| [[Datei:Fortinet-809.jpg]]
| |
|
| |
| === Was bedeutet IPS "fail-open" und wie verhält es sich? ===
| |
|
| |
| Nun IPS "fail-open" bedeutet, dass wenn ein IPS Profil/Sensor auf einer Policy aktiv ist und der IPS Service nicht mehr korrekt arbeitet das der Traffic/Verkehr komplett für diese Policy geblockt wird. Per Standard ist "fail-open" auf enabled gesetzt sprich wenn IPS nicht mehr korrekt funktioniert wird der Traffic dennoch durchgelassen. Wenn dies geschieht hat dies keine Auswirkungen auf die restlichen Profile wie Antivirus etc. Wenn der IPS Senso in einem High Security Umgebung eingesetzt wird so kann "fail-open" auf disabled gesetzt werden dh. wenn der IPS Service nicht mehr korrekt arbeitet wird sämtlicher Verkehr/Traffic für die betreffende Policy geblockt. Um "fail-open" auf disable zu setzen gebe auf der Console folgendes ein;
| |
|
| |
| # config ips global
| |
| # set fail-open disable
| |
| # end
| |
|
| |
| === Kann ich wenn der Traffic verschlüsselt ist (SSL) IPS aktivieren? ===
| |
|
| |
| Die FortiOS V4.x war nicht fähig den verschlüsselten Traffic (SSL) aufzubrechen um eine IPS Ueberprüfung für den Traffic durchzuführen! Mit FortiOS 5.x ist dies nun möglich jedoch ist folgendes zu berücksichtigen:
| |
|
| |
| Verschlüsselter (SSL) Traffic kann für IPS sowie für Application Controll überprüft werden für folgende Protokolle:
| |
|
| |
| HTTPS, FTPS, IMAPS, POP3S sowie SMTPS
| |
|
| |
| Dabei ist zu berücksichtigen das Application Control sowie IPS nur im "Flow-based" Proxy Mode benutzt werden können da für diese zwei Funktionen "Proxy-based" nicht zur Verfügung steht. Werden in einer Firewall Policy "Proxy-based" sowie "Flow-based" Mode konfiguriert, führt die FortiGate für diese Firewall Policy "Proxy-based" durch für alle Profiles die diesen Mode unterstützen. Dies bedeutet: Wird Antivirus im "Flow-based" Mode konfiguriert sowie WebFilter im "Proxy-based" führt die FortiGate für alle Funktionen inkl. Antivirus "Proxy-based" Mode durch. Dies gilt nicht für Application Control sowie IPS da diese zwei Funktionen nur den "Flow-based" Mode unterstützen. Der "Flow-based" Mode steht zusätzlich zum "Proxy-based" Mode für folgende Funktionen zur Verfügung:
| |
|
| |
| flow-AV, flow-Web Filering, flow-Antispam sowie flow-DLP
| |
|
| |
| Der jeweilige Mode kann in diesen Funktionen im jeweiligen "Security Profile" konfiguriert werden!
| |
|
| |
| === Wie erfasse ich für RDP eine IPS Signature um den Zugriff zu schützen? ===
| |
|
| |
| Nun wenn betreffend RDP auf einen Server zugegriffen werden möchte ist es ratsam diesen Zugriff zu schützen. Predistiniert dazu wäre eine RDP Signatur im IPS Bereich. Jedoch diese existiert so nicht von Hause aus. Soit muss eine manuell erfasste IPS Signatur für RDP konfiguriert werden. Dies kann über folgende Position geschehen:
| |
|
| |
| UTM Security Profiles > Intrusion Protection > IPS Signatures > Create New
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Sobald die Signature erfasst wurde kann diese wie bis anhin über ein IPS Profile eingebunden werden
| |
| sowie das entsprechende Profil in der entsprechenden Policy verwendet werden! Weitere Informationen betreffend
| |
| dieser Konfiguration siehe folgender Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_sollte_auf_einer_Fortigate_ein_.22IPS_Profil.22_aktiviert_werden.3F]]
| |
|
| |
| Vergebe der Signature einen Namen. Danach gebe unter Signature folgendes ein:
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Die folgenden Signaturen sind für Windows (RDP.1), Linux (RDP.2) sowie Mobile (RDP.3).
| |
|
| |
| '''Name:''' RDP.1
| |
|
| |
| '''Signature:''' F-SBID( --name "RDP.1"; --protocol tcp; --dst_port 3389; --flow from_client; --seq =,1,relative; --pattern "|E0|"; --distance 5,packet; --within 1,packet; --pattern "mstshash="; --within 50; --pcre "/mstshash=\s*/sm"; --distance -12; --within 50; --rate 3,15; --track src_ip; )
| |
|
| |
| '''Name:''' RDP.2
| |
|
| |
| '''Signature:''' F-SBID( --name "RDP.2"; --protocol tcp; --dst_port 3389; --flow from_client; --seq =,1,relative; --pattern "|03 00|"; --within 2,packet; --pattern "|e0 00 00 00 00|"; --distance 3; --within 20; --rate 3,15; --track src_ip; )
| |
|
| |
| '''Name:''' RDP.3
| |
|
| |
| '''Signature:''' F-SBID( --name "RDP.3"; --protocol tcp; --dst_port 3389; --flow from_client; --seq =,1,relative; --pattern "|84 11 3d 4f 2e 62 28 62 51 5d 6e ee f4 49 c2 7e fe 84 11 e6 61 e0 19 20 c9 e5 d3 39 3d f5 7e 24 46 49 84 11 15 be fa 6b 7d 35 09 44 8a c9 32 e7 1b 6e 65|"; --within 51,packet; --data_size 51; --rate 3,15; --track src_ip; )
| |
|
| |
| Weitere Informationen wie die IPS Syntax zu benützen ist findet man im IPS Syntax Guide:
| |
|
| |
| [[Datei:IPS-Signature-Syntax-Guide.pdf]]
| |
|
| |
| === Wie kann ich eine IP ausschliessen innerhalb eines IPS Sensors resp. Profil (Exempt IP)? ===
| |
|
| |
| Diese Funktion steht erst ab FortiOS 5.0.3 zur Verfügung. Natürlich waren solche Ausnahmen ebenfalls früher möglich über die Policy, jedoch nur indem man eine zusätzliche Rule implementierte für eine bestimmte Source und Destination. Auf dieser zusätzlichen Rule wurde dann der Sensor resp. das Profil nicht aktiviert. Neu ab FortiOS 5.0.3 kann diese Ausnahme einer Source und Destination direkt im Sensor konfiguriert werden. Vorraussetzung dafür ist, dass man spezifizierte Signaturen verwendet (Specify Signatures) und nicht Filter Basierend (Filter Based).
| |
|
| |
| Nehmen wir an wir hätten einen Microsoft Exchange Server im DMZ. Dieser wird von aussen angegangen mit einem Inbound NAT. Bedeutet eine Rule wird implementiert WAN > DMZ. Auf dieser Rule implementiert man einen IPS Sensor der den Microsoft Exchange Server schützen soll vor Angriffen. Nehmen wir weiter an, dass immer der gleiche MX Relay Server Mail's übermittelt zu diesem Microsoft Exchange Server im DMZ. Dieer MX Relay Server steht unter unserer Kontrolle (trusted). In diesem Scenario macht es keinen Sinn den IPS Sensor auf den MX Relay Server anzuwenden. Genau hier können wir eine "Ausnahme" Implementieren. Da der IPS Sensor einer der Performance intensivsten Funktionen auf einer FortiGate ist kann dies die Performane erhöhen und Resourcen sparen da die Verbindung des MX Relay bei Mailübermittlungen nicht mehr durch den IPS Sensor überprüft wird. Die neue Funktion findet man unter dem IPS Sensor sobald "Specify Signature" angewählt sowie eine entsprechende Signature ausgewählt wird:
| |
|
| |
| [[Datei:Fortinet-786.jpg]]
| |
|
| |
| Nun kann über "Create New" anhand der Source IP (In unserem Beispiel der MX Relay Server) und der Destination IP (In unserem Beispiel die internal IP des Microsoft Exchange Servers) die Ausnahme konfiguriert werden.
| |
|
| |
| === Wie kann ich eine "Brute Force" Attacke betreffend POP3 und/oder SMTP über eine IPS "Custome Signature" verhindern? ===
| |
|
| |
| Eine "Brute Force" Attacke stellt einen Angriff dar in der "potentielle Lösungen" eine nach der Anderen durchprobiert wird (http://de.wikipedia.org/wiki/Brute-Force-Methode). Für Pop3 und/oder SMTP im Zusammenhang mit "unverschlüsselten" Protokollen dh. nicht POP3S und/oder SMTPS kann ein "potentieller Angreifer" zB eine "dictionary attacke" durchführen dh. er probiert ein Passwort nach dem Anderen durch. Um das zu verhindern kann zB eine "Custome Signature" erstellt werden die das verhindert. Die bessere Variante ist jedoch klar auf ein verschlüsseltes Protokoll zu wechseln. Wenn dennoch so eine manuelle "Custome Signatur" erstellt werden soll führe folgendes durch:
| |
|
| |
| UTM Security Profiles > Intrusion Protection > IPS Signatures > Create New
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Sobald die Signature erfasst wurde kann diese wie bis anhin über ein IPS Profile eingebunden werden
| |
| sowie das entsprechende Profil in der entsprechenden Policy verwendet werden! Weitere Informationen betreffend
| |
| dieser Konfiguration siehe folgender Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_sollte_auf_einer_Fortigate_ein_.22IPS_Profil.22_aktiviert_werden.3F]]
| |
|
| |
| Vergebe der Signature einen Namen. Danach gebe unter Signature folgendes ein:
| |
|
| |
| '''Name:''' POP3.Brute.Force
| |
|
| |
| '''Signature:''' F-SBID( --name "POP3.Brute.Force"; --protocol "tcp"; --service POP3; --flow from_server,reversed; --pattern "-ERR [AUTH] Password supplied"; --rate 10,180; --track src_ip; )
| |
|
| |
| '''Name:''' SMTP.Brute.Force
| |
|
| |
| '''Signature:''' F-SBID( --name "SMTP.Brute.Force"; --pattern "AUTH LOGIN"; --service SMTP; --no_case; --context header; --rate 10,180; --track src_ip;)
| |
|
| |
| In diesem Zusammenhang ist es Wichtig die Position "--rate" zu verstehen da diese Zuständig ist um die Aktion durchzuführen. Dies bedeutet folgendes:
| |
|
| |
| --rate <matches_int>,<time_int>;
| |
|
| |
| • <matches_int> Ist die Anzahl (integer) der Uebereinstimmungen innerhalb einer Zeitspanne [time_int] in der die Signature anschlägt (matched)
| |
| • <time_int> Ist die Zeitspanne (seconds) die definiert wird in der die Signature Uebereinstimmung [matches_int] auftritt.
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Im oberen Beispiel wurde definiert "--rate 10,180". Dies wiederum bedeutet: Wenn ein "innerhalb" (time_int) 180 Sekunden 10 Mal (mateches_int)
| |
| versucht wird zB einzuloggen "AUTH LOGIN" so "matched" die "Custome Signature" und es wird ein Log Eintrag erstellt. Wenn die "Custome Signature"
| |
| Im IPS Profile auf Monitor steht wird ein Log Eintrag erstellt. Ist die "Custome Signature" auf "block" kann durch eine entsprechende "quarantine"
| |
| Konfiguration die entsprechende Source IP (--track src-ip) für eine gewisse Zeit ausgeschlossen resp. blockiert werden!
| |
|
| |
| Weitere Informationen wie die IPS Syntax zu benützen ist findet man im IPS Syntax Guide:
| |
|
| |
| [[Datei:IPS-Signature-Syntax-Guide.pdf]]
| |
|
| |
| === Kann ich IPS Funktion auf einer FortiGate über Hardware beschleunigen? ===
| |
|
| |
| Ja dies ist möglich und zwar bei FortiGate's die über einen CPx oder NPx Prozessor verfügen. Wenn die Beschleunigung über diese Prozessoren aktiviert wird werden die IPS Pattern über diese CPx oder NPx Prozessoren verarbeitet und dadurch beschleunigt. Um festzustellen ob die zur Verfügung stehende FortiGate über diese Funktion resp. über diese CPx und/oder NPx Prozessoren verfügt kann mit folgenden Befehl verifiziert werden ob der "hardware-accel-mode" zur Verfügung steht:
| |
|
| |
| # config ips global
| |
| # set hardware-accel-mode [ engine-pick | none | CP-only | NP-only | NP+CP ]
| |
| # end
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Diese Option steht ab FortiOS 5.0.3 zur Verfügung! Ab FortiOS 5.0.6 wurde das
| |
| Kommando ersetzt durch das Kommando np-accel-mode" sowie "cp-accel-mode" um mehr
| |
| Granularität zu bieten. Ab FortiOS 5.0.10 wird für die FG-300D und/oder FG-500D dieses
| |
| Kommando auf "none" gesetzt. Dies bedeutet diese zwei Device's unterstützen keinen
| |
| "np-accel-mode". Wird dieser Mode bei diesen Devices dennoch aktiviert beeinträchtigt
| |
| dies im negativen Sinne die Performance:
| |
|
| |
| # config ips global
| |
| # set np-accel-mode [none | basic]
| |
| # set cp-accel-mode [none | basic | advanced]
| |
| # end
| |
|
| |
| Dabei gilt "np" für Network Prozessor und "cp" Content Prozessor! Per Standard
| |
| steht die Option auf "cn-accel-mode advanced"
| |
|
| |
| Die einzelne Optionen haben folgende Bedeutung:
| |
|
| |
| • engine-pick --> Die IPS Engine wählt den besten Mode
| |
| • none --> Hardware Beschleunigung ist deaktiviert
| |
| • CP-Only --> Hardware Beschleunigung aktiviert über CPx (Content) Prozessoren
| |
| • NP-only --> Hardware Beschleunigung aktiviert über NPx (Network) Prozessoren
| |
| • NP+CP --> Hardware Beschleunigung aktiviert über CPx (Content) und NPx (Network) Prozessoren
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Bei einer FortiGate 60C steht zB diese Option auf "engine-pick"!
| |
|
| |
| === Kann ich über eine IPS Signature eine bestimmte WebSite blockieren? ===
| |
|
| |
| Grundsätzlich ist das möglich anhand einer Custom Signature! Es muss jedoch klar festgestellt werden, dass dies nur unter "nicht normalen" Umständen durchzuführen ist da dies klar nicht die Aufgabe einer IPS Funktion ist. Um eine WebSite zu blockieren steht auf einer FortiGate die WebFilter Funktion zur Verfügung. Weitere Informationen zur WebFilter Konfiguration siehe nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_kann_ich_im_Zusammenhang_mit_dem_URL_WebFiltering_ein_.22whitelisting.22_und.2Foder_.22blacklisting.22_konfigurieren.3F]]
| |
|
| |
| Wenn es dennoch keinen anderen Weg gibt -wieso auch immer- kann eine "Custome Signature" manuell erstellt werden und zwar folgenermassen:
| |
|
| |
| UTM Security Profiles > Intrusion Protection > IPS Signatures > Create New
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Sobald die Signature erfasst wurde kann diese wie bis anhin über ein IPS Profile eingebunden werden
| |
| sowie das entsprechende Profil in der entsprechenden Policy verwendet werden! Weitere Informationen betreffend
| |
| dieser Konfiguration siehe folgender Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_sollte_auf_einer_Fortigate_ein_.22IPS_Profil.22_aktiviert_werden.3F]]
| |
|
| |
| Vergebe der Signature einen Namen. Danach gebe unter Signature folgendes ein:
| |
|
| |
| '''Name:''' RDP.1
| |
|
| |
| '''Signature:''' F-SBID( --name "WEB SITE BLOCK"; --protocol tcp; --service HTTP; --flow from_client; --pattern "mydomain.ch"; --no_case; --context host; )
| |
|
| |
| Weitere Informationen wie die IPS Syntax zu benützen ist findet man im IPS Syntax Guide:
| |
|
| |
| [[Datei:IPS-Signature-Syntax-Guide.pdf]]
| |
|
| |
| === Kann ich über eine IPS Signature für DNS Request ein Monitoring einschalten für Domain Namen? ===
| |
|
| |
| Wenn man intern ein "Public DNS Server" betreibt und man bei Anfragen von extern herausfinden will -ohne den DNS Server zu konsultieren- welche Domains in den DNS Requests abgefragt werden, kann eine IPS Signature erstellt werden. Diese IPS Signture Monitored die DNS Request betreffend "Domain Name" und zeigt in den Logs den DNS Request auf:
| |
|
| |
| UTM Security Profiles > Intrusion Protection > IPS Signatures > Create New
| |
|
| |
| '''Name:''' Domain-Monitor
| |
|
| |
| '''Signature:''' F-SBID( --name Domain-Monitor; --protocol udp; --service dns; --log DNS_QUERY;)
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Sobald die Signature erfasst wurde kann diese wie bis anhin über ein IPS Profile eingebunden werden
| |
| sowie das entsprechende Profil in der entsprechenden Policy verwendet werden! Weitere Informationen betreffend
| |
| dieser Konfiguration siehe folgender Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_sollte_auf_einer_Fortigate_ein_.22IPS_Profil.22_aktiviert_werden.3F]]
| |
|
| |
| Im Dezember 2014 hat Fortinet ein "Cookbook Supplementary" herausgegeben das diese Konfiguration beschreibt:
| |
|
| |
| [[Datei:ips-logging-dns-domain-kookups.pdf]]
| |
|
| |
| Weitere Informationen wie die IPS Syntax zu benützen ist findet man im IPS Syntax Guide:
| |
|
| |
| [[Datei:IPS-Signature-Syntax-Guide.pdf]]
| |
|
| |
| === Kann ich über eine IPS Signature Media Downloads für ITunes Monitoren und/oder Blocken? ===
| |
|
| |
| Dies kann über eine entsprechende selbsterstellte IPS Signature konfiguriert werden dh. nachfolgende selbsterstellt Signaturen ermöglichen es ITunes zu Monitoren und/oder zu Blocken. folgendes ist durchzuführen:
| |
|
| |
| UTM Security Profiles > Intrusion Protection > IPS Signatures > Create New
| |
|
| |
| '''Name:''' iTunes_Monitor
| |
|
| |
| '''Signature:''' F-SBID( --name iTunes_Monitor; --protocol tcp; --flow from_client; --service http; --parsed_type http_get; --pattern "User-Agent: iTunes"; --context header; --no_case; --tag set,Tag.iTunes.client;)
| |
|
| |
| UTM Security Profiles > Intrusion Protection > IPS Signatures > Create New
| |
|
| |
| '''Name:''' iTunes_Music_Block
| |
|
| |
| '''Signature:''' F-SBID( --name iTunes_Music_Block; --protocol tcp; --flow from_server; --service http; --pattern "Content-Type: audio"; --context header; --no_case; --tag test,Tag.iTunes.client;)
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Sobald die Signature erfasst wurde kann diese wie bis anhin über ein IPS Profile eingebunden werden
| |
| sowie das entsprechende Profil in der entsprechenden Policy verwendet werden! In diesem Beispiel wird die
| |
| Signature auf iTunes_Monitor auf "montor" gesetzt und iTunes_Block auf "block". Weitere Auskunft wie das
| |
| durchzuführen ist siehe nachfolgenden Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_sollte_auf_einer_Fortigate_ein_.22IPS_Profil.22_aktiviert_werden.3F]]
| |
|
| |
| Diese Signaturen verhindern "nur" den Media Donwload jedoch nicht den Zugriff auf iTunes selber. In der "Application Control" sethen verschiedenen Signaturen zur Verfügung die Zugriffe auf "iTunes" verhindern jedoch nicht explizit den iTunes Media Download:
| |
|
| |
| iCloud - Block
| |
| iTunes.Store - Block
| |
| iTunes.Podcast - Block
| |
| iTunes.filesharing - Block
| |
| iTunes_Broadcast - Block
| |
| iTunes.mDNS - Block
| |
| iTunes.iMix - Pass
| |
| iTunes - Pass
| |
| iTunes-Mobile - Pass
| |
| iTunes-Appl.Store. - Pass
| |
| Apple.Support - Pass
| |
| Apple.Ipad - Pass
| |
| Apple.Iphone - Pass
| |
|
| |
| Weitere Informationen wie die IPS Syntax zu benützen ist findet man im IPS Syntax Guide:
| |
|
| |
| [[Datei:IPS-Signature-Syntax-Guide.pdf]]
| |
|
| |
| == DDos ==
| |
|
| |
| === Wieso ist die DDos Sensor Menüposition im WebGui nicht mehr ersichtlich nach einem Upgrade? ===
| |
|
| |
| Wenn man ein Upgrade durchführt 4.3 Patch 7 fällt einem auf, dass die Menüposition im Web Gui betreffend DDoS nicht mehr vorhanden ist. Dieser Menüpunkt steht für kleinere Geräten (FGT-20/40/50/60/80) nicht mehr über Web Gui zur Verfügung. Die Funktion selber steht jedoch nach wievor zur Verfügung und zwar auf der CLI:
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Die Menüposition steht für kleinere Devices ebenfalls für FortiOS 5.0 / 5.2
| |
| nicht mehr über Web Gui zur Verfügung!
| |
|
| |
| '''FortiOS 4 MR3'''
| |
| [[Datei:Fortinet-327.jpg]]
| |
| [[Datei:Fortinet-328.jpg]]
| |
|
| |
| '''FortiOS 5.0 / 5.2'''
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Unter FortiOS 5.0 / 5.2 wurde diese Funktion in der CLI verschoben in "config firewall DoS-policy":
| |
|
| |
| [[Datei:Fortinet-723.jpg]]
| |
| [[Datei:Fortinet-724.jpg]]
| |
|
| |
| Um ein DoS Sensor in der CLI unter FortiOS 5.0 / 5.2 zu konfigurieren siehe nachfolgendes Beispiel:
| |
|
| |
| # config firewall DoS-policy
| |
| # edit [Definiere einen DoS Policy ID zB "1"]
| |
| # set interface [Setze ein entsprechendes Interface zB "wan1"]
| |
| # set srcaddr [Setze eine entsprechende Source IP Adresse zB "all"]
| |
| # set dstaddr [Setze eine entsprechende Destination IP Adresse zB "all"]
| |
| # set service [Setze einen entsprechenden Port zB "ALL"]
| |
| # config anomaly
| |
| # edit "tcp_syn_flood"
| |
| # set status 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 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 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
| |
|
| |
| === Wie wird auf einer Fortigate ein "DoS" Sensor aktiviert/definiert? ===
| |
|
| |
| In unserem Beispiel erstellen wir einen "DoS Sensor" der und vor "basic flood" schützt! Führe folgendes durch:
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Wenn die Menüposition betreffend DoS Sensor nicht ersichtlich ist siehe folgender Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wieso_ist_die_DDos_Sensor_Men.C3.BCposition_im_WebGui_nicht_mehr_ersichtlich_nach_einem_Upgrade.3F]]
| |
|
| |
| UTM Profiles > Intrusion Protection > DoS Sensor
| |
|
| |
| Editiere den per Standard existierende Sensor "blook_flood" Eintrag:
| |
|
| |
| [[Datei:Fortinet-155.jpg]]
| |
|
| |
| In diesem vordefinierten Sensor sind drei spezifische Anomalien aktiviert dh. "tcp_syn_flood, udp_flood und icmp_flood". Um nun den "icmp_flood" anzupassen setze diesen auf "20" sowie aktiviere das Logging:
| |
|
| |
| [[Datei:Fortinet-156.jpg]]
| |
|
| |
| Damit der "DoS Sensor" auch in Benützung ist, muss dieser in einer entsprechenden "DoS Policy" aktiviert werden. Führe folgendes durch:
| |
|
| |
| '''Policy > Policy > DoS Policy'''
| |
|
| |
| [[Datei:Fortinet-157.jpg]]
| |
|
| |
| [[Datei:Fortinet-158.jpg]]
| |
|
| |
| In unserem Beispiel schützen wir das "internal" Inteface vor diesen Angriffen. Natürlich können Source und Destination je nach Zweck eingeschränkt werden. Um das Ganze zu testen kann innerhalb der Defintion der "Source" auf einem Windows basierenden Client anhand "fping" (http://fping.sourceforge.net) folgendes durchgeführt werden:
| |
|
| |
| fping [Destination IP] -c -t0 -w0
| |
|
| |
| Das Kommando bewirkt das "fping" ICMP Packete abschickt ohne auf Antwort zu warten. Einige dieser Packete werden durch unseren definierten "icmp_flood" Sensor geblockt da die abgesetzen ICMP Packet die Definition (20 per second) übersteigt. Unter folgender Position können die Log's eingesehen sowie der Vorgang verifiziert werden:
| |
|
| |
| '''FortiOS 4 MR3'''
| |
|
| |
| Log&Report > Log & Archive Access > UTM Log
| |
|
| |
| '''FortiOS 5.0 / 5.2'''
| |
|
| |
| Log & Report > Traffic Log
| |
|
| |
| Weitere Informationen betreffend Log Konfiguration unter FortiOS 5.0 / 5.2 findet man unter folgenden Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_sieht.2Ff.C3.BChre_ich_eine_vollst.C3.A4ndige_Log_Konfiguration_auf_einer_FortiGate_aus.3F]]
| |
|
| |
| === Was muss berücksichtigt werden wenn ich meine internen Server/Clients schützen möchte vor DoS Attacken? ===
| |
|
| |
| In erster Linie muss berücksichtigt werden, dass die DDoS Policy auf einer FortiGate "nicht" abgearbeitet wird innerhalb der Stateful Firewall Inspection/Policy sondern seperat. Dies bedeuet möchte man einen Server im internen Bereich schützen "vor" einer DDoS Attacke darf im Gegensatz zur "Stateful Firewall Inspection/Policy" Konfiguration nicht das VIP (Destination NAT) Objekt benutzt werden inneerhalb der definierten DDoS Policy sondern es muss ein adress Objekt benutzt werden mit das definiert wurde mit der Public IP des internen Servers. In einer Definition einer DDoS Policy würde das folgendes bedeuten:
| |
|
| |
| # config firewall DoS-policy
| |
| # edit 1
| |
| # set interface "wan1"
| |
| # set srcaddr "all"
| |
| # set dstaddr [Name des Adress Objektes mit der Public IP des internen Servers]
| |
| # set service [Definiation des Service zB "any" oder spezifiziert "SMTP"]
| |
| # config anomaly
| |
| # edit [Name der Anomaly zB "tcp_src_session"]
| |
| # set status enable
| |
| # set action block
| |
| # set quarantine attacker
| |
| # set quarantine-expiry 10
| |
| # set quarantine-log enable
| |
| # set threshold 100
| |
| # next
| |
| # end
| |
| # next
| |
| # end
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Wenn solch eine Konfiguration durchgeführt wird ist es "fundamental" sich zu verinnerlichen wie ein Service funktioniert und wie dieser
| |
| zu schützen ist. Dies bedeutet: Würde man im oberen Beispiel als Public IP des Servers die IP benutzen eine SMTP Servers zB MX Record
| |
| und als "Anomaly" entweder "tcp_src_session" und/oder "tcp_dst_session" sowie einen "threshold" von 100 so wird dieser SMTP Server
| |
| betreffend möglichen Sessions auf dem Service "SMTP" limitiert. Bedeutet wiederum, dass dieser vor "Denial of Service" Attacken im
| |
| Service SMTP geschützt würde.
| |
|
| |
| Ein Schutz im entgegengesetzer Richtung ist natürlich ebenfalls möglich dh. wenn man zB ein Client Subnet Bereich schützen müchte damit event. "worm" Attacken die FortiGate nicht beeinträchtigen kann folgendes implementiert werden:
| |
|
| |
| # config firewall DoS-policy
| |
| # edit 1
| |
| # set interface "wan1"
| |
| # set srcaddr [Definiation des Subnet der Client's anhand eines Objektes; benutze nicht "all"]
| |
| # set dstaddr [Name des Adress Objektes mit der Public IP des internen Servers]
| |
| # set service [Definition "any"]
| |
| # config anomaly
| |
| # edit "tcp_syn_flood"
| |
| # set status enable
| |
| # set action block
| |
| # set threshold 2000
| |
| # next
| |
| # edit "tcp_dst_session"
| |
| # set status enable
| |
| # set action block
| |
| # set threshold 5000
| |
| # next
| |
| # edit "ip_dst_session"
| |
| # set status enable
| |
| # set action block
| |
| # set threshold 5000
| |
| # next
| |
| # edit "tcp_port_scan"
| |
| # set status enable
| |
| # set action block
| |
| # set threshold 1000
| |
| # next
| |
| # end
| |
| # next
| |
| # end
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Die Anomaly Definition in diesem Beispiel verhindert, dass aus dem Client Subnet und/oder ein spezifizierter Client diese
| |
| Vorgänge durchführt und somit die FortiGate und dessen Umgebung beeinträchtigt. Die "Standard Werte" sind als Beispiele
| |
| anzusehen und müssen je nach Umgebung angepasst werden jedoch können diese als "Start" benützt werden! Auch in diesem Fall sind
| |
| die Auswirkungen zu berücksichtigen dh. ein Software wie zB Skype sucht sich anhand solcher Funktionen den Ausgang. Dies bedeutet:
| |
| Wenn im im internen Bereich Skype eingesetzt wird und zB "tcp_src_*" definiert werden mit einem zu kleinen "threshold" kann diese
| |
| Definition es Skype verunmöglichen - da durch die DDoS Policy dieser Vorgang geblockt wird - um mit dem Internet zu komunizieren.
| |
|
| |
| === Wie kann ich für eine "DDoS Policy" verschiedenen Informationen anzeigen lassen? ===
| |
|
| |
| Wenn eine "DDoS Policy" konfiguriert wird, kann nachträglich mit folgenden Kommando vers. Informationen dieser DDoS Policy augezeigt werden:
| |
|
| |
| # diagnose ips anomaly [clear | config | filter | list | status]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Die aufgeführten Optionen haben folgende Bedeutung:
| |
|
| |
| clear Clear anomaly meters
| |
| config Liste die DOS-sensoren auf
| |
| filter Liste den "anomaly" Filter auf
| |
| list Liste die "anomaly" meters auf
| |
| status Liste den "anomaly" status auf
| |
|
| |
| Nachfolgende einige Beispiele:
| |
|
| |
| # diagnose ips anomaly config
| |
| DoS sensors in kernel vd 0:
| |
| DoS id 1 proxy 0
| |
| 0 tcp_syn_flood status 1 log 1 nac 0 action 7 threshold 2000
| |
| 1 tcp_port_scan status 1 log 1 nac 0 action 0 threshold 1000
| |
| 2 tcp_src_session status 1 log 1 nac 0 action 0 threshold 5000
| |
| 3 tcp_dst_session status 1 log 1 nac 0 action 0 threshold 5000
| |
| 4 udp_flood status 1 log 1 nac 0 action 7 threshold 2000
| |
| 5 udp_scan status 1 log 1 nac 0 action 0 threshold 2000
| |
| 6 udp_src_session status 1 log 1 nac 0 action 0 threshold 5000
| |
| 7 udp_dst_session status 1 log 1 nac 0 action 0 threshold 5000
| |
| 8 icmp_flood status 1 log 1 nac 0 action 7 threshold 250
| |
| 9 icmp_sweep status 1 log 1 nac 0 action 0 threshold 100
| |
| 10 icmp_src_session status 1 log 1 nac 0 action 0 threshold 300
| |
| 11 icmp_dst_session status 1 log 1 nac 0 action 0 threshold 1000
| |
| 12 ip_src_session status 0 log 0 nac 0 action 0 threshold 5000
| |
| 13 ip_dst_session status 0 log 0 nac 0 action 0 threshold 5000
| |
| 14 sctp_flood status 0 log 0 nac 0 action 0 threshold 2000
| |
| 15 sctp_scan status 0 log 0 nac 0 action 0 threshold 1000
| |
| 16 sctp_src_session status 0 log 0 nac 0 action 0 threshold 5000
| |
| 17 sctp_dst_session status 0 log 0 nac 0 action 0 threshold 5000
| |
|
| |
| # diagnose ips anomaly status
| |
| meter budget: 100000
| |
| meter used: 8/8
| |
| meter depth: 2
| |
|
| |
| # diagnose ips anomaly list
| |
| list nids meter:
| |
| id=udp_dst_session ip=198.41.0.4 dos_id=1 exp=5998 pps=0 freq=0
| |
| id=udp_flood ip=198.41.0.4 dos_id=1 exp=998 pps=13 freq=13
| |
| id=udp_src_session ip=193.193.135.65 dos_id=1 exp=5998 pps=0 freq=0
| |
| id=udp_scan ip=193.193.135.65 dos_id=1 exp=998 pps=14 freq=14
| |
| id=udp_flood ip=193.193.135.66 dos_id=1 exp=998 pps=0 freq=3
| |
| id=udp_dst_session ip=192.228.79.201 dos_id=1 exp=5898 pps=0 freq=0
| |
| id=udp_flood ip=192.228.79.201 dos_id=1 exp=898 pps=0 freq=1
| |
| id=udp_flood ip=255.255.255.255 dos_id=1 exp=35 pps=0 freq=0
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Diese Liste zeigt nicht zwingen IP's resp. Sourcen von "Attacken" sondern Source IP's für die eine DDoS Policy
| |
| matched. Die Position "exp=" gibt ein Wert an in Sekunden nachdem der Eintrag entfernt wird sofern die Source
| |
| IP nicht mehr für eine DDoS Policy matched. Die Position "pps=" gibt an wieviele "Packet Pro Sekunde" von dieser
| |
| Source IP gesendet wurden/werden.
| |
|
| |
| Wenn die Liste für "diagnose ips anomaly" sehr lang ist kann anhand der Option "filter" ein entsprechender Filter gesetzt werden. Wenn nachträglich "diagnose ips anomaly list" ausgeführt wird so wird der gesetzte Filter benutzt:
| |
|
| |
| # diagnose ips anomaly filter
| |
| anomaly filter:
| |
| id any
| |
| ip 0.0.0.0 mask 0.0.0.0
| |
| nps 0 - 0
| |
| freq 0 - 0
| |
|
| |
| == Antivirus ==
| |
|
| |
| === Wo konfiguriere ich die Updates der Antivirus Pattern und was ist per Standard konfiguriert? ===
| |
|
| |
| Die Antivirus Pattern (Database) einer FortiGate dh. Zeit und Intervall können über das Web Mgmt. Interface über folgende Position konfiguriert werden:
| |
|
| |
| System > Config > FortiGuard > AV & IPS Download Options
| |
|
| |
| Per Standard gilt für FortiOS 5.0 die Einstellungen für ein "daily" Update dh. einmal pro Tag. Ab FortiOS 5.2.4 wurde diese Standard Einstellungen geändert auf alle "2 hours". In einem "normalen" Umfeld empfehlen wir ein Update Interval von 6 Stunden. Dies wird auf der Kommandozeile folgendermassen konfiguriert:
| |
|
| |
| # config system autoupdate schedule
| |
| # set status enable
| |
| # set frequency every
| |
| # set time 06:00
| |
| # end
| |
|
| |
| Desweiteen empfehlen wir unter normalen Umständen die "push" Updates zu deaktivieren. Dies bedeutet: Auch wenn der Zeitintervall einer FortiGate auf alle "6 Stunden" steht und "push" aktiviert ist, benachrichtig FortiGuard bei einem neuen Update den FortiGate Device, dass neue Informationen resp. Updates vorhanden sind. Durch diese Benachrichtigung, bei aktivierten "push", wird der FortiGate Device angewiesen die neuen Informationena aus FortiGuard runterzuladen und so die Antivirus DB resp. Pattern Files auf den neuste Stand zu bringen. Es muss dabei berücksichtigt werden das bei einem Update die Antivirus Engine neu gestartet werden muss dh. kurzfristig entsteht durch das Update der Antivirus DB resp. Patterns eine hohe Auslastung auf dem Device die dadurch entsteht da die Antivirus Engine neu gestartet werden muss um die neuen Information der Antivirus DB einzulesen. Um "push" Updates zu deaktivieren kann folgendes auf der Kommandozeile ausgeführt werden:
| |
|
| |
| # config system autoupdate push-update
| |
| # set status disable
| |
| # end
| |
|
| |
| === Wie setze/blocke ich die File Limite (maximum file size) für den Antivirus? ===
| |
|
| |
| Wenn man eine Limite setzen möchte (empfehlenswert) betreffend "maximum file size" im Antivirus Bereich so muss dies über die Console definiert werden. Möchte man zB eine Limite setzen von 15 MB (unkomprimiert) so würde der Befehl folgendermassen lauten:
| |
|
| |
| '''ACHTUNG''' Die Grösse resp. die Limite die angegeben wird für die Files im Zusammenhang mit der Antivirus Funktion steht
| |
| direkt im Zusammenhang mit der Performance! Dies bedeutet wenn diese zu Gross gesetzt wird zB über 100 MB kann
| |
| dies enorme Performance Einbussen nachsich ziehen! Wieso die Grösse im 10 - 15 MB Bereich liegen sollte zeigt
| |
| nachfolgendes Dokument auf. Dieses gibt Auskunft in welchen File Grössen sich die meisten Anitmalware befinden:
| |
|
| |
| [[Datei:MalwareFileSize.pdf]]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Unter FortiOS 5.2 existiert der Befehl "antivirus service" nicht mehr dh. alle Optionen wurden in die Protocol
| |
| Options verschoben resp. "firewall profile-protocol-options". Dies bedeutet: Unter FortiOS 5.2 muss die maximum
| |
| File Size für Antivirus in den Protocol Options für die einzelnen Services konfiguriert werden. Dazu stehen die
| |
| folgenden Optionen innerhalb der Protocol Options zur Verfügung:
| |
|
| |
| # config firewall profile-protocol-options
| |
| # edit [Name des entsprechenden Profiles]
| |
| # config [http | ftp | imap | mapi | pop3 | smtp | nntp ]
| |
| # set uncompressed-oversize-limit 10
| |
| # set uncompressed-nest-limit 12
| |
| # set block-page-status-code [Setzt den Return Code für HTTP; Standard 200]
| |
| # set scan-bzip2 [enable | disable]
| |
| # end
| |
| # end
| |
|
| |
| Weitere Informationen zu den unter FortiOS 5.2 "firewall profile-protocol-options" siehe nachfolgenden Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_konfiguriere_ich_die_UTM_Proxy.2FProtocol_Options_manuell_.C3.BCber_Kommandozeile.3F]]
| |
|
| |
| # config antivirus service [ftp | ftps | http | https | im | imap | imaps | nntp | pop3 | pop3s | smtp | smtps]
| |
| # set uncompsizelimit [Maximum File unkomprimiert für Antivirus Scanning; Standard 10]
| |
| # set uncompnestlimit [Setzt die max. Tiefe des Achrives 1 - 100; Standard 12]
| |
| # set block-page-status-code [Setzt den Return Code für HTTP; Standard 200]
| |
| # scan-bzip2 [enable | disable]
| |
| # end
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Die Option "uncompnestlimit" gilt für folgende Format:
| |
|
| |
| arj, bzip2, cab, gzip, lha, lzh, msc, rar, tar, zip (bzip2 Support ist per Standard deaktiviert)
| |
|
| |
| Wenn man den Befehl "uncompsizelimit" in Zusammenhang mit dem Wert "0" absetzt gilt dies
| |
| als "unlimited maxmimum file size". Dies ist nicht empfehlenswert dh. man sollte immer
| |
| ein Maximum definieren! Das Maximum kann von Modell zu Modell varieren dh. um die gesetzte Grösse
| |
| zu ermitteln benütze folgendne Befehl (Output Beispiel 60C):
| |
|
| |
| # config antivirus service http
| |
| # set uncompsizelimit ?
| |
| <value> max unompressed size to scan (1-44MB or use 0 for unlimited)
| |
| # end
| |
|
| |
| Wird Antivirus im Zusammenhang mit verschlüsselten Protokollen benutzt wie https, imaps etc. muss "Deep Inspection" benutzt werden. Was dabei zu beachten ist siehe nachfolgenden Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wann_muss_ich_die_UTM_SSL_Proxy.2FProtocol_Options_in_der_Firewall_Rule_aktivierten_und_definieren.3F]]
| |
|
| |
| Nun die Limite betreffend "Antivirus" ist zwar gesetzt jedoch ist folgendes zu berücksichtigen betreffend File Grösse:
| |
|
| |
| Die Angaben von "uncompsizelimit" gelten als max. Grösse für das Antivirus Scanning. Wird diese Grösse Ueberschritten
| |
| erscheint im entsprechenden Log der Hinweis "oversize". Das File wird jedoch nicht "geblockt/gesperrt" sondern wird
| |
| ohne Antivirus Scanning durchgelassen. Möchte man dies verhindern kann ein "oversize block" konfigurieren und zwar
| |
| folgendermassen
| |
|
| |
| Policy > Policy > Protocol/Proxy Options
| |
|
| |
| Wähle die Position Oversized File/Email und den entsprechenden Wert:
| |
|
| |
| [[Datei:Fortinet-245.jpg]]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Wenn die Konfiguration über die Kommandozeile durchgeführt werden soll muss folgendes durchgeführt werden:
| |
|
| |
| # config firewall profile-protocol-options
| |
| # edit [Name des entsprechenden Profiles]
| |
| # config [http | ftp | impa | mapi | pop3 | smtp | nntp]
| |
| # set options [oversize | clientcomfort | servercomfort | no-content-summary | chunkedbypass]
| |
| # set oversize-limit [Max. Grösse für Antivirus Scanning]
| |
| # end
| |
| # end
| |
|
| |
| Wenn die "oversize-limit" gesetzt wird so stellt dies die maximale Grösse dar für Antivirus Scanning. Wird
| |
| unter "set opitons" NICHT "oversize" gesetzt wird das File NICHT geblockt! Somit möchte man zB für "http"
| |
| eine max. Antivirus Scanning Grösse von 10MB konfigurieren und alles was Grösser ist als 10MB blocken,
| |
| würde die vollständige Konfiguration folgendermassen aussehen:
| |
|
| |
| # config antivirus service http
| |
| # set uncompsizelimit 10
| |
| # set uncompnestlimit 12
| |
| # set block-page-status-code 200
| |
| # scan-bzip2 disable
| |
| # end
| |
|
| |
| # config firewall profile-protocol-options
| |
| # edit [Name des entsprechenden Profiles]
| |
| # config http
| |
| # set options oversize no-content-summary
| |
| # set oversize-limit 10
| |
| # end
| |
| # end
| |
|
| |
| Diese Konfiguration ersetzt grunsätzlich nicht "das Maximum eines Files das über die FortiGate runtergeladen werden kann" sondern es steuern einzig und alleine ob ein File geblockt wird, wenn es die "Maximale Grösse von Antivirus Scan übersteigt". Möchte man eine Konfiguratin durchführen für "max. File Grösse betreffend Download/Upload" siehe nachfolgenden Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_kann_ich_verhindern_das_eine_bestimmte_Gr.C3.B6sse_von_Files_.C3.BCbermittelt_werden.3F]]
| |
|
| |
| === Kann ich die Antivirus Engine/Database manuell auf den neusten Stand bringen? ===
| |
|
| |
| Was manuell auf den neusten Stand gebracht werden kann ist das reguläre "Antivirus Definiton File" (ETDB) der FortiGate (enthält ebenfalls Update der Engine). Im Zusammenhang mit dem FortiClient (Premium) kann dies anhand des VCM Files durchgeführt werden. Dies bedeutet ein VCM File ist das "Antivirus Definition File" das benötigt wird damit dem FortiClient (Premium/Endpoint Security) seine Antivirus Definition Files bekommt. Diese Definiton Files können auf der Fortigate dem FortiClient (Premium/Endpoint Security) zur Verfügung gestellt werden. Das Definition File findet man unter folgender URL:
| |
|
| |
| https://support.fortinet.com/Download/AvNidsDownload.aspx
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Damit man die Files runterladen kann muss man sich mit seinem Support Account zuerst anmelden.
| |
| Danach muss der Verifizierungscode auf der Seite mit dem "confirm" Button bestätigt werden.
| |
| Danach können die vers. Files wie zB VCM runtergeladen werden. Für einen Fortinet Device benötigt
| |
| man das "ETDB" File.
| |
|
| |
| Sobald das Definition File runtergeladen wurde kann dies über folgende Menüposition eingespielt werden:
| |
|
| |
| System > Config > FortiGuard > AV Definition / VCM Plugins / IPS Definition > ....via Mnaual Update ) [Update]
| |
|
| |
| === Was ist der Hauptunterschied in der Antivirus Funktion zwischen FortiOS 5.0 und 5.2? ===
| |
|
| |
| Unter FortiOS 5.0.x wurde die Antivirus Funktion per Standard im "proxy-based" Modus verwendet (Default Profile). Der Grund war die Performance sowie die Antivirus Datenbank. Sprich unter FortiOS 5.0 konnte im "flow-based" Mode keine "extended" Antivirus Datenbank aus Performance Gründen genutzt werden. Dies bedeutet auch: Unter FortiOS 5.0.x waren im Hintergrund für "proxy-based" und "flow-based* zwei unterschiedliche "Engine's" im Einsatz.Unter FortiOS 5.2 wurde die Performance betreffend "flow-based" Antivirus massiv verbessert sowie viele der Features die unter "proxy-based" zur Verfügung stehen, können nun auch im "flow-based" benutzt werden. Der Grund dafür ist einfach: Unter FortiOS 5.2.x gibt es "nicht" mehr zwei Engines dh. für "proxy-based" und "flow-based" sondern die Antivirus Engine unter 5.2.x benützt die gleiche Engine und diese unterstützt "proxy-based" und/oder "flow-based". Unter FortiOS 5.0.x war es so, dass Archive nicht entpackt werden konnten und somit gescannt werden konnte da unter FortiOS 5.0 "flow-based" (seperate Antivirus Engine in FortiOS 5.0.x) das "ende" des Files nicht erkannt hat. Dies wurde unter FortiOS 5.2.x geändert und "flow-based" erkennt nun das "ende" eines Files und kann somit dieses -zB als Archive- entpacken und Scannen da für "proxy-based" und/oder "flow-based" die "gleiche" Antivirus Engine benutzt wird. Zusätzlich zu den genannten Neuerungen kann nun unter FortiOS 5.2.x und "flow-based" ebenfalls mit der "extended" Antivirus Datenbank benutzt werden, was unter FortiOS 5.0.x nicht möglich war (Performance Gründe). Aus diesen verschiedenen Verbesserungen sind die per Standard existierenden Profile's unter FortiOS 5.2 "flow-based" und nicht mehr "proxy-based". Neu unter FortiOS 5.2.x kann "flow-based" im Sniffer Mode benutzt werden.
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Weitere wichtige Informationen betreffend unterstützter Formate sowie Zusatzinformationen siehe nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Welche_.22compressed.22_Formate_werden_f.C3.BCr_die_Antivirus_Engine_auf_einer_FortiGate_unterst.C3.BCtzt.3F]]
| |
|
| |
| === Welche "compressed" Formate werden für die Antivirus Engine auf einer FortiGate unterstützt? ===
| |
|
| |
| Wenn es um die "Antivirus Engine" geht für eine FortiGate stellt sich zuerst die Frage "Welche" Version eingesetzt wird. Der Grund siehe nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Was_ist_der_Hauptunterschied_in_der_Antivirus_Funktion_zwischen_FortiOS_5.0_und_5.2.3F]]
| |
|
| |
| Nachfolgendes Dokument "official released" 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 (Auszug aus dem Dokument):
| |
|
| |
| '''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
| |
|
| |
| === Wie kann ich die "Extreme Virus Database" für die Antivirus Funktion aktivieren? ===
| |
|
| |
| Nun die "Standard Datenbank" (normal) einer FortiGate für die Antivirus Funktion enthält Virendefinitions die "comment" sind dh. alte "legacy" Virendefinitionen sind nicht mehr enthalten. Diese "legacy" Virendefinitionen stellen im normal Fall keine Gefahr mehr da denn diese nützen Lücken und Security Vulnaribility aus für "alte" Betriebssystem und zB Browser. Dies bedeutet: Um die Grösse der Virendefinitionen-Datenbank klein zu halten werden sollte "legacy" Definitionen von der Datenbank entfernt da die Gefahr einer Infizierung minimal ist. Um in einem Umfeld mit hohen Ansprüchen dennoch die vollständige Datenbank (inkl. "legacy") zu benützen aktiviere diese vollständige Datenbank auf der CLI folgendermassen:
| |
|
| |
| # config antivirus settings
| |
| # set default-db extrem
| |
| # end
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Diese Funktion sollten nur dann genützt werden wenn die entsprechenden Resourcen auf
| |
| einer FortiGate auch vorhanden sind! Es stehen grundsätzlich -ausser auf kleineren Geräten-
| |
| folgende Optionen zur Verfügung:
| |
|
| |
| [extended | extreme | normal]
| |
|
| |
| Wenn die Antivirus Funktion unter FortiOS 5.0 im "flow-based" Mode betrieben wird, ist es
| |
| aus "Performance" Gründen nicht möglich die "extreme" Datenbank zu aktivieren. Da die Antivrus
| |
| Funktion unter FortiOS 5.2 massive verbessert wurd ist dies nun möglich. Weitere Informationen
| |
| finden man im folgenden Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Was_ist_der_Hauptunterschied_in_der_Antivirus_Funktion_zwischen_FortiOS_5.0_und_5.2.3F]]
| |
|
| |
| Nachdem die Konfiguration durchgeführt wurde sollte ein Update ausgeführt werden damit die vollständige Datenbank geladen wird. Dafür führe folgendes durch:
| |
|
| |
| # execute update-now
| |
|
| |
| Nun sollte nach einiger Zeit die Datenbank vollständig auf den neusten Stand sein. Kontrolliere nach einiger Zeit das Datum des letzten Updates um dies zu verifizieren.
| |
|
| |
| === Wie kann ich die "grayware" Erkennung für Antivirus aktivieren? ===
| |
|
| |
| "Grayware" ist die Funktion innerhalb der Antivirus Funktion die "adware" sowie zB "dialer" erkennen kann. Um die "Grayware" Erkennung einzuschalten führe auf der Console folgendes durch:
| |
|
| |
| # config antivirus settings
| |
| # set grayware [enable oder disable]
| |
| # end
| |
|
| |
| === Wie kann ich die Antivirus Database in den gewünschten Modus (extended, extreme, normal) setzen? ===
| |
|
| |
| Die Antivirus Funktion mit Ihren Database Definition kann in 3 vers. Modi gesetzt werden. Diese wären:
| |
|
| |
| extended — 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 Art zu wählen macht nur Sinn in einer "Security" Umgebung!
| |
|
| |
| extreme — Beinhaltet "Wild Virus" sowie der "Zoo Virus". "Zoo-Viruses" sind in den normalen
| |
| Studien nicht mehr aufgeführt da sehr selten. Dies bedeutet diese Art zu wählen
| |
| macht nur Sinn in einer "High Security" Umgebung! Der Unterschied zum "extended"
| |
| Modus ist, dass in der "extrem" ALLE "Zoo Virus" enthalten sind.
| |
|
| |
| normal — Beinhaltet die "Wild Virus" sowie die "üblichen Virus". Für eine "normale" Absicherung
| |
| resp. Abdeckung gegen Virus sollte diese Art benutzt werden.
| |
|
| |
| Um den entsprechenden Modus zu setzen benütze:
| |
|
| |
| # config antivirus settings
| |
| # set default-db [extended | extreme | normal]
| |
| # end
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Unter FortiOS 5.2 wurden betreffend der Antivirus Funktion massive Verbesserungen
| |
| durchgeführt. Weitere Informationen siehe nachfolgenden Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Was_ist_der_Hauptunterschied_in_der_Antivirus_Funktion_zwischen_FortiOS_5.0_und_5.2.3F]]
| |
|
| |
| === Was ist "flow-based" Scanning und welche Vor- und Nachteile sind in diesem Zusammenhang zu berücksichtigen? ===
| |
|
| |
| "Flow-based" Scanning steht im Zusammenhang mit Antivirus, Web Filtering und DLP! Das "proxy" Scanning ist zwar schneller jedoch das "flow-based" Scanning ist Resourcenschonender. Beim "proxy-based" Scanning wird das zu überprüfende File auf dem Proxy Server zwischengespeichert (caching) um das File, wenn es als Ganzes gecached ist, zu überprüfen. Um diese Art dh. "proxy-based" durchzuführen -und weil die Files zuerst als Ganzes gecached werden müssen - wird mehr Memory alloziert dh. Resourcenintensiver. Beim "flow-based" Scanning wird das File als "flow" geprüft. Wie gesagt es wird nicht nicht das ganze File im Gesamten überprüft sonder ein Teil dh. eben nur ein "flow". Dadurch entstehen gewissen Nachteile wie zB ein ZIP File muss zuerst als Gesamtes zur Verfügung stehen (cached) um es zu entpacken und den Inhalt zu überprüfen. Bei einer "flow-based" Konfiguration ist dies nicht möglich da das File nie als Gesamtes zur Verfügung steht. "Flow-based" ist zwar Resourcenschonender jedoch muss folgendes berücksichtigt werden: Wenn Antivirus und DLP als "flow-based" konfiguriert sind jedoch Web Filtering nicht so ist diese Konstellation der Konfiguration NICHT Resourcenschonend da durch das Web Filtering Memory alloziert wird. Dies scheint im ersten Augenblick ein Nachteil zu sein jedoch ist dies nur die halbe Wahrheit denn wenn die Fortigate durch Memory Belastung oder Session Limits ausgelastet ist kann durch die "flow-based" Konfiguration ein Vorteil entstehen um den Device zu entlasten und um zu verhindern, dass eine Fortigate in den "conserve mode" schaltet (stoppen aller "proxy-based" basierenden Scans). Dieser "conserve mode" wird solange aufrecht gehalten bis wieder die nötigen Resourcen zur Verfügung stehen. Mit einer Kombination aus "proxy-based" Basierender Konfigurtion und "flow-based" kann diesem Umstand entgegengetreten werden. Die "flow-based" Konfiguration wird folgendermassen konfiguriert:
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Unter FortiOS 5.2 wurden betreffend der Antivirus Funktion massive Verbesserungen durchgeführt. Dies bedeutet die
| |
| oben erwähnten Umstände stimmen für FortiOS 5.2 nicht mehr für die Antivirus Funktion im "flow-based" Mode. Dies
| |
| bedeutet: Es gibt praktisch keine Einschränkungen mehr. Weitere Informationen siehe nachfolgenden Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Was_ist_der_Hauptunterschied_in_der_Antivirus_Funktion_zwischen_FortiOS_5.0_und_5.2.3F]]
| |
|
| |
| '''Aktivieren von "flow-based" Antivirus Scanning'''
| |
|
| |
| UTM Profiles > AntiVirus > Virus Database
| |
|
| |
| --> Selektiere "Flow-based Virus Database"
| |
|
| |
| '''Aktivieren von flow-based Web Filtering'''
| |
|
| |
| UTM Profiles > Web Filter > [Wähle das entsprechende Profil]
| |
|
| |
| --> Selektiere unter "Inspection Mode" Flow-based
| |
|
| |
| '''ACHTUNG''' "flow-based" Scanning unterstützt KEIN "Web Content Filtering". Wenn der "Inspection Mode"
| |
| auf "flow-based" gesetzt wird so führt die Fortigate für "Content Filtering" proxy Scanning
| |
| durch und für Web Filtering "flow-based"!
| |
|
| |
| '''Aktivieren von "flow-based" DLP'''
| |
|
| |
| UTM Profiles > Data Leak Prevention > [Wähle das entsprechende Profil]
| |
|
| |
| --> Selektiere unter "Inspection Mode" Flow-based Detection
| |
|
| |
| '''ACHTUNG''' Wird unter DLP "Flow-based Detection" aktiviert so gibt es unter diesem Modus KEINE
| |
| "File Grössen Limitierung"!
| |
|
| |
| Desweiteren ist zu berücksichtigen wenn in einer Firewall Policy Rule unter FortiOS 5.2 der Proxy Mode gemischt wird dh. "flow-based" und "proxy-based" und was in so einer Situation gilt. Weitere Informationen dazu siehe nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Welche_.22Security.22_Funktionen_unterst.C3.BCtzt_eine_FortiGate_im_.22flow-based.22_und.2Foder_.22proxy-based.22_Mode.3F]]
| |
|
| |
| === Kennt die Antivirus Funktion einer FortiGate die "Heuristic" und wie kann ich diese aktivieren? ===
| |
|
| |
| Die Antivirus Funktion auf einer FortiGate kennt die sogenannt "Heuristic". Diese kann aktiviert werden ist jedoch per Standard deaktiviert. Um die "Heuristic" Funktion zu aktivieren benütze folgenden Befehl in der CLI:
| |
|
| |
| # config antivirus heuristic
| |
| # set mode [ pass | block | disable]
| |
| # end
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Die Values "pass" sowie "block" bedeuten folgendes:
| |
|
| |
| pass - Enable heuristics but detected files are passed
| |
| block - Enable heuristics and detected files are blocked
| |
|
| |
| === Was bedeutet unter FortiOS 5.2 der Konfigurationspunkt "emulator" in einem Service für ein Antivirus Profile? ===
| |
|
| |
| Im Antivirus Profile für die verschiedenen Service wie zB http, smtp, pop3 usw. existiert eine Option "emulator". Diese Option hat nur Auswirkungen wenn ein Antivirus Profile im Proxy Mode benutzt wird dh. diese Option ist nicht unterstützt für Flow Mode:
| |
|
| |
| # config antivirus heuristic
| |
| # config [Gebe den entsprechenden Service an zB http | ftp | imap | pop3 | smtp | mapi | nttp]
| |
| # set emulator [enable | disable]
| |
| # end
| |
| # end
| |
|
| |
| Diese Option emuliert den Scan basierend auf Win32 und soll dadurch den Durchsatz erhöhen und wird speziell für "malware dedection" benutzt. Es kann jedoch zu Problemen kommen wenn ein File durch die Antivirus Funktion resp. Scan für Malware untersucht wird und in der AV Database keine entsprechende Definition enthalten ist. Dadurch bindet der Scan Prozess überdurschnittlich viele Resourcen und zeigt in machen Fällen eine vorübergehende sehr hohe CPU Auslastung. Ebenso kann es vorkommen das die Session für den Scan nicht korrekt beendet wird (crash). Wenn dies geschieht, markiert die Funktion "emulator" das File mit dem "suspicious flag". Ein Hinweid darauf geben die Informationen für "Suspicious Files" die im Widget unter "Advance Threat Protection Statistics" aufgeführt sind da diese Win32 Emulation Scan enthalten:
| |
|
| |
| Dashboard > Status > [Wähle Widget] > [Aktiviere "Advance Threat Protection Statistics"]
| |
|
| |
| [[Datei:Fortinet-2155.jpg]]
| |
|
| |
| Werden somit zwischenzeitliche "crash" festgestellt oder hohe CPU Last sollte diese Option vorübergehend deaktiviert werden um zu verifizieren ob diese zwischenzeitliche hohe Resourcenbindung für diese Option "emulator" benutzt wird.
| |
|
| |
| === Wie schalte ich für Antivirus auf einer FortiGate das Extended-UTM-Log ein? ===
| |
|
| |
| Im normal Fall werden Antivirus Events im regulären Log geloggt (Traffic Log). Nun möchte man die Event's seperiert in einem Log loggen, kann dies durch das sogenannte "Extended-UTM-Log" (Nur für FortiOS 5.0) erreicht werden. Um dieses "Extended-UTM-Log" zu aktivieren führe folgendes durch:
| |
|
| |
| # config antivirus profile
| |
| # edit [Gebe das entsprechende Profile an]
| |
| # set extended-utm-log [enable | disable]
| |
| # set av-block-log [enable | disable]
| |
| # set av-virus-log [enable | disable]
| |
| # end
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Durch "av-virus-log" wird jeder Scan Vorgang betreffend Antivirus für ein File das gescannt werden
| |
| soll geloggt. Durch "av-block-log" wird ein Log Eintrag erstellt wenn ein Virus Scann Positiv
| |
| abgeschlossen wurde! Die beiden Befehle "av-block-log" sowie "av-virus-log" stehen unter FortiOS 4.3.x
| |
| sowie unter FortiOS 5.0 / 5.2 zur Verfügung jedoch das "Extended-UTM-Log" steht nur unter FortiOS 5 zur
| |
| Verfügung! Weitere Informationen betreffend "Extended-UTM-Log" im Zusammenhang mit FortiOS 5.2 siehe
| |
| nachfolgenden Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_aktiviere_ich_auf_einer_FortiGate_das_.22Extended-UTM-Log.22.3F]]
| |
|
| |
| Sobald diese "Extended-UTM-Log's" wieder zur Verfügung stehn kann unter folgenden Punkt das "UTM Monitoring" aktiviert werden:
| |
|
| |
| System > Admin > Settings > UTM Monitors
| |
|
| |
| Wenn dieser Punkt aktiviert wird erscheint der entsprechende Menüpunkt unter:
| |
|
| |
| UTM Security Profiles > Monitor
| |
|
| |
| Diese Monitore können nur mit Daten abgefüllt werden wenn die "Extended-UTM-Log's" zur Verfügung stehen. Weitere Informationen betreffend "UTM Monitoring" siehe nachfolgenden Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_aktiviere_ich_auf_einer_FortiGate_die_.22UTM_Monitor.22_Funktion.3F]]
| |
|
| |
| === Kann ich betreffend AV Definitions, IPS Definitions oder IPS Engine ein Downgrade durchführen? ===
| |
|
| |
| Grundsätzlich ist dies möglich und wird folgendermassen durchgeführt (FortiOS 4 MR3 sowie 5.0 / 5.2):
| |
|
| |
| # diagnose autoupdate downgrade [enable | disable]
| |
|
| |
| Ueber den Support Bereich auf der Fortinet Seite müssen nun die AV Definition, IPS Definition/Engine manuell runtergeladen werden um ein Downgrade manuell über das Web Gui der FortiGate einspielen zu können:
| |
|
| |
| https://support.fortinet.com/Download/AvNidsDownload.aspx
| |
|
| |
| Um die AV Definition's, IPS Definition etc. manuell über das Web Gui der FortiGate einspielen zu können wähle folgende Position:
| |
|
| |
| System > Config > FortiGuard > AV Definitions / IP Definitons ...via Manual Update) [Update]
| |
|
| |
| Nachdem manuellen installieren der nötigen Files deaktiviere das "autoupdate downgrade":
| |
|
| |
| # diagnose autoupdate downgrade disable
| |
|
| |
| Mit folgenden Kommando kann die Version verifiziert werden:
| |
|
| |
| # diagnose autoupdate versions
| |
|
| |
| Wenn vorübergehend verhindert werden soll das ein Autoupdate wiederum auf eine neue Version durchgeführt werden soll kann das "autoupdate" deaktiviert werden:
| |
|
| |
| # config system autoupdate schedule
| |
| # set status disable
| |
| # end
| |
|
| |
| === Wo finde ich auf der Fortinet Support Seite mehr Informationen betreffend einem bestimmten Virus? ===
| |
|
| |
| Die Antivirus Definition DB von Fortinet resp. FortiGuard beinhaltet unzählig Virus Signaturen und deren Variationen. Um festzustellen ob eine bestimmte Virus Signature in der Antivirus Definition DB enthalten ist oder dessen Variationen gebe auf der folgende Seite den Namen des Virus ein:
| |
|
| |
| '''FortiGuard''' 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 etc.
| |
|
| |
| === Wie kann ich ein nicht "bekannten" Virus zu Fortinet übermitteln, damit die Information in die nächsten AV Definitions aufgenommen werden kann? ===
| |
|
| |
| Wenn ein nicht bekannter Virus zu Fortinet übermittelt werden soll, kann folgender Link dazu benutzt werden die Information resp. das File das den "allfälligen" Virus enthält zu Fortinet zu übermitteln:
| |
|
| |
| http://www.fortiguard.com/antivirus/virus_scanner.html
| |
|
| |
| Möchte man das File einfach mit der neusten zur Verfügung stehenden Antivirus Signature überprüfen gehe auf "Browse". Gebe das entsprechende File an und bestätige mit "Scan". Möchte man das File übermitteln und Feedback erhalten von Fortinet kann im unteren Bereich zusätzlich eine Nachricht definiert werden mit Name, E-Mail Adresse, Subject (zB New Virus found) sowie einer Kurznachricht (zB File delivered includes new Virus which is not recognized by Fortinet Scanner). Nach Angabe des Files (unter Browse) und Eingabe der Informationen benützt man "Scan and Send Message".
| |
|
| |
| [[Datei:Fortinet-838.jpg]]
| |
|
| |
| Eine andere Möglichkeit wäre die neue Funktion der "Sandbox" unter FortiOS 5.0 / 5.2 zu benützen dh. weitere Informationen siehe Artikel:
| |
|
| |
| [[FortiSandbox:FAQ]]
| |
|
| |
| === Was bedeutet im Antivirus Profile die Funktion "Inspect Suspicious Files with FortiGuard Sandbox"? ===
| |
|
| |
| Informationen zur Funktion FortiSandbox siehe nachfolgenden Artikel:
| |
|
| |
| [[FortiSandbox:FAQ]]
| |
|
| |
| === Kann ich über den "MIME" Header eine bestimmte Applikation vom Antivirus Scanning ausschliessen? ===
| |
|
| |
| Ja dies ist möglich und wird nicht direkt über die Antivirus Funktion sondern über den WebFilter "Content-Header" konfiguriert (FortiOS 5.0). Weitere Informationen wie vorgegangen muss um diese Konfiguration durchzuführen siehe folgender Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Wie_kann_ich_innerhalb_eines_WebFilters_einen_bestimmten_.22MIME.22_Type_.28zB_Audio.29_blockieren_.28Content-Header.29.3F]]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Um zB Audio/Video von einem Antivirus Scanning auszunehmen muss dies unter FortiOS 5.0 über die
| |
| "Content Header" Funktion konfiguriert werden. Unter FortiOS 5.2 kann dies über die "Protocol
| |
| Options" durchgeführt werden da dort eine neue Funktion zur Verfügung steht:
| |
|
| |
| # config firewall profile-protocol-options
| |
| # edit [Namen des entsprechenden Profiles
| |
| # set streaming-content-bypass enable
| |
| # end
| |
|
| |
| Diese Option "streaming-content-bypass" ist per Standard aktiviert!
| |
|
| |
| === Wie kann ich eine bestimmte Site/Domain vom Antivirus Scanning ausschliessen? ===
| |
|
| |
| Wenn man eine bestimmte Domaine/Site vom Antivirus Scanning ausschliessen möchte kann dies anhand der Antivirus Funktion nur über eine entsprechende Fireall Policy Rule durchgeführt werden. Dies bedeutet: Würde man folgende Firewall Policy Rule implementieren:
| |
|
| |
| '''Sequenz''' '''Source Interface''' '''Source IP''' '''Destination Interface''' '''Destination IP''' '''Action''' '''Security Profiles'''
| |
|
| |
| 1 internal all wan1 all allow Antivirus Profile
| |
| WebFilter Profile
| |
| Protocol Options
| |
|
| |
| So würde die FortiGate angewiesen alle Sites die im WebFilter als Allow gesetzt sind zu zulassen. Jedoch kann die Seite durch eine andere UTM Funktion wie Antivirus geblockt werden. Um nun zB Hersteller Updates vom Antivirus Scanning auszuschliessen kann oberhalb der bestehenden Rule (Top Down First Match Wins) eine Firewall Policy Rule implementieren werden anhand des FQDN ohne Antivirus Profile:
| |
|
| |
| '''Sequenz''' '''Source Interface''' '''Source IP''' '''Destination Interface''' '''Destination IP''' '''Action''' '''Security Profiles'''
| |
|
| |
| 1 internal all wan1 gr-microsoft.com allow None
| |
|
| |
| 2 internal all wan1 all allow Antivirus Profile
| |
| WebFilter Profile
| |
| Protocol Options
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Durch dieses Konstrukt/Definition in der Firewall Policy wird die FortiGate klar angewiesen für die einzelnen IP's/
| |
| Subnets/Sites/Services das zu tun betreffend Security Profiles was Sinn macht und somit wird durch diese Konfiguration
| |
| ebenfalls die FortiGate betreffend Performance entlastet.
| |
|
| |
| Da wie schon erwähnt in der Firewall Policy "Top Down First Match Wins" gilt wird greift die Sequenz "1" bei einem FQDN (Fully Qulified Domain Name) vor der Sequenz 2 und da auf der Sequenz "1" kein Security Profile implementiert ist wird auch keine Antivirus für den FQDN ausgeführt. Dies ist eine einfach Art FQDN's und/oder auch IP Ranges/Subnets von einer UTM Action auszuschliessen. Es besteht jedoch noch eine andere einfache Variante dies durchzuführen die jedoch in der Firewall Policy in dem Sinne nicht so abgebildet wird dh. diese ist nicht über die Firewall Policy Rule ersichtlich. Um diese Variante anzuwenden muss im WebFilter unter "Web Site Filter" eine FQDN als "exempt" erfasst werden. Nähere Informationen dazu siehe nachfolgender Artikel:
| |
|
| |
| [[FortiGate-5.0-5.2:FAQ#Kann_ich_.C3.BCber_einen_WebFilter_eine_Site.2FDomaine_vom_UTM_Security_Profiles_Action_wie_Antivirus.2C_DLP_usw._ausschliessen.3F]]
| |
|
| |
| === Was bedeutet im Antivirus Profile "Block Connections to Botnet Servers" und kann ich diese Funktion Testen? ===
| |
|
| |
| Im Antivirus Profile sei es im "Proxy und/oder Flow" Mode kann die Position "Block Connections to Botnet Servers" aktiviert werden. Wenn diese Position aktiviert wird, erkennt und blockt die FortiGate Anfragen zu Botnet Servern. Um was es sich genau handelt bei Botnet Servern kann im folgenden Artikel nachgelesen werden:
| |
|
| |
| [[Fortinet:ProduktInfo#Fortinet_Anatomy_of_a_Botnet]]
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Wenn die genannte Position über CLI konfiguriert werden soll so muss folgendes ausgeführt werden:
| |
|
| |
| # config antivirus profile
| |
| # edit [Name des entsprechenden Profiles]
| |
| # set block-botnet-connections [enable | disable]
| |
|
| |
| Für FortiOS 5.2 existiert das Kommando "block-botnet-connections" nicht mehr und wurde ersetzt mit:
| |
|
| |
| # set scan-botnet-connections [monitor | block | disable]
| |
|
| |
| Wenn diese Position aktiviert wird, fragt man sich ob dies auch getestet werden kann? Dies ist möglich dh. man kann Anfragen vom Internen Netz zu bestimmten Botnet Server/IP durchführen und über die FortiGate kontrollieren ob diese Anfragen geblockt wurden. Folgender Link gibt Auskunft über die momentanen bekannten Botnet Server/IP:
| |
|
| |
| https://zeustracker.abuse.ch/blocklist.php
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Man muss berücksichtigen, dass diese Server/IP immerwährend einem Wandel unterzogen sind dh. Server und deren
| |
| IP's werden oft gewechselt. Speziell folgender Link zeigt die aktuelle IP Liste der Server:
| |
|
| |
| https://zeustracker.abuse.ch/blocklist.php?download=ipblocklist
| |
|
| |
| Um somit die Funktion zu testen muss von "Internal" ein Request zu einer der IP's durchgeführt werden. Dieser
| |
| Request muss bei aktivierter Funktion "Block Connections to Botnet Servers" im entsprechenden Antivirus Profile
| |
| sowie dessen Benutzung in der entsprechenden Firewall Policy geblockt werden. Bei einem Test sollte deshalb darauf
| |
| geachtet werden "welche" Firewall Policy (Policy ID) genutzt wird und ob in dieser Firewall Policy das Antivirus
| |
| Profile konfiguriert ist.
| |
|
| |
| === Kann ich das Antivirus Scanning (scanunitd) im Memory anschauen und/oder manipulieren? ===
| |
|
| |
| Der zuständige Prozess für das Antivirus Scanning ist der Deamon "scanunitd". Dieser ist unter folgnden Kommando ersichtlich sofern dieser in Gebrauch ist:
| |
|
| |
| # diagnose sys top 5 20
| |
| Run Time: 0 days, 0 hours and 15 minutes
| |
| 13U, 5S, 82I; 443T, 276F, 78KF
| |
| newcli 100 R < 2.8 4.0
| |
| cmdbsvr 28 D 17.6 1.1
| |
| httpsd 89 S 0.0 4.6
| |
| httpsd 45 S 0.0 4.6
| |
| ipsengine 62 S < 94.6 22.1
| |
| fgfmd 85 S 0.0 4.1
| |
| newcli 97 S < 0.0 4.0
| |
| miglogd 43 S 0.0 4.0
| |
| cw_acd 87 S 0.0 3.8
| |
| '''scanunitd 93 S < 0.0 3.7'''
| |
| '''scanunitd 92 S < 0.0 3.7'''
| |
| forticron 63 S 0.0 3.6
| |
| '''scanunitd 52 S < 0.0 3.4'''
| |
| authd 65 S 0.0 3.4
| |
| merged_daemons 61 S 0.0 3.4
| |
| urlfilter 64 S 0.0 3.4
| |
| quard 80 S 0.0 3.4
| |
| dlpfingerprint 71 S 0.0 3.3
| |
| sqldb 67 S 0.0 3.3
| |
| eap_proxy 83 S 0.0 3.3
| |
|
| |
| Ebenfalls kann der Memorybereich eingesehen werden:
| |
|
| |
| # diagnose sys top-summary
| |
| CPU [|||||||||||||| ] 35.5%
| |
| Mem [||||||||||| ] 29.0% 539M/1839M
| |
| Processes: 20 (running=6 sleeping=84)
| |
|
| |
| PID RSS ^CPU% MEM% FDS TIME+ NAME
| |
| * 28433 18M 35.5 1.0 10 00:04.95 newcli [x2]
| |
| 36 20M 0.0 1.1 11 00:47.30 cmdbsvr
| |
| 39 11M 0.0 0.6 87 00:01.33 zebos_launcher [x12]
| |
| 51 9M 0.0 0.5 11 00:32.22 uploadd
| |
| 52 22M 0.0 1.2 57 00:22.81 miglogd
| |
| 53 9M 0.0 0.5 6 00:00.00 kmiglogd
| |
| 54 25M 0.0 1.4 19 03:03.25 httpsd [x4]
| |
| 57 23M 0.0 1.3 814 00:04.45 proxyd [x6]
| |
| 58 10M 0.0 0.6 8 00:00.28 wad_diskd
| |
| '''59 12M 0.0 0.7 16 00:01.28 scanunitd [x3]'''
| |
| 61 57M 0.0 3.1 18 00:08.57 ipsmonitor [x2]
| |
| 9233 14M 0.0 0.8 26 00:00.89 iked
| |
| 65 9M 0.0 0.5 8 00:00.60 merged_daemons
| |
| 66 9M 0.0 0.5 8 00:00.20 fnbamd
| |
| 67 9M 0.0 0.5 9 00:00.12 fclicense
| |
| 71 10M 0.0 0.6 18 00:00.31 forticron
| |
| 72 9M 0.0 0.5 11 00:00.12 forticldd
| |
| 73 11M 0.0 0.6 18 00:00.18 urlfilter
| |
| 74 12M 0.0 0.7 35 00:04.31 authd
| |
| 75 10M 0.0 0.6 14 00:00.47 fcnacd
| |
|
| |
| Wenn dieser Deamon untersucht werden soll dh. mit debug Methode steht folgendes zur Verfügung:
| |
|
| |
| '''Setze den Debug Filter zurück:'''
| |
|
| |
| # diagnose debug reset
| |
|
| |
| '''Setze einen neuen Debug Filter:'''
| |
|
| |
| # diagnose debug application scanunit -1
| |
|
| |
| '''Aktiviere den Debug Modus mit dem gesetzen Debug Filter:'''
| |
|
| |
| # diagnose debug enable
| |
|
| |
| <span style="color:#ba0c2f">'''NOTE'''</span> Wenn der Deamon "miglogd" neu gestartet werden soll führe folgendes aus:
| |
|
| |
| # diagnose test application scanunit 99
| |
|
| |
| Der "diagnose debug" Befehl ist "persistent" dh. auch wenn ausgeloggt wird läuft dieser im Hintergrund weiter und belastet -je nach Debugging- den Device im hohen Masse. Aus diesem Grund ist es wichtig den Debug wiederum zu "disablen" dh. führe folgendes aus:
| |
| Deaktiviere den Debug Modus:
| |
|
| |
| # diagnose debug disable
| |
|
| |
| '''Setze den Debug Filter zurück:'''
| |
|
| |
| # diagnose debug reset
| |
|
| |
| '''Kontrolliere den Debug Filter ob dieser zurückgesetzt wurde:'''
| |
|
| |
| # diagnose debug info
| |
|
| |
| Unter "config system global" ist es möglich die Anzahl der "scanunit's" zu definieren. Die Voraussetzung dafür ist das es sich um eine FortiGate Modell handelt mit mehreren CPU's. Bei dieser Einstellung -die unter normalen Umständen nicht manipuliert werden sollte- ist vorsicht geboten. Der entsprechende Befehl wäre:
| |
|
| |
| # config system global
| |
| # set scanunit-count [Anzahl der "scanunits"; Standard basierend auf dem Modell/Device]
| |
| # end
| |
|
| |
| Ab FortiOS 5.2.2 wurde ein neues API (Application Program Interface) implementiert das Statistiken zur Verfügung stellt für die "scanunit" resp. den Deamon "scanunitd". Diees API zeigt die Memory Statistik sowie anhand dieses Kommndos können Filter Optionen gesetzt werden um bestimmten Informationen aufzulisten. Folgende Befehle stehen zur Verfügung:
| |
|
| |
| # diagnose sys scanunit stats ?
| |
| list List all statistics.
| |
| all List all statistics.
| |
| clear Clear all statistics.
| |
|
| |
| # diagnose sys scanunit filter ?
| |
| list Display the current filter.
| |
| clear Clear the current filter.
| |
| negate Negate the specified filter parameter.
| |
| vd Index of virtual domain. -1 matches all.
| |
| worker Index of worker. -1 matches all.
| |
|
| |
| # diagnose sys scanunit log filter ?
| |
| list Display the current filter.
| |
| clear Clear the current filter.
| |
| negate Negate the specified filter parameter.
| |
| vd Index of virtual domain. -1 matches all.
| |
| worker Index of worker. -1 matches all.
| |
|
| |
| # diagnose sys scanunit restart
| |
